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)

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