逆転のシナリオ

小説, 第8章

初めてのスプリントレビュー

４月１日（水曜日）、呉服の桐生の会議室。この日の午前10時から始まったミーティングの参加者は、佐々木、加藤、前田、三上、そしてプログラマーである岡田、桜田、そしてコンサルタントの山田、木村である。心身の不調に苦しんでいた桜田は、岡田など周りのサポートもあり、週の中で少しずつ職場に顔を見せるようになっていた。客先に連れてこられる経験が初めての桜田は、少し緊張した面持ちだった。
この日、プロジェクトチームは初めてのスプリントを開始した。スプリントに入る下準備として、アジャイル開発ツールのバックログにストーリーを格納し、優先順位を付けた。その優先順位に従って、ファーストスプリントに入った。
ストーリーは、直営店における顧客情報の入力、である。入力すべきデータにどのようなものがあるか分析するかがテーマだった。例えば、直営店で催事などを行う際に、どのような情報を社内で共有し、サービス品質向上などにつなげるか、というシーンをイメージし、業務部門へのヒアリングを呉服の桐生川のメンバーである佐々木や三上とともに進めるオープン開発だった。前田は、2カ月前に訪れた日本橋直営店での着物コーディネーターによる来場者イベントに訪れていた、見込み客を含めた顧客の姿を思い出していた。

4月28日（火曜日）、ファーストスプリントが始まって約１カ月、メンバーは呉服の桐生に集まった。この日は第一回目のスプリントレビューだった。「スプリントレビュー」は各スプリントの最後に設けられる会議体である。ここで、ある程度、動作する段階まで作成したプロダクトを用いてスプリントの内容を振り返る。
ただ、佐々木らは実際に取り組んでみたものの、レビューするために必要な動くものを作ることが、設定したスプリントの期間内に間に合わなかった。動作するソフトウェアはないことからスプリントレビューは実質的には、反省会となった。
佐々木は、「今回は、初めてのスプリントに取り組みました。しかしながら動くものはできませんでした。失敗ですかね」とうつむいた。
山田は言った。「その原因について、これから議論をしていこうと思います。しかし、ここで注意点があります。決して他人の批判はしないでください。これがなかった、あれがなかったという表現ではなく、あれば良かったという表現を使うようにしましょう」。
その言葉に励まされて、佐々木は顔を上げた。
「それではまず、三上さん、思うところはありますか」と山田は、三上に意見を求めた。
「今回のスプリントにおいて現場からの要求事項は、それなりに盛り込まれていたと思います。ただ、詳細の詰めが甘かったと思いました。具体的には、顧客ごとの過去の取引実績件数のカウント方法や購入商品の履歴内容などです。とはいえ、開発されるプログラマーの皆さんが今回、Web会議で行った朝会などで、どのような機能が欲しいか、突っ込んで聞いてくれたので、その場である程度、解決することができものもありました」。
プログラマーの岡田が発言した。
「開発する立場で手こずったのは、マスターからの実装です。マスターのモデル設計は木村さんのアドバイスもあり、それなりにできたと思います。しかし、そこから実装していくために、既存のデータベースのバックアップデータやプログラムのソースなどを調査したのですが、データ項目がまちまちだったり、値が入っていたなかったりと、部署ごとに実装の仕方がバラバラでした。誰がなんのためにデータを利用するのか、その上で、誰がまたはどのシステムが、どのようなタイミングでデータを入力するのか、もう少し詳細な業務分析が必要だと思いました」
前田も続けた。
「そうですね。データの品質についての考慮が不足していたかも知れません。あ、もちろんこれは批判とかではなく、どこの企業でもある問題で・・・」。
三上が笑いながらフォローした。
「データの品質、昔から気にはなっていました。お客様も引越しをされたり、ご結婚をされて改姓されたり。古い住所や存在しない顧客などが放置されているという指摘がありました」
前田は頷きながら言った。
「発注側の仕様、実装側の理解及び技術力、ここまでは問題なかった。もう一つ重要な点としてデータの品質というものがあるということが学べました」
佐々木は、三上に尋ねた。
「現時点で、データ品質はどこまで上がりそう？」
「社内にあるすべてのマスターデータを精査するには至っていません。それは今後、全部署の担当者に依頼を出すつもりです。ですけど、それを待っていては先に進みません。当面利用できるように一部に絞ってマスターデータを精査しています」
「わかりました。他に、気がついたことはありますか？」と佐々木は尋ねた。
前田が発言した。
「スプリントミーティングではっきりしていたつもりでも、曖昧な部分はありました。具体的には、様々なデータのチェック処理です。日付の判定処理や項目間の値の制約などです。朝会や毎週のミーティングで話があり、そこで機能を追加はしました。といっても、今回のスプリントで十分に対応可能なものだと思います。そして」
前田は、岡田や桜田の方を振り向いていった。
「実装チームとしては、納期を決める権利を頂いています。ですので、当初要求にない場合、今回のスプリントでは採用しないという選択肢を持っていることは心強かったです。いままでのプロジェクトなら、『仕様変更ですか！？』って言ってしまっていたかもしれません」と前田がいうと、笑いが起きた。
「ただ、細かいチェック機能でも数が多くなると組み合わせも増えて大変になります。できれば事前に整理できればと思いました」と前田は言った。
アーキテクトの木村が言った。
「すみません、一つよろしいでしょうか。チェック機能、大変ですよね。プログラムはチェック対象の塊のようなものですから。しかし、そもそも、そのチェックって必要かどうか検討してみてはどうでしょう。情報システムはシンプルが一番です。そして、少しルーズなくらいの態度で臨むといい場合が多いと思うんです。この辺り山田さんどうですか」
スクラムマスターの山田も同意見だった。
「私もそう思います。従来のSIおよびウォーターフォール型の開発では、機能を最初に決定しておく必要がありました。ですから、細大漏らさずチェックする機能や制約を事前に洗い出す必要がありました。しかし、アジャイル開発では、あとからいくらでも追加することができます。木村さんのいうように、ルーズに実装することができる、これが大きなメリットなんです。企業の情報システムには、長い間に積み重なった機能や制約が複雑に絡み合っています」。
山田は、立ち上がってホワイトボードに「複雑系」と書いた。
「複雑系では、あるところで生じたわずかな変化が思わぬところに波及し、大きな影響を及ぼす可能性があります。今回、佐々木さんから、断捨離という言葉がありました。当初の機能は最小限にする。そして、どうしても必要なら追加する、という基本方針がよろしいと思います」