システムエンジニアの晴耕雨読

岡村正司「システム設計の必修スキル」

元・ＩＢＭの岡村さん。銀行の第三次オンラインシステム構築以来、
超大規模プロジェクト（別に基準があるわけではないですが・・・総工数、数万人月、
ピーク時１０００名以上）のプロマネを歴任されています。
経歴に載っている、一昨年のＪＡＬ／ＪＡＳ統合のＰＭだったことも噂で聞いていました。

１０年ほど前、岡村さんのプロジェクトで、３年ほどお仕事していたことがあります。

その際、大規模プロジェクトをいかにすすめるべきか、
そのための顧客・ベンダー双方を納得させるための
プロジェクト構造の可視化、システム開発方法論の説明への熱意は、
当然に私たちにも伝わりました。

プロジェクト発足にあたっては、
プロジェクト計画書の策定が必要ですが、大規模プロジェクトにおいては
プロジェクト計画書の策定そのものが一大プロジェクトとなり、
半年から一年以上の予備調査・検討が必要になる、と本書でも述べられています。

・・もちろん、方法論だけでスマートに立ち上がるプロジェクトなどあるわけではありませんが、
最終的に剛腕を活かすためにも、合理的な理論が必要条件になると思います。

岡村さんの他の著作もそうですが、
参画したプロジェクトの実例が、ふんだんに登場していました。

１０年前の自分の姿をダブらせながら、
ページをめくりました。

プロジェクトの基本構想段階の局面定義及びその狙い・内容の説明は、
システムアナリストの教科書等より、具体的・実戦的なものであると思います。

システム分析の工程は、
　現行物理モデル→現行論理モデル→新論理モデル→新物理モデル（＝外部設計）
と進むのですが、

・プロセス分析に適用したＤＦＤ（データ・フロー・ダイヤグラム）の最下位レベルの粒度
・新論理モデルの理想度合い（ノータイム、ノーコスト等物理制約をどこまで外すのか）
・新論理モデルから新物理モデルの展開の方法

等について、成果物のレビューを通しながら、侃々諤々したことを思い出しました。

小規模プロジェクトは、大規模プロジェクトのサブセット・・
だから、大規模プロジェクトの構築スキルにこだわる。

アプリの業務要件を踏まえてアーキテクチャを確定し、
そのプロジェクトにとっての業務設計方針を策定する必要があるが、
この設計者のほとんどが基盤システムの開発経験者だった。
その技術者たちがＩＴ業界から引退しつつあるのが、２００７年問題の本質なのだ。

だからこそ後進に伝えば・・という岡村さんの熱い想いが伝わってきます。

・・正直、この本は、以前ならここまで書いていいのか、と思う内容が書かれています。
あの数万人月のプロジェクトのノウハウがぎっしり詰まっています。

自宅と会社双方においておこうと思います。

【セオリー1】業務目標の理解
【セオリー2】業務概念設計
【セオリー3】業務設計方針
【セオリー4】業務体系化
【セオリー5】本番環境設計
【セオリー6】業務処理とマネジメント処理分離
【セオリー7】論理設計と物理設計の分離
【セオリー8】業務論理仕様把握
【セオリー9】業務コンセプトの継続的発展
【セオリー10】 ERPを利用した開発
【セオリー11】業務の保全性確保
【セオリー12】業務物理要件と物理設計方針
【セオリー13】サブシステム分割
【セオリー14】 IT製品への実装設計（業務）
【セオリー15】画面・帳票設計
【セオリー16】データベース設計
【セオリー17】基盤システムの位置付け
【セオリー18】基盤システム設計スキル1
【セオリー19】基盤システム設計スキル2
【セオリー20】処理性の実装
【セオリー21】データベース運用設計
【セオリー22】運用設計
【セオリー23】データ移行システム開発
【セオリー24】物作りの技術
【セオリー25】物作り“力”をつける