アジャイル推進のかなめ
２月28日（金曜日）、佐々木は、アメリカに戻る、というメールを遠藤から受け取った。20時を回った頃、高崎の本社から遠藤の携帯電話にコールした。遠藤が出た。
「先日の同窓会ではありがとう。あの後、匠の助言をもらって自分なりにアイデアを考えた。忙しいところすまないが、いま少し電話で話してもいいか。そうか。助かる。まず、うちの社内に最近のIT技術の知見が足りない課題だ。これは、ベンダーに依存するしかない。ただし、契約を請負契約から、設計・開発工程を中心に準委任契約に切り替えようと思う。。次に、開発の方式はウォーターフォールではなく、思い切ってアジャイル方式を導入し、自社でイニシアティブを取ろうと考えている。今回は、会社のビジネスモデルに関わる新たなチャレンジだ。定型業務の自動化じゃない。アメリカでのやり方がすべて正しいとは言わないが、そのアイデアの方向は間違っていないと思った。ただ、ネックがある。アジャイルの経験者がいないこと。もう一つが、要件定義を効果的に実行する方法がわからないことなんだ」
耳に当てた携帯電話から遠藤の返事が聞こえた。
「その2つの課題は関係しているな。小さく区切って開発することだ。アジャイル開発の本質はそこ、つまり小口化だよ」
希望が、大きな問題は分解するといい、と言っていたことを佐々木は思い出した。
「巨大で複雑な物事を、多くの人員が参画して設計・構築することは、そもそも難しい。だから、開発単位や人員の規模も小さくするんだ。その業務領域だけを詳細に分析すればいい、ということになるだろう。そうすると、様々な不安を抱えこまずに済む。今やることだけに集中すればいい。人員のストレスも低減する。これまでのように半年かけて要件定義、さらに半年かけて設計、実装に1年、という従来のやり方と様相が変わってくるんだよ」
「アジャイル開発とは、とりあえず作ってみて改修を繰り返す、という漠然としたイメージがあったが、それは正しくない認識なんだな。とはいえ、小口化で全領域を終えるにはかなり時間がかかりそうだが・・・」
「そこで、優先順位開発だ。小さく分割した業務領域の中から最優先される部分を見極めて開発を行う。一説には、現状存在するシステム機能の6割はほとんど使われていない、という調査データもある」
「ふーん。うちでは、使われている4割の部分も、本当に毎日利用する必須な機能かと尋ねられればNoだな。さらにその半分くらいかもしれない」と佐々木は言った。
「なら、その2割の機能に絞って取り掛かり、早期にリリースするんだ。残りの8割は本当に必要なら作ればいいし、不要なら作らなくていい」
「すると、仕事の断捨離にもなるし、最も利用する部分を早期にリリースできる、というわけか」
「そういうこと」と遠藤は言った。
「そもそも単なる現状の踏襲は、システム化の投資判断として良策とはいえない。アジャイルで優先順位開発をする時に、開発コストもハジく。開発コストと投資対効果を判断し、開発の是非を判断することができる。『現状この機能があるから』という根拠のない意見は、合理的ではない」
「確かに」と佐々木は電話越しに頷いた。
「もう一つ補足をしよう。小さい領域であっても、その領域について分析モデルを作成しなければならない」
「分析モデルというのはどういうものだろう」
「要するに、可視化と思っていい。可視化には2つの視点がある。一つは“流れ”に着目するもの、もう一つは“構造”の可視化なんだ」
「どうやって可視化するんだ」
「流れの可視化の方は、業務フローだ。これはおそらくベンダーが作成済みではないかな。重要なのは、もう一つの構造の可視化だ。これは、マスターやイベントの静的な構造をモデル化するものだ。概念モデルともいう。具体的には、UMLのクラスモデルや概念データモデルになる」
「確かに、業務フローはこのプロジェクトでも出てきた。ただ、概念モデルというものは見た覚えがないな」
「このあたりは専門家をコンサルに迎えたほうかいいかもしれないね。構造のモデル化にしろ、実際のアジャイルの推進にせよ、要になるものだ」
「わかった、コンサルは探してみる。匠、色々ありがとう」
電話を切った後、佐々木は、遠藤や希望との会話、異業種交流セミナーをきっかけに生まれたアイデアを整理して、プロジェクトマネージャーとしての提案内容をまとめた。うまくいくか、やってみなければわからない。でもやってやろうと、佐々木は決めた。
