Your SlideShare is downloading. ×
0
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
【12-A-1】 開発プロセスの心
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

【12-A-1】 開発プロセスの心

1,823

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,823
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
126
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 開発プロセスの心 12-A-1 萩本順三 株式会社 匠Lab 代表取締役社長 http://www.takumi-lab.co.jp
  • 2. 開発プロセスとは 時系列を伴う見える化 そのメリットとは何? いままでの開発の成功事例をパターンとして伝える 開発の標準化が行える
  • 3. プロセスとは見える化 時系列を伴う見える化 UMLなどは、局面の見える化
  • 4. それぞれの開発プロセスのメリット ウォータフォール開発プロセス 管理がしやすい 受発注契約に向いている 反復開発プロセス(RUP) システム要件を明確にしながらも、開発リスクに 柔軟に対応しやすい アジャイル開発プロセス 開発者のモチベーションを高めやすい 専門集団として開発パワーを発揮しやすい
  • 5. ウォータフォール開発プロセス の問題 なぜウォータフォール型開発プロセスではダメな のか? そもそも、それは、ウォータフォール型なの? 欠点は、 1. 要求の早期検証ができない 2. アーキテクチャの早期検証ができない。 時代が求めるリスクマネジメント型開発プロセスとは 上記を解消できる開発プロセス
  • 6. ウォータフォール開発プロセス をうまく活用する秘伝 隠れプロセスによるリスクマネジメント 知っていればうまくいく! 隠してていいの? 上流工程 要求仕様 “見える化”するとそれは何? 基本設計 企画 評価 仕様 設計 企画 下流工程 開発 実装 評価 仕様 要求の検証 開発 テスト アーキテクチャの検証
  • 7. ウォータフォール開発プロセス をうまく活用するには シャドウプロセスを“見える化“して リスクマネジメントを強化した、 パラレル型開発プロセスを確立せよ!
  • 8. 反復開発プロセスを成功させる リファレンスモデルの1形態と考えよ ドメインの特徴、開発経験によりカスタマイズせよ 下記の2点によりリスクマネジメント どの程度要求獲得にリスクがあるのか? 開発環境に不慣れ、アーキテクチャが複雑など、どの程度 アーキテクチャを検証すべきか? 方向付け、推敲、構築、移行なども拘りすぎるな 重要な事は、リスクマネジメントを如何にやるか 要求の検証 アーキテクチャの検証
  • 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のモデルと目標 ( 2003年に宣言した私の目標) ITシステム Bシステム ITシステム ITシステム 設計モデル ②スケッチ モデル(UML) ITシステム ITシステム (瞬間の写像モデル) 設計モデル 分析モデル 業務システム Aシステム 分析モデル ①プロセスのモデル (作業の時系列を可視化したモデル) ビジネスTo-Be, Realizeモデル ③変化するためのモデル ビジネスモデル (As-Is ToBe変化の過程を見える化) ④ヒューマンプロセス ビジネスAs-Isモデル のモデル化(育てのモデル) (参加者のモチベーションを高める)
  • 20. 開発プロセスは管理型から 人の能力を活かすプロセスに進化する そのために必要な「技」「人」「心」を強くするためのプロ セス作り 心に響くプロセス作り コミュニケーション 気づき 感動 開発言語・環境 モデル カッコよさ ウキウキ マネジメント ワクワク 人としての 心のモデル 活動モデル 技のモデル コタツモデル やる気 方向付け 推敲 構築 移行 プロセス ファシリテーション 思考法
  • 21. 守・破・離のプロセス プロセスのあるべき姿 守: まずは勉強する。 破 カスタマイズして独自のプロセスを確立する。 離 IT企業として価値を出せるよう、契約のやり方も含め て根本からチェンジする。
  • 22. 最後に:みんなで最適なプロセス作りに取り組もう 私も要求開発段階とシステム開発段階をも う一度見直し、両方のプロセスを「分け」、「 繋げ」「並行で走らせる」ためのプロセスつく りに励んでいます。 その名は、匠メソッド
  • 23. 関連 URL エンジニアフリー雑誌 EM ZERO「萩本インタビュー~~技術顧問という仕事~~」 連載中 アイティメディア 「ソフトウェアの匠」 匠メソッドの必要性について、@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/ リコーソフト Web技術情報ページ 要求開発超入門…匠メソッドのベースの要求開発を解説 http://www.ricoh-soft.co.jp/genki/ 豆蔵ソフト工学ラボ「エンジニアリングを楽しもう! 」 第1回:クリエイティブなエンジニアスタイル5カ条公開中 http://labo.mamezou.com/ 匠Lab技術情報ページ 1月公開予定 上記連載で取り上げているようなユーザ企業とIT企業における問題・課題の本質に迫ります。

×