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

　もう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に準じて行います。さて、どうなるでし
ょうね？　明日からが楽しみです。

5月10日のツイートより

• 選択肢が多く（例えば.NETかオープンソースか）、考慮すべきことも多い（BCPとか）。数年前、基幹システムの開発を手がけた時よりも、それらははるかに多様化している。唯一絶対の解などないからこそ、ポリシーが重要になる。 posted at 07:14:19
• ちょっと前は、システム部門を増員してバリバリ内製しようと考えていた。しかし、我が社のような中小企業が内部で技術水準を保つのは大変だ。今は、もっと軽量な人材で自社システムを回せるように舵取りを修正したい。 posted at 07:22:30
• ビジネスレイヤーは絶対に妥協できない。しかし、インフラは要件に合えばなんでもいい。UIは重要だがビジネスレイヤーほどではない。そんなザックリとしたポリシーをもとに、シンプルなITを構築したいのだか… posted at 07:31:26
• より具体的に未来を検討する為に、ペルソナを設定してみよう。ペルソナはシステム管理者、もちろん私ではない。 posted at 07:43:52
• つまり、ペルソナが回せる情報システムを、アウトソーシングなども含めて総合的にデザインするのだ。 posted at 07:53:35

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

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

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

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

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

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

下図はサンプルです。


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

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

簡単なソフトウェアを作ってみよう

会社の人達に少しでもソフトウェアに関する理解を深めてもらおうと、「簡単なソフトウェアを作ってみよう」と題して、分析、設計、開発、テスト、見積などを実物で紹介する活動を先週から始めました。
今日は実物を作ったので、お披露目です。



設計では3画面構成だったのですが、手を抜いて1画面にしました。


簡単なソフトウェアを作ってみよう(1) posted by (C)Satohru


簡単なソフトウェアを作ってみよう（２）に続く…

性質変換によるデスクワークの工場化(1)

　私の勤める会社は主に不動産賃貸業を営んでいますが、ある人にいわせると、「江戸時代からビジネスモデルが変わっていない業態」ということだそうです。この真意はともかくとして、そんな会社で情報システムを任されている私には、この業態が故の「当たり前のムダ」というものがたくさんあります。
 　例えば「鍵」。賃貸住宅のドアのキーです。お客様との契約前には内覧をしていただきますが、その為にはたくさんの鍵を管理し、社員がお客様に同行し、中を開けて説明し、他の部屋が見たいと言えば、では後日、と言って再び同じことを繰り返します。あるいは、契約書であるとか、預金口座自動振替依頼書であるとか、さまざまな「紙」が発生し、これをお客様との間でやり取りする過程で、封入コストや郵送コスト、管理・保管コストが発生します。
　このような例が、私がいうところの「当たり前のムダ」です。言い方を変えると、他の業態と比べると相対的にムダに見えるものということになります。例えば、ネット証券会社を考えてみてください。ほとんどのオペレーションが電子的に済み、さまざまなリソースを多くの顧客でシュアしている業態は、うらやましいほど効率的です。しかし、「当たり前のムダ」がある中でも、より効率的なオペレーションは築いていけるはずです。
　私は何とか「工場化」できないか？　と考えています。「IT化」ではなく「工場化」です。つまり、事務作業やデスクワークといわれる業務を、製造作業のような「性質」に変換できないか？　ということです。
　では、「製造作業」と「デスクワーク」の違いは何でしょうか？　これを考える前に、ビジネス（あるいは、仕事、業務、作業）の構造を考えてみましょう。

　上記の図を一旦ビジネスの構造とし、ビジネスルールと呼ぶことにしましょう。

