ITプロジェクトの係争と、プロジェクトの銀の弾丸(あるとしたら)
2017年、ITプロジェクトの「サグラダ・ファミリア」とも呼ばれたみずほ銀行のシステム統合に完成のめどが立ったというニュースが出た。
開発規模は、4000億円台半ば、20万人月。最大時は8,000人のプロジェクトであったという。
ネットの書き込みには、このプロジェクトに携わっていたと思われる人、携わってないまでも近い環境にいたと思われる人たちの言葉を多く見つけることができるが、透けて見える状況(惨状?)には身をつまされるばかり。。
そんな折、かつて日経コンピュータの「動かないシステム」というテーマで掲載されていた記事(2006〜2007年)が全文公開されている。
内容の詳細はリンク先の本文に譲るとして、
「10年前のことだから。今はこんなことないよね」と笑い飛ばせる状況にいる人はそんなに多くないんじゃないかと思う。残念ながら。
自分は、幸いにして、担当したITプロジェクトで裁判レベルに発展するものはなかったが、しばしば頭の片隅によぎった経験はある。。
そんな中で「明日は我が身かも・・・」という思いで手に取った本で、一番参考になったのは、この1冊。
著者は、裁判所でITに関わる民事調停委員を務めているという人物。
いわゆる「出るところ出ましょうか?!」の「出た先」でどろどろの係争を見ている人の言葉は重く響くものがある。(軽めのストーリータッチで描かれているところがかえってリアリティがあり重い。。)
少し自分の解釈も入るけど、「おぉ~なるほど」と学んだことはこの二つ。
- 裁判は起こさずにいられることに越したことはないが、第三者が関与するというひとつの解決手段としては有効
- 裁判では杓子定規に契約内容や履行内容が争点になるか?といえばそうでもなく、双方がどれだけ解決や和解のために協力しあったか?をむしろ重視する
裁判になることは絶対さけるべきことなのか
or
裁判になることも念頭に置いて行動すべきか
契約内容を盾にして顧客とケンカすべきか
or
今の契約内容にはこだわりすぎずに良い解決策を模索するか
このようなジレンマの中で、↓のような考え方をお守りにして、自分のスタンスと行動を支えてくれた本だった。
- 契約はあくまでそのときの状況で結んだ契約であって、過去を蒸し返すこともできるが、今時点での状況で契約を変更したり追加するというオプションもある
- システムが無事に稼働して、ユーザーに喜んでもらえることが何よりのゴール
- プロジェクトメンバーが元気でプロジェクトが進むことが何よりの土台
で、あらためて、
10年前の記事を読んでも3つともに言えることは、「スタートをうまく切れていない」つまり、本当の要件定義を誰もできていないのではないか?できていたとしても、しがらみの中で玉虫色の要件定義になってしまっているのではないか?ということ。
プロジェクトの成功と失敗を分ける一番の制約は、要件定義であり、「たしかな要件定義を、関係者が腹落ちレベルで合意する」ことができれば、プロジェクトはもう半分成功したものと言ってもいいのではないかと思う。
「システム開発に銀の弾丸はない」とまことしやかに言い伝えられてきているけれど、「誰もが納得いく要件定義ができる」としたら、これが銀の弾丸になりうるのではないか?
道のりは長いかもしれないけれど、だいぶ本気で信じている。
(システムの意義とやることがわかって、関係者の得意や持ち分もお互いにわかっていたら、各人が勝手に気づいて勝手にゴールへ向かっていくというプロジェクトをいくつか見ていて思うことである)
次の10年後には、これらの記事を読んで「昔はこんなことあったよね。よくやってたよなぁ~(苦笑)」と思い出話になっていることを夢見て。