« 2016年8月 | トップページ | 2016年10月 »

2016年9月

2016/09/25

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事をメモ。
特に主張はなし。

【参考1】
『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

M・アンドリーセン氏が考える2012年--「ソフトウェアが世界を飲み込む」 - CNET Japan

次の5年でソフトウェアが世界を食べつくす。 | リーディング&カンパニー株式会社

(引用開始)
コンピュータ革命から60年、マイクロプロセッサーの発明から40年、そして近代インターネットが興隆してから20年、ソフトウェアによって産業を変革するのに必要な技術の全てが、ようやく実用化され、世界規模で広く提供されるようになった。
(中略)

私の意見では、医療と教育が、次にソフトウェアをベースとした根本的な変革が起きる分野である。
私のベンチャー・キャピタル会社は、これら両方の巨大で重要な産業において、積極的なスタートアップ企業を支援している。
私たちは、これら両産業は、歴史的に見て起業家精神に基づいた変化に対しては非常に抵抗を示してきたが、現在、新しい、ソフトウェアを中心に据えた偉大な起業家達によって、臨界点に達する時期にきていると信じている。

(中略)
あらゆる産業において各社は、ソフトウェア革命がやってきていることを想定する必要がある。
これには、今現在ソフトウェア・ベースである産業も含まれる。Oracle社やMicrosoft社など、既存のソフトウェア大企業ですら、Salesforce.comやAndroid(特にGoogle社が大規模ハンドセット製造会社を保有している世界では)といった新しいソフトウェアの出現によって、自社製品が陳腐化してしまうという危機にますます脅かされている。
(引用終了)

池田信夫 blog : ソフトウェアが世界を食う

(引用開始)
第二は、労働や教育が大きく変わることだ。
これから先進国では、コーディングができるかできないかで収入は桁違いに変わる。
ソフトウェアの使えない労働者は、新興国の単純労働者と競争するしかない。
教育も、つまらない教養科目を教えるより、早い時期からプログラミングを教えたほうがいい。

最後に、ソフトウェアの価値を実現する必要がある。
すでにグーグルやフェイスブックは収益を実現したが、他のソフトウェア企業が資本主義の世界で既存の企業をしのぐ存在になるかどうかは今後の問題だ。
そういうビジネスモデルを開発した者が次の時代の勝者になるだろう。
(引用終了)