1. トリガー（業務の引き金）　：　どんな業務でも、必ず開始されるきっかけがあります。それには「アイデアがひらめいた」とか、「仕事の依頼がきた」、「上司に指示された」、「期日がきた」などさまざまでしょう。
2. ロール（業務の実施者と役割）　：　業務は人によって行われます。誰が、どんな役割で業務を行うのか？　これがロールです。IT化された業務では、システムがロールとなることもあるでしょう（ロールがシステムだったとしても、その処理内容は人が管理していますので、最終的にはすべての業務が人によって行われているということになります）。
3. インプット（業務に必要なもの）　：　業務には何らかのインプットがあります。伝票や請求書、要件などです。また、業務の実施者の知識や経験、アイデアのような無形のものもあります。
4. プロセス（業務の手順）　：　何を、どう処理していくかという業務の手順がプロセスです。「請求書の内容を確認し、支払管理システムから支払依頼書を発行し、経理に提出する」というようなものです。
5. コントロール（業務の制御）　：　取り敢えず「制御」という日本語を充てていますが、管理、監督、統制など、Controlのいくつかの和訳に置き換えてもいいでしょう。プロセスには何らかのコントロールがあります。「上司の承認を受ける」とか「支払額は予算の範囲内」とか、「条件分岐」であったりします。
6. アウトプット（業務の成果）　：　プロセスによって生み出された成果となるものがアウトプットです。インプットと同様、アイデアなどの無形のものもあるでしょう。

 　ビジネスルールは、下図のように次のビジネスルールへと引き継がれるケースがあります。また、下図「ビジネスルール A」と「ビジネスルール B」をひとつのビジネスルールに集約することも可能ですから、ビジネスルールはネスト構造になっていると捉えられます。つまり、「粒度」があるということです。

　ビジネスルールを一定の定義に基づき理解した上で、製造作業とデスクワークとの違いを考えてみましょう。

　製造作業は、明確な役割分担のもと、品質レベルが明確な成果物を、定まられた手順に従って行い、かつ、生産量や技術レベルを物理的・定量的に捉えることができ、作業全般を通じて可視化されています。
　これに対しデスクワークの一部は、不明確な役割分担のもと、品質レベルが不明確な成果物を、試行錯誤の連続によって行い、かつ、成果物や業務遂行レベルを定性的に捉えることが多く、作業全般を通じて見えにくくなっています。
　上表のように、{ T,R,I,P,C,O }で比較してみましょう。

1. ロール　：　デスクワークでは責任と権限のバランスがとれていないケースがあります（責任だけは押しつけられるが、それを遂行するだけの権限がないなど）。
2. インプットとプロセス　：　例えば新規事業を企画する、というような業務を行う時、インプットやプロセスは試行錯誤の連続によって行われます。「市場調査をやってみたけれど有用な情報を得られなかったから、競合他社の分析をしてみよう」というようなケースです。そうした試行錯誤の連続は、スピードや効率の低下要因となります。
3. アウトプット　：　最も大きな違いがアウトプットです。製造作業のアウトプットには明確な品質レベルが測定可能な形で定義され、よって検証することができます。しかし、デスクワークのアウトプットの大部分はこの逆です。例えるなら、製造作業はX,Yの座標で弓を射る目標を定義しているのでズレを定量評価できますが、デスクワークは的のどこかに当たればいいというような曖昧な定義なので、定性的な評価しかできません。

　このようなデスクワークの各要素を製造作業の持つ性質に近づけることができれば、デスクワークの「工場化」を推進することが可能です。

　性質変換によるデスクワークの工場化、理屈はこれでいいのかもしれませんが、では実践ではどのようなアプローチをすればいいのでしょうか？　これから具体的に検証していきたいと思います。

第2回 クラウドコンピューティングEXPO

　昨日、幕張メッセで開催された第2回 クラウドコンピューティングEXPOに行って来ました。出展製品の中から、私が興味を持ったものを紹介します。

■ BPMワークフローシステム『Questetra BPM Suite SaaS Edition』
　株式会社クエステトラ

