2008年8月3日のNIKKEI NETに、富士通が東証トラブルを受け障害対策専門組織を発足させたという記事が出ているのを読んで、ここまで来たかと驚いています。「経験豊富な技術者を約20人集め、東証をはじめ大規模な社会インフラシステムの障害防止や復旧支援を手掛ける」とのこと。東証の問題はITプロジェクト管理の常識からすれば「あとの祭り」なのです。２，３ヶ月の仕事で失敗したのではなく、長期間かけて構築したシステムですから、管理を怠らなければこのような事態に陥らない手立てを打つタイミングはいくらでもあったはずです。かくいう私自身、ある泥沼プロジェクトの原因を作ってしまった張本人ですし、また、そうしたプロジェクトの救済に何度も駆り出され、馬車馬のように働いた経験から、その舞台裏が手に取るように分かります。富士通に限らず、大手システムプロバイダーは口いっぱいに仕事を頬張って、消化しきれずにいます。ITゼネコンの多重下請けのトップの企業としては仕事を断れないのかもしれませんが、能力以上の仕事を受注してしまったつけが今来ているのでしょう。戦線拡大を続けてにっちもさっちも行かなくなっているのではないかと思います。私は、この記事を大手システムプロバイダーの断末魔の叫びと受け取っています。
Archives for : プロジェクト管理
私は経済学についてまったく知らないのですが、「市場・知識・自由 －自由主義の経済思想－」（F.A.ハイエク 田中真晴/田中秀夫編訳、ミネルヴァ書房）というハイエクの論文を収録した書籍の第二章に「社会における知識の利用」（American Economic Review,XXXV,No.4,September 1945,pp.519-30から転載。）という論文（訳）があり、興味を感じて読んでみると、その第１節に、
「合理的な経済秩序の問題に特有な性格は、われわれが利用しなければならない諸事情の知識が、集中された、あるいは統合された形態において決して存在せず、ただ、すべての別々の個人が所有する不完全でしばしば互いに矛盾する知識の、分散された諸断片としてだけ存在するという事実によって、まさしく決定されているのである。したがって社会の経済問題は、『与えられた』資源をいかに配分するかという問題だけではない―『与えられた』ということが、それらの『データ』によってセットされた問題を、熟慮して解くひとりの人間の知性に対して与えられていることを意味するのであるならば、その問題だけではないのだ。社会の経済問題はそれよりもむしろ、社会のどの成員に対しても、それぞれの個人だけがその相対的重要性を知っている諸目的のために、かれらに知られている資源の最良の利用をいかにして確保すべきかという問題である。すなわち簡単に言うならば、どの人にもその全体性においては与えられない知識を、どのように利用するかの問題である。」
と書かれています。
ITプロジェクト管理考の前書きで、日本のソフトウェア企業のITプロジェクト管理力が育たないのは何故かを問い、その後思いつくままに書き綴ってきましたが、前稿：ソフトウェア事業と共同体を書き終えたとき、ソフトウェア産業構造に疑いを持つようになりました。ITプロジェクト管理力をつけ、活かすには下地ができていなければならないのではないか。下地とはITユーザ企業やソフトウェア企業経営者のITプロジェクト管理に対する認識や取組み、産業界の活動、法制度などを指しています。残念ながらこれまでのところ下地ができていないということです。IT（情報技術）は社会や企業、個人の生き方を支援する強力な手段です。これを生かすも殺すも使い方次第です。ITプロジェクト管理はITシステムの構築・維持（保守、更改）を合理的に行う手法であり、これを旨く使いこなすには下地がなければならないということです。
日本のソフトウェア企業の売上の約７割はSIです。多くの顧客は安心・安全を求めて発注先として大手ソフトウェア企業を選びます。大手ソフトウェア企業はシステム開発のプロジェクト管理と上工程（要求設計・機能設計・構造設計）を担い、下工程（詳細設計･コード化・テスト）は外注するのが一般的です。企業によっては、上工程の大部分を外注するケースもあります。中小零細企業はこの大手企業の下請けとなっています。下請け企業もまた外注するいわゆる孫請けを行うこともあります。このような慣習を指してＩＴゼネコンと呼ばれる多重構造が生まれました。多重構造であっても、末端の企業が正当な収益を上げることができるならば、何ら問題はありません。しかし、下請け、孫請け、・・・と階層が下になるにつれ、最下位の企業はピンはねされて、見るも無残な状況に甘んじなければならなくなるケースがあります。
ソフトウェアの“設計”は大きく機能設計（What）と構造設計以降（How）に分けることができます。そのどちらにもついても品質が問われますが、一般に、構造設計以降の品質について議論されることが多いようです。
機能設計の品質が悪いと、いくら構造設計以降の成果物の品質が良くても、顧客の信用は得られません。顧客の要求を満たしていなければ、どうしようもない訳です。
構造設計以降の品質についてはコード化されたプログラム（モジュール）のテストを開始した直後に決定的に明らかになります。品質が良いプログラム（モジュール）は一発目のテストでストーンっと走ります。品質が悪いプログラム（モジュール）は２０、３０ステップ毎にズッコケます。テストしながらソース・コードを見直すということを繰り返すようでは話になりません。このような悪戦苦闘しているSEやプログラマがいることに気づいていないプロジェクト管理者がいたとすれば最悪です。設計段階から何も見ていない状態だったのです。SEやプログラマを追加したり、交代させ、納期を大幅に遅れて納入できたとしても、顧客の信用は失墜してしまいます。
