９　前進と退却の攻防

　２０１９年８月。
　浅草では、盆休み前に墨田川で灯篭流しが行われる。無病息災や事業成功など、祈りや思いを何かに託すことは、文明の発達した時代にあっても、不完全な人間にとって必要な営みなのだろう。このプロジェクトでも初期の思いが託された業務共通チームであったが、いざ実践となると、なかなかうまくいかない。いっそのこと初期の思いを断ち切ったほうがどれだけ楽になるか。その考えが、何度も皆の頭をよぎっていた。
　この時期、プロジェクトへ着任してから１年が過ぎていた。開発工程としては、業務アプリが基本設計に着手して２か月が経過。業務共通チームの芳しくない進捗に対し、業務アプリの設計は着々と進んでいた。
　業務アプリケーションの設計には、いくつかの構成要素があり、それらを駆使して一つの業務システムの設計となっていく。まず画面設計書で入力フォームのレイアウトや項目を定義し、機能設計書で個々の処理の仕様が定義される。また他システムインターフェース設計書では、関連するシステムとのＡＰＩの仕様を定義する。そして業務共通チームの設計は、これら業務アプリの設計と密接な関係があった。
　チェックコンポーネントであれば、共通チームで画面入力項目に対する標準的なチェック仕様を定義し、業務アプリの画面定義書で、どの仕様を適用するのかを一つ一つ決めていく。ログインパスワードに必要なチェックであれば、チェックコンポーネントのうちパスワードチェックを当てはめていく、といった進め方だ。家を建てる場合で言うと、窓やフローリングの素材をどれにするか、カタログから選んでいくイメージだ。
　チェックであれば分かりやすいが、取引履歴などは、次期システムの要求を取り込むため、業務アプリの基本設計の完了を待たなければならなかった。
　待つだけで良いなら何も問題はないが、共通チームもこの後は実装というプログラミング工程が控えていた。逆に、業務アプリもあと４ヶ月ほどで実装工程に入っていく。さらにその前提として共通機能が業務アプリに組み込める状態になっていなければならない。フローリングのカタログはあっても、実物が存在しないのでは、家の建築は進まないのだ。このプロジェクトにおいて、カタログとそこに掲載されている部品を開発するのは業務共通チームの仕事である。つまり、この前後関係の逆転は、このチームが何とかして取り戻さなければならなかった。
　そんな彼らが開発する機能の例をあげると、以下のようなものである。
・履歴
　銀行システムが必要とする履歴情報は、顧客が後で参照するお取引の記録、セキュリティ設定に関する変更履歴、システムエンジニアが障害解析の際に参照するシステム履歴などがある。各履歴の目的と要件はそれぞれにあり、取得項目やデータのライフサイクル、アクセス権などが全て異なった。現行システムでもこれらの履歴は取得しているが、一つだったシステムが次期システムでは勘定系とフロントシステムに分割されるため、双方の役割分担と、それによりデータベースの構造をどのようにするかも決めなければならなかった。
・取引認証
　振込など資金を動かしたりする際に行う認証機能だ。ログインとは異なり、手続実行時のセキュリティリスクに応じて認証要素を変更できることが要件であった。例えばスマホを使ったかぞくスマート認証、ワンタイムパスワードによる二要素認証などを用いることで、取引によって組み合わせを選択することが可能になる予定だ。この取引認証はフロントシステムの機能の中ではもっとも複雑で、これだけでも小さなシステムが作れるほどの規模となっていた。
・エラー処理コンポーネント
　システムが正常終了しなかった場合に利用者に適切なメッセージを表示し、後続の操作を正しく誘導することで、誤操作の防止を図るものである。エラーはさまざまなことが原因で発生する。入力値の誤りや、ハードウェア障害などだ。エラーは色々なところで発生するが、その際の誘導は、システムとして決まった動線を確保しなければならない。このため、どこでどのような例外が発生したのかを正しく識別できることや、その際に表示する統一のメッセージ、画面誘導などの機能を開発することが求められた。