　私はホワイトカラーのデスクワークを「工場化」することによってより高付加価値な業務にパワーシフトできないか？　という理想を持っていますが、その為には業務の可視化が重要な一歩となります。
　Questetra BPM Suiteは、恐らくエンドユーザーレベルでも定義可能な「プロセスモデラー」とアクティビティに対する「入力画面」を作成し、「業務実績グラフ」などで進捗や結果を可視化し、PDCA基盤を構築できます。しかも、5ユーザー、100MBまで無償で使用することができますので、早速試してみたいと思います。


■ 『VR-Studio』等
　株式会社フォーラムエイト

　大規模な3次元空間CGを製作する為のソフトウェア製品です。


■『ホワイトワークスタイル』
　ソフトバンクテレコム株式会社

　ホワイトカラーの生産性向上、ワークライフバランス、メンタルヘルス、事業継続性の観点から、このようなワークスタイルは今後普及が進むかもしれません。
　今後、継続的に研究すべきテーマだと感じています。

ソフトウェアの開発プロセスについて

本コンテンツの趣旨としては、世の中の知恵を集めて自己の基礎を作り、後は状況に応じてカスタマイズしましょう、というようなことです。
先人の知恵として、富士通SDEM、共通フレーム2007、RDRA、ICONIXを取り入れています。

これからの企業IT

　私が描く次期IT基盤のイメージはこんな感じです。

1. シンプルなルールで情報にメタ情報を付加しよう！
2. 情報はファイルサーバーに保存するのではなく、情報発信基盤に投稿しよう！
3. 情報は、Googleで検索するように探そう！
4. 情報は、分類ツリーやタグクラウドでも探そう！
5. 注目している情報発信者やカテゴリーは、RSSでマークしよう！
6. 情報は内容品質が命！　形式にこだわらずに発信できることからどんどん投稿しよう！
7. ちりも積もれば山となる。一つひとつの小さな情報発信が、蓄積され、検索され、再利用されることで知恵に成熟する。
8. 情報にはレーティングを入力しよう！

工場見学を終えてのちょっとした感想

　先日、ある精密機器メーカーの工場見学に行って来ましたので、ちょっとした感想をメモします。

　製造の仕事は、成果が明確であり、その出来不出来が定量的に測定でき、個々人の作業が定型化されていて、かつ、その作業の進捗を誰もが目視で確認することができます。

　一方、いわゆるホワイトカラーが行う事務作業は、成果が不明確なことが多く、その出来不出来が定性的に判断されることが多く、個々人の作業が非定型で、かつ、その作業の進捗が見た目では分かりにくいという性質を持っています。

　つまり、ホワイトカラーの生産性を上げるために、作業を可視化が極めて重要であることを再認識しました。また、成果を明確にするためにも、目的、目標を作業前に定義することが重要です。

多様化技術 - Diversified Technology

