５ 即席の提案
２０１８年１月中旬。
姫宮は守口営業部長とともに、かぞく銀行の応接室にいた。
訪問理由は、今回の提案を辞退するためであった。
あれほど意気込んでいたはずだが、一体何があったのか。
まだ正式な提案依頼を受けたわけではない。ただ、志賀・東山を通し、ＧＣＳＣに対する期待値が日に日に増していることを聞いていた。
ここに至るまでにＧＣＳＣ社内で何度も体制の検討を行ったが、日の丸銀行を中心とする今後の事業見通しから、体制がまとまらないまま時が過ぎた。そして最終的には田中本部長の判断により、かぞく銀行には丁寧にお断りを入れるべきという指示が下り、この日守口営業部長と共に犬澤執行役員を訪れたのだった。
「先日の田中役員のお話しでは、体制作りが難しいということでしたが、正直どのような状況なのでしょうか？」
犬澤役員が単刀直入に質問する。
実は２０１８年の年始挨拶で、田中本部長は一度かぞく銀行を訪問し、プロジェクトへの対応方針を説明したつもりだった。ただその時ははっきりと断るわけでもなく、やんわりとした訪問で終わってしまったため、意図が伝わっていなかったようである。
「先日のご挨拶の際にお伝えしたつもりでしたが、今回のご提案依頼を頂戴しても体制が作れそうになく、回答が出来ないと考えています。」
「それは、もうこのプロジェクトに関わることはできない、ということなのでしょうか？」
「もちろんこれまでの検討に関わってきた経緯がありますので、弊社としてケジメが付くまでは担当させて頂きます。ただご提案、つまり開発フェーズを担当することは出来そうにありません。」
「そうですか。本体に関わっていただけないのは大変残念です。でもここまでアーキテクチャも検討頂いておりますので、東山さん、志賀さんのお二人についてはプロジェクトがカットオーバーを迎えるまで責任もって面倒を見て頂きたいと思っていますが、それは問題ないですよね？まさかＧＣＳＣさん、我々をかき回すためにここまで深く検討に入られたわけではないでしょうから、グランドデザイン通りにシステムが完成するところまでは見届けて頂くよう期待していますよ。」
こちらの意図を見透かしていたかのように、先に釘を刺された。
「その点は、調整付くように検討して参ります。」
「ではそこは前提ということで宜しくお願いします。」
あっという間の訪問であった。１年半近くも戦略的に関わり、スペックインを目指しシナリオを考えてきたのである。総論では皆理解されてはいるが、各論となると東山の頭の中にあるイメージが一番正確だ。そうやすやすと人を変えることなど出来るわけがない。もしここで守口営業部長が全員撤退などと強行して言おうものなら、今後一切の取引が出来なくなってしまうリスクがあっただろう。我々ＳＩｅｒにとっては数ある案件の一つかもしれないが、銀行にとってシステム更改できるかどうかは死活問題だ。それくらい、重みのある仕事をしてきたのだ。
帰りがけにカフェに立ち寄り、守口営業部長とこの先の選択肢について話し合った。
「犬澤さんは本気で最後まで面倒見ろと言っていたのかな。姫宮、どう思う？」
「全体アーキテクチャから実際に開発するフレームワークの仕様まで、ほぼＧＣＳＣのみで考えてきましたので、先ほどのご意見は本心だと思います。あの言葉通り、２人はプロジェクトが完了するまで塩漬けになると思います。」
「４年間だろう？無理に断ったら後々大変になりそうだな。」
「そうですね。昨年の夏に参入方法を考えると決めた時点で適当にするわけにも行きませんでしたので、これはこれで一つの判断だと思います。」
「でも、あそこまで２人を頼りにしているってことは、体制が作れないにしろ何かしらできることがあるんじゃないのか？」
「今回の提案依頼は基盤フレームワークとセキュリティ機能、業務共通機能の領域が対象になりますので、やはりその道に詳しいエンジニアがいないと難しいと思います。」
「それはいったい誰なんだ？以前言っていた２人以外に出来そうな人物はいないのか？」
守口部長のこれらの反応は意外であった。銀行システム営業部にとって、かぞく銀行の取引はごく小規模だ。それに対し日の丸銀行は主力顧客の１つである。エンジニアが提供価値の中心となっているＳＩ業界では、選択と集中をしなければどれも事業がうまくいかないことは一番わかっているはずだ。
何より１ヶ月前に役員室で、かぞく銀行のプロジェクトは諦めるよう田中本部長と共に説得してきたのではなかったのか。
何をいまさら、というあの時の無念さが姫宮の中に沸き戻ってきた。
この訪問の１ヶ月前、かぞく銀行プロジェクトを立ち上げるための体制検討を、姫宮、田中本部長、守口部長とで行っていた時のことである―
姫宮「日の丸銀行のプロジェクトから、２人で良いのでかぞく銀行にリソースを割いてください。そうすれば体制は作れます。」
田中「２人と言ってもお前の言っているのはこっちのプロジェクトのキーマンじゃないか。そんなことをすれば日の丸銀行がうまくいかなくなる。むしろまだ足りないくらいだ。はっきり言う、体制が作れないからお前らの活動はもう諦めてくれ！！」
守口「姫宮、君たちはよく頑張った。ここまで本当によくやったと思うが、大型プロジェクトで要員がバッティングしている状況では、そっちは諦めるしかないと思う。」
あの時役員室で２人して説得してきたのではなかったのか。守口部長は昔からお世話になっている人物だ。自分のシナリオを大切にしろと常日頃言われて育てられた。かぞく銀行のプロジェクトにも参入できるように何とか考えろと以前言ったのは守口部長ではなかったのか。あの時ばかりは守口部長が言い放った言葉がショックだった。だから今日はおとなしく横に座って話を見守るだけのつもりだったのだ。
だが、今日の守口部長は逆に諦めが悪い。何か考えがあるのだろうか。
「そうですね。日の丸銀行のプロジェクト以外では三宅か、大島あたりなら。」
三宅も大島も、日の丸銀行のグローバルプロジェクトにアサインされていたわけではなかったが、その隣の部署にいたため、どのみち可能性は低いだろうと考えていたエンジニアだ。そのため少し高めの球を投げてみたつもりだった。
しばらく考え込んで、口を開いた。
「わかった。三宅は今すぐ難しいかもしれないが、大島であれば調整したい。」
１ヶ月前であれば聞く耳も持たなかったはずの話である。意外な回答に姫宮には懐疑心と、それに反してかすかな希望を感じた。
「本当ですか。ありがとうございます。もし可能であれば、大島にも提案チームに参画してもらい、一緒に提案から考えてもらいたいと思っています。でもグローバルのプロジェクトは大丈夫なのですか。あれほど人が足りないということだったため、隣の部署からでも人が出せるなんて思ってもいませんでしたが。」
そういうと守口部長は、少し事情を説明してくれた。
「田中本部長は確かにグローバルプロジェクトの件でピリピリしていたからな。このプロジェクトに対して少し感情的になっていた部分があったと思う。だが今日の犬澤さんの反応を見ても、中途半端な状態で続けるべきではない。それにあっちは既にほとんど体制は出来ている。これ以上は過剰になっていくばかりで、少し神経質なんじゃないかと感じていたところだ。」
時間が経つとこうも簡単に状況が変わってしまうものなのか。姫宮は半分呆れ顔で聞いていたが、同時に、状況の変化に着いて行こうとする組織の修正力を感じた。確かにあの時の田中本部長の感情だけで仕事の適否が判断されるのはたまったもんじゃない。こちらにはこちらの大義がある。たまたまそれが出来ないタイミングで遡上に上げただけで、やらないと判断するにしても熟考を重ねなければ、正しい判断など出来るはずがないのだ。
守口部長の話から、役員室で突き付けられた結論に至った背景を探ろうと考えを巡らせると、先ほど感じたかすかな希望は、確かな期待に変わろうとしていた。
昨日まではどうやって撤退を考えるか、しんがりを務める２人に何と説明すれば理解してもらえるだろうか、そんなことばかりを考えていたが、この日を境に１８０度状況が回転した。
フロントチャネルシステムは基盤フレームワークとセキュリティ業務、それと業務共通機能からなる３層の領域に分かれ、前者の２つは姫宮の管理下にある要員を調整すれば何とか体制を整えることは出来そうだった。もう一つの業務共通という機能は、コアなＪａｖａシステムとコアな業務知識がスキルセットとして必要になるレベルの高い領域であり、社内で担える人間は限られていた。だが、大島がいれば業務共通機能を任せることが出来る。
２０１８年２月末。
風向きが急に変化した後、考えている体制が機能するのか何度も検討を重ね、姫宮は参画メンバーや調整先の責任者に出来るだけ丁寧に説明を行い、体制づくりのため走り回った。そして大島も合流し、形だけではあったが何とか体制が出来上がった。
提案体制は、基盤フレームワーク担当の神城、業務システム担当の中井、そして共通機能担当の大島を含む総勢１０名ほどのチームとなった。即席で集められただけだったが、チーム「レインフォース」の誕生である。
２０１６年８月より次期システム検討に参画して１年半。紆余曲折はあったものの、ここまでのところ東山・志賀と共に描いてきたストーリー通りの展開となった。もっとも、体制は一部希望通りではなくなったが、それでもほぼシナリオ通りに進めて来られたことは、皆にとって十分な自信となった。次は描いたシナリオを実際に形にする番だ。
一通り提案が行える体制ができたため、かぞく銀行にはすぐさま前言撤回を報告した。
やると言ったりやらないと言ったり、そしてまたやるという。かぞく銀行にとってはどれだけ迷惑なベンダーだろう。とはいえ、この時点で彼らの期待がさらに高まったことは間違いない。待ってましたとばかりに、すぐさま営業に提案依頼の説明会スケジュールが通知されてきた。
翌月の２０１８年３月。各領域で提案責任者となるメンバーでＲＦＰ説明会に参加した。
事前に東山・志賀を通し、様々な情報の展開は受けていたのだが、どうやら聞いていた話はごく一部の断片的な情報でしかなく、ＲＦＰの全容を見たのはその場が初めてであった。だが説明会では資料の中身の説明は行われず、資料の見方の説明だけで１時間半を費やした。そしてその説明会の終了と共に膨大な量の資料がＤＶＤで引き渡された。
提案期限は５月１日。ここから先、件のプロセスが遂にこのチームでも始まったのだ。
自分たちの描いたシナリオ通りに話が進み、その通りに提案が出来る。本来ならばこんな素晴らしいプロジェクトはない。
ＳＩの新規案件は大抵の場合、ある日突然顧客から要求が示され、我こそはと各社が名乗りを上げ、一斉に見積りを進め、競合よりもいかに経済的かつ、特別な価値観を醸し出すかということに全神経を集中させるものだ。それがどうだろう。今回の提案はほぼ競争相手がいないような状態である。
いや、何を作ろうとしているのか、しっかり理解していればその通りなのだろう。だがこの時は膨大な量の資料を目の前に、そんなことを考える隙は一瞬たりともなかった。むしろ期限が決まっている中で、進め方を考えるまでにあっという間に１週間を費やしてしまい、日々焦りと戦わなくてはならなくなった。
仮になんの準備もせず、誰も何も知らない状態から始めた場合、提案作業とは次のような悲惨な展開になる。
まず突然提案チームが招集されたかと思うと、大量のＲＦＰと期限だけを渡され、資料を読み込み、顧客の業務と要求を理解し、自社のソリューションや強みを関連部署に確認しながら当てはめ、提案ストーリーを考え、文書とプレゼン用資料を作成する。
並行して予算を意識して見積りも行う必要がある。その中では委託先ベンダーに依頼して見積を取得し、何パターンかで算出してみて内容を精査し、もし予算オーバーとなることがわかれば、機能を削ったり辞めてもらったりする部分を洗い出し、その場合の影響と回避策を提案書に盛り込む。委託先には何を見積もれば良いか明確にするために、依頼書を都度出し直すことになる。
インフラやプロダクトに対しては、それぞれでメーカーからライセンスの見積を取得し、全体を集計する必要もある。メーカーやプロダクトライフサイクルごとに契約期間・金額の発生の仕方、責任範囲が異なるため、それらの差異を前提とした見積もりに引き直し集計する。
これらを行っていく中で、出来ないことは見積り前提事項として明確に記載する。そのうえで利益の算定、体制と要員計画の作成、スケジュールとの整合性などを取って完成させたうえで、社内承認を取り、必要な稟議を申請し、組織が納得するように説明する。リスクがあればヘッジする対策を考え、前提として追記、または回避するためのコンティンジェンシ予備費用を個別に見積もっていく。
さらに提案チームはほぼ全員、昼の仕事を持っているため、業務終了後か休日にしか提案作業を行うことができず、ほぼ一ヶ月間は休み返上で進めることもある。
これらは一例ではあるが、即席の提案チームであるレインフォースは、実はほぼそんな状況の真っ只中にいた。
考えただけで吐き気がしてしまいそうな仕事だが、そんな領域が最低３つあり、これらのことを１ヶ月少々で行うのである。進め方だけを考えて過ごしてしまった最初の１週間が、１分１秒すら勿体ないと何度感じたことだろう。後悔しても遅いのだが、体制が作れないからと一度は提案を諦めてしまったことによって、結果的に準備にあてる貴重な時間を無駄にしてしまった。いくら組織の判断とはいえ、このことは自らを苦しめる痛恨の極みであった。
肝心のＲＦＰについては次のようになっている。フロントチャネルシステムをフルスクラッチとするために、色々な機能からなるコンポーネントをフレームワークとして開発し、業務アプリケーションの開発者に利用してもらう、という要求が示されていた。
このうち基盤フレームワークでは通信やファイルの操作、セキュリティの主要な機能に関するコンポーネントを担当することになっている。散々注目を浴びたＭＶＣに関するコンポーネントもこの領域に含まれている。
次に業務アプリケーションは、インターネットバンキングのセキュリティ、預金為替、定期預金、外貨預金、顧客管理からなる画面機能の開発、外部事業者とのＡＰＩの開発などが要求されている。業務共通機能では、開発者が直接利用する画面の操作や入力チェック、利用者ごとの認証機能を開発することなどが要求されていた。
銀行は次期システムの検討をスタートしてここまで１年半、フロントチャネルだけでも１年程度かけ要求事項を詰めてきている。その間にやりたいことは殆どと言ってよいほど具体的に決まっていたのだ。１つの機能に対する説明が、そのまま設計書として使えるのではないかと思うほど、完成度は高かった。
この前のＲＦＰ説明会では、銀行からは資料の見方の説明しかされなかった。その理由は時間的に説明可能な範囲が限られていたということもあったのだが、既にＧＣＳＣとして色々な情報に接しているだろうという前提が置かれていたことが大きい。
それはそうだ。ずっと一緒に作ろうとしているものを探求し、時には銀行に懇願しながら進めて来たのだ。誰よりも東山が一番詳しいのは疑いもない事実である。だが彼はＲＦＰを作成した立場であるため、公平を期すために提案チームに入ることはできなかった。
この時点で、顧客要求を最も理解しているのがＧＣＳＣであるのと同時に、何も理解していないのもまた、ＧＣＳＣとなってしまった。
そんな中ではあったが、優秀な人間というのは東山だけでもない。
神城は一年前に金融事業本部に異動して来たエンジニアだ。当時から目立つことはなく、人物的にも大人しい方で、自ら主張するタイプではない。基盤技術に明るいためこの提案には基盤フレームワークのリーダーという立場で参画してもらったのだが、いざ担当してもらうと、驚きの働きを見せた。
基盤フレームワークの基盤とはシステム基盤のことを言うが、ＯＳやネットワークなど一般的なハードウェア構成がある前提で、その上に構築されているアプリケーションサーバや、オープンソースのモジュールを駆使して、開発者や構築システムにとって効率の良い枠組みを機能として提供する。
例えるならば、家を建てる時に地盤調査をしてライフラインの状況、耐震性などを考慮し、基本的な構造を基礎として準備するようなプロセスが、まさに基盤アーキテクチャを設計する部分にあたる。
それに対し神城にとってＪａｖａは大がつくほど得意であり、この分野は十八番の領域である。チーム全体では一週間のビハインド状態であったが、神城の担当する領域では、既に見積り作業が始まっていた。
「姫宮さん、基盤フレームワークの見積り終わりました。」
神城がニコニコしながら話しかけてきた。
「え？もう終わったの？ベンダーの見積も確認した？」
「確認終わっています。想定通りであり、特に問題はありません。強いていうとあと１割は減らせるんじゃないかと思ったくらいです、はは。ＲＦＰで質問受けている、画面開発の実現方式についても回答作成しました。」
「そうか。確認するので所定の場所に格納しておいて。」
「既に保存してありますので見といて下さい。ではこれにて失礼します。」
先回りして仕事を済ませているというのは、普通に優等生だ。それに加えて、Ｊａｖａのコアなフレームワーク機能を開発するという見積りは、これまでＧＣＳＣ社内でもあまり扱ったことがなかった。通信や暗号化、ストレージ、ミドルウェアなどの基本機能を熟知した、本当にその筋のエンジニアにしか出来ない難しい業務である。普通のエンジニアでは見積もりのやり方すらままならないというのに、神城は少しの時間でやってのけた。
逆に、会社にとっては彼の見積りをどう評価できるのかということが問題であった。見積もり作業の中で特に疑問もなかった様子から、きちんと必要な工数を割り出してくれているはずだが、同じ知識を持ち合わせていないためその評価は本人しかできそうにない。そのため基盤フレームワーク領域については、考え方を確認することが必要であった。
次に業務アプリケーション領域である。このエリアは、利用者の認証機能などを司るセキュリティ、振込などを扱う預金為替、外貨預金、円定期預金、家族預金、顧客管理など、複数の業務領域からなっている。まず、これらの業務のうち自分たちはどこまでを担当範囲としたいかを決めることから必要となった。
フレームワークを担当するベンダーは最低限セキュリティ業務を担当することが提案条件となっている。そのため、必然的に一つの領域は確定である。他にどこを担当するか。欲を出せば、やれるほどやりたい。しかしながら体制構築に苦心して来た身だ。今は欲を出す余裕は全くない。
また、勘定系にＢＡＮＫＣＥＮＴＥＲを導入するにあたり、円定期は改修が最も少ないと思われたが、外貨預金は機能がないため、新たに構築することになっていた。勘定系も新規、フロントチャネルも新規だと、さすがにリスクが大きい。その他色々なことを検討したところ、安泰なのはセキュリティに加えて円定期、預金為替だろうと考えられた。
「では、その３つの業務について見積もりをお願いしたい。」
姫宮は業務アプリケーションを担当する中井に対し、一週目にしてようやく指示を与えられた。
「わかりました。でも、使ったことがないフレームワークですし、どの手法で見積もるのが良いでしょうか。」
中井は聞き返した。
業務アプリケーションの見積方法には、幾つかある。代表的なものとして、ファンクション・ポイント法、標準タスク法、類似見積法などである。物の値段は、市場相場や原価、将来収益などの要素で決まるのが一般的だが、ＳＩの仕事は余程のことがない限り、原価に利益を上乗せして値付けするものだ。
業務アプリケーションの見積り方法の三つは、いずれも原価を算定するための手法である。ただ、類似見積法と標準タスク法は、過去の実績をそのまま、もしくは標準化して使う物である。これから新しく取り組む、実績もないシステムの見積もりにはこれらは使えないため、どうするべきかと中井は質問していた。
「そうするとＦＰ（ファンクション・ポイント）しかないから、それで見積れる？」
見積もりは根拠が重要である。セオリーに従っておけば、まず間違いない。その場は一旦決めて見積もりの作業に入ったが、その一週間後に中井から追加で質問が来た。
「ＦＰにより算定してみたのですが、画面が多いのと類似の機能が多いため、感覚的には相当膨らんでしまっていると思います。」
ファンクション・ポイント法では開発対象の画面の入出力の項目数やデータベースの項目数などからシステムの規模を算定する。画面や項目が多くなると作る機能も多くなるという考えから、開発を依頼するユーザーにも分かりやすい手法として浸透してきた。だが今どき、ほぼ同じ処理だが画面が違うだけのシステムは沢山ある。そのようなシステムにとっては、画面に紐づく機能が別の数字として集計されるため、この手法は割高になりがちであった。
「うーん、どうするかな。そもそもその見積もりだと予算も大きくオーバーしているし、預金為替を外すしかなさそうだなあ。」
「どうされますか。円定期なんかは共通機能を定義して片寄せすることで、機能数を下げることはできると思います。」
中井は従順だ。こちらの考えや思いを最大限汲み取ろうとしてくれる。似たような機能は共通して使えるように開発する前提とすれば、一つとカウントしても良さそうだ。
「なるほど、チェック処理やデータベースの登録処理が共通機能に出来るということだね。ではその前提でも試算してもらえるかな。」
この他にもいくつかのやり取りを行なったが、見積もり機能の不足なども発覚し、最終的にはやや予算をオーバーしそうだった。
「どうされますか。これ以上は難しいかと。」
「ではここから先は全体を合計して判断するので、少し考えるよ。提案書本体の作成に取り掛かって欲しい。」
「わかりました。また１週間後にお願いします。」
見積もりを始めてから、既に２週間が経った。まだ一度も全ての見積りの合計がどうなっているのかすら確認できていないため、ここは一旦引き取ることにした。
そして最後の領域である業務共通機能の見積である。この領域は今の体制の頼みの綱、大島にお願いしていた部分だ。
「姫宮さん、そもそも今の仕事が引き継げず、まだ見積もりに入れていません。」
「まだＲＦＰも見ていないってこと？」
「ちょっとずつ見てはいますが、見積もるのってこの一覧にある機能だけで良いのですよね？」
「まあそうだけど、細かい仕様は業務要件を個々に見ていかないと理解できないと思うよ。」
「わかりました。では週末に頑張ります。」
『週末に頑張る』提案作業ではありがちだ。ＲＦＰを受領してから既に２週目を迎えていたが、この共通機能だけはほとんど作業が進んでいない状況だった。そのため姫宮と大島、もう一人の作業者とで共通機能の見積もりを出すため、週末に臨んだ。
「姫宮さん、詳細仕様は読みました。今の時点では機能一覧以上のものはないですね。取り敢えずこれらを見積もっていきますね。」
「本当にそれだけで良いの？」
「ええ、認証とかはどんな種類のものがあるのかが書いてあるだけですので、詳細見ても新しい発見はありませんね。それにこの週末で答え出さなきゃなんで、もう見積もりに着手します。」
大島は１０年ほど前に姫宮の担当プロジェクトで一緒に働いていた。要領のよい人物ではあるが、事情をあまり考えずその時に最も近道になるものを選ぶ癖がある。効率的に仕事を進める意味では良いのだが、検討に深さがなさそうなところが、今回も気になっていた。
１０年前も共通機能を担っていたため、パワーアップした大島ならこのプロジェクトでも活躍するだろうと思いアサインしたのだが、三子の魂百までである。どうもその癖は変わっていないようだ。
そうはいっても大島の言うことはまんざらでもなかった。ＲＦＰの完成度が高く、一つ一つの機能が具体的に記述されており、一見すると定義通りに物を作っていけば良さそうに見えた。ただ、ＲＦＰの中には「検討中」と書かれてあるもの、「具体的には要件定義で確定予定」など、いくつか未確定事項も残っていた。これらを大島はどう認識しているのか。姫宮自身でＲＦＰをチェックしながら確認する必要があった。
「大島、例えばここに、画面開発のアーキテクチャは要件定義で確定、と書かれてあるけど、見積もりの前提としてはどうするんだ？」
「ああ、それですね。一応銀行が検討すると言っているので、その時まで待とうかと思います。ただ画面の開発なんてそんな特殊なことをするわけではないでしょうから、一般的な方法で開発する前提を置こうと思います。」
「ではその点は見積もり前提としてしっかり記載するように。」
「わかりました。」
このようなやり取りを経て、その日のうちに見積もりを出せた。
「姫宮さん、一旦作りました。これでどうでしょうか。」
「思ったよりすんなり出せたんだな。取り敢えずご苦労さん。」
「機能は網羅させて、ＦＰと標準タスク法の２パターンで出してみました。標準値は過去担当したプロジェクト実績ですので、ハズレってことはないと思います。検討事項も抜き出してどんな前提としているか記載しましたので、必要なものは揃ったと思います。」
「特に方式上問題となることはなかった？」
「そうですね。色々書いてはありましたけど、方式に落とすのは要件定義か基本設計かなって思ってるんで、今は深く検討していません。これで過不足なければ、今日はちょっと娘の体調も良くないので早く帰りたいんですが、良いでしょうか。」
「ああ、わかったよ。では明日は私の方で確認しておくので、休んでくれ。」
要領が良いと言う点では神城もそうであったが、大島のそれは少し異なる。業務共通機能というと、色々な業務アプリケーションが利用する機能のことであり、横断的に要件を把握しておくべきものだ。今この段階で押さえるべきことを押さえて効率的に進めているならば良いのだが。一抹の不安が頭をよぎった。
見積もりにはこれらの他、フレームワークの機能として利用する製品のライセンスもいくつかあったが、それらは営業に任せることにした。
ＲＦＰ受領から３週間が経過する４月１４日。まもなく夕暮れを迎えようという時間になる頃、ようやく一通りの見積もりの集計結果を営業の武尾が持ってきた。
「姫宮さん、見積もりの集計が出たんですけど、予算の３倍になっています・・。」
時間をかけて皆んなで頑張って見積もってきたが、この数字はほぼ振り出しに近い。体制も厳しいと何度も書いて来た通り、このチームにはたくさんの開発をやる余裕はない。安全確実にプロジェクト運営しなければ、トラブルが生じるのは目に見えている。
諦めムードを醸し出しながら、姫宮は呟いた。
「こんなんじゃ、ちょっと、出せないな・・。」
武尾もそれは分かっていた。
「やっぱり、そうですよね・・。」
「明日の朝に役員報告を行うことになっている。提案前に役員の皆さんを勢い付けたつもりだけれど、これでは一発で停止の判断になりかねないな。明日向けの資料を作ろうと思っていたけれど、なぜここまで膨らんでしまったのか、原因を分析するところからだな。」
「そうですね。私もお付き合いします・・。」
長くなりそうなこの日の夜のことを思うと、会社の窓から眺める美しい夕日が、いつもより恨めしく感じられた。
翌朝―
「何だ！この見積もりは！聞いていた話と全く違うじゃないか！！こんなのでは提案は無しだ！営業、お前らも一体何を見ていたんだ！！」
金融事業全般を統括する、フィナンシャルグループ・プレジデントである北島副社長の怒声から、この日は始まった。
「だいたい姫宮、お前んとこの体制でできる仕事量だと言ったから信じたのに、こんだけの見積もりになるってことはリスクが高いか凄く難しいか、どっちかってことじゃねえのか！」
激昂する相手には、できるだけ冷静に対応するのが定石だ。
「はい、昨日時点では初回の見積もりであるため過剰となってしまいましたが、機能重複もあり見直しているところです。ＲＦＰを分析すると元々の想定より要求が増えている部分もあり、領域も絞ろうと思っています。本日は、一旦全てを見積もったらどうなったか、ということでお待ちしました。」
姫宮は夜通しで見積もりの精査を続けていたが、結局この程度の言い訳の材料しか作れなかった。
「言い訳すんじゃねえよ。次にこんな状態だったら絶対やめさせるからな。営業、お前らも座ってるだけでどうせ何にも考えてないんだろ。そんなんだったら皆んな辞めちまえ！」
「先程ご説明した方針ですが、具体的には預金為替と、フロントシステムの基盤構築は提案から外すことを考えています。また機能共通化の観点でも効率化は図れますので、今の半分にはなると思います。」
この日の役員報告には、北島副社長と役員が数名、事業部側は田中本部長と守口営業部長、姫宮、営業部課長が同席していた。
が、何か言い返そうものなら容赦なく罵声が飛んできそうで、田中本部長ですら黙って聞いている始末だ。つまり姫宮は一人で相対しているようなものだった。
そこへふと、ある人物が発言した。
「君たち本当にシステムのことわかってるの？どう考えたってこんなになるわけないだろう。」
隣で話を聞いていた、エグゼクティブ・ヴァイスプレジデントの南町専務が、嘲るように指摘してきた。
北島副社長の隣に座っているこの南町専務は、エンジニア上がりだ。１５年前、当時の帝国銀行に出向し銀行員の立場でインターネットバンキングのフレームワークを作った人として語り草になっている。今でも銀行の一部では伝説になっているそうだ。
つまり、今回のかぞく銀行プロジェクトのスコープは、南町専務にとってとても詳しい領域であった。
役員報告は通常プロジェクトの概要、体制、リスクと対策を一通り説明して終わるはずだが、中身に踏み込まれるとこの人には敵わない。
「いーい？こんなに見積もりが高いってことは、君たち何にもわかってないってことなんだよ。そのことを解ってる？」
「わかっているとかわかってないというよりも、標準的な方法で算定しているだけです。その結果が高いということは、会社の標準的な生産性が低いということでは無いでしょうか。会社自身がわかっていないという事を仰っているように聞こえますが。」
売り言葉に買い言葉だ。楯突く必要はないのだが、高いのは事実であり、見直すと言っている以上の説明はないし、その時間も勿体ない。
「え？何を言ってるの？いい？そもそも、君たちの考え方が違うと言っているんだけど。そんなフレームワークなんて作っちゃダメなんじゃないの？そういうのは、フレームワークを作るんじゃなくて、使うんだよ。」
何を言ってるんだ、はこちらのセリフである。
新しい仕組み（フレームワーク）を作ることを目標にして、それを銀行と共有して来たから、今こうしてＧＣＳＣに依頼が回って来たのではないか。この一言で、これまでの一年半の取り組み自体を丸ごと否定された気がした。
どう返そうかと暫く考えたが、冷静に思案していくと南町専務の言葉からは本質的な指摘をされているようにも感じられた。
今はないものを一生懸命定義し、それを作ろうとして来たが、あるのであればそれを使うのはもっともな意見だ。見積もりの見直し時間を考えると出来るだけ宿題を持ち帰りたくはなかったが、このまま素直に聞いておくことにしよう。
「どういうことでしょうか。」
南町専務が優しそうな眼差しで答える。
「いーい？フレームワークなんて一から作ると大変だし、帝国銀行でも似たようなものがあるはずだよね。何でわざわざ、このプロジェクトの中で全部作ろうとしているの？銀行にお願いすれば使えるんだから、あるものは使えっていうことを言っているの。やっぱり本当に何も分かってないね。君たちは。」
帝国銀行のフレームワークとは、確かにそのような話を銀行としているし、少し流用出来れば良いな、というくらいにしか考えていなかった。
さらに専務のご意見が続く。
「それに契約的にも、責任範囲ってもんが限定出来るじゃないか。昔俺が帝国銀行のフレームワークを作った時は、銀行の立場として作ったから良かったものの、一から、しかも全て請負で作って、何か問題起こした時に責任は取れるのか？そういうところが、システムだけじゃなくて何にも分かってないって言ってるの！」
言われていることは概ね正しいし、不足していた点でもある。数分前は少しムッとしたが、ここは素直に従い、貴重なご意見ということで立てておこう。
「なるほど。貴重なご意見ありがとうございます。役員のおっしゃる通りだと思います。再利用の点はまさに銀行内で検討中でしたので、状況を確認して反映致します。」
「宜しく。どうせフレームワーク考えたのは東山だろう？よく話して、君も俺と話せるレベルになってから来てくれよ。ひ・め・み・や・くん。」
１５年前のプロジェクトで、この南町専務と東山はツートップで活躍した間柄だ。確かに凄い人で、一生かけても到達できそうにないが、こちらを嘲る感は何とかして欲しい。
この日の役員報告を受け、改めて提案メンバーが集合し見積もりと提案範囲を見直した。その結果業務アプリケーション領域を円定期とセキュリティに絞ることで、何とか予算内に収まりそうであった。
ただし１点問題があった。この規模のプロジェクトを取り仕切るプロジェクトマネージャを誰にするかが決まらなかった。これについては姫宮自身が自ら仕切る、ということで最終的に社内の意見をまとめることが出来た。
結論が出るまでに提案領域を何度も見直し、見積もりも１０回以上試算し直したことで、銀行には予定の２週間遅れで提示することが出来た。普通なら時間切れの時点で外されてもおかしくない。
２０１８年５月１９日。銀行への提案プレゼンの日を迎えた。
「今回のＲＦＰを詳細まで確認させて頂いた結果、ほぼ構想通りに開発していけば良いと考えています。一方でご提案のポイントとなるのは、プロジェクト体制です。基盤フレームワーク、業務共通、業務アプリケーションそれぞれの領域について、帝国銀行の実績を有するメンバーを集めました。この体制で、未来永劫愛され続けるフレームワーク、そして次期システムを開発していきたいと思います。」
自分がやる以上は、まずは案件を確実に受注するのが前提だ。プレゼンでは個々の技術課題をどのように解決するのかということではなく、この日を迎えるまでに生じた色々なことを想起しながら、思いのたけをぶつけた。
技術課題に着目せずに体制にポイントを置いた理由は２つある。
一つはこれまで基礎検討を共にしてきたＧＣＳＣ社は、逃げずに最後まで見届けるという意思を最大限表明すること。もう一つは、実際の提案は中身があるようで、実際はそんなに無かったことだ。中身がないとは言い過ぎだが、ＲＦＰの完成度が高く、質問されたことに回答していけば提案が完成するようになっている。
基盤フレームワークのようにテクニカルな問題にどう対処するかということは提案要素となりうるが、それでも全体を通すとそこまでオリジナリティのあるものではなかった。そのため、体制が唯一のアピールできることだと考えたのだ。ただ、それがどのようにかぞく銀行に刺さるかはわからない。
プレゼンののち、ほどなくして熊手部長より姫宮に連絡があり、かぞく銀行に呼び出された。
「姫宮さん、体制の提案ありがとうございました。これから毎週、プロジェクトの立ち上げに向けて打ち合わせをさせてください。ご提案では概算見積ということでしたが、個々に集計し直しているところです。これから細かな情報提供の依頼をすると思いますので、宜しくお願い致します。」
かぞく銀行への参入を目指してから１年１０ヶ月。スペックインは、ついに成功した。
この記事が気に入ったらサポートをしてみませんか？