要件を知る人、決める人、契約する人——全部バラバラだったプロジェクトの末路:国民健康保険組合事件
この記事は以下の節で構成されている。
かなりの長文のため、「プロジェクトの炎上リスクを下げるよい質問」だけを知りたいなら、
最後の5.だけを読むといいかも。
1. 3行でまとめる
2. 決められない構造
3. 「現行踏襲」という同床異夢
4. 「現行踏襲」はいつ火を噴くか
5. 「決められない構造」を可視化する質問
要件を洗い出し、仕様を確定する会議であれば、当然、そこにいるのは「要件が何かを知っている人」だ。
例えば、実際に業務で利用する担当者だったり、そのシステムを運用する情シスの人だったり。あるいは、そのシステムと連携している他システムの担当かもしれない。どんな形にせよ、作り上げるシステムを「利用する人」だから「ユーザ」だと呼ばれる。
しかし、要件定義の場に、「ユーザ」がいなかったらどうなるか?
あたりまえだが、決めるべきことが決まらない。会議に出るのは「窓口」の人で、「その要件は持ち帰って確認します」とだけ言う。そして、持ち帰った先から帰ってこないまま、時間だけが過ぎてゆく。
そんなことがありうるのか?
要件を決めるべき場に「ユーザ」が不在で、実現したい「何か」が分からないのに、プロジェクトは進められるのか? 冗談みたいな地獄だが、実際にあった。
それが、国民健康保険組合事件だ。
3行でまとめる
- 国民健康保険組合の基幹システムのリプレース。提案時は95機能、240人月で、提案2億4000万、その後追加も含め3億3000万円で契約
- 要件が決まらず、懸案が解決されないまま規模が膨らみ続け、稼働は延期。着手から2年後、ベンダが「倍額を超える費用負担か、処理数を半分以下に削減するか」の二択を突きつけて決裂
- ユーザが契約解除して6億円を請求、ベンダも4.6億円を反訴。裁判所は双方の債務不履行をどちらも認めなかった
ユーザ側(国保:国民健康保険)の主張
- 完成させていない: 納入期限を過ぎてもシステムは完成せず、一部稼働した部分もテスト段階にすぎない
- 前工程の報告書が契約内容だ: 1920万円払って同じベンダに作らせた現状分析調査報告書には「現行システムの機能をすべて網羅する」とあり、それが約束のはず
- 処理は増えていない:基本設計書347処理に対し最終時点は233処理。むしろ減っている。追加要求のせいで膨らんだというのは事実に反する
つまり「現行システムをすべて網羅する」という約束にもかかわらず、作れなかった。しかも、規模が膨らんだという言い分も数字が合わないという主張だ。
ベンダ側の主張
- ユーザが決めなかった: 懸案事項が期限までに解決されず、要求は変転を続けた。契約は国保だが、システムを使うのは労組だった。労組本部と38の支部の二重構造が意思決定を止めた
- 仕様は凍結した:DFDを凍結し、凍結後の追加・変更は別扱いと説明した。ユーザは異議を述べず、基本設計書の検収書も交付したが、その後も追加があった
- 規模が倍以上になった以上、金は払われるべき:開発工数は大幅に増加した。追加料か処理削減か、どちらかを選んでもらうしかない
つまり、決められないユーザのせいで膨らんだのだから、増えた分は負担するか、要件を減らして欲しいという主張だ。
裁判所の判断
- どちらも債務不履行ではない:どちらも「懸案が片付かない以上やむを得ない」という共通認識で作業を進めていた
- 「凍結」は「確定」ではない:ベンダ自身が凍結後の変更もあり得ると説明し、PLも社内に「未決定事項を凍結した状態で納品した」と報告していた。基本設計が確定していない以上、ユーザが要求を出すのは当然
- ただしベンダはPM義務を怠った:提案書に書いたレビューとプロトタイプは不十分で、規模の拡大を把握したのは着手2年後。納入期限を過ぎるまで追加費用を示唆した形跡すらなく、そのうえでの倍額要求は「唐突かつ過激」
裁判所は結局、ユーザの解除を、注文者の任意解除(民法641条)として扱った。この場合、債務不履行が無くても契約解除としてみなされるため、ユーザは損害を負担することになる。
その上で、国保は「懸案事項を目標期限までに解決しなかった」こと、ベンダはPM義務違反だったことを認める。裁判所は、任意解除によるベンダの損害を算定したうえで、ベンダ自身のPM上の問題を考慮して、その損害を6割減額した。国保が負担すべき額を4割とし、既払金との差額1億1340万円をベンダに返還させた。
決められない構造
「現行踏襲って言ったじゃん!」vs.「おまえが決めなかったから!」という、地獄のような争いだが、争点だけを見ていると、プロジェクト破綻の原因を見誤る。
既に裁判になっているのだから、プロジェクトは炎上どころか爆発してる。その責任の押し付け合いで、互いに最も有利なポイントから議論するのが裁判になる。だから、争点だけでなく、このプロジェクトの特徴的な構造に目を向けたい。
ヒントは出ている。
原告は2者おり、国保と労組とあるところだ。
システムを実際に使うのは、国保の本部と、労組38支部の担当者になる。ベンダにとって、国保は契約相手だから直接ヒアリングできるが、労組38支部については、国保を経由する必要があった。
「原告国保は、重要事項の決定に際して、原告労組支部の意見を聞かなければならなかった」とある。また、遅延に対応するため、納期を6ヶ月延長するのではなく、段階的な稼働に対応する方針としたのだが、その理由は、「納期の延長だと労組に説明できない」ことによる。
つまり、国保の意思決定の実質的な制約条件は、労組だったのだ。ベンダからすると、要件を決めるためのヒアリングや、疑問や懸案の解消、意思決定を求めても、「いったん労組に確認する」ところでストップする。
そして労組側は、一体ではない。全部で38支部あり、意見を集約・決定するのに時間も手間もかかる。実際、労組側の会議体(電算化検討委員会)は7ヶ月で5回しか開催されていない。
さらに、労組とプロジェクト側との帯域が非常に狭かった。労組側とプロジェクト側の打ち合わせにおいて、労組の参加者は、R書記の1名のみになる。38支部・600分会・7000群から成る巨大組織に比べて、代表は書記1名のみで、プロジェクトとの接点は極めて限られていた。
図:判決から読み取れる主な連絡経路を模式化
判例を見る限り、支部担当者とベンダが直接同席したのは、基本設計書の納品から3ヶ月後、しかも一度だけになる。ベンダはオブザーバー参加であり、要件を合わせるような立場ではなかった。ベンダは設計が終わった後で、部屋に呼ばれただけになる。
ここからは私の想像だが、「基本設計書」という表紙であっても、そこに「ユーザの要望」が反映されているとは到底思えない。
ベンダは提案書に「利用者の意見が反映された使いやすいシステムを構築するため、設計、開発作業の各段階ごとに、利用者とベンダがレビューを行い、確認しながら作業を進める」と書いた。
だが実態は、そうでなかった。ベンダはこの二重構造が、プロジェクトの遅滞を招いたと主張した。判決ではこの主張をそのまま取り上げられなかったものの、国保の「懸案事項を目標期限までに解決しなかった」協力義務違反は認めている。
期限までに決めるべき人は、国保にはいなかったのかもしれぬ。
一般に、仕様検討において、ユーザ側の「窓口」となる人は、経営企画部やIT戦略部といった事業企画部系が多いように見える(組織マトリクス図だと経営幹部の横にくっついている組織)。
そして、私の経験上、この立場にいる人は、会議を仕切り、テキパキ割り切って進める人が多い(というか、Go/NoGoを即断しないと回らないので、割り切らざるを得ない)。さらに、経営層へ案件を上げるため、社内でも一定の権限を持ち、各組織へは「質問を投げかけ、回答をもらう」という立場にいる。
だから、仕様検討において出てきた課題は、「各組織へ投げて、回答をもらう」ことで完結する、と考える(だって、「窓口」だからね)。この人は、「ユーザの代表」であったとしても、必ずしも「要件を知っているユーザ」ではない。
しかし、本当に必要なのは、各組織から帰ってくる「回答」の濃淡やばらつきを見極め、取りまとめることだ。一つの課題について、38支部からの回答を一覧表にすることが、「取りまとめ」ではない。「こうしてほしい」「ああするべきだ」「もう使わないのでどうでもいい」などの要望を一つ一つ拾い上げ、どの要望を採用するのか、他の課題との優先順位も考えながら決めていく。
場合によっては支部からの圧力を突っぱねたり、なだめたり、バーター取引するといった「寝技」も必要になる。全ての支部に向けて「こう使え!」とルールを命じなければならない場合だってある。
こうした、各部を聞いて回りながらする、粘り強い調整は、「窓口」の人には向いていない、というか、できない。
かくして課題は放置される。
決めて欲しい要件は、「ヒアリング結果」という一覧で返ってくるだけで、結局どうするのかは書いていない。ある処理について松竹梅の3案を持っていっても、組織ごとにバラバラの回答になる。スケジュールが押して、優先順位を決めてくださいとお願いすると、「全部最優先で」という回答が来る。各組織の調整をしてくださいとお願いすると、「なんでワタシがしなきゃならないの?」と真顔で返事される(殺意が湧くのはこの瞬間だ)。
対策としてよくあるのが、籍はベンダだが席だけユーザの立場に移るパターンだ。ユーザの各組織の「御用聞き」のように立ち回り、意見を集約する。優先度や要件で衝突が起きるようなら、プロジェクト会議に上げて、そこで決着をつける。
ただ、今回の場合、この対策をするのであれば、ベンダは国保の向こう側の労組に移る必要があった。これは契約上、難しかったのかもしれぬ。
「現行踏襲」という同床異夢
「決めるべき人が決めるべき場にいなかった」という地獄みたいなプロジェクトだ。
おそらく、ベンダ側も何かしらの算段は講じていただろうが、見積もりの甘さかもしれぬ。
そこで安易に「ベンダが甘かった」という結論に飛びつくと、教訓を見失う。
このプロジェクトの構造として、もう一点、注意喚起したい。「国保の基幹システムのリプレース」という点だ。
国保の本部と、労組の38支部・600分会・7000群の組織で利用してきた、現行システムがある。それを刷新するのがこのプロジェクトの目的だ。
そのため、国保は慎重に進める必要があると判断し、現行システムの分析を委託している。1,920万円で委託し、およそ8ヶ月かけてベンダは現状分析を行った。ベンダは現行機能を網羅した報告書を提示し、国保と支部のネットワーク化を提案している。
その後、国保は複数社のRFP・見積書の提出を依頼し、最終的に、あるベンダに開発を依頼する。このベンダは、1,920万円で現状分析を行ったベンダと同一である。
ベンダの分析報告書には「現行システムをすべて網羅する」と記載されており、現状調査を行ったところで開発をするのだから、当然、現行システムについて熟知している……と国保は考えていたはずだ。
そして、ベンダも同じことを考えていた可能性がある。現状分析の過程で、現行システムの設計書やソースコードは分析していたはずだ。
ここからが私の想像だが、これがリプレース対象の全てだと考えていたのかもしれない。すなわち、現行のシステムの要件は明確になっており、ここに新たな要件を追加すれば出来上がりという前提の下、見積もりを行っていたと推察する。
この図は、IPAの「システム再構築を成功に導くユーザガイド」からの引用だ。
ユーザから「現行踏襲でお願い」されたとき、その「現行」の一言に含まれている様々なギャップを可視化したものだ。
- 左上の、オレンジの枠は、「設計書に書いていること」
- 中央の、グレーの枠は、「ソースコードで実装されている範囲」
- 右下の、四角形の枠は、「動作している現行システムそのもの」
設計書に書いていることや、ソースコードで実装されているものは、理解しやすい。
まず、設計書に無いけれど、ソースにあるもの。これは、バージョンアップや不具合の改修で手を入れたけど、設計書に反映するのが漏れていたもの。暫定対処だったものが恒久化したり、設計書を横断的に変更しなければならないけど、してなかったもの。
あるいは、設計書にあるけれど、ソースに反映されていないもの。実装モレなんだけど、たまたま見つかっていないか、微細なのでスルーされているもの。
問題なのは、「現行動作しているシステムそのもの」だ。
ユーザは目の前で動いているシステムが「現行」だと考える。だが、それは運用保守者の手作業や、業務担当者が一緒に使っている独自のツールで動かしているものだ。これは、設計書にもソースにも無いけれど、それがないと「業務が回らない」ため、やっているものだ。
あるいは、過去に問題が生じて、「そういう運用にする」とルール化され、それがなぜそうするのか、伝えられないまま、ルールだけが手順書に残されているものだ。
一時的にマスタ設定値を手修正して、システム負荷を下げたり、エクセルでデータ並び順を変えていたり、「締め日が月曜の場合、△△作業は締め日ではなく、翌日にすること!」と手順書に書いてある。
また、設計書には「10秒以内にレスポンスを返す」と書いてあるが、実装されているサーバの性能が優れているため、現状では3秒で返却されている、といったこともある。この場合、ユーザは、新システムも3秒でレスポンスするものだと考えるだろう。
そして、そうした例外的な運用やツールは、全国的に統一されているわけではなく、支店の数、いや組織の数だけ存在する(いわゆるローカルルールとか裏ツールというやつ)。
「現行踏襲」の一言で済まされているが、それぞれの組織ごとに、見ているものが違うのだ。
「現行踏襲」はいつ火を噴くか
同じ言葉なのに意味が違い、その違いのズレが、プロジェクトに致命的な要因となる。
これは、後から火を噴く火種となる。
例えば、現状分析や見積もりの段階では、設計書を見て、「この通りに作ればいい」と考えるだろう。そして開発者はソースコードを見て、「こう実装されている」と理解するはずだ。実際にシステムを利用しているユーザは、「いま目の前の通りに動くはず」と期待するだろう。
この3者がそれぞれ違う「現行」を前提に話を進めていくと、何が起きるか?
まず、要件定義を掘り下げていく過程で食い違いが出てくる。
ベンダとユーザが、ある機能について、どのように運用しているか、どう改善するかといったテーマで議論していくと、ベンダが把握している機能と、ユーザが使っている運用のズレが見えてくるだろう。
ただ、ベンダとユーザが同席して、そこまで要件を深掘りするかどうかは、プロジェクトのスケジュールによる。多くの場合、いくつか「ズレ」は散見されるが、後工程で詳細化し吸収していくといった方針で進められていくだろう。
次に見つかるのが、テストの場合だ。
パイロットユーザとして選ばれた担当が、実際に触り始めて気づく。そして、「今そんな動かし方をしていない」「こんなアウトプットだと、運用できない」といったユーザの声が噴出する。プロジェクトが変更対応に耐えられる範囲なら、仕様バグや仕様検討漏れといった形で吸収し、体裁を繕うだろう。
さらに厄介なのが、「移行できない」という形で露見する場合だ。
日次処理や月次処理のバッチを動かそうとするとエラーが出てくる。そこを修正してもまたエラーが出てくるという場合だ。現行システムの運用者の勘と経験で対応していた例外的な手作業が、コードにも設計書にも記載されていないと起きる。移行作業という時間的制約がある中で、先が見えないモグラたたきのような悪夢だ。
最悪なパターンが、移行して、使い始めてから「これではない」という場合だ。
各組織で吸収されていたズレが、その場において明らかになるが、プロジェクトは後戻りできないところにいる。「業務が回らない」とい怨嗟をどうやって抑えるか、あるいは、別にリリースを区切って手を入れていくか、そもそもそういうレベルで対応できるようなズレか、といったところから議論が始まる。非機能要件が炎上要因となるのは、ここ。
「決められない構造」を可視化する質問
決められない構造はプロジェクトを殺す。
課題を提示して、〇日までに決めてくださいと依頼しても、決まらない。これは、依頼する相手と、実行する人、決定できる権限が一致していないことから生まれる悲劇だ。
いま関わっている、あるいは関わろうとしているプロジェクトが、この「決められない構造」になっているかどうか、分からない。国保の事件も、こんな歪な構造だったことは、プロジェクトが炎上爆発して、裁判となったので明るみに出たのだから。ましてや、現在あなたが渦中にいるプロジェクトがどうなのか、分かるべくもない。
だが、決められない構造となっているかどうかは、質問により炙り出せる。
この課題について、誰が意見を集め、誰が調整し、誰が最終的に決めますか?
「誰が決めますか?」という問い方だと、形式的に決裁者の名前が返ってきて終わる恐れがある。国保の場合なら、「(国保の)窓口の担当です」か、せいぜい「(労組の)R書記」だろう。
だから、「支部が38もあって、600分会もあるので、R書記のお一人で意見集約から調整をするのは現実的ではないと思います。おそらく、ヒアリングや取りまとめをしている人がいると思いますが、その人はどなたですか?」という更問いになる。
そして、「そんな人はいない」や「全部R書記に一任している」といった回答であるなら、もっと本質的な質問になる。
もし、意見が割れたとき、誰が一つに決めますか?
単純に窓口として投げるのではなく、対立が起きた時の調整能力を問う。「各分会に確認します」というだけなら、窓口でできる。しかし、「結局どうするの」を窓口担当が決められるとは限らない。
「個別に検討します」というのであれば、「それを検討するのがこの場なので、その人のご都合に合わせて会議をするのはいかがでしょうか」といった提案もできる。分会が多いなら、会議体の規模を縮小して調整の場の数を増やす、分会の代表を選び、決定権限も持たせる等の案も出てくるだろう。
そこで起きるのが、分会ごとに違う回答が得られることだ。当然だろう。38支部もあるので、それぞれ異なる運用をしている可能性が大きい。「マイルール」が38個あると思ったほうが自然だ。その時は、こう問うことで、「決めるのは誰か」を炙り出せる。
自分の部署の希望ではなく、分会全体としての回答は何ですか?
おそらく、「マイルール」を言った人は、「私じゃない」と返事するだろう。まさにそこが欠けている点になる。「決める人がいない」ことが明確になり、「決める人を決める」ことが最優先であることが、皆の目に明らかとなる。
あるいは、担当同士で「私じゃない」「ウチじゃない」とモメることがある。これもよくある話だ。そもそも、システムのリプレースなんて頻繁にある話ではない。コストもかかるし、全社的な施策だし、業務も変わる影響だってある。数年か、十数年にあるかどうかというくらいだ。
そんな場合、そのシステムの「決め方」なんて決まっていると考える方が変だろう。決算処理といった定型業務であっても、まれに起きる例外事象の手作業を、どこの部署でやるのかで押し付け合いがある。定型業務でコレだから、例外中の例外である、新システムの要件の決め方なんて、誰も知らないのが普通だ。
そういう時は、こう問うてみよう。
期限までに回答が出なかった場合や、担当者で回答できない場合、どの会議体に上げますか?
伝書鳩の窓口しかおらず、決めるべき仕様調整の場に決めるべき人がいない。それが明らかになったらどうする? それを問うている。暗にエスカレーションを示唆しているため、言い方によっては、伝書鳩を侮辱していることになるので、できるだけ低姿勢で伝えるのが良いだろう。
口頭では低姿勢で説明するものの、議事録にはきっちり残しておこう。国保の落ち度として認定されたのは「懸案事項を目標期限までに解決しなかった」の一点であり、その期限が記録に残っていたことがそのまま過失相殺の根拠になった。議事録や課題表の中には、「本件の回答が期限に得られない場合、エスカレーションを行い、上位層にて議論する」と残しておく。
いずれにせよ、決めるべき人を決めるべき場に据えて、そこへ課題を持ってくるように仕向ける。
「現行踏襲」の悪夢から醒める質問
「現行踏襲」「現行と同じ」は便利な言葉だけど、実は何も言っていないに等しい。むしろ、「現行踏襲のギャップ図」の通り、極めて危険な言葉だ。
だが、「現行踏襲は危険です」と言っても、ピンと来ないだろう。だから、まず「現行」と呼んでいるものが何を指しているのかに注意を向けるのが、よい質問になる。
ここでいう「現行」は、設計書、ソースコード、実際の動作、現在の運用のどれですか?
喋りながら、ホワイトボードに「現行踏襲のギャップ図」を描いてもいい。おそらく、描いた瞬間、その場にいる人は「現行」の意味が何重であることに気づくだろう。そして、「現行踏襲」の代わりに、「現システムの設計書」や「現在の運用」といった言い方にしてもらうように促す。
受け入れ条件に接続する質問として、これも使える。
「現行どおり」を、何と比較して確認しますか?
言い換えるなら、「何が満たせれば、”現行通り”になるのか?」と問う質問だ。できれば、もっと早い段階で問いたい。
というのも、この質問は、先ほど出た「決める人を決める」にも直結するからだ。「何を満たせば現行通り?」という質問に、「〇〇さんに聞かないと……」と答えたら、その人が決める人になる。「現行通り」と比較する対象は、設計書やソースや手順書とは限らない。
そういう、暗黙のルールが良いか悪いかは別として、みんなの心の中にあるルールがあることが明確になることが重要だ。暗黙のルールは、暗黙であるが故に書かれない場合が多い。だが、それが無いと運用が回らないからルール化されている。そういうルールがあると分かれば、後は書き出すだけだ。
全拠点で共通の運用と、拠点独自の運用を分けてください。
「現行踏襲」と謳う場合、「現行」が拠点数だけ存在することがある。ある支部ではシステムが出力したファイルをそのまま使い、別の支部では独自のフォーマットにExcelで加工したり、さらにまた別の支部ではVBAで自動化している。どの現場の人にとっても、「現行」になる。
そして、「全拠点で共通」と「拠点独自」とが分けられないのであれば、その人は、「決める人」ではないと言える。最低でも「全拠点ではこう使う。拠点の独自のものはそれぞれの責任で加工すべし」と言える人をアサインする必要がある。
結局、「現行踏襲」の同床異夢に陥っていることを気づかせるのが「よい質問」になる。「いつまで経っても仕様検討が終わらない」「重要な課題がオープンなまま突き進んでいる」といった現象が赤信号だ。そうした兆候が出てくる前に、この「よい質問」を投げかけてみよう。
その回答が「持ち帰り確認します」というのであれば、持ち帰り先が次に集まるのはいつかを伺おう。国保の場合、7ヶ月間で5回しか開催されなかった。それが、裁判の過程で明らかになるか、プロジェクトが炎上する前に分かるかは、大きく違うのだから。


















最近のコメント