　ITコストを削減する、あるは費用対効果を高める。これらを実現する方法は、ひと言でいえば汎化にあると考えられます。例えばパッケージ ソフトウェア。企業が個性を捨て、ベストプラクティス、あるいは標準という名の特化から汎化への転換を受け入れることで、ひとつの資源を他社と共有することによるコスト削減を実現できます。
　クラウド コンピューティングのサービス種別は、IaaSからPaaS、SaaSと進む毎に汎化の度合いが増します。IaaSは、クラウド上のVMにどのような仕組みを載せるかをかなり広い範囲から選択できますが、セキュリティなどには一定の制限、つまり汎化を必要とします。そしてSaaSになると、出来合いのユーザー インターフェースなど、汎化がかなり進みます。一方、コストは汎化が進む毎に低下していきます。Salesforceアプリケーションなどはかなり柔軟性を持ったSaaSですが、それでも一定の汎化を伴うことに変わりはありません。結論として、個性を捨て汎化を進めることで、コストは削減できるということになります。
　しかし、コストの削減には限界があります。この限界点に達した時、企業の取るべき道は大きくふたつあると考えられます。ひとつは、イノベーションを起こす、あるいはイノベーションが起こるのを待ち、限界点がさらに低下するのを待つという消極的な方法。もうひとつは、コスト削減によって生じた内部留保によって追加投資を行い、相対的な費用対効果を高めるという積極的な方法です。
　私はここでひとつの仮説を持っています。企業競争に打ち勝つためにコストを汎化によって削減してきた企業が、コスト削減の限界点に達すると共に内部留保を蓄えた時、これまでの汎化ストレスを開放する形で特化を求め、結果として独自ソリューションの構築による競争力の強化を求めるのではないか？　という仮説です。つまり、スクラッチ開発への回帰が起こるのではないか？　ということです。
　しかしながら、伝統的な手法によるスクラッチ開発への回帰では、退化の道を進むことになります。そこで、既存資産を有効活用し、素早く、インクリメンタルに開発できる方法論が注目されるでしょう。具体的には、各サービサーが提供するWeb APIなどをラップする形でアプリケーションを構築し、それをIaaSに載せる。また、開発手法についてはアジャイルな価値提供プロセスが普及する、というようなトレンドです。
　また、例えば、自動化が進んだカメラが撮る者の感性を顕著化したように、汎化が進んだITを使いこなす能力－ITリテラシーの全社的向上が、これまで以上に競争力に大きなインパクトを与えるでしょう。
　Salesforce.comは、汎化によるコスト削減を企業に提供しましたが、Salesforceアプリケーションの価値を存分に得るためには、PaaSとしてのSalesforceを使い倒す能力が必要です。つまり、業務部門の業務設計や改善の能力、システム部門の開発力です。このふたつを携えSalesforceアプリケーションを利用すれば、その投資効果を極限まで引き出すことができるでしょう。
　脱・汎化、ITリテラシーの向上、どちらも私は「多様性」という言葉で包括したいと考えます。SaaSを使いこなすユーザーのリテラシー、SaaSをカスタマイズするシステム部門のリテラシー、各種クラウド サービスを最適にブレンドしてのシステム構築リテラシー。こうしたリテラシーによる特化された（個性化された）競争力の源泉。いうなれば、既存資産を上手に組み合わせて個性を築く「多様化技術」が、クラウド サービスが一定の成熟を得た年からその後数年間のトレンドを形成すると予見しています。
　「多様化技術 - Diversified technology」とは、数ある既存サービスをラッピングすることによって安価に素早く、インクリメンタルに個性あるアプリケーションを開発すること、あるいはパラダイムです。そして、多様化技術を支える中枢となるべき人材が、企業内に存在することがこれまで以上に重要になるとの仮説を持っています。

サイボウズを使って業務の見える化(2)

　サイボウズを使って業務の見える化（試行）の続編です。今回は実際のデータを使って簡単な分析を行ってみます。

　サイボウズのスケジュールには、前回の例（下図）のように入力しますが、今回は業務、会議となっている予定項目を、業務（定型）、業務（非定型）、会議、外出の4項目で入力しました。
　
　例）4/1 10:00-11:00　業務（定型） 業務報告書の作成



　このように入力した実績データを2月24日～3月11日までエクスポートし、Excelを使って分析してみます。

　Excelに読み込んだデータをピボットテーブルにし、条件付き書式を使って数値を読み取りやすくしました。

　これを見ると、部下の定型業務がタスクの数（データの個数 / 予定詳細）、所要時間共に一番多いことが分かります。これは、細かな定型業務をいくつも行っていることを表しています（1タスクあたり平均約2時間で38タスク）。

　一方、非定型業務の割合はSatohruの方が多く、部下との役割やスキルの違い等が表れています。

　そこで、タスク数をレーダーチャートにしてみました。

　Satohruの定型業務を部下にシフトできれば、非定型な業務にパワーシフトできます。また、部下がスキルを高めて非定型業務の幅が拡がれば、2人で負荷分散をしやすくなります。