　これらを、業務アプリと業務共通とで役割分担された設計を行っていくのだが、この役割分担が少し分かりにくいいため、別の例えで示そう。
　システムを支える仕組みとは、上のレイヤから下のレイヤまで何階層にもなっている。１０階建てのビルの中で、１階では受付業務を、２階では相談とコンサル、３階以上は個々の目的によりサービスフロアが分かれ、会計はまた１階で行うように、それぞれの組織分担の中で進むものだ。
　システムも同じように責任分担を決め、それに従った小さなパーツが相互に連携してはじめて、「システムは有効に機能している」と言える。
　これが組織の役割分担であれば、認識間違いがあった場合でもその都度修正を加えていけば良い。だがシステムの場合、認識間違いは設計やプログラムをもう一度作り変えることになり、手戻りがとても大きい。そのため、役割分担は最初から適切に行い、修正を発生させないことが必要である。
　その役割分担を決めるためには、ある程度どのような機能・分担になるのかたたき台を作り、アプリ担当者に説明し、理解させ、予め問題点を指摘してもらう必要がある。意見がぶつかる場合、目的に立ち戻り、一つ一つ妥協案を考えながらこれらのことを進めて行くのだ。
　ここまでのことが出来たとしても、最終的にＡＰＩのレベルで役割分担を決め、試しに実装してもらい、指摘があれば修正し、ようやく合意に達することが出来る。そこまでやって初めて、業務共通チームの開発範囲が確定となるのである。
　業務共通チームはこの点で、たたき台を作っていく情報も知識も不足していた。そのためたたき台として考えた案通りに決着することは稀であり、様々な押し問答の末にこれらは進められた。
　もちろんこのチームにも、そもそも銀行と契約合意している仕様はある。ただ、システム全体として考えられていなかった機能があると、誰かがやるしかなく、そのための情報整理もまずは彼らで考える必要があった。
　さらにその場合、当初仕様通りなのか仕様変更なのか、銀行が納得出来るよう、全て明らかにしなければならない。それをする上で、そもそも承っていた要件は何か、これまでの経緯でどのように変わったのかなど、様々な角度から経緯の整理が必要となる。設計作業を止め、それら情報の探索に多くの時間が取られるため、このようなやりとりは特に多くの期間がかかった。
　２０１９年１０月。
　設計の現場では新島の活躍により何度も進捗のリカバリーを続けてきたが、さすがに多くの機能の面倒を見ている余裕もなくなってきた。そうこうしているうちに、ついに取引認証の設計が遅れ始めた。そしてある日の進捗会議の場で、新島から状況が報告された。
　「三宅さん、取引認証はもう間に合わないから、リスケしてちょうだい！」
　状況報告というか、一方的な宣言だ。
　三宅はこの時期、毎日のようにスケジュールと要員稼働表とを睨めっこしながら、チームの遅れが出ないようにと調整を繰り返していた。それもこれも、チーム運営がなかなか安定しないため、毎週のように調整が発生していたのである。
　・夏休み中に自転車で事故ってしまい、２ヶ月間来られなくなってしまったエンジニア。
　・人の仕様書に文句をつけては自分の設計は何も進んでいない協力会社。
　・導入する製品の仕様について毎日のように問い合わせてくる銀行員。
　・新たな仕様変更を依頼してくる大手製作所。
　・日本語が通じているが正確さに欠ける中国のエンジニア。
　三宅の仕事のほとんどは、これらの対応とスケジュールの調整が占めていた。そのため取引認証が遅れているのは、三宅にとっては把握していた数ある事象の一つであった。
　「新島さん、取引認証は遅延確定ですね。今のところ、リカバリーに当てられる要員が全くいませんので。」
　新島も何とかしたい思いであったが、全てを救おうとすると、全てが失敗する。そのため、割り切るのは仕方がない判断だ。
　「そうなのよ。あたしも過去のクソみたいな設計見直してるヒマはないし、誰かアサインできるまでは仕方ないんじゃない？」
　無い袖は振れない。ただ彼らはそれで良いが、業務アプリ開発者はどうするのか。取引認証は業務アプリにとって必須の機能だ。これがなければ、業務アプリは完成しない。分かってはいながらも、三宅は腕組みしながら新島を眺めた。
　「新島さん、業務アプリチームには何て言いましょうかね。」
　「うーん。設計が出来てないのでそこだけ３ヶ月後に再開してちょうだい！というのは簡単だけど、ちょっと影響が大きそうなのよね。」
　「そうですね。何も出せないとわかると、彼らは何と言ってくるでしょうね・・。」
　取引認証について大手製作所と合意していた提供スケジュールは、２０２０年２月末。間に合わないものは仕方ないと割り切りたいが、それを調整する当事者となると、簡単には割り切れない。さらに三宅はプロジェクトに途中参戦した身だ。調整のために時間が取られるなら、自分が進めた方がマシだ、とも思った。新島も困った三宅を見て、何とかうまくいく手がないかを考えた。
　「特に取引認証って業務は使わなくても良い画面じゃない？別々に作ろうと思えばできるけど、最低限のインターフェースは決めておかないといけないのよね。」
　「何か、良い方法はありそうですか。」
　「そうね。これは業務開発者が呑むかは分からないけれど、Ｊａｖａのメソッドのうち公開用ＡＰＩだけを決めておくの。そうすれば少なくともコンパイルは通るし、今の工程では事足りるのではないかしら？」
　新島の発案したＡＰＩだけ決めておく、というのは、ある意味業務との役割分担に基づく発案だった。システムは最終的にプログラム単位に分解される。業務アプリからすると共通機能のプログラムを呼び出すのだが、呼ばれたプログラムが動かなくても、ＡＰＩさえ決まっていれば形の上では実装は完成するだろうという考え方であった。
　家づくりで言えば、窓枠だけがあり、窓の実体がない状態だ。内壁を作る側から見れば後から窓枠に何がはめ込まれようと、内壁の工事には影響はない。つまりこの時の内壁大工の責任範囲は、窓枠の大きさを確保し、型枠まではめておくことである。そしてこの考え方によって、先に業務アプリの実装を終わらせてもらおうという提案であった。あとは、多くの業務アプリ開発者を有する大手製作所が、この提案を呑めるかどうかだ。早速三宅は姫宮に一連の状況を相談した。
　「では、そもそも完成版というのはもっと先で、どちらにしてもこのタイミングでは実装に影響の無い不完全なものしか提供できない、ということで交渉しよう。」
　そこで三宅は早速大手製作所と打ち合わせを設定した。
　「・・ということで、取引認証はＩＴ１開始前の２０２０年５月末に提供することとしたいと思います。それまでは２月末にＡＰＩのみ提供しますので、実装工程には影響ないと思います。」
　相手は大手製作所の寺岡氏だ。百人規模の業務アプリエンジニアを抱えているチームのサブリーダーであった。彼の立場からすると、この提案はどう映るだろうか。
　「状況は理解しました。実装の完了基準は単体テストをパスすることですので、そこに影響ないのであれば問題ありません。逆にこちらからお願いがあるのですが。」
　少し意外な反応であった。単体テスト・・工程完了基準を考えれば、確かにもっともな理屈だ。
　逆にお願いとは一体なんだろうか。調整案を呑んでもらえたのだから、広い心で聞くことにしよう、と考えた。
　「はい、何でしょう。」
　「実はもう一つ作って頂きたい機能があるのですが。」
　「追加機能ですか。」
　「そうです。御社もお困りだと思いますが、画面遷移ボタンを作って頂けないでしょうか。」
　「はあ、どのようなことでしょうか。」
　三宅は少し拍子抜けした。
　「画面を遷移するときって、契約者番号やログイン情報を引き継ぐじゃないですか。今のままだとそれぞれの業務アプリで、ボタンを押すたびに引き継ぐためのコードを書かないといけないんです。なので、最初から共通機能として提供して貰った方が良いと思うんです。」
　三宅は少しの間拍子抜けしていたが、すぐに納得した。
　「なるほど。確かにそれはあった方が良さそうですね。」
　同時に、彼らの検討の進捗に少し感心した。こちらは一つの機能の設計を進めるだけで大変な状態なのに、大手製作所は、今回利用するフレームワークの特性を早くも理解しており、不足していると思った機能を指摘してきた。それに対しＧＣＳＣの業務チームであるサクセス社からは、これまでそのような要望は聞いたことがなかった。
　「ご理解頂きありがとうございます。では画面遷移ボタンはいつ提供可能でしょうか。」
　大手製作所も自分たちの進捗を守るのに必死であるため、次の関心ごとはスケジュールのみだ。
　「そちらも同じように２月末にＡＰＩの提供、５月末に実装版でいかがでしょうか。」
　「ありがとうございます。ではそれでお願いします。」
　打ち合わせ目的であるスケジュールの調整に少しオマケが付いてしまったが、調整は成功した。
　三宅はすぐに戻り新島に報告した。
　「調整できたのなら良かったわね。オマケの方は、アタシも考えていたのよ。やっぱり彼らは言ってきたわね。では切り替えてＡＰＩ作りましょ。誰でもできるからワンちゃんでもオジ様でも、誰でもアサインしてちょーだい！！」
　「ワンちゃん」とは中国エンジニアの王氏のことである。日本語検定一級の実力者だが、彼の設計書は日本語になりきっていないと、新島が以前から皮肉っていた。
　「オジ様」は新島が着任する以前からいた古参のメンバー達だ。古参といっても若手もおり、未だに旧態依然の考えをしていると、同じく皮肉るときの呼び方であった。
　新島には彼らをアサインする様に言われたが、せっかくスケジュール調整が成功したのに、これ以上余計な揉め事は起こされたくない。そのため別のアサインを考えた。
　「わかりました。では藤原さんでお願いします。」
　「りょーかい！藤原なら、あっという間よ！！」
　新島の単純明快さは、使い方次第である。こうして業務共通チームは方針転換し、２０２０年２月末に一部をＡＰＩ提供する前提で、スケジュールを組み替えた。
　ＡＰＩとは、アプリケーション・プログラミング・インターフェースの略である。ＦｉｎｔｅｃｈなどでいうＡＰＩとは、システム間を通信する際のデータによるインターフェースを指すが、ここではＪａｖａＡＰＩのことを指しており、プログラムのインターフェースということである。
　そしてＡＰＩを決めるというのは、引数のバリエーションを持つ複数のメソッドを決めることであった。たとえば、画面に検索結果を出す場合、検索項目をもつクラスから、データベースを操作するクラスに対してデータを渡す。その際、検索キーの組み合わせとなるものが、引数のバリエーションになるイメージだ。
　またＡＰＩは、それ自体が単独機能として動作するように設計しておかなければならない。本体の実装をする際に検索キーが足りないとなっても、呼び出す側に項目を追加してもらうことになってしまうため、後から変更することができないのだ。
　画面からの検索キーに従うだけであれば想像に難くないが、検索結果の返し方や、プログラムを流用することなども考えると、一般的にはたくさんのＡＰＩの候補が存在する。このためＡＰＩだけ作成するといっても、相当量の作業があった。加えて、この度のスケジュール調整期間を含めるとさらに遅延が拡っていたため、とにかく急いでＡＰＩを作る必要があった。
　同時に、開発者にどのＡＰＩをどのように使ってもらうのかを示すため、利用ガイドも整備していく必要があった。このガイドは中国エンジニアの王氏やオジ様たちをアサインして取り組むことにした。王たちでもできると考えたのは、先に藤原がＡＰＩを作るため、ガイドはそれを見て書き写せば良い、という三宅の考えであった。
　そして次の日。ＡＰＩ開発班の旗振り役として、藤原から王氏にガイド作成作業の進め方の説明が行われた。
　「王さん、私が順次詳細設計書にＡＰＩの仕様を記載していきますので、ドキュメントを見て、実装ガイドの作成をお願いします。」
　「はい。ガイド作るは、どこで作ると良いですか。」
　「どこでというと・・レビュー前のフォルダに入れて頂ければ結構ですよ。」
　「レビュー前はフォルダは、どこですか。」
　「まだ作っていませんので、後ほどメールしますね。」
　「はい。わかりました。」
　ぎこちないやりとりだが、この時は三宅も参加しており、一連の会話の流れを聞いていた。そのうえで特に問題はなさそうであった。
　業務共通チームがこのように擦った揉んだをしている一方で、基盤フレームワークチームでは、既にフレームワークの提供を終えたところであった。リーダーである神城と、イージー技術者集団の李、及びそのメンバーにより、完璧なまでの仕様管理が行われ、彼らの当初のスケジュール通りに完了していた。業務共通チームの混乱と比べると、さすがプロ集団の仕事、といえた。そしてこの提供物により、ＧＣＳＣはインターネットバンキングのＪａｖａアーキテクチャを構築する、という初期の目的の一部を達成したことになる。とはいえ基盤フレームワークは、所詮システム基盤としての機能でしかない。ここから業務アプリケーションの開発に落とし込むためには、やはり業務共通機能のコンポーネントが絶対に必要である。
　かつて朝比奈調査役のレビューでも何かと比較されてきた両チーム。残り数か月で、同じ水準まで持っていけるのかどうかは、三宅、新島たちに完全に期待がかかっていた。ただし彼らの活動も限界ギリギリのラインにある。日々行われる指摘と修正、新たな設計の繰り返しで、チームメンバーは疲労困憊の努力を続けていた。
　そして２０１９年１１月末。
　１ヶ月後には２０２０年、そこからいよいよ業務アプリ開発の詳細設計・実装工程が開始される予定であった。その工程の開始を目前に、共通チームより業務共通機能のガイドがリリースされた。
　「ガイドのリリースありがとうございます。これで予定通り詳細設計に着手できそうです。」
　大手製作所の森下はメールにそのように記載し、当たり前のように連絡をくれた。だがここに至るまで、チームが大変な苦労を繰り返してきたという事実は、彼らには知る由もない。
　このあと始まる詳細設計・実装工程では、２０２０年６月末にかけて、業務アプリケーション本体の開発が行われる予定である。ようやく実際に動くシステムが作られる工程だ。
　全体で２００人以上いる開発者が、認識を共有して始めて品質の良いシステムが開発できる。洗練されたシステムは非常にスマートな形をしているが、決して一人のスーパープログラマが作っているわけではない。公共インフラ事業のような、地道な設計の積み重ねで、ようやくシステム化の入り口に立つことが出来るのである。３歩進んで２歩下がるという一進一退を繰り返してきた業務共通チームは、果たして予定通りアウトプットを提供することが出来るのか。
　開発の火蓋が切られるまで、あと１ヶ月となった。