1. 開発プロセスの心
12-Ａ-1 萩本順三
株式会社 匠Lab
代表取締役社長
http://www.takumi-lab.co.jp

2. 開発プロセスとは
時系列を伴う見える化
そのメリットとは何？
いままでの開発の成功事例をパターンとして伝える
開発の標準化が行える

3. プロセスとは見える化
時系列を伴う見える化
UMLなどは、局面の見える化

4. それぞれの開発プロセスのメリット
ウォータフォール開発プロセス
管理がしやすい
受発注契約に向いている
反復開発プロセス(RUP)
システム要件を明確にしながらも、開発リスクに
柔軟に対応しやすい
アジャイル開発プロセス
開発者のモチベーションを高めやすい
専門集団として開発パワーを発揮しやすい

5. ウォータフォール開発プロセス
の問題
なぜウォータフォール型開発プロセスではダメな
のか？
そもそも、それは、ウォータフォール型なの？
欠点は、
1. 要求の早期検証ができない
2. アーキテクチャの早期検証ができない。
時代が求めるリスクマネジメント型開発プロセスとは
上記を解消できる開発プロセス

6. ウォータフォール開発プロセス
をうまく活用する秘伝
隠れプロセスによるリスクマネジメント
知っていればうまくいく！
隠してていいの？
上流工程
要求仕様
“見える化”するとそれは何？
基本設計
企画
評価 仕様 設計
企画
下流工程
開発
実装
評価 仕様
要求の検証
開発
テスト
アーキテクチャの検証

7. ウォータフォール開発プロセス
をうまく活用するには
シャドウプロセスを“見える化“して
リスクマネジメントを強化した、
パラレル型開発プロセスを確立せよ！

8. 反復開発プロセスを成功させる
リファレンスモデルの１形態と考えよ
ドメインの特徴、開発経験によりカスタマイズせよ
下記の２点によりリスクマネジメント
どの程度要求獲得にリスクがあるのか？
開発環境に不慣れ、アーキテクチャが複雑など、どの程度
アーキテクチャを検証すべきか？
方向付け、推敲、構築、移行なども拘りすぎるな
重要な事は、リスクマネジメントを如何にやるか
要求の検証
アーキテクチャの検証

9. アジャイル開発プロセスを成功させる
プロセスが嫌い？
プロセスを重視しないが、プロセスは存在する。
設計をしない？
設計は行わないわけではない、検証重視の設計を行う
だけ。
モデリングをしない？
モデリングをしないのではなく、モデルはコミュニケーシ
ョンの中で最低限共有する。
ドキュメントを書かない？
ドキュメントを書かないのではなく、無駄なドキュメントを
書かないだけ。

10. 反復とアジャイルの違い
計画重視
反復開発 価値 価値
価値
構築
方向付け 推敲
計画重視(管理重視)
早期検証の 早期検証の
価値固定型 ための反復 ための反復
現在見えている価値
アジャイル開発 価値
価値 価値
価値重視（価値拡大型）
実施の中からプランを最適化 価値重視 価値重視
拡大のため 拡大のため
の反復 の反復
それぞれの長所が弱点となる！

11. プロセスはこれから進化する
（弱点の解消）
ウォータフォール開発プロセス
シャドウプロセスを”見える化”せよ
反復開発
開発プロセスの中で、ビジネスをモデリングする
ようなチンケな発想ではダメ
要求開発を参考にせよ！
www.openthology.org/
アジャイル開発
ビジネスのスケールで考えなければ道に迷う。
要求開発段階でアジャイル開発が必要とされる

12. 要求開発とは
要求は、すでに在るものではなく、開発する
ものであるというコンセプトの基にビジネス
の見える化局面を方法論（プロセス含む）化
したもの。
http://www.openthology.org/

13. 要求開発のプロセス範囲
オペレーション
戦略
ビジネス
ビ
ビジネス戦略 オペレーション
ジ
ネ
ス
表（価値） What How 裏（実現）
What 表（価値）
裏（実現） How
シ
表（価値） What How 裏（実現）
ス
テ
ム システム要求 システム設計

14. 開発プロセスの進むべき方向
分ける：
フェーズを分ける、フェーズの中での
作業を明確にする。 開発プロセス
現状は開発プロセスのみ
繋げる：
ビジネス開発プロセス ビジネス開発プロセス 開発プロセス
を定義し開発プロセス （たとえば要求開発）
と繋げる
ビジネス開発プロセス
並行性を試みる：
ビジネス開発プロセス
の中に開発プロセスを
組み込む 開発プロセス
（並行に行う）

