がんばれベアーズ

　がんばれベアーズというのは映画のタイトルですが、この映画にちなんで、我がシステム開発チームを「Bears」と呼称することにしました。これは、私がある席で我がチームを形容する時に、「がんばれベアーズみたいなチームでやってるんで……」と言ったことによります。その時とっさに出た言葉ですが、なかなかいい表現だと思っています。

　Bearsは、開発歴20年ほどの私、50にしてプログラミングを始めた先輩、30手前のほとんど初心者の3人です。決して上等とはいえないチームだと思っています。しかし、がんばれベアーズという言葉が出たのは、私がBearsの成長を期待していることの表れでしょう。

　さて、このBearsのミッションは何かというと、業務システムの構造再編成です。我が社はユーザー企業。その業務システムを再構築し、私が「KPI駆動経営」と名付けた経営手法により、継続的改善能力を組織力として定着させることが目的です。こんなミッションを、私はBearsで実現すると会社にコミットしてしまいました……

　がんばれベアーズは、寄せ集めの問題児集団。しかし、成長していくチームです。Bearsも、彼らのような奮闘と成長を必ず実現できると考えています。

　さて、来月（5月）27日は第1回目のリリースです。どんなことになるやら、とても楽しみです。

モデリング、コーディング、そしてテスト

　ソフトウェア開発。久しぶりに自身の手でコーディングしています。流れはこんな感じ…

　Enterprise Architectを使ってクラスを設計する。
　どう設計すべきか迷ったら、UMLからコードを生成してコーディングしてみる。実際の動作を確認することでいろいろ気づきがある。この時、テストとテストデータも一緒に作り、品質を確保するとともにリファクタリングを常に行う。
　書けるだけのコードが書けたら、それをリバースしてクラスモデルにし、まずいところがないか確認しながら既存クラスの修正や新しいクラスを設計していく。
　この繰り返しを行うことで、モデル視点、コード視点、テスト視点でソフトウェアを開発していくことができる。
　取り合えず、今の私にはあってそうなやり方。

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

　もう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フェーズに入った。この続きはまた今度…

プロジェクトの進捗

　新プロジェクトの要件定義が始まって約１ヶ月が経ちました。今回のプロジェクトの開発手法は、開発チームを2班に分け、チームAは業務フローからユースケースを抽出し、チームBの私はドメイン分析からユースケースを抽出するというもので、双方の分析結果を突き合わせることでより豊かな分析を行おうという試みです。
　今のところ、この手法はうまくいっています。双方の気づきやアイデアを交換し合うことで、システム要件はユーザー満足度の高い方向に進んでいると考えています。来週にはこうして導き出されたシステム要件をユーザーレビューし、私たち開発チームの成果を確認したいと思います。

　私はドメイン分析を担当していますが、これまでのプロセスはざっとこんな感じです。
　①ドメインモデルの作成。
　②状態変化を伴うエンティティのステートマシンモデルの作成。
　③トリガーからユースケースの抽出。
　④状態変化を伴わないエンティティのCRUDからのユースケース抽出。
　⑤スケッチしたUIからのユースケース抽出。
　⑥UIスケッチにより、ユーザーにとって付加価値となる機能の発見と、この機能のドメインモデルへの組み込み。

　一方、チームAはAsIsとToBeの業務フローを作成し、ここからユースケースを抽出します。その後ロバストネスモデルを作成し、そのエンティティからデータモデルを作成しています。

明日から新プロジェクト！

　明日から新しいプロジェクトが始まります。今回は、ある業務のシステム要件定義を進
めつつ、全社的な情報アーキテクチャーを整理しようとするものです。私と外部のエンジ
ニア2名によって、まずは7月中に最初の成果を出すことを目標としています。
　この業務を行うにあたって、私はユースケース駆動とドメイン駆動の両面からアプロー
チするという手法を考えました。
　私は主に問題領域の「もの」に着目し、ドメインモデリングを中心に分析を進めます。
外部のエンジニア2名は、主に問題領域の「こと」に着目して業務モデリングやユースケ
ースの抽出を中心に分析を進めます。そして、「もの」から発見されたビジネスエンティ
ティやトリガーなどと、「こと」から発見された情報やユースケースなどの整合性をチェ
ックすることで、新しい業務を正しく設計し、システム要件定義の網羅性を担保しようと
するものです。
　もちろん、要件定義の基本となる方法論はRDRAに準じて行います。さて、どうなるでし
ょうね？　明日からが楽しみです。

次期ITプロジェクトの進め方

問題領域の「もの・こと」。

「もの」はドメイン駆動で、
「こと」はユースケース駆動で分析し、
互いの関係性を検証することで、より豊かな分析・設計ができる。

という仮説に基づいて次期プロジェクトを進めたい。

次期プロジェクトの要件定義手法

今度のプロジェクトでは、ひとつの問題領域を2チームで要件定義する予定。そして、チーム毎の作業を対照的に行うことで、成果の品質を高めるという目論見。

下図はサンプルです。


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

要件定義手法のRDRA、ユースケース駆動開発手法のICONIXプロセスを組み合わせて、UMLをツールとして使用します。
モデリングツールはEnterprise Architect。9.0が間に合うといいけど…
ちなみに、上図はEnterprise Architect 9.0のベータ版で「手書き風」にしてみました。