　次に、会議の中身を見てみます。

　タスク（先頭2文字のみ表示）別に所要時間を表示していますが、パッと分かることは、Satohruは会議の機会が多いということです。ムダな会議をしている認識はありませんが、タスクを切り替えるにはコストがかかりますから、いかに会議を少なくするか？　というのが課題として浮かび上がってきます。

　以上、簡単ですが前回の続編でした。

　いずれまた、続きをレポートできればと思います。

論文執筆までの過程（メモ）

　突然、管理職昇格試験の通知が来て（考えてみれば該当年度だったが）、主要課題として論文の提出を求められました。文章を書くことは好きなので、論文という課題に抵抗はありませんでしたが、問題は、当たり前のことですがその内容品質です。そこで、今回の論文執筆にあたっては、これまで身につけてきた各種の手法や技法を駆使し、論文の構成を組み立てることにしました。

　まず、テーマの選定ですが、出題されたテーマは4つ。この中からひとつを選択し、その「課題と提案」を論じよという出題です。
　私は「組織」を選びました。もともと来年度は、業務改革や教育に力を入れたいと考えていたので、それほどの時間を要さずにテーマを決定しました。
　次に、論法の方向性ですが、私は「課題と提案」の「課題」というキーワードに注目しました。「課題」という言葉には、どちらかといえば将来に向かって改善すべき点、というような意味合いがあると思います。ということは、会社は管理職候補たちに、「現状を改善していくための、前向きな提案をして欲しい」という要求があると認識しました。そこで、現状が良いとか悪いとかではなく、「より良くしていくためにどうするか？」という理論と実践を構築することにしました。

　そうはいっても、やはり現状の問題点を整理することは重要ですので、まずは、TOC（Theory Of Constraints：制約条件の理論）の根本原因モデルにより、根本原因や循環する原因（負のスパイラル）を抽出しました。

　なお、本文で登場するモデルの作成には、Enterprise Architectを使用しました。

　次に、主要な問題に対する解決の方向性（大要求）を数十文字で記述し、なぜそれらの大要求が必要なのかという理由を「目的」として定義しました。この「目的」は、今回の論文で提案する施策の「目的」となります。そして、目的の実現方法である大要求を、私が「（行動の）3要素ツリーモデル」と呼んでいるモデルに落とし込み、大要求をさらに細粒化しながら、具体的な実現手段を検討しました。

　大要求の細粒化によって細かくなった実現手段を、価値提供の単位であるストーリーにまとめ、そのストーリーを今回はユースケースモデルで表現しました。
　例）大要求→その実現手段→その実現手段→その実現手段(a)
　　　　　　　　　　　　    →その実現手段→その実現手段(b)
　　　上記、(a)と(b)を実現することで大要求を満たす＝価値提供の単位＝ストーリー

　次は、ストーリーの実現シナリオを記述します。イメージとしては、ユースケースとユースケースシナリオに相当します。実現シナリオには、ストーリーの目的、方法、目標（またはベンチマーク、効果）の3項目を記述しました。

　基本的には、この実現シナリオを合成すれば論文ができあがるのですが、論理には論理の筋道であるストーリーが大切です。そこで、ストーリーをユースケースモデルで使用する「先行」・「呼出」の関係で整理することで、論文のストーリーを組み立てました。また、他の分析手法（バリューチェーンやマトリクス分析など）により、各種モデルやそこに記述されている文言を洗練化し、特に、「目的」を会社にとって魅力的な文章に磨きあげました。

　いよいよ論文の執筆を開始しますが、これまでの作業により、目的、ストーリーとその関係、実現シナリオを組み合わせ、文章として組織化することでシステマチックに執筆できるはずです。

　＊今回は自身の頭の整理ということで投稿しました。文章だけでは伝えきれないことが多々ありますので、いずれ具体的なモデルを示しながら再編集できればと思っています。

