なぜ提案段階でシステム開発方法論の並行がリスクであると見抜けなかったのか
久しぶりに何かきましたね。期限付き公開なので適宜引用する形式で。
最近は委託元から止めようと言い始めるケースが表沙汰になるケースが増えてますね。
文化シヤッターは、この提案は実質的に従来のプロジェクトの成果を破棄するものであり、この段階でプロジェクトは頓挫したと判断。開発失敗の責任は日本IBMにあるとして、同社に支払った開発委託費約22億円を含む27億4475万円の損害賠償を求めて同社を訴えた。
引用（以下引用表記略） ［特報］27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴 | 日経 xTECH（クロステック）
ざっと眺めて一番最初にダメだろう点と思ったのはここですね。
両社は当初、アジャイル開発とウォータフォール開発の併用によるシステム構築を目指していたが、途中からウォータフォール開発のみに方針を転換。要件定義、設計・開発、システムテストと工程を進めた。
もう、ガチのウォーターフォールで工程完了させないと次へ突入できないようにするか、小さなアジャイル開発チームを作って、のんびりと開発するのの二択だったんですよ（多分ね）。
まあ、どうして共存できると思ったのかを提案を承認したレビューアに教えて欲しいところです。提案をした、つまり受託側は、この委託元は要件を五月雨で際限なく突っ込んでくる文化を持っていると察した（それを吸収しないと提案で勝てないと判断したかもしれない）のでしょう。
文化シヤッターが既存の販売管理システムを刷新するプロジェクトを始めたのは2015年3月のことだ。文化シヤッターは日本IBMに提案依頼書（RFP）の作成を委託。そのRFPに基づき複数のITベンダーから提案を受けたうえで、日本IBMをシステム構築の委託先として選定した。
さらに言えば、委託元から要件の追加は開発期間中にいくらでも吸収させる要件をRFPに織り込んでいたのだろうと推測できます。だからこそ、受託側がそれを飲み込んだ提案をしたのでしょう。それを提案のレビューの段階でシステム開発方法論を並行（なのか）で行うことの矛盾を見抜けなかったのか、呑み込まなければ（元に戻るけれど）勝てないと判断して提案したのかもしれません。
上記の引用から推測できることはRFPを書くコンサルかエンジニアはRFPを書くプロジェクトで委託元の家風を察することができたはずです。どうしてそう思うかというと、オンサイトで少なくともレビューは受けていて組織文化で揉まれているはずだから。
資料の作らせ方、指摘の仕方、ましてやRFPを各プロジェクトの契約条項、価格合意で関係者はどんな文化を持つ委託元かは感じることができたはずですが…。
日本IBMの提案は、販売管理システムの構築にERP（統合基幹業務システム）などのパッケージを使わず、米セールスフォース・ドットコム（Salesforce.com）のクラウド開発基盤「Salesforce1 Platform」を利用してシステムを「手作り」するというものだった。稼働時期は約1年半後の2016年7月、総開発費用は約12億3500万円を見込んでいた。
不思議なことは、Salesforce の PaaSを使うのに標準機能でやりましょう、とせずに手作り＝スクラッチ開発にしたことです。これは委託元の要求なのか受託側がなんでもやりまっせと受託金額をかさ上げしようと思ったのかは記事からはわかりません。
知っている限り、パッケージ開発もスクラッチ開発も「想定している機能や規模」以上に膨らむことに対してキャップをかけることがプロジェクトのスコープクリープすることをコントロールする基本なのですが。
開発を進めたシステムは、Salesforce1 Platformの標準機能で実装した部分が5％、同基盤上でカスタム開発した部分が95％だった。これを標準機能が80％以上、カスタム部分が20％以下になるよう開発し直す。標準機能を多用するため、画面のレイアウトやシステムの機能にも制約が加わる。
ね、やっぱりそうなんでしょう。
だからスクラッチよりパッケージだし、カスタマイズすると費用が返ってかかるよと誘導して標準機能に収めるのが吉なのですけど。
日経コンピュータが入手した訴状によれば、同テストで「多数の不具合が発見され」た。その数は同年10月までに600件以上にのぼったという。両社の会議で日本IBMの担当者は、受け入れテストの段階で不具合が多数見つかった理由として「要件定義フェーズ、設計フェーズの遅延に伴う開発フェーズの期間圧縮・テスト検証不足」を挙げた。加えて、受け入れテスト段階で要件の変更に当たる事項も顕在化し、その理由として「機能要件および外部設計に関するヒアリング・確認が不十分」などを挙げた。
要件定義、設計フェーズの遅れを後工程の期間を短縮してやろうとなんで思ったのでしょうか。短縮してやれって言ったのでしょうね、PMは。多分、この時点で冷静な判断ができない状況まで追い込まれていたのかも。
それで、ヒヤリング、確認が不十分というのは受託側がプロジェクトマネジメント義務違反が問われそうな予感。
ところで、
この時点で見つかっていた不具合は1000件ほど。日本IBMはこのうち約800件を「プログラムのバグでなく仕様の変更に当たる」とし、バグは200件弱と主張した。文化シヤッターはこの分類に異論を唱えつつも、システムの早期稼働を優先。まず日本IBMがバグと認めた200件弱の不具合のみを修正してシステムを稼働させるよう、日本IBMに要請した。
こう言った言い合いを見ていると変更管理プロセスをちゃんとやろうね、と言いたいところですがRFP上はテストまで仕様変更ができるシステム開発を提案せよ、となっていたんでしょうか。邪推ですが。
であればどうあれば回避できたのかしら。ガチでやればと思うけどそれじゃ進捗しない＝委託元のレビュー承認下りないだろうし、アジャイル開発でちまちまと実装していくのが良さそうだけど、全体の規模が大きそうで誰が破綻しないアーキテクチャを設計しきれるのかがまた…。
解決しないけど勉強になりますねぇ。
