１０ 絶体絶命
２０２０年１月。
本来であればその年の無事や安全を願う初詣の時期である。だがこの年は非常に多忙な状況と共に始まった。
昨年１０月に、限られた体制の中でスケジュールを延伸し、一部をＡＰＩとして提供することにした業務共通チーム。当時の状況を理解してもらうためにもう少し解説しておくと、開発に必要な期間は、体制によって決まってくる。
例えば４ヶ月間で５人を必要とする作業量は４ヶ月×５人で、２０人月（にんげつ）と表現される。言い換えると、２０人月の作業を完了させるには、１ヶ月あたり５人が稼働できれば、４ヶ月間のスケジュールで完成できるという意味でもある。ここに人が足りずに、例えば３人しか作業に入れないのであれば、必要な期間は２０人月÷３人となり、７か月近くかかるということになる。
先般の共通チームのスケジュール調整は、まさに設計に入れる人数制限のために行われた変更であった。そして計算上単月当たりの稼働人数に抑えることはできたのの、もともと作成予定だった共通機能の設計とガイド、本体の実装に加えて、「ＡＰＩを先出しする」という作業が追加されたことで、実はチームとしてやることは当初より増えていた。
増えた作業は調整と引き換えの借用書のように、チームにとって早く返済しなければならない重荷となっていた。ＡＰＩ提供を速やかに片づけ、早く本線の作業に戻らなければ、またその先のスケジュールに影響してしまう。
ここで、共通機能は業務アプリの実装に組み込まれて機能することは何度も書いた。その際、想定通りの動作となることも担保できていなければならないが、業務アプリがまだ存在していないため、業務アプリに見立てたテスト用のアプリを作って、共通機能を組み込んで稼働確認を取る必要があった。
例えば彼らの開発機能の１つに銀行や信用組合などの金融機関を検索するための機能があり、これをテストするには、用意した全ての検索機能を使うようにテストアプリを開発する必要があった。テスト対象のＡＰＩごとに検索条件を画面から入力して結果を画面で検証するのだが、このような場合数十種類近いテストアプリを用意する必要がある。１つ１つのＡＰＩごとにテスト用画面を用意すると非効率なため、テストについても段階的進める工夫が取られていた。
まず、ＡＰＩをＪａｖａのみのテストクラスから呼び出し、テストをする。次に代表的なＡＰＩを組み込んだテストアプリを用意し、画面から呼び出して稼働させてみる。このように段階的にテストをすれば、テスト用アプリも最低限必要のものだけを用意すれば良いことになる。このとき前者を単体テスト、後者を内部結合テストと呼んだ。内部結合といっているのは、結合テストと呼ぶとプロジェクト工程である結合テストと混同してしまうことから、チーム内に閉じた結合テスト、という意味でそのように呼んでいた。
前置きが長くなってしまったが、１月はまだ続く実装に加えて、単体テスト、内部結合テストを機能ごとに実施する必要があり、当然ながらテストアプリの開発も並行して進められていた。
２０２０年２月１日。
未だ右往左往している業務共通チームだが、ここへ来て様々な問題が表面化してしまう。まず共通機能を動かすテストアプリ自体が、色々な仕様を取り込まなければならなかった。システム日付を管理するカレンダー機能は、システム日付、運用日付、テスト日付など、用途によってさまざまな日付を扱うため、実施したいテストによって日付の定義を読み替える必要がある。その日付も、データベース、設定ファイル、ＯＳ、他システムなど様々なところにあるため、カレンダーコンポーネントをテストしようとすると、色々なシステムを繋げる必要があった。端末やサーバ、ソフトウェアとの接続に多くの時間がかかり、計画を定めた時点で作業量が正確に見積もれていなかったことに、テストして初めて気づくことになってしまった。
だがこんな問題はまだ序の口に過ぎない。
次に機能間の参照問題というのが発生した。ある機能を動かそうとした場合に、別の機能が必要になる、という問題である。ログインコンポーネントでは、どこからログインしてきたのかという情報を保持しておき、画面遷移ボタン経由で業務アプリに情報を引き渡す、という仕様になっていた。この場合、画面遷移ボタンが完成していなければ、ログインの機能をテストすることは出来ない。
しかしながら、画面遷移ボタンは大手製作所から追加で依頼された機能だ。先方との約束で画面遷移ボタンはＡＰＩのみを作ることになっていたため、この担当者もログインを動かしてテストすることが出来なかったのである。
このような機能間の参照問題は、詳細設計をして初めて明確になるため、作業を進めてみなければなかなかわからない。一方チームはコンポーネントごとに独立したスケジュールを引いていたため、参照問題の存在にも後から気付くこととなってしまった。
このような作業間の関係は整理して計画するべきだったとも言えるが、この時の三宅は、チーム内で発生する様々な問題 ―エンジニアの個人的なものから、スケジュール遅延時の調整など― を１つ１つ解決しながら、何とかやりくりしていた状況であり、そこまで気が回らなかった。
設計者の新島も、ダメな設計を１つ１つ再設計するという作業に注力してきたため、スケジュールの前後関係にまで頭が回らなかった。
そうはいっても、納期は決まっている。何としてでも間に合わせる必要がある。この事態が発覚してすぐ、三宅はふたたびスケジュール調整に乗り出した。
「２月１１日～２２日までに２週間ある。この２週間で、ＡＰＩの作成と並行しライブラリ機能のテストを進め、２５日に全体を統合した内部結合テストを実施する。そうすれば、２月末である２８日にリリースすることが出来るはずだ。」
頭の中では、このように考えていた。
一方チームメンバーたちにとっての作業環境も過酷であった。機能のテストをしようとすると、何か問題が生じる。テストによる不具合ではなく、テストできる環境を作るための問題ばかりだ。だが思いとは裏腹に、肝心のテストは一向に進まない。進まないことで、進捗が遅延し、それがストレスになる。
２月２５日。
前の週の１８日時点での進捗報告では、ライブラリ機能のテストが進んでいなかったが、１週間で着手出来るとメンバーから報告があった。だが、１週間たったこの日、さらに決定的な状況に陥っていることが発覚した。その日、共通チームの進捗会が行われ、メンバーの石崎からの報告が行われた。
「三宅さん、ライブラリ機能ですが、デプロイしてもエラーになってしまいテストが進みません。このままのスケジュールだと、絶対終わりませんが、どうしましょう。」
単独で動くと考えていたライブラリ機能が、まだ稼働させることが出来なかったのである。さらに悪いことに、動かない原因が分かっていなかった。
「そんな状態ではもうダメですね。一度立て直しましょう。」
三宅は、この事態に対して、原因を特定するための期間と追加のテスト期間を設けようと、改めてスケジュールを２週間伸ばせないか調整しようと判断した。
「姫宮さん、このような状況ですので、今月末のリリースは出来ません。リリースを延長したいと考えています。」
だが、２月末に機能をリリースするというのは、プロジェクトとしてのクリティカルパスである。さすがにそれ以上延ばせる状況ではなかった。
「そうかもしれないけれど、２月末のリリースはクリティカルパスになっているし、このタイミングで延ばすというのは影響が大きすぎる。このタイミングでリリースしようとしていた意味を、理解して欲しい。」
姫宮からの返事は、冷たかった。
クリティカルパスとはスケジュール管理における用語で、工程の開始～終了までを成す作業のうち、最小かつ最長の経路のことをいう。例えば今やっている作業Ａと他に並行している作業Ｂがある場合に、作業Ａを終わらせても、作業Ｂが終わらない限り次の作業が進められない場合、作業Ｂのことをクリティカルパスという。そしてこの時、共通機能をリリースすることはプロジェクト全体のクリティカルパスとなっていた。それを変えるというのは、プロジェクト全体のリリースを伸ばすということと同じくらいのインパクトがある。
だが、チームはこの１週間ほぼ徹夜で作業をしており、既にメンバーの疲労も極限に達していた。同時に、三宅はそれを当然見逃すわけには行かない事態と考えた。
「でも、今のままだと動いてもいませんし、絶対に無理です。」
三宅は三宅で事実と向き合い、冷静に考えた上での判断だ。
だがプロジェクトとしても簡単に容認することは出来ない。具体的に何がどう問題なのか、姫宮は確認しようとした。
「いや、その前に基盤フレームワークのメンバーにも確認しているの？テスト環境であれば彼らの方が詳しいはずだろう。」
「それはまだしていません。」
「では、今日中に確認して、とにかく原因を究明しよう。実装までは終わっているわけだし、動かないものが動けば、走り始めるはずだから。」
下を向きながらしばらく黙って考えていたが、三宅は渋々答えた。
「・・・わかりました。」
姫宮は、もしここで先送りすることになってしまえば、また余計な借金を増やすことになり、悪循環が続くことを恐れた。何とか約束のリリースを果たしたうえで、その先のスケジュールを調整した方が良いはずだった。だが、そんな思いも虚しく、翌日再び恐れていた事態が発生する。
「姫宮さん、本日は朝から体調不良で動けません。リリース直前でご迷惑をかけて申し訳ありませんが、お休みします。」
「そうか。これまでずっと大変だっただろうから、今日はしっかり休んで欲しい。」
そういうと、三宅はそのままかかりつけの医者の診察を受け、直ぐに結果の連絡があった。これ以上、三宅はこのプロジェクトで働くことが出来ない、ということであった。大島のときと同様である。またしてもこのプロジェクトの犠牲者を出してしまった。
姫宮は知らせを受けてしばらく、年が明けてから数週間、必死でチームのマネジメントを担っていた三宅の姿を思い返しながら、オフィスの天井を見つめていた。そこには一組だけ、半分明かりが消えている蛍光灯があることに気付いた。
「ああ、自分はこんな身近な変化にすら、全く気づけていなかったのか・・。」
その壊れた蛍光灯の景色と、今回の三宅の変調に気づけなかったことを、重ね合わせずにはいられなかった。だが、なってしまった以上、決して元には戻らないだろう。ただただ後悔とともに、数日前のあの時の三宅の気持ちに思いを寄せると、さらに涙が出そうになった。
会社のために所定時間以上の時間を費やし、ついには力尽きた。そのようなメンバーを、何人生み出し、何度ダメにしてきたのか。そこまでしてプロジェクトを進める意味とは、一体何なのだろうか。
何より共通チームは昨年、半強制的に複数のメンバーが入れ替わったが、その都度後任に引継ぐこともままならず、一からやり直しを繰り返してきたという辛い経験がある。
エンジニアにとっての仕事の半分は、調べたことを理解し、頭の中にストックしておくというノウハウ蓄積がある。ドキュメントを追っていけば分からなくはないが、何百枚というドキュメントを一から探していくことと、前提知識があるのとでは雲泥の差がある。そのため、要員が離脱した際のダメージは非常に大きいのだ。要員の入れ替えが多いプロジェクトは、ほぼトラブルの原因になるとすら言われている。
ましてやチームリーダーには、チームの全ての情報が集まるようになっている。リーダーが離脱したということは、チーム運営自体を一からやり直すことと等しい。この事態に対して考えなければならないことは山ほどあると考えられたが、この時は目先のリリースに全神経を集中した。
三宅が倒れた２６日の段階で、姫宮がチームリーダーを代行し、残り３日間でどのようにリリースできるのかをメンバーと話し合った。そこには、基盤フレームワークリーダーの神城も同席し、技術的な方法での解消を図っていくことにした。
「では、ライブラリ機能については私の方で確認しますよ。」
そういうと神城は、いつものように淡々と作業を進めていった。
そして翌２７日。
「原因が分かりました。基盤フレームワークに対する参照定義が間違っています。データベースアクセスする機能が、フレームワークのルール通りに実装されていません。これだと単独で機能するのは不可能ですね。」
これまでの共通チーム体制の弊害が、膿となって出始めた瞬間だった。
「そんな、何故ルール通りに実装されていないんだ？」
姫宮にとっては全てが後の祭りである。ここまで担当者に任せっきりだったとは。しかしながら原因が分かったことで、修正すべき内容も明確になった。この参照問題は神城によって修正され、予定通り２月末に、共通機能をリリースすることが出来た。
安堵したのも束の間、その２日後に、今度は大手製作所より、画面が動かないとクレームが生じた。画面遷移ボタンはＡＰＩしか提供していない。動かないのは当たり前だろう。ところがこれでは約束と違うと、銀行も巻き込み大炎上していった。この頃銀行のフレームワークの担当である亀村調査役が姫宮のところに飛んできた。
「姫宮さん、共通機能が動かないと、大手製作所が凄い勢いでクレームをいってきてますよ！何があったのですか？」
「え？どう言うことでしょう。大手さんとはどれをいつリリースするのかということで合意していて、その通り提供したはずなのですが。」
「よくわからないのですけど、大きなクレームになっているため朝から銀行内は大騒ぎになっています。とにかく一度事情の説明をお願いします。」
「わかりました。」
そう言って、朝から巻き込まれている熊手部長に対する説明の場が用意された。
「ＧＣＳＣさん。大手さんが言うには、画面遷移ができない中途半端なものが提供されているということです。いったいどんな状況になっているのですか？」
「大手さんとはコンポーネントごとにリリース時期を合意しています。画面遷移をするには画面遷移ボタンが必要になりますが、それは業務共通チームで開発することになりました。その代わり、現時点ではＡＰＩのみを提供することになりました。」
「だとしたら、彼らは何故こんなに大騒ぎしているのでしょう？」
横から亀村調査役が割って入った。
「彼らは画面遷移が出来ないと言っていますが、単体テストでは画面遷移までテストするつもりだったと言っています。でも実際には画面遷移出来ないので、このままだと実装が終わらないと、このような言い分となっているのです。単体テストをどこまでやるのかって、既に決まっていますよね？」
「はい。もちろんです。」
「ではそれは、どのような内容で合意していたのですか？」
事情聴取のように質問が続く。
「こちらからテスト手順を示していますが、単体テストではテストクラスを作ってテストして頂く想定です。それに対しては特に機能制限があるということではありませんが。」
この会話で、単体テストに対する決定的な考え方の相違が伺えた。ＧＣＳＣで定義している単体テストでは、Ｊａｖａクラスによるテストを指している。それに対し大手製作所のそれは、実際に画面を操作するところまでを定義していた。そこで改めて、大手製作所とかぞく銀行を交え、確認の場が設けられた。相手は、大手製作所のプロジェクトリーダー森下と、サブリーダーの寺岡である。こちらは、新島、姫宮、東山とで臨んだ。
「ＧＣＳＣさんは合意していた機能を提供していると仰っているのですが、大手製作所さんは何が不足していると仰っているのでしょうか？」
亀村調査役が促す。
「はい。そもそもこのプロジェクトは勘定系もフロントシステムも更改と、全て更改する前提です。全てが初めてではさすがに次の工程のリスクが大きいですし、我々は画面も動く『正しい状態』を確認した上で実装を固めたいのです。」
一旦こちらの主張は置いておくと、彼らの言っていることはプロジェクトのためであるし、当事者であれば同じように思っただろう。得体の知れないフレームワークがどんなものなのか、早く確認を済ませたいという気持ちは良くわかる。それをするには、さっさと動かしてしまいたい。
「大手さんのお考えは分かりますが、開発工程はＲＦＰでも示していましたし、勝手に基準を変えるのであれば、自社で解決すべき話ではないのですか？」
亀村調査役も、冷静に取り仕切る。大手側にしてみればこの先のスケジュールを案じての主張である。が、冷静には亀村調査役の言う通りだ。同じ立場だったとしても、つくづく銀行だけは敵に回したくないと思った。だが森下も主張を曲げるつもりはないようだ。
「勝手にとおっしゃいますが、業務アプリの実装をするのに、共通機能が動かないのは逆に正しいのでしょうか？我々が認識しているリリース計画はこちらでした。」
そういって、証拠となるマスタースケジュールを指し示しながら説明された。
「この段階では、共通機能としてのリリースは２回であると明確に書かれています。１回目が今回、かぞく認証が５月末と言われている程度で、画面遷移まで５月末になるとは書かれていません。現時点が予定通りだとすると、逆に２月末では何の完成を目指していたのですか？」
交渉では過去に何を合意していたのかが重要であり、それを証明するエビデンスを提示した側が正しい。これは契約の大原則である。そしてそのスケジュールは、確かに姫宮が送ったものだった。
だがマスタースケジュールとは別に、コンポーネントごとに細かく提供時期を決めてきたはずだ。
「大手さんとは、過去の複数回の打ち合わせの中で、個別にリリース時期を調整しています。これがその時に使用した資料です。」
そう言って姫宮も、調整会での資料を投影した。
「この調整会の際に、画面遷移ボタンは２月末ではＡＰＩを提供するとお伝えしており、合意頂きました。その際、画面遷移ボタンはこちらが開発することになった代わりに、２月末ではＡＰＩのみ提供することになりました。」
事実としては以上でしかない。
「仰ることはわかりましたが、弊社側の誰かと調整したということですか。」
隣の寺岡は当事者だ。さすがに彼とは認識が一致しているだろう。直ぐに反応した。
「はい、確かにその説明は受けましたが、そういう機能制限があるという説明は受けていませんでした。」
時期は合意したが、中身は承知していないということか？あの時は確かにスケジュールにしか興味が向いてなさそうだったが、でもそれでは結局何を合意したというのだろう。それを確認しようとしたが、森下が先に進めてしまった。
「聞いていたけどそれをうちは、何も考えず承諾した、ということ？」
「何も考えてなかったということではありませんけど、画面遷移ボタンはこちらが依頼した機能であって、それがないと画面遷移できないとは考えていませんでした。」
寺岡氏の回答も正直であった。あの時こちらはスケジュール調整が目的であったため、確かにどんな影響があるのかまでは説明していない。その後しばらく二人でボソボソ話していたかと思うと、森下はこちらを向き、腹を決めたように話を進めた。
「そういうことですか。合意していたというのならこちらの認識相違だったようです。すみません。ところでＧＣＳＣさんのその資料は、我々に送付頂いているのでしょうか？何を合意していたのか、社内でも今一度確認してみます。。」
先程の話に納得してくれたのだろうか。
「はい、ご確認宜しくお願いします。」
「ありがとうございます。」
その言葉を聞くと、姫宮は決着したと少し安堵した。だが、彼らの主張は止まらなかった。
「でもそれが事実としても、画面を動かせるのが５月末を待たなければならないなんて、プロジェクトとしてリスクが高すぎませんか？ＩＴ１まで１ヶ月しかないということになりますが、もしその時になって動かないということになれば、テスト未消化のまま数ヶ月ロスする事になりますよ。銀行さんとして、それで良いのでしょうか。画面動かすだけであれば、何か方法はないのですか？」
銀行の立場も汲み、それを理由にむしろ畳みかけてきた。この時は亀村も腕組みし、頷きながら聞いていた。
「森下さん、確かにＩＴ１工程を始めることを考えると、５月末に画面動かして致命的な事が起きると、次工程には進めませんね・・ＧＣＳＣさん、今ようやく正しく状況を理解しましたが、このままだとリスク回避のための単体テストにならない気がします。何とか早めてもらうことは出来ませんか？」
交渉は結果が全てである。経緯についての言い分は理解されたが、そこは彼らにとってのゴールでは無い。逆に姫宮はそこで話は終わりだと思ってしまったため、この質問に答えは用意していなかった。
「・・・それは、持ち帰り検討が必要です。」
だがそこへ、ここまでの話を黙って聞いていた東山が静かに口を開いた。
「大手さんとしては、画面が遷移できれば、宜しいですか？」
？？？突然何を言い出すのだろう。画面遷移の機能は５月末と決めているのに、まさか早めるとでも言い出すのだろうか。それではせっかく調整したスケジュールが水の泡だ。
「はい、この際何かのツールでも結構ですが、画面を遷移させて、実際の遷移の定義が間違ってないかを確認したいのです。」
森下は東山の話に乗ってきた。
「わかりました。もともとＡＰＩのみで合意していたのですが、それだと大手さんの画面遷移テストが出来ないという事ですので、ＡＰＩにデータを詰められるスタブを準備することにします。一時的にそのツールを使っていただく必要が出て来ますが、それで動かすことは可能です。」
何の話だろう。今まで一度も聞いたことがない解決策だ。
「そうなのですか。そんなことができるのであれば、是非お願いしたいです。」
「ご希望ということで我々も予定外作業として行いますので、その先のスケジュールは改めてご相談させて頂きます。」
「わかりました。我々の要望という理解は間違っていませんので、スケジュールも調整可能です。」
その会話は、ものの５分。東山による、奇想天外な解決策であった。普段結びつかないもの同士が、くっ付けられたような感覚だ。
画面を動かすには、情報を設定するためのプログラムを完成させなければならない。ただ、東山によれば、プログラムではなくダミーのデータにしておけば良いという発想だった。通常ルートに沿っていくと一時間かかるところ、近道となる道を簡単に見つけてショートカットし数秒で済ませてしまう。彼の繰り出す解決策は、言われてみると確かに、と納得するが、いざ当事者となると飛躍しすぎていて思いつかないことばかりである。東山は、自分の体の一部であるかのようにプログラムを使いこなし、この問題についても１週間も立たないうちに解決してしまった。
だがこの時点で早くも３月１５日。残り２ヶ月半で、共通機能を全て完成させなければならなくなった。
東山の起点で窮地は救われたが、三宅という大きな犠牲も発生した。さらにスケジュールを伸ばすと、他の作業が増える。その間に他のスケジュールが遅延する。そしてまた計画変更が余儀なくされる。何度も繰り返してきた悪循環だが、ついにその調整手段も潰えてしまった。いよいよスケジュールのデッドエンドが迫ってきた。
そして、先の画面遷移問題の対応も加わり、この時点で５月末のリリーススケジュールに、さらに１ヶ月の遅れが生じていた。残された期間はあと２ヶ月半。これを今のメンバーでキャッチアップするのは、逆立ちしても出来ない。
遅延の中でメンバーの疲労も限界だ。無理のないスケジュールとしなければ、今度こそチームは瓦解してしまうだろう。全員が疲弊した中で、今は亡霊のように毎日のルーチンをこなしているだけだ。この中から前向きな計画など出てくるわけがない。いっそのことチーム全体を１週間は休ませたいくらいだ。さらにそんな中、チームの中で主要な委託先となっていた、緑システムの大畑氏から、突如申し入れを受けた。
「姫宮さん、私たちはもう限界です。三宅さんからはこれまでスケジュールだけ守るように言われてきました。でも結果はこのザマです。ろくにテストのやり方もわからずに開発なんて出来るはず無いじゃないですか！そんな中で５月に次のリリース？そんなスケジュールを無理強いするなら、もう撤退させて頂きます。」
責任者として、今の労働環境はどう見てもブラックだ。三宅という調整役も失ったタイミングで、ここぞとばかりに大畑が訴えてきた。
「大畑さん、皆さんには２月末のリリースで本当に頑張って頂いて助かりました。あと少しのところですが、何とか立て直す方法を考えて貰えないでしょうか。」
「はあ？こちらの話を理解していますか？こんな体制とスケジュールではもう無理だと言ってるんです。どこまで働かせれば気が済むんですか！」
そういうと、机を叩いて行ってしまった。
当事者たちができないと言う以上、プロジェクトは進まない。そのためメンバーの意見は最も尊重すべきだ。ここまでのスケジュールは、リーダーの三宅が作ってきた。だが、メンバーの立場としては、実現可能性があったわけではなかった。
あの時スケジュール調整する前に、もう少し体制を補強できていれば。管理者を増やして三宅の負担を下げられていれば。姫宮の頭の中では、この先の予定どころか、過去の後悔しか思い浮かばない。だが全ては後の祭りである。ここまで来ると、遂に万策尽きてしまった。
さらに今回の一連のトラブルを聞きつけたＧＣＳＣの本社より連絡があった。
監査チームがプロジェクトを訪問し、事態を監査するということになったのだ。ＧＣＳＣでは、年間数百ある社内の全プロジェクトを、トラブルなく成功させることが課題となっている。上からとにかくやれと言われたプロジェクトで、取り敢えず集まった人たちが、言われるがまま進めた結果トラブルになる例が後を絶たなかったのである。このような現象はむしろ当たり前のように発生しており、業界そのものの課題でもあった。
システム開発のプロジェクトが成功するためには、要員スキルが把握できた上で、要件の確定度合いやスケジュールなどの契約条件、顧客のとりまとめ力、アサインのタイミングといったことがきちんと整合していることが重要である。逆にそうでない状態をアンマッチやミスマッチの状態という。
そのようなミスマッチの状態で進んでいくプロジェクトは、いわゆるデスマーチと言われる行軍になり、放置しておくと大きなトラブルと化してしまう。。そうならないように、プロジェクトの実施にあたって一つ一つクリアしなければならない条件を確認し、組織として評価するための取組みが行われていた。
そして監査の日。監査チームリーダーの野田と対面した。
「姫宮さん、先日のトラブルは収まったそうですが、この先の計画はどのようになっていますか？」
監査チームの野田氏が質問してきた。彼は社内におけるプロジェクト管理の権威であり、過去２０年に渡りプロジェクト管理や監査のルールを作ってきた、その世界の仙人のような人物だ。良くも悪くも、様々なことを知り尽くしている。彼の眼鏡の奥から、大きく鋭い眼差しが姫宮を見つめて来た。
「リーダーの三宅が倒れてしまい、私が代理を勤めている状況です。引き継ぎもありませんでしたので、計画の見直しには今しばらく時間がかかります。」
姫宮は疲れきった様子で現状を素直に説明した。
「現時点で、計画がないってこと？時間かかるって、いつまでなの？」
急に口調が変わった。何かのスイッチが入ったのだろうか。
彼らは外部組織としての独立性を保ち、あくまで第三者として監査している。これまで三宅やチームがどれだけ苦労してきたのかなどは関係ない。彼らにとってはこの先の計画の有無だけが重要なのだ。
「来週までには考えます。」
忙しい時にばかりこういうのがやってくる。正直、結論を持っているならさっさと出して欲しいと思った。
「来週っていつ？リーダーがいないのだよね？姫宮さんはただの繋ぎだしさ、交替の目処は立ってるの？」
「チームメンバーや顧客に対するフォローはどうなってるの？計画仕切り直すことは伝えているの？」
「大体今回の問題の原因はわかってるの？それに対する対策がないと次の計画立ててもまた守れませんよ！」
彼らの正論に基づく質問が、矢継ぎ早に繰り出された。
「リーダーの交替については本部と相談中です。顧客やチームには、今の計画に従って遅延のまま進めてもらっています。問題の原因は、実装レビューが不十分だったことにあります。」
「それだけではないよね！」
まだ説明しようとしていたところ、話を遮られた。
「今の時点で交替も決まっていない。メンバーには遅延のままずるずると残業させてる。問題点は原因がよくわからない。こんなの完全に終わってますね。とにかくリーダー代行だというのなら、貴方が再計画、レビューを行う前提で、早急に計画を考え直してください。」
「わかりました。」
ようやく結論と思しきものが出てきた。これを聞けば話は終わるだろう。姫宮は流れに身を任せるように、野田の話を聞いていた。そもそも監査チームの意見は常に正論であり、その考え方から少しでも外れているプロジェクトの意見は全て否定されてきた。そのスタンスは形式的だと社内でも煙たがられていたため、多くのプロジェクトでは監査をどうやり過ごすか、ということに関心が向いているものだ。
だが、結論はこの事ではなかったらしい。
「それから、我々監査チームとしては、このプロジェクトに対して緊急事態を宣言します。経営に報告しますから、本部とよく相談して立て直してください。」
もうどうにでもしてくれ、という気分だ。今更何を言っているのだろう。プロジェクトとしては、大島が離脱した頃からずっと緊急事態と言ってきたつもりだ。やり場のない悔しさを置きざりにして、トラブルの根本原因究明と至急の立て直しが指示され、監査は終わった。
この先どうなってしまうのか。姫宮の２０数年間のＳＩ経験の中でも、緊急事態というのは立ち入ったことがない世界だ。何か考えるように指示を受けたようだが、目の前の情景をただ呆然と眺めていることしか出来なかった。
２０２０年３月末。
世の中は新年度に向け慌ただしいが、この頃は暖かい春の陽気が待ちどおしくなる、希望に満ちた時期となるのが一般的だ。
だがチーム「レインフォース」にとっては先が見えず、どうなってしまうのか全く予想も出来なくなった。そしてその時間は、とてつもなく長く感じられた。
この記事が気に入ったらサポートをしてみませんか？