上流工程の研究グループを立ち上げました

　2010年2月24日、私を含む有志5人により、上流工程の研究グループを立ち上げました。
　第1回目は、2時間程度のフリーディスカッションにとどまりましたが、システム開発に対する想いや、今後の方向性は共有できたと思います。具体的な成果（中間的な物や、問題提起も含め）は、Satohru Noteでもレポートしていきたいと思います。
　次回は、UMLモデル駆動開発チャート（SDEM@富士通の開発ライフサイクル、要件定義手法のRDRA、開発手法のICONIXが合体したもの）を仮の開発パターンとして、さまざまな観点から幅広く議論を行い、より具体的な研究テーマの抽出を行いたいと思います。

サイボウズを使って業務の見える化（試行）

　業務の可視化、特に一人ひとりが行った仕事の実績を捉えるというのは、理屈は簡単ですが、実践や運用が難しいです。
　日報や週報などの業務報告書は、いざ組織的に定義しようとすると項目が多くなり、項目を埋めるだけでもひと苦労です。また、最初はみな真面目に取り組んだとしても、書く方も見る側も、次第に形骸化し消えていく、こんなところではないでしょうか？
　ITで何とかならないか？　と要件を定義し始めると、セキュリティを始めとする非機能要件に煩わされる。そして、情報システム部門の仕事が確実に増えることになりますし、コストもかかります。

　何とか手軽に、あるものを利用して、コストをかけずに、持続可能な業務実績の見える化ができないかなぁ…　と昨日から考えていました。

　我が社には、サウボウズというグループウェアが導入されています。そして、これにはスケジュール管理機能と、そのデータをCSVファイルとしてエクスポートする機能があります。これを利用できないか？　ということで今日は朝から機能の確認をしていました。

　今日から試行運用をシステム部門限定で始めたところですが、大体こんな感じになります。

　このように主要な業務とその時間帯を実績として入力します。これをエクスポートすると、下記のようなCSVファイルが取得できます。

"イベントID","開始日付","開始時刻","終了日付","終了時刻","予定","予定詳細","メモ","参加者","設備"
"710883","2010/3/29","8:30:00","2010/3/29","10:00:00","業務","Xシステム要件開発","","Satohru",""
"710891","2010/3/29","10:00:00","2010/3/29","12:00:00","会議","次期ITインフラについて","","Satohru",""
"710895","2010/3/29","13:00:00","2010/3/29","14:00:00","業務","稟議書の作成","","Satohru",""
"710899","2010/3/29","14:00:00","2010/3/29","16:00:00","業務","社屋LAN工事仕様書作成","","Satohru",""
"710903","2010/3/29","16:00:00","2010/3/29","17:00:00","業務","Xシステム要件開発","","Satohru",""

　これをExcelでちょっと加工し（水色の項目を追加）、

　ピボットテーブルで可視化します。

　いかがでしょう？　これなら安くて簡単です。

　実データを使ってピボットテーブルを操作すれば、おもしろい分析ができるかもしれません。

続きはこちら

情報化ガイドライン

　私は自社の情報化を今後どのように進めていこうとしているのか？　昨年後半から考えていることを一度整理してみます。

　まず、業務には「ストック系」と「フロー系」の業務がある、ということを私は前提としています。

1. ストック系業務
1. 他の業務と強い結びつきを持っておらず、業務の様々な局面で繰り返し利用されるような業務。
2. 例えば、顧客情報を参照する、商品情報に新商品を登録する、などのユースケース。
3. その他の特徴として、非定型な業務であり、要求が利用シーンによって変化することが多い。例えば、レポートに関する要求は、報告する相手やシーンによって異なることが多い。
2. フロー系業務
1. 前工程の成果が次工程のインプットとなる関係の連続によって完了する業務。
2. 例えば、注文から出荷までを管理する、などのユースケース。
3. その他の特徴として、定型的な業務であり、要求が比較的安定している。また、ビジネスモデルの陳腐化に伴い、ある時に一気に変化することがある。

