【12-础-1】 开発プロセスの心
- 1. 開発プロセスの心 12-Ａ-1 萩本順三 株式会社 匠Lab 代表取締役社長 http://www.takumi-lab.co.jp
- 4. それぞれの開発プロセスのメリット ウォータフォール開発プロセス 管理がしやすい 受発注契約に向いている 反復開発プロセス(RUP) システム要件を明確にしながらも、開発リスクに 柔軟に対応しやすい アジャイル開発プロセス 開発者のモチベーションを高めやすい 専門集団として開発パワーを発揮しやすい
- 5. ウォータフォール開発プロセス の問題 なぜウォータフォール型開発プロセスではダメな のか？ そもそも、それは、ウォータフォール型なの？ 欠点は、 1. 要求の早期検証ができない 2. アーキテクチャの早期検証ができない。 時代が求めるリスクマネジメント型開発プロセスとは 上記を解消できる開発プロセス
- 6. ウォータフォール開発プロセス をうまく活用する秘伝 隠れプロセスによるリスクマネジメント 知っていればうまくいく！ 隠してていいの？ 上流工程 要求仕様 “見える化”するとそれは何？ 基本設計 企画 評価 仕様 設計 企画 下流工程 開発 実装 評価 仕様 要求の検証 開発 テスト アーキテクチャの検証
- 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月公開予定 上記連載で取り上げているようなユーザ企業とＩＴ企業における問題?課題の本質に迫ります。