忘れ去られた日本のIT技術～プロジェクト管理

「曖昧性とのたたかい―体験的プロジェクトマネジメント論」「はじめての上流工程をやり抜くための本 (エンジニア道場)」の本を読んで思ったことをメモ。
ラフなメモ書き。

【1】「曖昧性とのたたかい―体験的プロジェクトマネジメント論」は大規模な業務システムを構築する時のプロジェクト管理に関する経験談とそのノウハウを書いた本。
読み物だけど、読んでみて色々と参考になった。
但し、WF型開発を想定しているので注意は必要。

「確率の低い事象は必ず起きる」という文言はまさにその通り。
実際の業務システムは、とても稀な障害は頻繁に多発する。特に初回の本番稼動直後は特にそうだろう。

「プログラム修正に副作用あり」「触らぬ神(ロジック)に祟り(デグレード)なし」は信頼性を重視する業務システムでは特にそうだろう。
バグ修正や仕様変更が多いほど、デグレードが発生しやすいし、予期しなかったロジックが現れてバグの温床になる。
テスト駆動開発＋継続的インテグレーションでカバーできると思いがちだが、ハードウェアも含めたシステム全体の観点では、それだけでは足りない。
しかし、この観点が行き過ぎると、保守性が悪くなり、その後の機能追加に工数がかかってしまうと言う技術的負債の事象も発生する。

「窓拭きは真ん中ではなく四隅から」とは、異常ケースのテストをきちんとやれば自ずから正常ケースも綺麗になるというたとえ。
確かに、ソフトウェアのロジックの8割は異常処理と言われるので、そういうロジックがたとえ稀でも徹底的に潰す方針を取れば、開発者もテスターも仕様をより深く理解するようになる利点もある。

「進捗報告をリーダー自ら作ること」は、リーダークラスになるとメンバーに作業を任せがちだが、自分で書いてみて問題点を把握することが重要という話。
いくら手間を省いて合理化しても、実質的なマネジメントができなけば何の役にも立たない、という指摘はまさにその通り。

他にも色々な話は参考になるが、体系化されていないように思う。
「曖昧性とのたたかい―体験的プロジェクトマネジメント論」だけでなく、以前読んだ本「プロフェッショナルマネジャーになる50の技法―「前進」「機能化」「立案」「解決」の4つの技法で『プロマネ』のツボを攻略する (アスカビジネス)」「SEのためのプロジェクト管理心得ノート」もいい本だけど、プラクティスやパターンへ抽象化されてないので、まとまっていない印象を持った。
むしろ「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」の方がより深みがある気がする。
PMBOKの方が抽象的すぎるけど、PMBOKの言葉に色んな人の体験談が抽象化されていて、誰でも共有できる利点がある。

【2】また、「はじめての上流工程をやり抜くための本 (エンジニア道場)」は、システム化提案や要件定義に関するノウハウを書いている本。
特にシステム化提案のような超上流工程のモデリング技法は参考になった。
但し、WF型開発を想定しているので注意は必要。

「システム」の定義がSLCP-JCFでは98年度版から2007年度版では後退しているという指摘は鋭い。
つまり、(業務)システムとは、コンピュータシステムとそれを利用する人達の活動(業務)も含めたはずなのに、2007年度版では、システムがコンピュータシステムに限定されてしまって、手運用でフォロー出来る業務の設計が外れている点はおかしいと指摘している。
確かに、実際の業務システムの設計では、何でもかんでもIT化する必要はない。
開発コストやユーザがシステムを運用するコスト、システム化によって業務が変わってユーザが慣れるまでのコストなどを考慮して、故意に手運用するフローも考慮すべきだからだ。
つまり、BPRの視点が漏れている点はおかしいわけだ。

システム化提案では、いきなり設計ではなく、顧客の業務をモデル化して、どこをIT化して効率化するか、とか、他の業務とつなげるか、などいろんな観点で考えれるようにモデルを作る。
実際は、AsIsモデル(現状業務)とToBeモデル(IT化後の業務)を対比させて、BPRを具体化していく。
その時に使うモデルは、業務機能関連図が多いだろう。
業務機能関連図は、組織・プロセス・データを一体化したポンチ図であり、PowerPointで描く時が多いだろう。

業務機能関連図はDFDに似ているが、DFDは図面としての表現力は弱いと指摘してる。
つまり、プロセスの順序や配置で業務の意味が変わるのに、DFDは一昔前のモデリング技法ゆえに力不足だと言う。
エリクソン・ペンカーのプロセス図やIDEF0のように、矢印の向き先だけで供給プロセスだったり、制御プロセスだったりする意味をDFDでは描ききれない弱点があるわけだ。

普通は業務機能関連図を書くときは、ストア(データ)を書かずにプロセスだけを書くのが多い。
ファイルやDBを書くとシステム設計に近づきすぎて業務分析にならないし、モデルが煩雑になるだけ。
ストアを書くのはデータとプロセスを分離したDOAが登場する以前の技法であることを示しているという指摘は鋭い。
実際の業務分析では、プロセスを中心に描いて、組織やデータ、お金の流れを顧客が理解できるレベルにしておくのが普通だろう。

業務機能関連図の描き方で参考になったのは、組織の枠を入れると論理モデルから物理モデルに変わるという指摘。
AsIsモデルからToBeモデルへデータモデリングする場合、「現物理モデル→現論理モデル→新論理モデル→新物理モデル」の流れで設計するのが普通だろうが、業務フローに組織の枠を入れてモデル化することは「新論理モデル→新物理モデル」に相当する。
つまり、ToBeモデルにある業務を誰が担当するのか、という観点を入れれば、現場の業務フローにより近づける。

「はじめての上流工程をやり抜くための本 (エンジニア道場)」を読んで業務機能関連図の描き方は参考になったけど、ノウハウが体系化されておらず、プラクティスまで昇華されてない。
BaBOKが今、システム化提案という超上流工程をBOK化しようとしている最中であり、じきにこの本の内容も含まれるだろうと推測する。

【3】以上の本を読んで思ったのは、日本人技術者が大規模な業務システム開発を長年行っている間に、プロジェクト管理や業務設計で色んなノウハウを持っているにも関わらず、共有されていないことだ。
忘れ去られた日本のIT技術～DOAと品質管理: プログラマの思索でも思ったけれど、DOAや品質管理などの技術は世界的に見て優れているにも関わらず、現在のIT技術者は殆ど関知していない。

今アジャイル開発がソフトウェア開発で注目を浴びているけれど、実は日本発のアイデアや日本人が提唱した論文や製造モデルが元ネタだったりする。
PMBOKを取得している日本人マネージャは結構いるだろうが、取得できる人が多いのはプロジェクト管理を経験できる開発案件が実際に多く、試行錯誤しながらプロジェクト管理の本質を理解していったからだろう。

日本の歴史を紐とけば、中国から文化を輸入した後、平仮名や和歌のような独自の日本文化を生み出した。
明治時代に西洋から文化を輸入した時も、簿記や製造技術、学問などをそのまま取り入れるだけでなく、日本人に合う形で咀嚼して、今の製造業がある。
アジャイル開発でも、平鍋さんは初期の頃はXP行脚など活動された後に、プロジェクトファシリテーションという日本人らしいアジャイル精神のプラクティスを提唱された。
チケット駆動開発もまちゅさんが提唱されたアイデアだが、コミュニティやネットの中で議論して、以前よりも体系化されたものになりつつある。

同様に、日本人技術者が保持しているプロジェクト管理の技法も日本流にアレンジして、もっと共有出来る形へ体系化されるべきものだと思う。