　このように業務（機能要件）を捉えた時に、下図で示すような情報化の方向性が、今私が考えている「情報化ガイドライン」です。

　ストック系の業務は、簡単にいえば「データに対するCRUDができればよい」業務であり、機能要件を実現するため選択肢はかなりたくさんあります。こうような特性から、アジャイルな開発アプローチによって、素早く、継続的に価値を提供することが大切でしょう。そして、既存IT資源を効果的に活用することで、安く、柔軟なシステムを構築できるだろうと考えます。

　いわゆるクラウド・コンピューティングのSaaSやPaaS、IaaSは、ストック系業務の情報化手段として大いに期待しています。

　◆注目している技術、サービスなど。

　Salesforce CRM、Force.com、Google App Engine、Windows Azure Platform、その他WebサービスAPI、XAML。

　フロー系の業務は、組織文化に根差した個性を基盤として構築されていることが多いので、機能要件の実現には、一言でいえば「作り込みが必要」となるケースが多いです。そこで、問題領域をしっかりと分析し、最適化された解決領域をシステム化要件とし、情報化を進める必要があるでしょう。ウォーターフォールを基本としつつ、生産性の高い開発基盤によって、時間とコストをコントロールすることが重要になります。

　◆注目している技術、サービスなど。

　NET Framework 4、Visual Studio、LINQ、ADO.NET Entity Framework。

　こうして出来上がったさまざまなサービスが、疎結合によって、いわゆるSOA( Service-Oriented Architecture )的価値を創出してくれればさらに理想的です。

　また、自社プラットフォームに関しては、仮想化技術を積極的に採用することで、コストの面だけではなく、非機能要求をより高いレベルで実現するためにも重要な要素だと考えます。

　◆注目している技術、サービスなど。

　Hyper-V、VMware、VDI、プロビジョニング。

　自社プラットフォームのサービスから特化した形で、「BPM ( Business Process Management )」と「BI( Business Intelligence )」を明記してみました。

 　BPMは、組織や事業などを継続的に改善していくためになくてはならないものでしょう。また、BIは、見えない未来を少しでも予見するために必要です。

　◆注目している技術、サービスなど。
　SQL Server。

　以上が、現時点で私が持っている、今後の情報化の方向性です。

要求関係モデル

　現在、来期の行動計画を策定中ですが、今年は要求の関係に着目して計画を練っています。
　今までは、私が社にとって必要だと考えた要求を、コスト削減や生産性向上などの一般的な価値として、定性的に、あるいは定量的に表現してきました。しかし、一般化された価値では、ステークホルダー間で共有がスムーズにいかない場面があり、計画の確定、予算の承認までに時間を要することがあったのです。
　そこで、今回はステークホルダーの１人ひとりに、具体的な価値を示すことを目的として、要求の関係を整理することにしました。

　まず、予算編成方針などから経営層の要求であるトップダウン要求を洗い出します。次に、私の要求をピックアップします。そして、下図のように、トップダウン要求を実現するのはボトムアップ要求である、という関係が成り立てば、ボトムアップ要求には妥当性があり、経営層にとっても価値ある要求である、という関係が成り立ちます。また、私はボトムアップ要求の出所を説明しやすくなり、経営層は理解しやすくなると考えられます。

　しかし、ボトムアップ要求がトップダウン要求に直接結びつかないことがあります。例えば、次のようなケースです。

1.  トップダウン要求：　経常利益を○○億円以上にする。 
2. ボトムアップ要求：　不用なPC等を廃棄処分する。

 　不用なPC等の廃棄は必要なことであり、そのための予算が必要ですが、このままではトップダウン要求に対する妥当性が説明できません（「当たり前」であるとか「常識」は、要求同士の関係を何も説明していません）。

