ビジネスという物語
山田が一通りアジャイル開発に説明をしたところで、データモデリングの専門家である木村が、話に加わった。さらに、ちょうど別件の打ち合わせが終わった業務管理課の三上も席に加わった。会議室に入ってきた三上は前田と目が合うと微笑んで会釈をした。
木村は、イスラエルに本社を置くIT企業の現地および日本法人に勤めた後、UMLの専門家として日本で実務に携わっていた。年齢の割に、話し方がゆっくりで落ち着いていたと佐々木は思った。
木村は言った。「アジャイル開発については、私も経験はあります。山田さんがおっしゃる通り、いきなりスプリントに入ることはなかなか難しいですね。まずは、骨格となるモデルを構築し、関係するメンバー全員で理解することが重要です。日比谷ソフトウェアさんでは、データモデルはどのように作成されますか？」
加藤が答えた。
「作成するのはER図です。実装工程で変更が入らないようにできる限り、事前に十分な検討を行います」
「ER図は、プログラマーが見る実装用のモデルですか」と木村が加藤に尋ねた。
「もちろん、そうです」
木村は、しばし考えてこう言った。
「できれば、実装をあまり意識せず、事業の構造を可視化するために概念データモデルを作ることをおすすめします。呉服の桐生の情報システム課では、概念データモデルを作られていますか」と、木村は佐々木に尋ねた。
「いいえ」
「総務部情報システム課では、それらを一元的にマネジメントしていないのですね」
「ええ。そもそも存在していない、ですね。」と佐々木は言った。
加藤は、木村にこう依頼した。
「私にも、概念データモデルの作成のノウハウがありません。その部分の作成で、木村さんの手腕をお借りしたいのですが、お願いします」
「わかりました。手順としては、最初にビジネスの骨格をモデル化します。それからストーリーを作り、スプリントの計画を練る、ということになると思います。しかし、私だけでは実現できるものではありません。皆さんが主役ですから、一緒に進めてまいりましょう」。
佐々木、加藤、前田、そして三上は、頷いた。
（もちろん、すぐにうまくいくわけではないはずだ。しかし、だからこそのアジャイルなのだろう。アジャイルの本質は小口化だ。小さな失敗は恐れない。そこから学びを得ることが大事なんだ）と、佐々木は自分を奮い立たせるように自問した。
2020年3月13 日（金曜日）、前田は、日比谷ソフトウェアの自分のデスクで、3日前の呉服の桐生で行なった、スクラムマスターの山田や、アーキテクトの木村の話を振り返っていた。そして、何か状況が大きく変わるのではないか、という期待を感じた。前田もアジャイル開発の経験はない。しかし、チャレンジしたい、このプロジェクトを成功させたい、と思うようになっていた。
これまで自分がやってきたプロジェクトを思い出してみた。それは、いわゆるSIというものだ。その問題点に対する指摘は多い。
例えば、今回のような二重の下請構造である。日比谷ソフトウェアが請け負ったその下に、ベトナムの協力会社が入る、と言う形だ。最下層にプログラムの開発者であるプログラマーが存在する。プログラマーがユーザーに対して作っているソフトウェアがどのように使われるのか、尋ねたり対話をしたりする機会は皆無に等しい。プログラマーがユーザー企業の同じフロアに常駐して開発していても、ユーザーとプログラマーの部屋が仕切られていることも特に珍しくない。構造が三重、四重と深くなればなるほどメッセージは届かなくなる。プログラマーには対人コミュニケーションが苦手な人もいる。口下手なプログラマーを見下す風潮も厳然と存在している。プログラマーはどのようにプログラムが使われるのか、推測に推測を重ねて、実装してしまうことはざらにある。こんな機能は必要なのかと疑問を持っていても、手探りで進めるしかない。受託するIT企業側も作れば儲かるのだから、そのやり方を変えようとはしない。つまり、発注者と受注者の価値のベクトルの向きが違う。逆を向くことさえ珍しくない。これでは一緒に作るというより、綱引きをしながらどっちが勝つか決めるようなものだ。
販売部の高橋の部下である古田の前で、思わず押し付けがましく、不機嫌な態度をとったことを、思い出した。相手の怒りを買い、担当を外されかけた。
ただ、良い情報システムを作りたい、企業に価値を与えるようにしたい、という入社当初からの思いは、前田の中で消えてしまったわけではなかった。
「前田さん、そろそろ打ち合わせの時間だけどいいかな」と、加藤が声をかけてきた。
時刻は、午前11時を回ったところだった。
「はい。この間教えてもらった佐々木さんの立て直し案、おもしろそうですね」
「そうだね。ユーザー企業が、イニシアティブを取る。このような態度に変わったことには驚いた。その変化を受け止めて、こちらも万全の体制を整えて良い結果に結びつけたいね」
「そうですよ。もう中止するのはこりごり。でも、油断はならないですよね。どこに注意すればいいのか・・・」
「まず、向こう側に提案したいと思っているのは、コミュニケーションの仕方のことだ。ただ、漫然と会議をひらけばいい、という意味じゃないよ」
「確かにアジャイル開発では、コミュニケーションを重視しますよね」
「そう。だから毎朝15分程度で、進捗情報を共有する朝会（デイリースクラム）を必ず実施しよう。その場には、コードを書いているプログラマーも主体的に会話をさせたい。そこで、体制を根本から見直そうと思う。具体的には、オフショア開発はやめる。当社のエンジニアで開発を進めるんだ」
「それはいいですね。でも、社内のメンバーをどれだけ、このプロジェクトにアサインできるでしょうか？」
「そっちの方は、俺に任せてくれ」と加藤は言った。
「今回は少数精鋭だ。10人に満たない人数でいい。若手のなかでやる気のある人間を選定する。引き抜きにはなるが、上に掛け合あうつもりだ。朝会に参加するプログラマー、実際に手を動かす彼ら、彼女たちもこの物語に欠かせない主要メンバーなんだ」と加藤は言った。
「従来のプロジェクト会議では、プログラマーのメンバーが不在のことが多かったですからね。私たちが話を主導するのではなく、プログラマーからの言葉が、顧客サイドに直接届くといいですね」。
加藤も頷いた。
「納期を決める権利を我々が持つが、実装にかかる期間や手間を一番知っているのはプログラマーだ。岡田や桜田にも、出てもらうつもりだよ」
「私達は、できる限り会話が活性化するようにファシリテートしていきましょう」
「そうだな。プログラマーも、最初はミーティングの場で自分の意見を言い出しにくいかもしれない。活性化にはファシリテーターが重要になる。前田にその役を買って出てほしいんだけど。どうかな」
「わかりました。やってみます！」と前田ははっきりと言った。
