きっかけは二線の提言
二線のプロジェクト審査の過程で、「行員も成果物をレビューすることで品質に責任を持つべきだ」との提言を受けた。
言っていることはごもっともである。特別な指示でも、大げさな話でもなかった。
早速システムテスト仕様書を一通り書面レビューしてみたところ、指摘らしい指摘はそれほど多くなかった。
ただ、非機能要件まわりの質問事項が、思った以上に大量に出てきた。
メールでやり取りすると伝言ゲームになってしまい、時間がかかりそうだったので、開発ベンダーの担当と直接会って話がしたいと思い立った。
これは、二次請でサブリーダーをやっていた頃とまったく同じ感覚だった。
論点が多いときはそのへんに集まって対面レビューをする。
今回もその延長のつもりだった。
開発現場にこちらから出向いたのも、深い意図があったわけではない。
現場は忙しいだろうし、来てもらうのは大変だろう。
だったらこちらから出向くべきだろうという、ごく普通の配慮のつもりだった。
開発側に、以前からやり取りしていて信頼しているコンサルがいた。
その人に頼んだのも、シンプルな話だった。
「システムテスト仕様書をレビューしたんですが、質問事項がすごい数になっちゃって。書面だと時間がかかるので、可能であれば対面で話がしたいです。今度そっちへ行くので、関係者を集めて場をセッティングしてもらえませんか」
あくまで、技術的な論点整理のためのお願いだった。
「銀行レビュー」
当日、会議室に入ると既に10名ほどが席についており、何やら物々しい雰囲気だった。
さらに、上海のオフショア拠点なども含めてオンライン出席者も集まり、結果的に30人ほどが集まった。
そこで投影されたアジェンダを見て、ようやく事態を理解することになる。
大きな文字で「銀行レビュー」と書かれている。
コンサルめ、なんてことをしてくれた。ちょっと会話するだけのつもりが、大事になってしまった。
こうなってしまったものは仕方ないので、まずは出席者に挨拶を試みる。TeamsのカメラをONにする。
「××銀行の××でございます。平素より当行システムの開発ならびに安定稼働にご協力いただきまして誠にありがとうございます。さて、システムテスト仕様書について銀行側でもレビューを行いましたところ、いくつか確認したい事項がありましたため、本日お時間を頂戴しております。先に指摘事項一覧をお送りしておりますが、こちらをもとに、順番に説明してまいります」
物々しい雰囲気のまま、「銀行レビュー」が始まった。
性能テストのデータ量
「まず、性能テストのデータですが、データ量が現行＋3か月分しか入っていなくて、次の更改を考えたら最低でも＋5年分は必要だと思っています。何か意図があるのかなと思ったのですが、3か月にした意図について、どなたか教えていただけますか」
どうやらこの質問は意外だったようで、会議室が一瞬ざわつく。
ただ、この件については、大量データによる検証は別途実施する予定で、＋5年分のデータを投入して負荷ツールを回す計画になっている、という説明があった。
なるほど、それなら問題ない。最初の質問は、そういう意味ではすぐに解決した。
誤字脱字の指摘
「テストの目的の部分、コピーペーストして使いまわしているのだと思いますが、誤字脱字が増殖してしまっているのと、あと日付も yyyy/mm/dd のままなので、一度全部見直してください」
それだけ言って、その話題も終わった。
WebLogic の基盤ログ
「WebLogic サーバーの基盤ログ、すなわち SystemOut / SystemErr に関する確認観点が抜けています。不要なログが出ている可能性があり、運用面でも問題がありますので、確認観点を追加していただきたいです。もし出ているようであれば、この全面リニューアルのタイミングで綺麗にしちゃいましょう」
しかし、反応が微妙である。
アプリチーム・インフラチームともにこの問題を把握していなかったようだった。
とりあえず、このログはインフラチームが主管であるということだけはわかったが、対応については難色を示している。
「一番手間が少ない方法ですが、アプリチームの日々のサイクルテストが終わったら、インフラチームでログを回収してアプリチームに渡していただけませんか。帰る前にファイルサーバーにでも置いてもらえればそれでいいです。アプリチームはこれを日々確認するようにしてください」
インフラチームも「まあ、その程度であれば…」と納得してくれた。
その後の対応と空気の変化
「銀行レビュー」で指示したのはログの回収と連携だけだった。それ以上のことを求めたつもりはない。
しかし、この指摘から得られた成果は非常に有益なものだったものと思える。
当初、インフラチームはログを連携するだけの予定だった。
ところが、実際に回収されたログはあまりにも大量で、インフラチーム側で主体的に問題点の切り分けが行われ、アプリチームと積極的な議論が進められた。
アプリ自体は一見すると正常に動作しており、アプリチームからは「影響範囲を考えると、今から直すのはどうなのか」という意見も出た。
もっともな話だと思う。
それでも、「行員の言葉」という重みはあった。行員は品質のよいシステムを望んでいる。
結果として、対応は先送りにされず、ログ周りは最終的にすべて綺麗になった。
開発プロジェクトにおいて、行員はどうあるべきか
この一連のやり取りをきっかけに、開発側からの信頼を得られたのは事実だと思っている。
それまで、行員はどこか「雲の上の存在」だった。
「正しいことを言うが、現場の事情までは分からない人」という距離感があった。
この件では、
- 「問題は実在する」
- 「でも、どちらか一方に押し付けても解決しない」
という前提に立って、現実的な落としどころを一緒に考えた。
結果的に、変わったのは成果物だけではなかった。
関係性も確実に変わった。
そんなやり取りの後、開発リーダーからこんな一言をもらった。
「もういっそ、協力会社定例会にも出ますか？」
この一言が、また別の問題を呼ぶことになる。
その話は次回へ続く。