【参考2】
ソフトウエア、それが問題だ Software Matters - 日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (2/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (3/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (4/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

(引用開始)
ソフトウエアは物事を変換しうる本質を持つ。
日本のビジネスリーダーはこのことへの理解が遅れていた。
日本の製造業は過去、ソフトウエアの役割を最小化する“ものづくりイデオロギー”によって成功したが、そのことによってソフトウエアをハードウエアのためのものとみなしてしまい、ソフトウエアが新機能、付加価値そして差異化の牽引役であることになかなか気付かない。
(引用終了)

| | コメント (0)

組織論の背後には経済学の概念があるという仮説

組織論の背後には経済学の概念があるという仮説について、ラフなメモ書き。
自分が理解したことを適当に書いただけ。
間違っていたら後で直す。

【0】組織の構造や成長の方向性は、人々の恣意的な意思決定よりも、資源の制約や外聞環境の制約という要因の方が大きいのではないか。
市場経済を前提とする限り、企業は営利組織として売上と利益を確保できなければ、生存理由がない。

ミクロ経済学の根本思想は「市場経済の原理を徹底すれば、世の中の取引や資源は最適化される。無駄がない」という発想。
この発想を組織論に当てはめた場合、どれくらい、組織構造や組織の成長モデルを説明できるか?

【1】チャンドラーモデル、組織は戦略に従う

すぐ分かる経営戦略論: チャンドラーモデル

組織は戦略に従う。そして、戦略は組織に従う。

【経営力強化】組織は戦略に従うのか?|コラム|株式会社 ブレインパートナー

(引用開始)
チャンドラーは企業成長を4つの階層に分類した。
チャンドラーは4段階を経て多角化した製品―市場分野ごとに事業部を作り、事業部制組織が登場した。
これら4段階をチャンドラーモデルという。

1段階:垂直統合戦略を行い、経営資源を蓄積する段階である
    急速に増加した需要を満たすために行う

2段階:経営資源を能率的かつ有効に活用するための組織を作る段階
    各諸資源を「組織」として有効に活用する

3段階:多角化戦略を行う新たな成長段階
    成熟による発展の限界から経営資源を有益に転用する

4段階:経営資源の運用の合理化とさらなる成長のために組織を革新していく段階
(引用終了)

普通の企業は事業部制モデル。
でも、事業部制組織の中身を見ると、機能別組織で、工程別・作業別に課が分かれている場合が多い。

たとえば、大企業になるほど、たくさんの機能別組織が作られていて、組織がサイロ化され、局所最適化されて、全体最適になっていない。

一方、ベンチャー企業や中小企業は、小さな有機的チームから始まる。
しかし、じきに経営資源を効率的に配分するために、管理的な組織構造が必要になってくる。
さらに発展すれば、事業が増えるので、多角化戦略を取り、事業別組織が形成される。

おそらく、チャンドラーモデルのような組織の成長モデルは、経営資源の制約と効率的な配分の考えで発生するのだろうと思う。
ミクロ経済学のパレート最適などが使えないか。

【2】資源依存モデル

資源依存論

資源依存型経営戦略理論 Resource Based Theory || INVENIO LEADERSHIP INSIGHT

組織に不足している資源を獲得するため組織間関係が形成される。

資源依存そのものから回避⇒「代替的取引関係の開発」「多角化」
資源依存関係を認めつつ他組織からの影響を小さくする⇒「交渉」「包摂」「結託」「所有」

たとえば、「他の組織と「結託」し対抗⇒業界標準やカルテル⇒独占経済⇒独占禁止法」につながる。
そもそも、独占禁止法という法律は、ミクロ経済学の市場独占・寡占の理論を理由として成り立っている。

【3】取引コストモデル、機会主義的行動

取引費用とロナルド・コース

取引コスト理論(1) - toraponの部屋

取引コスト理論(2) - toraponの部屋

内外作問題 - toraponの部屋

取引が市場で行われた時(外注)よりも組織で行われた時(内作)の方が取引コストが少ない場合に組織間関係が形成される。
大企業は、自社内の作業をビジネス化して、子会社としてたくさん作り、垂直的なビジネスモデルを形成しやすい。
連結決算を考えると、自社内で経営資源を広く持った方が売上高を大きく見せやすいはず。

一方、中小企業は経営資源が少ないので、全ての作業や工程を自社で持つのはコスト高なので、アウトソーシングする。
いわゆる内外作問題に通じる。

取引コストモデルでよく出るのは、ミクロ経済学の「コースの定理」。
コースの定理は「取引費用がないと仮定した時、権利の配分がどうあろうと、それはパレート最適な資源配分に影響しない」。
取引費用がゼロの場合には、所有権を法がどのように割り振ろうとも、私的交渉を通じて効率的な利用が達成される。
つまり、取引には取引費用なるコストが必要であり、そのために取引費用を節約する方向で組織が編成される。

すなわち、取引はできるだけ市場経済の環境で行えば、自然に最適化されるはずという理論。
しかし、実際は、公害のような外部不経済では通用しない。

機会主義的行動とは、一定の原理や原則よりも変化する状況に応じて行動すること。
取引コストに関する「情報の非対称性」が原因で、機会主義的行動を冗長する。
たとえば、20代のスキルのある会社員はお金などを動機として転職しやすいが、40代のスキルのない会社員は会社にとってコスト高なののに、会社にしがみつくしかない。

「情報の非対称性」はミクロ経済学の「レモン市場」などにある。

情報の非対称性として、逆選択、モラルハザードがある。
たとえば、プリンシパル・エージェンシー理論は「情報の格差や利害の不一致が存在するプリンシパル(依頼人)とエージェント(代理人)との関係」。
プリンシパル・エージェンシー理論は、株主と経営者の関係でよく使われる。

【4】組織エコロジー理論(個体群生態学モデル)

個体群生態学モデル - 企業経営理論の問題 | パワーアシストロボット、医療機器のLAP 平野 淳 のブログ - 楽天ブログ

移動障壁と戦略グループとは?|E.M.ポーターの競争戦略論 | FOOLINE

ダーウィンの自然淘汰説のアナロジーの組織論。
前提として、「組織慣性がある」「環境による影響が大きい」という仮定がある。
結論は、「新」形態の組織が環境選択で残る。

例えば、ある成功した企業の組織形態を、他の多くの企業が正当性を獲得するために模倣することを通じて、組織個体群に含まれる企業の組織形態は類似する傾向がある。
つまり、ポーターの「戦略グループ」につながる。

戦略グループの形成の流れは、「成功 ⇒ 模倣 ⇒ 業界内の組織形態が類似する ⇒ 戦略グループの形成」みたいな感じ。
たとえば、清涼飲料水、ビール、お菓子、携帯電話、スマホなどの業界。

すると、ある製品分野の生産のために垂直統合を強めると、企業の生産体制や製品ラインは似通ってくる為、戦略グループが生まれやすくなる。
戦略グループに分化された業界では、参入障壁、撤退障壁よりも、移動障壁が高くなりがち。

この考えは、ミクロ経済学の「完全市場の長期均衡」で説明できるはず。

【5】ガルブレイスの情報処理モデル(情報プロセシング・モデル)

ガルブレイスモデル: DCT LIVe

組織は、不確実性(Uncertainty)を情報処理して減らす活動を行う機構であり、必要な情報の創造及び獲得活動である。
不確実性とは、ある問題を解決するために必要な情報量と組織が保有している情報量の差である。
組織の情報処理能力は、組織および経営の中核的能力である。
結果として、組織設計の戦略は情報処理能力の強化を目的にしなければならない。

つまり、組織とは、情報処理機構ないし情報処理モデルとみなせる。

たとえば、不安定な環境下では不確実性が高いために、「専門職的な有機的管理システム」により情報処理する能力を増幅することが有効である。
一方、安定した環境下では「官僚制的な機械的管理システム」が有効である。

情報処理モデルでは、「情報処理量の削減 ⇒ スラック資源の捻出、自己充足タスクの形成」「情報処理能力の拡大 ⇒ 垂直的情報システムの強化、水平的関係の形成」の二つの対策の傾向がよく見られる。

つまり、不確実性に対処できた組織のみが、利益を取れる。
また、情報の不確実性は時間とともに解決する場合が多いので、情報処理のスピードも重要。

【6】野中の自己組織化モデル

組織研究に自己生産理論を導入する目的|わかりやすい自己生産

「組織は、多様性を削減して均衡を達成するというよりも、むしろ主体的に多様性を増幅させ、既存の思考・行動様式を破壊し、新たな思考・行動様式を創造することによって進化する」。
SECIモデルとか。

【7】組織ライフサイクルモデル

チームビルディングに組織のライフサイクル理論を使う|プロジェクトマネジメント実践

すぐ分かる経営戦略論: 組織ライフサイクルモデル

組織のライフサイクルモデル①: 人事労務アドバイザー!

(引用開始)
組織の成長には、以下の4つの段階があるという理論です。

①起業家段階
②共同体段階
③公式化段階
④精巧化段階

有期的とは言え、プロジェクトチームも組織のひとつですから、この4つの段階に準じて成長します。
(引用終了)

組織ライフサイクルモデルは、チームのライフサイクルモデルにも似ている。

他に、グレイナーの企業成長モデルもある。
グレイナーの企業成長モデルは、ベンチャー企業の成長の過程にそっくりそのまま使えると思う。

組織成長モデル「グライナー・モデル」のメモ: プログラマの思索

グレイナーの企業成長モデル - すべてが学びと思えたら

組織の成長過程は、組織内の資源の制約、外部環境からの制約によって、方向性が限定される。
その背後には、ミクロ経済学の諸理論で説明できるはずと思う。

【9】上記の経営理論と経済学の理論と比較検討してみると、巷で言われている経営戦略論とか、組織論の話の正当性は経済学の理論を使って説明しているのではないか、と想像する。
そうでなければ、経営戦略や組織論という理論の再現性がないから。

実際、ポーターの競争戦略や戦略グループ、コトラーの競争地位戦略のような経営戦略論は、ミクロ経済学の理論で説明できるはずと思う。
また、取引コストモデルは、情報の非対称性やコースの定理などの経済学の理論を背景として持っている。
たぶん、マーケティング理論も同様のはず。

ポーターの競争戦略理論<経営と情報(経営情報システム)<Web教材<木暮仁

競争地位戦略 - マーケティングWiki ~マーケティング用語集~

したがって、経済学の理論を背景に持つ経営戦略論や組織論は、反論に強く、理論的に頑健なのだろうと推測する。
つまり、学者の思いつきのような、一過性の説明ではなく、たくさんの具体例や堅固な理論を元に作られた経営戦略論なわけだ。

一方、経済学の理論を一通り知っておけば、ネット上に流れる経営戦略論や組織論がエセ的な話なのか、正当性のある話なのか、という見極めができるはずだ。

| | コメント (0)

2016/09/23

ソフトウェア開発でバグ管理はなぜ必要なのか

「品質・バグ管理はなぜ必要なのか」という質問があって、回答が面白かったのでメモ。
以下は、深く考えずにラフなメモ書き。

【参考】
Redmine - 品質・バグ管理の必要性についてご意見をお聞かせください。(10612)|teratail

BTSを制する者がソフトウェア開発を制する: プログラマの思索

akipiiさんのツイート: "数人の回答が面白い。僕なら「BTSを制する者がソフトウェア開発を制する」という言葉で回答するかな。「品質・バグ管理の必要性についてご意見をお聞かせください。故障票などに記載(Redmine的なものです)」 https://t.co/L5LKK7hDEd #teratail"

【1】(引用開始)
タイトル通りですが、品質管理・バグ管理の必要性について質問させてください。
個人的には、「100%必要ない!」とは思っていませんが、厳重に管理したバグ票やらを必死に分析して最終的に何に使うのでしょうか?
(中略)

例えば、「あるexceptionによるシステムエラー」が起きたとしたら
1.なぜバグが起きたのか?
→exceptionをキャッチしていない
2.なぜcatch文をいれていないのか?
→設計書から見落とした
3.なぜ見落としたのか?
→凡ミス
4.なぜ凡ミスが起きたか?
→疲れていた、作業効率の低下、特に理由なし

ここで最後の回答をしたところで、管理者は「なるほど、気をつけて」としか言いようが無いし、作業者としても「疲れていた」とは言いにくいものもあります。
バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか?
それより、さっさと改修しても良い気もします。
一つの現場だけでなく、だいたいどの現場も同じ漢字なので不思議です。
(引用終了)

ソフトウェア開発でバグ管理が重要な理由は、障害管理のプロセスがソフトウェア開発の全てのプロセスの根幹をなすからだ。
つまり、BTSを使いこなす者はソフトウェア開発を制する。
以前、Blogにその考えは書いた。

BTSを制する者がソフトウェア開発を制する: プログラマの思索

Bugzilla、MantisからTrac、Redmine、Jiraに至るまでのBTSには、世界中のソフトウェア開発者のベストプラクティスが埋め込まれている。
だから、できるだけ最新のBTSに慣れた方がソフトウェア開発のスキルも向上できるはず。

【2】なお、製造業の品質管理とソフトウェアの品質管理は別物とみなした方がいいと最近は思っている。
製造業の立場から見れば、ソフトウェアの品質管理は、正直笑ってしまうぐらいの低レベルと思えてしまうだろう。

製造業の品質管理が知りたいなら、たぶん、QC検定2級レベルの知識を一度見てみればいいと思う。
彼らは、大量生産される工業製品の品質管理を統計学的手法で、細かな部分までコントロールしようとしている。
統計学における仮説検定、相関・回帰分析などが必要とされるので、相当にレベルは高い。

QC検定とは? | 一般財団法人 日本規格協会

QC検定2級って奴 受けてみた - Pass Hunter

製造業の品質管理は、管理図を使って、製品の規格のばらつきを抑えるように、工程や作業を改善するのが王道だと思う。
たとえば、ネジを作っていて、そのネジの大きさや長さにバラつきがあれば、どの作業工程でそのバラつきが発生したのか、どの人が担当するとばらつきが大きいのか、などを細かく突き止め、原因を把握して、作業方法を改善していく。

一方、ソフトウェアの品質管理は、製造業の品質管理を真似ようとして色々試されているが、そのレベルまで到達しているようには思えない。

とは言え、ソフトウェア工学では経験則としていくつか知られている知見はある。
たとえば、人月の法則とかコンウェイの法則、リーマンの法則とか。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

【3】製造業とソフトウェアの品質管理が全く違うように思える理由は、生産プロセスが全く違う観点で存在するからではないかと思う。
製造業は徹頭徹尾、WF型開発のように、生産計画重視で大量生産が王道。

大量に仕入れして原材料費を安く交渉し、大量に販売して売上を大きく稼ぐ。
大量生産するには、見込生産が必要で、そのためには、どの程度の需要があるか、計画段階で決めなければならない。
さらに、大量生産するための土地や工場、機械が必要なので、膨大な額の設備投資という資金も必要。
半導体産業が典型例だろう。

akipiiさんのツイート: "アジャイル開発はソフトウェア開発特有の考え方。製造業とは全く違う。 @koshian: アジャイルもスクラムも日本の製造業から来たものなのになぜ日本始めアジアで普及しないと言われてしまうのか。アジャイルはなぜアジアで普及しないか” https://t.co/2UtpidH2zo"

akipiiさんのツイート: "アジャイル開発が日本で普及しない原因の一つは、予算取りや設備投資の発想にあると思う。製造業は、工場への設備投資で、規模の生産性を生かして、大量に安く作り、市場を独占して先行者利益を得たい。政府も、設備投資は不景気のカンフル剤として有効だから、金利を下げて煽る。"

一方、ソフトウェア開発は、大量生産と言うよりも、個別受注生産して、その製品を長く保守することで売上を確保する。
つまり、ソフトウェア開発プロセスは、ビジネス上も保守プロセスの方が重要なのだ。

そのためには、BTSのように、ソフトウェア保守のために特化したツールが必要で、そんなツールがなければ効率化できない。
ソフトウェアの品質管理が低レベルと言っても、BTSチケットに本番障害を記録していけば、何らかのルールは見出だせる。
また、障害修正のワークフローは、仕様変更や派生開発、新規開発にも拡張できるので、BTSをしっかり運用できる開発チームは、他のプロセスにもすぐに馴染むと思う。
その考えの中に「チケット駆動開発」というアイデアも含まれる。

【4】個人的には、製造業で言われる5S活動(整理・整頓・清掃・清潔・躾)とか、3S(単純化、標準化、 専門化)という概念や活動は、ソフトウェア開発には適さないと思う。

たとえば、製造業の人は「標準化」という言葉が大好きで、確かに、生産プロセスでは標準化活動がすごく効果を持つ。
しかし、ソフトウェア開発に「標準化」という概念を適用しようとすると、すぐに標準化されたプロセスや技術は陳腐化してしまう。
プログラマの創造性を逆に阻害する遠因になりやすい。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

そもそも、メーカーと無関係のソフトウェア企業で、5S活動を社内で推進している所はあるのだろうか?
5Sの順番にも意味がある、とか、3Sの順番にも意味がある、とか、そういうことまで理解して活動しているのだろうか?
少なくとも、日本の製造業の人たちは理解しており、そこまで細かく管理しているが、ソフトウェア企業はそこまでやっているのか?
たぶんやっていないし、創造性が重視される場のソフトウェア開発ではたぶん必要ではないかもしれない。

| | コメント (0)

マルチプロジェクトのWF型開発にはRedmineのどんな機能が必要なのか

Redmineの全てのページに全プロジェクトへのリンクを設置したい要望を見つけたのでメモ。
その要望の背後には、「マルチプロジェクトのWF型開発にはRedmineのどんな機能が必要なのか」という問題があると思う。

【参考】
Redmine - 【Redmine】全てのページに、全プロジェクトへのリンクを設置したい【カスタマイズ】(19566)|teratail

Redmineでヘッダメニューに項目を追加する(View customize plugin) - Enjoy*Study

【1】(引用開始)
■■知りたいこと■■
Redmineの全てのページのヘッダに、全てのサブプロジェクトへワンクリックで飛べるリンクを設置したいです。
このような事が出来るプラグイン、もしくは、redmineのどこのコードを弄ればよいのか、ご教授ください。

■■背景■■
数名で複数プラットフォーム(Web/iOS/Android/Farmware/Server)に跨った開発をしており、
Subversion/Gitとredmineを組み合わせた変更履歴・バージョン管理のセットアップを命じられました。
私自身、新卒で駆け出しのエンジニアであり、redmineの設置は初めてでruby / ruby on railsに触った経験はありません 。

■■問題点と解決したい方向性■■
しかし、実際にはサブプロジェクトは、Farmwareはハードウェアのバージョンアップ毎に3つほど、Serverは機能別に複数あり、
現状10個程のサブプロジェクトが想定され、今後も増えていくと思います。
プロジェクトの移動が煩雑になり、チーム内でredmineの運用に消極的なメンバーが発生する事が懸念されます。そのため、今どのプロジェクト・どのページを閲覧していても、別のプロジェクトへワンクリックで移動できるリンクがあればよいのではないかと考えています。
(引用終了)

上記の質問を読むと、新人SEと言いながらも、質問の内容がとても分かりやすく書かれていて、新人とは思えない。
上記の質問の背景としては、Web/iOS/Android/Farmware/Serverというアーキテクチャごとに複数チームが分かれていて、Redmineでタスク管理とバージョン管理を行いたいらしい。
その時、各プロジェクトから関連するプロジェクトにワンクリックで移動する方法が知りたいらしい。

回答は、ViewCustomizePluginで解決できるでしょう、とのこと。
僕も、この方法が最も簡単で、今後のカスタマイズもやりやすくなるので、お勧めと思う。

(引用開始)
こちらのページで紹介されているプラグインはいかがでしょうか?

Redmineでヘッダメニューに項目を追加する(View customize plugin) - Enjoy*Study

文化を変えていく、というのは難しいですよね。同じようにredmineの教育、運用に苦労しています。

プロジェクトの移動が手間、というのが根本問題になりそうであれば、サブプロジェクトを使わず、対象バージョンやカテゴリなどで種別わけするのも一つの方法かもしれません。共通のカスタムクエリを準備しておけば、移動もワンクリックです。
がんばってください。
(引用終了)

【2】改めて、上記の質問を読んで感じることは、アーキテクチャ別の複数チームがRedmine上でプロジェクト管理したい場合、Redmineにはどんな機能が不足していて、どんな機能を追加すべきなのか、という疑問だ。

たとえば、業務システム開発案件では、画面・帳票・バッチ・インフラのような機能別チーム構成になる。
あるいは、Webサービス開発でも、アプリ・スマホ・デザイナー・インフラのような機能別チームになりやすい。

すると、複数チームを横断した課題管理や障害管理がやりたくなるし、隣のチームに課題の解決を依頼したり、バグ対応の依頼を受けたりすることも多くなる。
つまり、チーム横断の課題・障害について、優先順位を決めたり、リソース配分を行うと言った、意思決定プロセスが必要になってくる。
その意思決定プロセスを支援する機能がRedmineにあるか?

複数プロジェクト機能、チケットの階層化機能を使えば、原理的にはRedmineで対応可能だ。
しかし、Redmineにもっとビューがあればいいな、と思う時もある。

その問題の真因を探ってみると「マルチプロジェクトのWF型開発にはどんな機能が必要なのか」という問題に落ち着くのではないか、と思う。
日本でRedmineをいきなり使いたい、という要望が多い理由は、たぶんこれがあるのではないか。

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

Redmineが日本人好みのツールであるという仮説: プログラマの思索

原理的には、Redmineのプロジェクトとチケットで、プロジェクトに存在するすべての情報は一元管理できる。
残った問題は、蓄積されたデータをどのように表示して、プロジェクトリーダーの意思決定に使えるビューにするか、だと思う。

【3】個人的には、ガントチャートとかんばんの2つの機能を組み合わせれば、ある程度解決できるのではないか、と思う。

【3-1】まず、各タスクの予定・実績は、プロジェクト横断またはプロジェクト個別でガントチャートで見たい。
プロジェクトリーダーとしては、WBSの枚数と個別のWBSの進捗の2つの観点を常にトレースしたいからだ。

一方、各タスクの現時点の状況は、かんばんで一瞥したい。
プロジェクトリーダーとしては、課題や障害をステータス別に見ることで、今どこで作業が滞留しているのか、ボトルネックを把握したいからだ。

たとえば、どこかのステータスでチケットが大量に滞留していれば、そのステータスがボトルネックなので、即対応したい。
一般にレビューで滞留する場合が多い。

【3-2】ガントチャートとかんばんの2つの機能は、WF型開発の観点とアジャイル開発の観点の2つのビューに相当する。
マルチプロジェクトでは、この2つの相反するプロセスのビューが必要であると直感している。
その理由を考えてみた。

【3-3】上記の質問にあるように、日本のソフトウェア開発は、アーキテクチャ別の機能別チームが作られやすい。
すると、機能別チーム単体では、リリースできるソフトウェアを作れないので、チーム間のやり取りがソフトウェアのI/Fを形成し、そこが複雑化し、バグの温床になる。
まさに「アーキテクチャは組織に従う」という事例そのもの。

その内容をそのままRedmineに反映すれば、組織構造がRedmineプロジェクトに反映される。
一般にプロジェクト計画時は、見積時のWBSがそのままチケット化される。
メンバーは、そのチケットに従って作業していく。
だから、ガントチャートでチケットの進捗状況を随時追跡していきたい。

【3-4】しかし、Redmineのサブプロジェクトが機能別チームであったとしても、親プロジェクトは、リリースできるソフトウェアないし開発案件になるので、別の観点では一つの有機体のPJ型チームを形成する。

今まで、メールや電話、打合せで、チーム間のやり取りが非公式に行われていただろう。
Redmineが導入されると、そのやり取りが全てチケット化されて、公式なやり取りとして全メンバーに公開されて、ペアプログラミングしているような雰囲気になる。
おそらく、プロジェクト後半には、障害や課題のように、メンバー一人が解決できるような作業は少なくなるはずだ。

すると、複数メンバーで問題解決していくタイプのチケットは、かんばんのようなステータス別チケット集計画面で、状況を把握したくなる。
普通は、レビュー担当やテスト担当、承認担当のように、ステータスごとにメンバーが固定されている場合が多いから。
どこでボトルネックになっているか、チケットが毎日スムーズに流れているか、フローとして見たい時に、かんばんはとても有効だ。

【3-5】換言すれば、ガントチャートは「全体の進捗」のスナップショット、かんばんは「チケットのやり取り」のスナップショットではないか。

【4】Redmineでは、ガントバーの赤・緑色の表示で進捗遅延の度合いが分かるし、イナズマ線を引けば、プロジェクトの進捗状況が一目で分かる。
但し、Redmineのデフォルト機能では、ガントバーの予定・実績の区別がないし、ガントチャート画面に担当者が表示されないので、頻繁に改善要望が出る。

一方、Redmineではチケット一覧で、ステータスにグルーピングすれば、かんばんと同等に使える。
但し、Redmineのデフォルト機能には、ビジュアルなかんばんLikeな機能はないので、プラグインを導入すればいい。

一番有名なプラグインは、海外製のRedmineAgilePluginだろう。
機能限定の無償版でも十分に使えるみたい。

Agile - Plugins - Redmine

最近、LyhceeAgileプラグインがリリースされたらしい。
日本で作られているので、こちらを試してもいいかもしれない。

LyhceeAgile | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

【5】そんなことを考えると、もう一つの問題「なぜRedmineのロードマップはもっと活用されないのか」に気づく。

本来は、マイルストーンやリリースバージョンごとの進捗はロードマップで見たい。
プロジェクトリーダーとしては、イテレーション単位の進捗状況やタスクのボリュームを見たいからだ。
つまり、2次開発や保守では、リリース計画そのものになる。
だから、チームのリソースや生産性に応じて、どれくらいのボリュームのチケットがこなせるか、リリースバージョンごとに、チケットの取捨選択を行う。

ロードマップは「イテレーション」のスナップショットなのに、なぜ使われにくいのか?
たぶん、日本のソフトウェア開発がWF型開発に偏っていて、WF型開発に最適化されたソフトウェア組織のために、最初のスコープをがっちり決める開発スタイルで、小刻みにリリースしていく開発スタイルがやりにくい、という状況があるのではないか。

この辺りの問題も考えてみる。

| | コメント (0)

2016/09/21

ドメイン駆動設計の方程式はOO+XP=DDD

増田さんの資料に「OO+XP=DDD」と書かれていて、ああこれだ、と思ったのでメモ。
ドメイン駆動設計に関する素晴らしい資料だと思う。
以下はラフなメモ書き。
特に主張はなし。

「人間の知りたいこと/やりたいことを定義する。内部の実装(データ型と処理手続き)は見せない」
「業務の関心事を抽象データ型として表現する」
「変数名ではなく、「型(クラスとインタフェース)」と「メソッド名」で 意図を表現することを習慣にする」
などの文章がすごく心の琴線に触れた。

業務システムの設計では、まさにユーザの業務、たとえば、発注・販売・請求・入金などの業務のモデリングでも使える。

丁度、法務について勉強していると、法律の内容がすごく分かりにくく感じていて、フラストレーションが溜まっていた。
しかし、上記の資料を読んで、法律の内容はまさにドメインモデル、概念モデルに相当するな、と気づいた。

「AさんがBさんと結んだ金銭貸借消費契約を破って、お金を返さない」「Aさんが、Bさんの財産を勝手に盗んだという不法行為を行った」「AさんがBさんに土地を売ったのに、Cさんにも二重譲渡した。」などの要件事実に対し、法律の要件を当てはめて、誰が権利を主張できるのか、誰の権利を侵害したのか、を導き出す。
その時に、法律の内容は概念モデルであり、クラス、メタモデル。
それぞれの要件事実はインスタンス、オブジェクト図。
話しているレベルが違う。

更に、その内容はできるだけ、人が分かるようなドメインで表現した方が分かりやすい。

但し、ITエンジニアが概念モデルを描こうとすると、どうしてもプログラムぽく、内部の実装処理をイメージしてしまうため、メタモデルにしにくい時が発生するのは注意。

| | コメント (0)

法務脳の作り方part1

法務脳の作り方について、考え方をメモ。
以下は、今の自分の理解と直観で適当に書いているラフなメモ書き。
特に主張はなし。
間違っていたら後で直す。

【1】「法律=要件+効果」。

要件と効果について - 法テラス静岡法律事務所日誌

(引用開始)
たとえば,民法で一番有名な709条は,「故意または過失によって他人の権利又は法律上保護された権利を侵害した者は,これによって生じた損害を賠償する責任を負う。」と規定しています。

これを要件と効果に分類すると

(要件)①他人の権利又は法律上保護された権利を侵害した

    ②前記①が故意または過失によるものであること

(効果) 要件①によって生じた損害の賠償責任(相手方にとっては請求権)が発生したこと。

となります。
今まで起きたことのないような事件が発生したときが起こったとき,リーガルマインドを備えた人は,「誰のどのような権利が侵害されたのか?」「その権利は法律上保護されるのか?」「行為者は権利侵害について予見可能性があったのか?」「どこまでの損害を賠償する責任があるのか?」という観点からアプローチします。
(引用終了)

上記はいわゆる「不法行為に対する損害賠償の請求権」。
「要件=加害者の故意過失による不法行為」を被害者が立証すれば、「損害賠償を請求できる権利が発生する」効果が生まれる。

あえてこの時期に読んでほしい「法学」―「要件」「効果」とは?

(引用開始)
「貸金返還請求権」なんてものは,実際に物体として世の中にあるわけではありません。
裁判官も見たことはありません。
よって,「オレには貸金返還請求権がある」と言っている貸主のことを裁判官がそのまま信じるわけにはいきません(貸主がどんなに信用できそうな顔をしていても)。

そこで出てくるのが,「要件」です。
要件が揃えば効果が発生しますので,貸金返還請求権を裁判所が認めることができます。
その要件が,民事訴訟法で学習する「主要事実(要件事実)」です(主要事実と要件事実の違い〔違いがあるか〕は気にしなくていいです)。
(中略)
前回の記事で「1000万円を返せ」という請求権がある(上記のピラミッドでいえば,1の「請求レベル」)と裁判所に認めてもらうには,法的根拠(2の「法律レベル」)が必要であるとご説明しました。
そのためには要件を充たす必要があり(3の「事実レベル」),要件を充たしていると裁判官に信用してもらうには証拠が必要である(4の「証拠レベル」)とご説明しました。
(引用終了)

【2】ストーリー問題は、法定三段論法で解く。
つまり、ストーリーに出てくる事件(要件事実)に対し、どの法律の要件が当てはまり、どんな効果が得られるのか、を考える。

法的三段論法について|太郎の弁護士ブログ

【3】法律の勉強では「~権」「~の義務」「~の責任」「~の利益」「~の不利益」という言葉はすごく重要なので丸暗記すべき。

権利の反対は、義務。
金銭が絡むと、貸借対照表(BS)をイメージすると分かりやすい。

負債は債権者のモノ、純資産は株主のモノ。
つまり、BSの右側は会社の外の人たちがお金を貸してくれている。
彼らは、リターンが欲しくてお金を貸しているのであり、お人好しではない。
お金が返せないと分かったら、自分の取り分を戻すために、どんな手段を使ってでも取り戻しに来る。
その時に、法律が債権者(と株主)と債務者の双方の権利を守る。

【4】法律特有の概念に慣れるのも一苦労。

法律の資格は、弁護士、行政書士、司法書士、宅建など星の数ほどあるけれど、よく聞かれるパターンはあるらしい。
たとえば、民法なら「不動産の二重譲渡」。
「債権の二重譲渡」も同じ構造。

対抗要件という考え方は特殊。
ややこしい。
明治時代にフランスの民法から対抗要件という考え方を取り入れたために、何となく時代に合っていない気がする。

「善意」「悪意」「過失」などの言葉も、普通の用語とは意味が違うから、初心者は間違いやすい。
下記のBlogがわかりやすい。

民法用語 善意、悪意、有過失、軽過失、重過失をたとえ話にて|fungusticのブログ

法学の「逸失利益」は経済学の「機会損失」と同じ。

「推定」と「みなす」は意味が全く違う。
「みなす」の方が強力。

「みなす」と「推定する」の違い | 法律事務転職キャリアNET

「証明」と「疎明」も違う。

証明と疎明(ショウメイ/ソメイ)とは - コトバンク

| | コメント (0)

2016/09/17

技術の背後に数学の理論があると廃れない

最近考えていることをラフなメモ書き。
特に主張はなし。

【1】最近、IOTや自動運転の技術が注目されているが、それら技術はもうすぐ廃れるのだろうか?と考える時がある。
今までも、IT業界では数多くのバズワードが生まれては消えていった。

でも、たぶん廃れない技術であり、今後も発展していくだろうと思う。
理由は、その背後に、ベイズ推定という統計学の理論があるから。

統計学の検定、ベイズ推定の考え方は、既に20世紀に理論化されていた。
しかし、膨大な計算が必要なために、コンピュータのない時代には手計算でやれる範囲が限られていて、本来の力を発揮できなかった。
でも、今は、プログラミングによる強力な計算機能のおかげで、検定処理がすごく楽になった。
たとえば、販売予測や購買分析などのマーケティングは、プログラミング経験がある人ならば、ちょっと統計学の知識をマスターすれば、R言語を使って即座に仮説検証ができてしまう。

統計解析向けのプログラミング言語「R言語」の魅力と汎用言語との違い | Think IT(シンクイット)では、こんな文章がある。

(引用開始)
私がR言語を習得した時の印象としてはアソシエーション分析が簡単にできることが衝撃的でした。
アソシエーション分析とは、コンビニエンスストアや百貨店や店舗などで集めている顧客ごとの購買商品データを活用して、購買された商品の関連性について分析する手法です。
例えば、雨の日に購買された商品Aを購入した顧客は商品Bを同時に購入される割合が何%であるといったような感じで、分析することを指しています。
コンビニエンスストアや百貨店では、如何に店舗を有効に活用するかがとても重要であり、どの商品をどういうときに、どこに陳列するかなどを分析していく必要があります。
R言語の独自性(クセ)を理解し、関数を知ることができると、このアソシエーション分析も簡単な関数で行うことができるようになるのです。

R言語を習得すると、このような分析も試行錯誤しながら進めていくことができるようになるのです。
統計学をかじったことがある人でしたらどなたでも分かりますが、数値をどのように分析するか、どのように導き出すかは、分析者のセンスにもよりますし、ベストプラクティスに至るまでかなりの試行錯誤を繰り返すはずです。
まさにR言語はそのような試行錯誤に適した専用言語なのです。
(引用終了)

統計学の知識とR言語さえあれば、ECサイトにおける広告の最適化、とか、見込み客に対する営業活動の効率化、とか、勉強会のアンケート結果から因子分析、とか、本番システムのシステムログや本番障害データからアソシエーション分析で障害が発生しやすいルールを検出、など、色んな場面に適用できる。

数学の理論が確固としてあれば、その技術はもっと飛躍できる可能性が高い。
自分のアイデアをプログラミングできる能力さえあれば、色んな状況に適用していけばいい。

統計学の理論のように、理論が生まれた当時は計算力不足の環境でその威力が限定されていたが、コンピューティングパワーの発達によって、その理論の本来の可能性が具体化されたわけだ。

【2】そのような事象は、他の技術でも見受けられる。
たとえば、RDBやデータモデリングは、1970年代に集合理論を元に作られて発達してきた。

達人に学ぶSQL徹底指南書」によれば、コッドは「関係計算を定義したこと」「関係代数を定義したこと」「DB操作の基礎に1階の述語論理を適用したこと」の3つを成し遂げたという。
そこから、「データは命題である」という発想はすごいことではないだろうか。
RDBに格納すれば、そのデータは業務の状況や業務のロジックを表しているのだ。

だから、オブジェクト指向プログラミング言語が全盛の今でも、RDBはミッションクリティカルな技術として残り続けている。
RDBと数学の理論を背景として持っているから、SQLもどんどん拡張できているし、数多くの業務にも適用できている。
NoSQLや非RDBの技術が今後流行したとしても、RDBが廃れることはないだろう。

【3】Redmineにおけるチケット駆動開発も、単純なアイデアではあるが、その背景には、ソフトウェア工学・PMBOK・ITILのような理論が存在する。
また、品質管理、進捗管理だけでなく、CRMやBPMなどのツールにも関連する。
つまり、ソフトウェア工学のような理論や、数多くの具体的な事例が背景に連なっているので、そう簡単に廃れることはないだろうと直感している。

たぶん、他の技術でも背後の数学の理論やソフトウェア工学の理論が隠れているものがあると思うし、そういう技術がどのように生まれ、今後どのように発展していくのか、を見てみたいと思う。

| | コメント (0)

2016/09/15

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる

Redmineが日本人好みのツールであるという仮説について、考えていることをラフなメモ書き。

akipiiさんのツイート: "Redmine はアジャイル開発よりもWF型開発に向いているから日本で流行している仮設あり。RT @vvakame: 他人をこき使うにはGitHubよりRedmineのほうが適しているのではないかという着想を得た"

akipiiさんのツイート: "@makopy_inside 分かります。Redmineのようなチケット管理ツール は本来はアジャイル開発に向いているのに、日本ではWF型開発の仕組みに取り入れられてる。原因を調べたい。"

akipiiさんのツイート: "@makopy_inside 発注者、受注側元請け企業、下請けPGの観点でそれぞれの事情がよく分かります。ソフトウェア開発がコモディティ化した現在、Redmineのようなチケット管理ツールで作業内容をやり取りしたい動機が多くなっている状況なのでしょう。そこにWF型開発があるみたい"

【1】Redmineが日本で普及しているのはなぜなのだろうか?
実際、世界で見れば、RedmineはTracの人気度にも及ばないらしい。
世界では、日本以外に、ロシア、韓国、台湾、チェコなど世界の東側でよく使われているらしい。

【1-1】「Redmineが日本人好みのツールである」という仮説については、以前書いた。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

理由は下記の3つがあると思う。

(1)Redmineはライセンスが無料であり、導入や設置が簡単で、保守工数だけで十分であること
 日本のIT企業やソフトウェア開発の現場では、開発基盤にコストを払ってもいいという認識はないから。

(2)パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれていて、自社の開発プロセスにフィットしないから。
 「Redmineは組織の戦略に従う」「Redmineを組織構造や開発プロセスに従わせる」ことがやりやすいから。
 日本人は、ERPにせよ業務システムにせよ、自社の組織や業務に沿った仕様へカスタマイズしたい動機が強すぎる。
 特に、日本人の帳票レイアウトへのこだわりは尋常ではない。

(3)自分たちで機能拡張していく機運が生まれて、現場主導で業務を効率化していこうとする動機づけを強化してくれること。
 つまり「カイゼン」が自主的に生まれやすいこと。
 日本人はラディカルイノベーションよりもプロセス・イノベーション、持続的イノベーションの方が得意であり、Redmineはその気質に向いているツールである。

【2】Twitterでのやり取りでもう一つの仮説を思いついた。
それは「Redmineはアジャイル開発よりもWF型開発に向いているツールだから、日本の現場で適用しやすいのではないか」という仮説。

akipiiさんのツイート: "「JiraよりもRedmineの方がWF型開発に向いている」という仮説があるのか。 https://t.co/JLeLaXVYX7"

akipiiさんのツイート: "Redmine はアジャイル開発よりもWF型開発に向いているから日本で流行している仮設あり。RT @vvakame: 他人をこき使うにはGitHubよりRedmineのほうが適しているのではないかという着想を得た"

僕はそもそも、Redmineはアジャイル開発の作業管理に非常に向いていると気付いて、その裏にはチケット駆動開発という開発プロセスがあるのではないか、と思っていた。
しかし、日本の実際の開発現場は、ほとんどがWF型開発が主流のはずだ。

色んな人の話を聞くと、Redmineを使ってみたい理由は、いくつかある。

【2-1】一つは、ガントチャートがデフォルト機能であること、チケットの階層化でWBSを表現できることにあるみたい。
つまり、MSProjectやExcelのガントチャートをRedmineでWebで表現して共有できることにメリットを感じているみたい。

以前は、チケットを階層化した場合、親チケットの開始日・期日・進捗率・予定工数は、子チケットの属性値を自動で集計してしまうために使いづらい、という声があった。
本来は、WBSの100%ルールにより、親チケットは子チケットをロールアップすべきなのだが、実際の運用では、試行錯誤しながら階層化したい場合が多く、当初入力していた予定期間や予定工数が、子チケットを作った時点で消えてしまうのが使いづらい、と言われていた。
しかし、Ver3以後では、親チケットは「子チケットから独立」の設定が可能になったので、この点もクリアされている。

Redmineの親チケットの値に子チケットをロールアップさせない設定方法: プログラマの思索

特に昨今、オフショア開発やニアショア開発が普通になってきているので、オフショアチームや社外のベンダーと障害だけでなく、課題や作業の情報を共有したい場合、Webアプリでやりたい動機がある。
その時に、Redmineを導入すれば、ライセンスが無料だし、仮想サーバーにBitnamiを入れればすぐに稼働でき、ガントチャート画面上で進捗状況を即座に把握できる。
その時に、WBSの修正や操作は、直感的に気軽にやりたいニーズがある。

SIだけでなくメーカーでも、そのようなニーズがあるのだから、日本でもRedmineが相当に使われているのではないか、と思う。

【2-2】もう一つは、複数プロジェクト機能があるので、大規模な作業管理にも適用しやすく、派生開発やプロダクトラインのような製品ファミリーの並行開発にも向いている点だろう。

プロジェクトの階層化によって、複数プロジェクトの案件を横串で集計できるし、一つの案件で複数チームの作業管理を子プロジェクトで分割統治できる。
Redmineは本来は少人数のタスク管理に向いたツールだが、プロジェクトの階層化機能を使えば、100人月規模のタスク管理にも使えるだろうと思う。

SIで大規模な開発案件でタスク管理を共有したい場合はあるし、最近は新規開発よりもソフトウェア保守や派生開発の方が案件が多い。
だからこそ、気軽にプロジェクトをたくさん作れて、作業規模が大きくなっても管理したいニーズがあるのだろう。

その場合、Redmine上の組織構造としてはマトリクス型組織になるだろう。
すなわち、製品ラインと機能・職種というラインのマトリクスで、タスクと作業者が各プロジェクトにアサインされるので、メンバーは作業の役割を認識しやすくなるし、作業負荷も担当チケット数で把握しやすくなるメリットが出てくる。

【3】他には、日本企業の組織構造が機能別組織に偏っているため、Redmineを取り入れるとプロジェクト型組織の雰囲気が出てきて、組織が活性化するという点があるのではないか、と思う。

日本ではWF型開発が主流である理由の一つは、組織体制がWF型開発に最適化している環境になっていて、おそらく機能別組織のような縦割り組織が主流だからではないか、と思う。
しかし、機能別組織でも、Redmineを導入すると、体制上はPJ型チームになり、一つの有機的なチームが形成されやすい利点がある。

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

他に、IOT案件のように、ハードウェアチーム・ソフトウェアチーム・サポートチームのように気質が違う複数チームでやり取りしたい場合もある。
その場合、機能別組織に複数プロジェクト機能を対応付けて、それぞれのレイヤーで作業をチケット化して、管理する方がチケットの粒度もまとめやすいし、プロジェクトごとにチケット管理の特徴を出しやすい。

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい: プログラマの思索

すなわち、古い日本企業の組織構造にRedmineを取り入れると、当初は想定しなかったメリット、つまりPJ型組織やマトリクス型組織の雰囲気が出てくる点があるのではないか。
一方、既にアジャイルな開発組織の場合、PJ型組織やマトリクス型組織をツール上に作る必然性はないので、Redmineを使うメリットがそう感じられないという点もあるのではないか。

つまり、Redmineにガントチャート機能があるから、という単純な理由よりも、日本の硬い組織構造をRedmineが柔らかくしてくれる所にメリットがあるような気がしている。
そうであれば、Redmineを組織変革のためのツールとして使えないか、と思ったりもする。
色々考えてみたい。

【追記】こんな意見もあり。

まいく@定時に帰りたいさんのツイート: "時代はScrumだJIRA使うぞー!って感じでJIRA導入したけど我々が本当にやりたかったのはマルチプロジェクトのWFだということが分かりRedmineにしたい"

| | コメント (0)

OSSのMSProjectクローンProjectLibreの使い方

OSSのMSProjectクローンProjectLibreの使い方に関するWebページを見つけたのでメモ。

【参考1】
ProjectLibreのインストールと使い方、基礎、入門 - SEO対策 大阪

OSSのMSProjectクローンProjectLibre: プログラマの思索

づめメモ Projectlibreで日付の書式を変える方法

MS Projectの基準計画の使い道: プログラマの思索

ProjectLibreを使ってみたら、MSProjectとほぼおなじアプリと考えていい感じだ。
実際、ProjectLibreでガントチャートをXML出力すれば、MSProjectで読み込んで開ける。
つまり、プロジェクトリーダーはMSProject、MSProjectのライセンスを持たないユーザはProjectLibreで使い分ける、という運用は可能だ。

僕が使う操作はこんな感じ。

ExcelでWBS、予定工数、担当者を作る

ProjectLibreにプロジェクトを新規作成

ProjectLibreのガントチャート画面でWBS、予定工数、担当者をコピペする

ProjectLibreのリソース画面で担当者全員もコピペする

ProjectLibre上で、WBSを階層化する。

ProjectLibre上で、WBSの先行後続関係をマウス操作で付けて、綺麗にして入力完了

MSProjectの最大の利点は、WBSの先行後続関係がマウス操作だけで簡単にできることだろう。
ProjectLibreも同様に、WBSで先行後続関係を結ぶには、先行タスクをドラッグして、矢印線を後続タスクへロドップすればいい。
そうすると、鎖アイコンが表示されて、先行後続関係のリンクが貼られる。

ProjectLibreのガントチャート画面で作業負荷の山崩しをやりたいならば、ビュー>ヒストグラムを画面下部に表示させて、100%以上の負荷のタスクをずらすか、担当を変更すればいい。
この辺りもMSProjectと似たような操作感で簡単にできる。

他に、タスク>更新で実績入力できるし、タスク>ベースライン保存で、基準計画を保存できる。
基準計画の個数も11個あり、MSProjectと全く同じなのが何となく笑える。

MSProjectに慣れたマネージャなら、ProjectLibreは全く問題ないと思う。
但し、無料版ではイナズマ線やクリティカルパスは表示されないので注意。

個人的には、MSProjectにある機能は全てRedmineのガントチャート機能で実現して欲しいと思う。
そうすれば、Redmine上でプロジェクト計画も実績管理も全て一元管理できる。

最近はRedmineのガントチャートを機能拡張した有償プラグインが続々出ているので、取り入れてみたらいいと思う。
たぶんMSProjectのライセンスよりも安いだろうと推測する。

【参考2】
MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part1~Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmineのもう一つのガントチャートプラグインEasyGanttのリンク: プログラマの思索

もう一つのRedmine製パッケージ製品ANKO REDMINE: プログラマの思索

| | コメント (0)

GitHubにかんばんライクなチケット管理機能が付いたらしい

GitHubにかんばんライクなチケット管理機能が付いたらしいのでメモ。

【参考】
[速報]GitHub、かんばんライクな新機能「Projects」発表。GitHub Universe 2016 - Publickey

[速報]GitHub、コードレビューのための新機能を発表。コードの行ごとや課題ごとにコメント可能。GitHub Universe 2016 - Publickey

Chrome Extension - GitHub をより便利にしてくれる『ZenHub』の使い方 | phiary

akipiiさんのツイート: "プルリクできる構成管理とカンバンが使えるタスク管理で十分かもしれない。RT @kyon_mm: なんかわからないけど、RedmineでできることをどんどんGitHubがやっていくのをみていて、おもしろい。そんなもんなんだろうなぁ。みたいな。"

Kさんのツイート: "GitHubにカンバンができたことで、ソフトウェア開発のみに特化した小規模なチームは、RedmineやJIRAやTracやTrelloなどの他のツールで管理する必要がより無くなるのかもしれないなぁ。"

Kさんのツイート: "@Will_meaning インフラ周りやプロジェクト管理としてのRedmineやJIRAなどの利用はまだまだ残ると思います。"

【1】GitHubはやっぱりプルリクエストが気軽にできるのがすごくいい。
ソース管理がソーシャルなやり取りになっているのがいい。
Wikiも使いやすい。

しかし、GitHubはIssue管理がしょぼかった。
タスクがどんどん出てくると、Issueが埋もれてしまうし、タスクのステータスが見えづらい。
チケットのワークフロー、チケット一覧のビュー、チケットの階層化などをやりたくなってくる。
チケット管理で全てのタスクの見通しを良くしたいと思うと、Redmineのチケット管理のような機能が欲しくなってくる。

プルリクエストが使える構成管理と強力なチケット管理の連携機能が欲しいのだ。

GitHubにかんばんのようなIssue管理機能が付けば、Redmineほどの厳格なチケット管理が不要ならば、十分だろうと思う。
今、プロジェクトがどの程度のタスクが滞留していて、今誰がどのIssueを担当しているか、見えれば十分と思う。

【2】チケット駆動開発が当たり前の環境になるまで普及した現在、チケット管理は今後どの方向に進化していくべきか?
僕の直観では、一つはアジャイル開発に適したビューの提供、もう一つは大規模な作業管理に向いたビューの提供だろうと思う。

アジャイル開発に適したビューとして、タスクかんばんとプロダクトバックログの2つがあり、スプリント管理ができて、アジャイル開発で使うメトリクスをリアルタイムに出力する。

一方、大規模な作業管理に向いたビューとしては、MSProjectのように、ガントチャート・リソースヒストグラム・EVMの3つのビューを交互に切り替えて操作できるような機能が欲しい。
さらに、PMBOKやITIL、ソフトウェア工学の観点のビューが付属していればなお良い。

その他に、サポートデスクのCRM、BPMのような事務処理ワークフロー管理の観点のビューもあれば、より汎用的に使えるだろう。
実装上は、入力されたチケットに対し、チケットのビューをRedmineプラグイン化するだけのことだ。

チケットのビューを誰がどんな時に、どんな目的で利用したいのか?

【3】実はRedmineは、日本の利用シーンとしては、アジャイル開発よりもWF型開発に向いているから、日本で普及しているのではないか、という仮説がある。
他の理由については下記に書いた。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

その仮説とも合わせて考えてみたい。

| | コメント (0)

2016/09/12

「関数型プログラミングはオブジェクト指向の正当な後継である」記事のリンク

「関数型プログラミングはオブジェクト指向の正当な後継である」記事が素晴らしいのでリンクしておく。
オブジェクト指向設計の概念で、関数型プログラミングの概念を翻訳できるという指摘が腑に落ちた。

【参考】
関数型プログラミングはオブジェクト指向の正当な後継である - Qiita

「モナドの主な使い方は「保持役(状態役)に暗黙の制御構造を付与すること」になります」という指摘が腑に落ちた。
Haskellでは、Maybeモナドでエラー制御とか、IOモナドで状態を保持する処理で使うけれど、ではモナドとは一体何か、と自分の中で言えなかった。
上記の指摘では、オブジェクトの責務の6個のうち、「保持役」のロールに相当する。

そして、モナドはポリモルフィズムの使い方に似ている、と。

一時期、UMLやオブジェクト指向設計を貪るように乱読した時があったけれど、上記の記事を読むと、その知識は関数型プログラミングでも無駄ではない、という気がしてくる。

| | コメント (0)

2016/09/10

Redmine Wiki ListプラグインでTracのクエリのように使うアイデア

Redmine Wiki ListプラグインでTracのクエリのように使うアイデアをメモ。
特に主張はなし。

【参考】
Redmine Wiki Lists プラグインの使い方メモ - torutkの日記

Wiki ListsプラグインでRedmineをカード型DBと見なしRedmineをCRM化するアイデア: プログラマの思索

Tacのクエリ機能は、Wikiに直接SQLを書いたらその結果を表示できる。
SQLiteのテーブル構造さえ分かれば、そのままSQLを書けばいい。
プロジェクトマネージャなら、障害やQA、残作業の情報をリアルタイムに抽出したい動機があるので、その気になれば自分でSQLを書いてプログラムを書きたい。
顧客や上司に定期的に報告する必要があるからだ。

現状のRedmineでは、それぞれの現場のプロジェクトマネージャが欲しいSQLはバラバラなので、それぞれにカスタマイズできるような仕組みがあると嬉しい。
サマリ機能だけでは不十分。

だから、Redmine Wiki Listプラグインのように、SQLぽく、チケット情報を好きなようにマクロで書ける機能はありがたい。
マクロの記法もそんなに難しくない。

たとえば、チケットの説明欄に書いてもいいし、Wikiに、障害情報・QA情報・残作業情報を書いておいて、リアルタイムに表してもいい。
以前のTracでは、月別の予定工数と実作業工数を出力するために、Tracのクエリを使っていた。
あるいは、進捗報告用のマクロをWikiに貼り付けて、必要な時にチケット一覧を出力してもいい。

Redmine Wiki ListプラグインはDBマイグレーションもなく、配置して再起動するだけで有効になるので、今後のRedmineのバージョンアップでも問題無いだろうと思う。

ほかの使い方も探してみたい。

| | コメント (0)

2016/09/07

2016年8月のRedmineの機能改善に期待できること

最近のRedmineの機能改善に期待できることをメモ。
たぶん、Ver3.4で実現されるだろう。

【参考】
2016年8月のRedmine開発状況 | Redmine.JP Blog

2016年7月のRedmine開発状況 | Redmine.JP Blog

2016年6月のRedmine開発状況 | Redmine.JP Blog

【1】やっと「プロジェクトの設定画面の「バージョン」タブにフィルタ機能を追加」が対応されるようだ。
従来は、バージョンをたくさん作る運用を行うと、チケット一覧やプロジェクト設定画面で大量にバージョンが表示されて扱いづらい問題があった。
下記の記事を以前書いた。

Redmineチケット一覧のフィルタ「対象バージョン」のリストが大量表示されて使いにくい問題点: プログラマの思索

下記の記事では、「毎月10個ぐらいバージョン作成した運用」をすると、「3年運用するとなると、300個以上リストが出てくる」問題があったらしい。

チケット一覧のフィルタ「対象バージョン」のリストから終了したバージョンを表示させない方法 - Google グループ

下記チケットで、Ver3.4で解決されるようだ。

Feature #10412: Target version filter shoud group versions by status - Redmine

Feature #22608: Enable filtering versions on Project -> Settings -> Versions - Redmine

Redmineのバージョンは、使うチームと使わないチームが真っ二つに分かれる機能。
バージョンを使えないチームは、大量のチケットに溺れかけて、タスク管理できない場合が多い。
そもそも、ロードマップ画面がリリース計画作りに使われる、という気づきもないので、チケット管理が雑になりやすい。
この機能改善で、Redmineが更に使いやすくなるに違いない。

【2】興味深いのは、RedmineのTimeTrackingの機能強化だ。
作業時間の画面では、フィルタリングの機能がしょぼいし、検索条件を保存できなかった。
しかし、ようやく、作業時間画面をチケット一覧画面と同じように、クエリで保存できたり、検索条件の種類が多くなることで使い勝手が良くなるようだ。

Redmineには工数管理機能がデフォルトで付いている点に一つの特徴が従来からあった。
チケットに作業の実績工数を残せば、作業時間が一つのDBに蓄積されるので、データを出力すれば好きなように加工して集計できるメリットがあった。
SIならば、作業時間の報告が準委任契約の作業報告書の重要な項目なので、Redmineで作業管理するならば、取得したいメトリクスの一つになるだろう。

しかし、Redmineの画面UIでは、多種多様なフィルタリングができなかったために、せっかく作業時間を登録しても、利用ユーザが便利なビューがないのでメリットを感じにくかった。
WorkTimeプラグインなどの他プラグインで代用するしかなかった。

「次期feature releaseとなるRedmine 3.4.0向けのコミットとしてはTime tracking関係の改良が目につきます」「Redmine開発者のJean-Philippe Lang氏の関心が最近はTime trackingに向いていたのかもしれません」というコメントから、今後、Redmineの工数管理も機能改善が期待できるだろう。

【3】個人的に期待している機能は、ロードマップ画面でチケットをドラッグ&ドロップで並び順を変更できる機能だ。
既にパッチが添付されている。

akipiiさんのツイート: "これはイイ!RT @g_maeda: Redmineのロードマップ画面でチケットの並べ替えができるようにするパッチ。これはぜひ欲しい。 https://t.co/IOab4rFQKX"

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

2016年9月のRedmine開発状況 | Redmine.JP Blog

MAEDA, Goさんのツイート: "「Feature #22802: バージョン内のチケットをドラッグ&ドロップで並べ替え」はぜひ3.4.0に入って欲しい。 https://t.co/Tmto62aY5O"

アジャイル開発では、かんばんやプロダクトバックログで、チケットを優先順位別に上から順に並べる。
そうすれば、メンバーはチケットの上から順に取って、作業していけばいい。
メンバーは優先順位をいちいち考える必要もない。

ロードマップ画面はリリース計画に相当する機能なので、チケットの並び順は優先順位順であって欲しい。
優先順位は、チケット番号別でもないし、チケットの優先度で決まるわけでもない。
唯一つの順序でチケットが並んで欲しいのだ。

たとえば、チケットのカスタムフィールドを作り、ナンバリングする運用が考えられるが、優先順位の入れ替えが発生すると運用が面倒になる。

上記のチケットが対応できれば、手動で並び順を設定できるので、ロードマップをより「かんばん」らしく扱う運用ができるようになるだろう。

【4】Redmineの今後の課題はUI改善だろうか。
JPLいわく「Redmine 4ではUI/UXの改善を行いたい。RedmineのUIは、3.2でのレスポンシブデザイン対応を除けば10年間ほとんど変わっていない」。
JenkinsがUIを刷新したように、Redmineもそろそろ現代風のUIにしたいところだろう。

個人的に注目しているのは、view customize pluginによるRedmineのUIカスタマイズだ。

Redmineのプラグイン「view customize plugin」のカスタマイズ例 - Qiita

View Customize - Plugins - Redmine

onozaty/redmine-view-customize-scripts: Script list for "Redmine View Customize Plugin"

Mori, Yuichiroさんのツイート: "これは使えそう! / “Redmine: チェックボックスのカスタムフィールドを2列で表示する (View customize plugin) - Enjoy*Study” https://t.co/rgBtzznrY4"

y503Unavaiさんのツイート: "View customizeでチェックボックス2列表示 https://t.co/nPz3ZLla0c +カスタムフィールド1列表示化 https://t.co/jvW2mngy6h ますます良くなる→ #redmine フィールド単位制御したいなー。CSSエントリ追加希望"

akipiiさんのツイート: "このプラグインのTipsを集めてみたい。RT @netazone: Redmineの進捗率バーが見づらいとのことなので、色をちょっと濃く変更した。ありがとう View customize plugin ! #redmine https://t.co/0YfcEHDCnc"

たとえば、「カスタムフィールドを連動させる(親の値に応じて、子を絞り込む)」「チケット作成時にトラッカーに応じてデフォルト値を設定」「進行中にもかかわらず担当者が未設定の場合に警告を表示」のような機能は正直欲しい。
でも、現場ごとに実現方法は異なるので、ユーザが自由に修正できるような方法が欲しい。
そんな要望に見事に応えるプラグインがview customize pluginになる。

CSSとJavaScriptで自由に画面の挙動をカスタマイズできるのを見ると、RedmineはUI設計も非常に優れているのではないかと推測する。
画面UIの骨組みはCSSで定義されていて、綺麗に設計されているので、そこにフック処理やオーバーロードのような処理を埋め込みやすいのだろう。

Redmineが画面UIを改善する場合、機能本体をマイクロコア化して、画面UIは自由にカスタマイズできるような設計になったらいいなあと思う。
アイデアは下記に書いた。
元々、RailsはJavaScriptと相性が良いので、アーキテクチャとして可能だろうと思う。

ViewCustomizeプラグインでRedmineをマイクロコア化できるか: プログラマの思索

他にも、custom_workflowsプラグインのように、ワークフローにフック処理を自由に入れられる機能があればいいなあと思う。
ワークフローを現場ごとにカスタマイズしたい、という要望は多いからだ。

Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflows: プログラマの思索

Custom Workflows - Plugins - Redmine

色々考えてみる。

| | コメント (0)

2016/09/03

「マネジメントに悩める全てのエンジニアにささげる」資料が素晴らしいのでメモ

「マネジメントに悩める全てのエンジニアにささげる」資料が素晴らしいのでメモしておく。
以下は、思いついたことをラフに書いたラフな感想。
特に主張はなし。

【参考】
マネジメントに悩める全てのエンジニアにささげる 伊藤直也の1人CTO Night | Kwappa研究開発室

日経電子版 開発内製化の取り組み / nikkei web development 2015 // Speaker Deck

デザイナー横断組織の変遷 - クックパッド開発者ブログ

4ヶ月の間に一休.comで起きた変化 - zimathon blog

モダンな現場にするために実践したこと - SSSSLIDE

【1】自分が最近持つ問題意識として、組織構造はソフトウェア開発プロセスにどのように影響させているか、がある。

第15回RxTstudy 『大規模組織や多様な業務における Redmineの課題』

ベンダーへ開発工程を一括発注とか、製品ファミリーの派生開発、1回限りの受託開発プロジェクトのパターンに、Redmineは大きく影響される。
組織構造の影響は、Redmineの良さを打ち消すぐらいの大きさだ。

組織構造の問題が嫌なのは、開発者がコントロール出来ない問題のレベルだから。
でも、色々探ってみると、開発者がコントロールできる問題もある。
その辺りを切り分けたい、と思っていた。

【2】
【2-1】上記の資料で「日経の場合」のパターンは、今の日本で技術力のないユーザ企業の問題そのものだ。
開発は外注しており、社員は外注ベンダーのプロジェクト管理がお仕事になっている。
すると、その組織構造がそのまま反映されたプロセスになる。

つまり、開発プロセスは社内・社外のベンダーという組織単位に分断されてしまう。

その組織文化のまま、内製化しても上手くいかないのは道理だ。
「内製にしたがチーム構造はそのまま」「内製の経験がないからチーム構造を変えなくてはならない、ということに気づけない」「チームの枠組みがないからラーニングが蓄積されない」という指摘はまさにそう。

そこで、「兼務を解消、1チームに1ミッション」という解決策。
つまり、機能別組織にプロジェクト型チームを持ち込んで、クロスファンクショナルな組織を作った。
このやり方ならば、プロジェクト型チームが有機的なチームになりうる。

【2-2】「Kaizen Platformの事例」の場合は、マイクロマネジメント化してチームが機能しない問題。
SIなら本当によくある。
プロジェクトリーダーが全権を持ち、かき集めた開発者とチームを形成していると、契約上そのような雰囲気になる。
元請けSIにある典型的なアンチパターンだろう。

「PMとエンジニアが1:1で仕事している」「PMがアサイン権限を持っている状態」「エンジニア同士がお互いの仕事を知らない->ラーニング結果が蓄積されない」「コンテキストが分断されスイッチコストが発生する」という指摘はまさにそう。

そこで「PMとチームリーダーが話をする」という解決策。
このやり方は、スクラムチームの構成に似ている。
チームの外側のプロマネとスクラムチームがやり取りする。
そうすれば、チームはチーム自身で問題解決でき、チームに暗黙知が自然に蓄積される。

【2-3】「一休での事例」では、「心理的安全性か責任か」というマトリクスで考えると、チームが置かれている状況が不安定である問題があった。
どの会社でも、事業部の中では、うまくいっているチームもあれば、うまくいっていないチームもある。

「レストラン事業部 : 快適」では、心理的安全が既にあったので「ミッションの明確化、ロードマップの精度向上」を課し、「責任を増やす」。

「宿泊事業部 : 不安」では、開発者が安心して開発できるような環境ではなかったみたい。
おそらく、頻発する障害や数多くのリリースに忙殺されて、メンバーが疲労していた状況ではないか、と勝手に想像する。
そこで、「チームビルディング、技術基盤部の確立」を行い、「心理的安全性を高める」。

デスマーチプロジェクトになれば、「心理的安全性を高める」ことはすごく重要。

【3】そんな話を聞くと、組織構造をいじることで、簡単に問題解決できそうに思ってしまう。
「組織構造で変化を起こす」。
逆コンウェイの戦略みたいに、アーキテクチャ主導でチームを作る。
それである程度解決できる場合も多い。

でも「組織構造はいじりすぎない」。
「組織構造は時間的断片」「フェーズに合わせて横と縦のバランスをうまく組み替えていくことで更に良いサービスづくりが行える」という指摘はなるほどと思った。
組織が成長することで、問題のフェーズ、問題のレベルは変わっていく。
安定した組織を壊す必要はないし、組織に応じた問題ごとに、解決策を変えていく。
その一つに、組織構造をいじる方法があるだけ。

【4】「相談しにくる人たちの共通点」が「技術の問題だと思ったら9割がた組織の問題だった」という指摘は経験上そう感じる時がある。
そして、そのように感じる時は、気分が重たくなる。
開発者が解決できる問題のレベルではないからだ。
やっぱり、CTOクラスのように、経営層と開発者の中間のような立場の人が必要ではないか、と思う。

| | コメント (0)

Excel2010を使ってABテスト結果に対しt検定を行う方法のメモ

Excel2010を使ってABテスト結果に対しt検定を行う方法が紹介されていたのでメモ。[
特に主張はなし。

【参考】
やってみよう分析! 第5章:Excelの分析ツールとソルバーの活用(回帰、最小2乗法) - Qiita

【1】自分は統計初心者だが、色々書籍をあさって、t検定の意味がようやくわかった。
t検定を使う場面としては、「サンプルの平均値は母集団と同じか?」「2つのサンプルの平均値が同じ母集団から出ているのか?」があるだろう。
たとえば、前者は工場における製品の品質管理、後者はABテストなどで使われているだろう。

t検定の例は下記が分かりやすい。

平均値の検定

(引用開始)

和歌山の某梅干し工場では,塩分7%の梅干しを生産している.品質をチェックするため,30個の梅干しをピックアップし,検査したところ,平均は7.2%,標準偏差は0.6だった.
(引用終了)

では、某梅干し工場の梅干しの品質は良いといえるか?
言い換えれば、サンプルで抽出した数値から、梅干しの塩分の平均の目標値7%とほぼ同じであり、バラつきは誤差の範囲内、と言えるか?

(引用開始)
帰無仮説:7%である
対立仮説:7%ではない

母集団の分散が未知のケースの式に数値を代入すると,
t=((7.2-7)*√30)/0.6=1.826

この例では7%から高くても低くても製品としては不合格なので,両側検定を考える.自由度29(=30-1),有意水準5%のtの境界値はt.inv.2t関数を用いて
=T.INV.2T(0.05,29)=2.045 なので,「検定統計量(の絶対値)<境界値」より,
帰無仮説は5%の有意水準で棄却されない,つまり帰無仮説が採択され,梅干しの塩分濃度は7%である,という結論を得る.
(引用終了)

【2】t検定、F検定、カイ二乗検定で使われる仮説検定の考え方も分かりにくい。
「」を読んだら、「仮説検定で、帰無仮説を置いて、p値よりも発生する確率が低いから捨てて、対立仮説を採用する、という方法は、確率的背理法と言ってもいい」と記載があって、この文章でようやく理解できた。

中学数学では、「√2は無理数である」という証明に背理法を使っている。
そのやり方を統計検定で採用した場合、前提となる仮説が発生する確率は5%未満だから当初立てた仮説は否定していい、というロジックで評価するわけだ。

知っている人にとっては当たり前なのだろうが、こういう所でつまずいていたので。
上記の例は、t検定の流れと少し違うけれど。

個人的には「推計学のすすめ」という本がすごく分かりやすかった。

【3】B2CのWebサービスならば、ABテストを実施している所も多いだろう。
その場合、ABテストの結果に対し、有意味な差があるかどうか、簡単に評価するには、t検定を実施すればいい。

Excel2010を使って t検定 で新手法と旧手法の差を統計的に調べる zuqqhi2のIT日記

つまり、画面にA機能とB機能を乗せていて、どちらが反応があったか、その反応の差は有意味であるか、という評価に使える。
ロジックの流れとしては、「機能Aと機能Bは、どちらも反応が同じ」という帰無仮説を置き、採取したログからExcelでt検定の結果を出力したら、実際は、その仮説が発生する確率は5%未満だった。
だから、「機能Aと機能Bは、どちらも反応が同じ」という仮説は棄却されて、「機能Aと機能Bは反応に有意差があり、機能Aの方が反応が良い」という仮説が導かれるわけだ。

このやり方を応用すれば、ABテスト以外にも、アンケート処理などの心理学、消費データの解析などの経済学、関連購買の分析などの販売分析、製品の品質管理などへ適用できるわけだ。
今や文系の学問ですら、統計処理がなされていないと、その研究の確からしさや正当性を主張できない、という話は理解できる。

日本の製造業の品質管理が優れていると言われる理由は、こういう統計学的手法をいち早く取り入れて、製品の品質のばらつきを抑える手法を色々と編み出したのだろうと推測する。
そして、そのやり方を同じようにソフトウェア開発にも適用して、ソフトウェア工学の観点に持ち込んで、ソフトウェアの品質を定量的に評価したい、という流れがあるのだろう。

【4】Excelで検定する以外に、R言語を使えば、採取した数値を元にプログラムで検定結果を色々出力できる。
ECサイトの日別・商品別・ユーザ別の売上分析、アンケートの相関分析など色んな使い道がある。
Apacheのログ、政府の統計情報のように、データは既にいくらでもある。

確かにやってみるとすごく面白い。
この辺りの知識もまとめてみたい。

| | コメント (0)

« 2016年8月 | トップページ | 2016年10月 »