15. プロセスの洗練
What What
（何をしたいか） （何をしたいか）
最適な実現
方法を発見
How How
How How
How How
（実現方法） （実現方法）
要求のリスクマネジメント イノベーティブな提案による要求の創出

16. プロセスの本質
Step1:分ける
分けることは分かること
ビジネスとシステム開発、プロセス・フェーズ、レイア、作業分担、所属部
署
Step2:繋げる
繋げることで初めて価値が生まれる
繋げるには分けたもの同士の知識のカスケードが鍵となる。
Step3:並行性を試みる
価値の検証、価値の向上、究極の効率化
そもそも分けたものは同時に理解したり、実施したりすることが
望まれる。それにより、価値の検証と、価値の向上、および効
率化につながる
※残念ながら、現在の開発は、
「分けるだけに関心を持つ」か「分けないで繋いでいる」だけ

17. コタツモデル

18. 目指すべき開発プロセスとは
リアルなプランニングが可能な知識
プロセスは常に改良されなければならない
プロセスはシンプルでなければならない
プロセスは”見える化”されていなければならない
プロセスはやりがいをもたらさなければならない
プロセスはチームによって最適化されなければなら
ない

19. Openthologyのモデルと目標
（ ２００３年に宣言した私の目標）
ITシステム
Bシステム
ITシステム ITシステム
設計モデル
②スケッチ
モデル（UML) ITシステム
ITシステム
（瞬間の写像モデル） 設計モデル
分析モデル
業務システム
Aシステム
分析モデル
①プロセスのモデル
（作業の時系列を可視化したモデル）
ビジネスTo-Be, Realizeモデル
③変化するためのモデル
ビジネスモデル （As-Is ToBe変化の過程を見える化）
④ヒューマンプロセス
ビジネスAs-Isモデル
のモデル化（育てのモデル）
（参加者のモチベーションを高める）

20. 開発プロセスは管理型から
人の能力を活かすプロセスに進化する
そのために必要な「技」「人」「心」を強くするためのプロ
セス作り
心に響くプロセス作り
コミュニケーション 気づき 感動
開発言語・環境 モデル カッコよさ
ウキウキ
マネジメント
ワクワク
人としての
心のモデル
活動モデル
技のモデル
コタツモデル
やる気
方向付け 推敲 構築 移行
プロセス ファシリテーション
思考法

21. 守・破・離のプロセス
プロセスのあるべき姿
守：
まずは勉強する。
破
カスタマイズして独自のプロセスを確立する。
離
ＩＴ企業として価値を出せるよう、契約のやり方も含め
て根本からチェンジする。

22. 最後に：みんなで最適なプロセス作りに取り組もう
私も要求開発段階とシステム開発段階をも
う一度見直し、両方のプロセスを「分け」、「
繋げ」「並行で走らせる」ためのプロセスつく
りに励んでいます。
その名は、匠メソッド

23. 関連 URL
エンジニアフリー雑誌
ＥＭ ＺＥＲＯ「萩本インタビュー～～技術顧問という仕事～～」 連載中
アイティメディア 「ソフトウェアの匠」
匠メソッドの必要性について、＠IT自分戦略研究所にて、問題点と解決策の概要を連載します。
http://jibun.atmarkit.co.jp/lskill01/rensai/takumi/01/01.html
マイクロソフト主催「ソフトウェア開発未来会議」
ソフトウェア開発の未来について対談および記事を書いていく
http://developerscafe.jp/future/
日経エンタープライズプラットフォーム「萩本・匠Style研究所」
現在のソフトウェア開発の問題やあるべき姿をユーザの視点で説明します。
http://itpro.nikkeibp.co.jp/article/COLUMN/20081215/321471/
リコーソフト Ｗｅｂ技術情報ページ
要求開発超入門…匠メソッドのベースの要求開発を解説
http://www.ricoh-soft.co.jp/genki/
豆蔵ソフト工学ラボ「エンジニアリングを楽しもう！ 」
第1回：クリエイティブなエンジニアスタイル５カ条公開中
http://labo.mamezou.com/
匠Lab技術情報ページ 1月公開予定
上記連載で取り上げているようなユーザ企業とＩＴ企業における問題・課題の本質に迫ります。