　そこで、下図のように要求と要求を接続するためのブリッジ要求を見つける必要があります。これを見つけることができれば、それぞれの要求は次のように文章化できます。

1. トップダウン要求は、ブリッジ要求を内包し、ブリッジ要求はボトムアップ要求により実現される。
2. ボトムアップ要求は、ブリッジ要求を実現し、ブリッジ要求はトップダウン要求に含まれる（または、実現する）。

　先の例も、ブリッジ要求を加えることで関係を整理できます。

1. トップダウン要求：経常利益を○億円以上にする。
2. 【ブリッジ要求：コストを削減する。】
3. 【ブリッジ要求：無駄を排除する。】
4. ボトムアップ要求：不用なPC等を廃棄処分する。

 　このような手法により、情報システム部門として来期必要なすべての要求を整理したものが、下図になります。

　ブリッジ要求は、単に要求同士を橋渡しするだけでなく、管理層の要求に結びつくことが考えられます。したがって、要求関係モデルを作成することは、経営層、管理層、実務層のそれぞれに、全体整合のとれた価値を提供する可能性を高めます。もちろん、システム開発の要求分析にもこの手法は適用できます。

＊上図から一部を抜粋し、具体例を示します。

　黄色で示したボトムアップ要求は、ブリッジ要求として性質を合わせ持っているため、このような位置に表現しています。

　「サーバー更新」というのは、保守期間の終了により自然発生するボトムアップ要求です。しかし、トップダウン要求は「利益目標の達成に繋がる投資を積極的に検討すること」ですので、単純にリプレースするのではなく、そこに投資対効果を高めるためのアイデアが要求されます。そこで、「サーバー更新」とトップダウン要求のふたつに答えるために、「仮想化技術の導入による所有コストの削減計画」というブリッジ要求を加えています。

1. トップダウン要求「経常利益を○○億円以上にすること」は、トップダウン要求「利益目標の達成に繋がる投資を積極的に検討すること」を内包する。
2. ボトムアップ要求「サーバー更新」は、トップダウン要求「利益目標の達成に繋がる投資を積極的に検討すること」の検討要素である。
3. ブリッジ要求「仮想化技術の導入による所有コストの削減計画」は、上位要求を満たす要素である。
4. ボトムアップ要求「仮想化実験」は、ブリッジ要求「仮想化技術の導入による所有コストの削減計画」を実現するために必要なプロセスである。
5. ボトムアップ要求「次期ITインフラストラクチャー」は、上位要求を実現する。

手法の比較

＊言葉足らずと思い緑字部分を補足します。

　本投稿は、要件定義時における設計への踏み込み具合について、ふたつの手法を比較することで検討しています。従いまして、下記赤字の目的とは、要件定義を意味しています。

　簡単な業務モデルを基に、要件定義手法「RDRA」と分析設計手法「ICONIXプロセス」によるモデリングを比較してみました。

　RDRAは要件定義手法なので、設計や実装には原則触れません。ICONIXプロセスは分析から設計へのプロセスなので、下図の一部であるロバストネスモデルはその橋渡しとなる予備設計を行います。

　これらは性質が異なりますので、どちらが優るかという話ではなく、目的を達成するためにはどちらの手法がフィットするか（あるいはどうミックスするか）の問題です。

　プロジェクト特性やプロダクト特性、開発の局面により、特性を認識したうえで使いこなすことが重要です。

（ここから先は見積もりをも含めて）

　同じように、業務フローとユースケースシナリオ、ユースケースの粒度、ユースケースポイントかファンクションポイントかストーリーポイントか？　これらの内どれが優れているとか、唯一絶対の手法はどれかではなく、いかに効率的に、正確に、問題や解決の領域を表現し、コミュニケーションできるかの選択であると考えています。

　つまり、より多くの手法等を学び、適用の対象となる物事に合わせていいとこ取りできればよいと思うのです。