業務改善プロジェクト システム化構想立案～要件定義編

　もう14年も見ている我が社の業務だから、どこをどう直すべきかは理解している。しかし、組織のアクションとして実現するためには、私の考えを社に示さなくてはならない。そこで、今回はバリューチェーンを使ってみた。


バリューチェーン posted by (C)Satohru

　このバリューチェーン分析によって、各部門の業務の性質やIT成熟度などがとても説明しやすくなり、私の作り上げたアクションプランは社のアクションとして承認された。
　そして2011年4月、具体的に物事を考え始めた。


仕事場 posted by (C)Satohru

1. IT化のスコープはできる限りコンパクトにして、ユーザーと開発者の負担を軽くしよう。
2. 工程をいくつかのフェーズに分け、成果を確認しながら、成功（失敗）体験をユーザーと共に積み重ねながら進めて行こう。
3. 今までと違う手法を試してみたい。今回はドメイン駆動設計を軸にしよう。
4. ドキュメントはイントラネットに公開しよう。

　やるべきこと、やりたいことが湧き上がってくる。しかし、我が社が持つIT系人的リソースは私ひとり（3月までは部下がいたが、諸事情により退社した）。当然というべきか、計画どおり外部リソースを活用することになるのだが、問題はどう使うかだ。
 　SIerに丸投げする気など毛頭ない私は、派遣されてくるエンジニアと私の役割分担を考え、ドメイン駆動とユースケース駆動のツイン駆動だ！（？）、というアイデアにたどり着いた。こうすることで、要件定義手法RDRAの関係性の基づく網羅性の確保がより強固になると考えたのだ。


次期プロジェクトの要件定義手法 posted by (C)Satohru

 　このアイデアのもとSIerと協議し、結果としてふたりのSEと私の3人で今回のプロジェクトを開始することになった。
　
　6月。SIerのSEふたりは業務のフローに着目して分析を行い、業務フローからユースケースを導き出すことを最初のゴールと定めた。一方、私は業務の言葉やものに着目し、ドメインモデルとステートマシンモデルを作成した後、ステートマシンモデルのトリガーからユースケースを導き出した。

　プロジェクトを開始して2週間。私は重要なビジネスエンティティを発見した。これにより、業務のつながりがハッキリと見えるようになった。ドメイン駆動設計を意識したプロジェクトは今回が初めての経験だが、その有用性を十分に体感することができた。

　SEふたりの作業進捗はすばらしかった。モデリングはユースケースからロバストネスモデルの作成まで進み、その過程でラフなデータモデルもできあがっていた。また、私は最初の画面スケッチを手書きでノートに記していた。プロセスには拘らず、今考えるべきこと、今なすことが有効だと思われることをどんどんこなしていった。実に楽しいシステム開発である。

　それぞれが導き出したユースケースを突き合わせ、認識の違いや網羅性を確認していった。これがまた楽しく有用な作業となった。ドメイン駆動とユースケース駆動のツイン駆動。その有効性がこの作業で確認できた。ただし、プロジェクト特性を十分に考慮してこの手法は採用する必要がある。小規模でデータ集約型業務のシステム開発には、極めて有効なのではないだろうか。

　ひとまずユースケースが出そろったので、今後の計画作りのためにも、作ろうとしているシステムの規模を見積もることにし、ストーリーポイントによる規模見積もりを実施した。
　0、1、2、3、5、8、13の7枚のカードを3人が持ち、ユースケースに対する相対的な重みをカードを出すことによって示し合うのだ。意見が分かれたときには議論し、最終的にはチームの合意としてストーリーポイントを決める。
　これもまたエキサイティングな作業となった。この際の議論を通じ、ユースケースの突き合わせを行ったとき以上に、認識ギャップを埋めることに成功し、ユーザーにとって価値あることとは何かについて深く議論することができ、時には実装方法についても議論がおよんだ。

　規模の見積もりをすると、それに時間や単価という要素を加えて金額を見積もりたくなるのが人情である。サクッとSEが見積もったところ、32人月・4,000万円弱というような数字が出た。
　おいおい、ちょっと待ってくれ。仮に私ひとりでこのシステムを作るとして、32ヶ月もかかるわけがない。この意見にSEふたりも賛同してくれた。伝統的システム開発手法（請負契約によるウォーターフォール型開発など）は、知識の伝播を行う課程で相当の工数を消費する。そこでチームで議論し、このチームにPG2名を加えてアジャイルな開発をしようということになり、その後の私の再計画では5ヶ月・700万円くらいでリリースできるというシミュレーションがはじき出された。んーん、700万円かぁ。まだ高い…
　ということで、PGを外し、新たに採用する私の部下を加えた4人で開発していくプランを考えることとなった。

　そしてビジネス部門への最終提案。関係者を大会議室に集めて説明、質疑応答、議論と続いた。いい会だったと思う。ユーザーたちも主体的に業務のあり方を考えてくれている。

　このプロジェクトの最も大きな問題点は、直接的なユーザーである現場担当者と、間接的なユーザーとなるマネジメント層の関心事があまりにも違うということであり、私たち開発サイドの提案は、段階的にみんなの要求を実現していきましょうということである。

　業務においてどんな分析をするにしても、データがなければどうしようもない。マネジメント層が持つさまざまな関心事も、結局は現場担当者が作業することであり、それにはパワーシフトを起こさなければならない。
　今回提案したシステムは、いわば基礎工事である。基礎なくしてはどんな建物も建築することはできないのだから…　

　8月。プロジェクトは第2フェーズに入った。この続きはまた今度…