度重なる追加要求
佐々木は、「なんとしてもサービスインの期日は厳守したい。実装工程で遅れているスケジュールを取り戻すために、当初のスケジュールに組み込んでいた2カ月間のコンティンジェンシーの期間を食いつぶしても先に進めるべきだ」と主張した。まるで顧客である自分たちの要求を通せ、と言わんばかりだった。仕様の確定が先決だ、と言い続ける前田や加藤の意見は押し切られ、プロジェクトは数週間遅れで実装工程に入った。
前田や加藤ができることは、定例プロジェクト会議の議事録に、佐々木の言葉をユーザーの意向として書き残し、それを既定の関係者に通知し、承認者である佐々木の署名を得ることだった。
2019年10月頭から予定していた実装工程のスケジュールが見直され、10月中旬から本格的に動き始めた。日比谷ソフトウェアの開発チームが急に慌ただしさを増した。「ベトナムの協力会社に、要件定義と設計ができた部分からどんどん開発に回してくれよ」という声が飛び交った。
オフショア開発。いつの頃からか、システム開発におけるプログラミングなどの実装工程を、人件費の安い海外で行うことを「オフショア開発」と呼ぶようになった。いわゆる国際分業ということなのだが、橋渡し役のブリッジSEのコストがオーバーヘッドとなってうまくいかないことも多々あると前田は聞いていた。
ベトナムのオフショア開発拠点のメンバーに渡すプログラムの開発仕様書の英訳については、機械翻訳の性能がある程度上がってきているため、なんとか形になりそうだ。ただ、着物業界独特の用語の翻訳辞書が、どれくらい整備されているのかは未知数である。だが迷っている時間はない。やってみるしかない。
これまでに、ユーザーである呉服の桐生と合意したカスタマイズ項目を直販部や販売部の顧客管理に関する機能別のまとまりに分けた。これらのまとまりをバッチと呼ぶ。バッチの数はこの段階で３つになった。これらのバッチに関する開発仕様書などを揃えて、ベトナムの協力会社に、プログラム作成の委託を行った。
カスタマイズ機能のオフショア開発スケジュール（予定）は、次のようになっていた。
10月21日（月曜日） 第１回バッチ ベトナムへ出荷
11月5日（火曜日） 第１回バッチ、日本に納品
11月12日（火曜日） 日比谷ソフトウェアにて、第１回バッチ受け入れ（うけいれ）テスト（すなわち委託側によるプログラムの品質レビュー）完了
10月28日（月曜日） 第２回バッチ出荷
11月11日（月曜日） 第２回バッチ納品
11月18日（月曜日） 第２回バッチ受け入れテスト完了
11月5日（火曜日） 第３回バッチ出荷
11月19日（火曜日） 第3回バッチ納品
11月26日（火曜日） 第3回バッチ受け入れテスト完了
第１回バッチは、10月21日（月曜日）にベトナムの協力会社に配信された。日本にいる日本語の堪能なベトナム人2名がブリッジSEとなり、ベトナム人5名の現地チームで作業をし、日本に引き渡される予定であった。2週間後（11月5日）、出来上がったプログラムが到着し、早速前田、チームメンバーの中堅のSEである岡田篤、そして、新人の桜田で、受け入れテストが始まった。が、結果は、思わしくなかった。プログラムが開発仕様通りに動かない。こちらから渡した設計書に欠陥があったのか、英訳がうまくいかなかったのか、明確に要件を落とし込めていなかったのか、またはプログラムに問題があるのか、ブリッジSEを含めて、検証作業を行ったが、予定の11月12日まで終了することができなかった。
第１回バッチの開発作業と並行して発送された、第2回バッチがその前日11月11日に納品された。第1回バッチ検証作業が終わらないままの次のバッチの受け入れテスト開始に前田は不安を感じたが、もっと前田を不安がらせたのは、この時点でも終わらない呉服の桐生の佐々木チームからの仕様追加と変更であった。
第１回のバッチ納品が行われた11月の上旬に、コーディング業務の進捗報告を兼ねて、佐々木からの要望で、週一回（毎週火曜日）の定例会が必要に応じて金曜日にも追加されることになった。スケジュールはさらにタイトになったが、前田はこの対応から佐々木チームが、やっと本格的に自分たちが担うべき役割を自覚して、プロジェクトへの積極的な参加意識をもってくれた結果だと前向きに思っていた。しかしそれは前田の勘違いだった。
３回目のバッチが納品された翌日11月20日（水曜日）、佐々木から呼び出しを受けた前田は、検証作業を岡田に任せて、呉服の桐生に出向いた。
「SF1が参照する発注処理データのことだけど、業務部門の担当者から閲覧できる過去の発注書をできるだけ多く、具体的には過去10年分を裏で保管して欲しいというんだよ」と佐々木は言った。
「えっ、以前申しあげましたが、SF1では、クラウド上に格納されるデータ量や保管期限がこのように制限されているんです」と前田は、「データの保管について」と書かれた資料を見せながら、佐々木に説明した。
「そうだよね。私も過去3年分という保管に関する仕様については、担当者に言ったんだよ。でもさ、過去の履歴データを参照できなければ不便だって、言い張るものだから」
「それは無理です。最初の約束とは違います」と前田は詰め寄った。
前田の言葉を無視して、佐々木は続けた。「おたくらは、システム開発の専門家でしょう。なにか方法があることは私だって容易にわかるよ。例えばさ、履歴データを外部の保管場所に格納しておいて、瞬時に拾いにいけるとかさ、なんか方法を考えてよ」
「今この時点で、データ容量の再見積もりとか、データベースの再構築などをしていると、スケジュールは間違いなく遅れます。開発を一旦中止して、PMBOK🄬が言っているように、この変更のコストやスケジュールの及ぼす影響、そしてそれに伴うリスクを再評価するのが筋だと思います」と前田は言いながら、（このように佐々木さんを追い詰める言い方は逆効果かもしれない。彼だって困っているのだから、お互いによく話し合って解決法を探っていくべきなんだろう） という思いが頭をよぎった。
しかし前田の中で（でも無理、もう時間だってないし、まだ最初のバッチのチェックだって終わっていないのだから）と否定するもう一人の自分がいた。
「ともかく持ち帰って内部で検討してみます。2～3日お時間をください」と前田は帰り支度を始めた。
「前田チームに期待しているよ。君たちは優秀だから必ず、なにか方法を考えてくれると信じている」と安心した表情で佐々木は言った。
「ついで、っていえばなんだけど、実は、顧客接点として複数ある既存業務でそれぞれ割り振っている顧客の識別IDが今、５つあるよね。これを名寄せするにあたって、6つ目のこの種類を追加して欲しい、という要求が上がっているんだけど。これは簡単だよね」と、佐々木は続けた。
要求項目は、そのほかに２つあった。それらの資料を前田に見せながら、話を続けようとする佐々木をみて、前田は、話をこれ以上続けると不毛な会話になるような気がした。
「御社からの要求事項を明確にして、メールで提示してください。それを次回の進捗会議で、検討させてください」と伝え、佐々木との会話を打ち切った。
←第15話：「顧客」とは誰か 第17話：メンタル不調のサイン→
