BPStudy#97 世界に価値を創り出すエンジニアの技術

5,166 views

Published on

2015/9/29(火) に開催されたBPStudyで発表した資料です。

Published in: Internet
0 Comments
20 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,166
On SlideShare
0
From Embeds
0
Number of Embeds
3,702
Actions
Shares
0
Downloads
23
Comments
0
Likes
20
Embeds 0
No embeds

No notes for slide

BPStudy#97 世界に価値を創り出すエンジニアの技術

  1. 1. 世界に価値を創り出す エンジニアの技術 株式会社ビープラウド 佐藤治夫 2015/9/25 BPStudy#97
  2. 2. 自己紹介 • 佐藤治夫(Sato Haruo) • 株式会社ビープラウド代表取締役社長 2006年5月設立 • BPStudy主催(2007年9月〜) • connpass 企画・開発・運営 • PyConJP2015 基調講演で登壇します。 2015/10/11(日)
  3. 3. ・仕事における価値とは何か? ・アジャイルと要求開発の関係 ・要求開発(匠メソッド) ・デリバリー ・私が今後やりたいこと アジェンダ 世界に価値を創り出すエンジニアの技術
  4. 4. 仕事における価値とは何か? テーマ: 世界に価値を創り出すエンジニアの技術
  5. 5. 仕事における価値とは 製品やサービスを届け 効果を生み出すことで 人を嬉しい気持ちにすること 製品 サービス 嬉しい 対価 つくる 提供する 価値 届ける (デリバリー) 効果 (インパクト) アイデア
  6. 6. 仕事 = 価値を創り出すこと 創り出した価値が 大きいほど対価は大きい 対価 価値 創り出す 良い仕事をするには → 価値は何かを問い続ける必要がある
  7. 7. エンジニアの場合 製品 サービス 嬉しい 対価 つくる 提供する 価値 届ける (デリバリー) 効果 (インパクト) アイデア エンジニアの場合 ソフトウェア
  8. 8. 製品 サービス 嬉しい つくる 提供する 価値 届ける (デリバリー) 効果 (インパクト) アイデア → 価値 価値はどうやって創り出せばよいか? アイデア 仕事 = 価値を創り出すこと ソフトウェア
  9. 9. 「価値のあるソフトウェア」は どのように創られるのか?
  10. 10. すべてのものは2度つくられる 知的創造 物的創造 「7つの習慣」 スティーブン・R・コヴィー著
  11. 11. 価値アイデア 要求 要件 設計 実装 ・製品 ・サービス ・システム 知的創造 物的創造 価値を生み出すソフトウェアを創るには「要求」が重要な位置を占める <理由> ・アイデアは実現しなければ意味をなさない ・要件・設計、実装は、要求を実現するためのもの ソフトウェアは2度つくられる 1度目 2度目 直結
  12. 12. 価値を創り出す「要求」は どのように導き出せば良いか?
  13. 13. アジャイル開発宣言 アジャイルソフトウェアの12の原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に 提供します。 http://www.agilemanifesto.org/iso/ja/principles.html Q. アジャイル開発を実践すれば、 価値のあるソフトウェアをつくることができる?
  14. 14. スクラム スクラムマスター メンバー メンバー 開発チーム プロダクトオーナー プロダクト バックログ スプリント1 スプリント2 ・・・ 選択 開発 開発 要求 サポート 前提:プロダクトオーナーが価値を生み出す要求を把握している →属人的 価値を創り出す「要求」はどのように導き出せば良いか?
  15. 15. ユーザー・ストーリー・マッピング プロダクト バックログ ストーリーの流れ 詳細 説明 ユースケース記述をマッピングしていく 落とし込む リリース計画 開発戦略 価値を創り出す「要求」はどのように導き出せば良いか? 懸念点:導き出した要求の検証根拠が曖昧になりがち
  16. 16. インセプション・デッキ プロジェクトの枠組みを定義→要求の具体的な提示は無い 我々はなぜ ここにいるのか エレベーター ピッチ パッケージ デザイン 夜も眠れない 問題 期間を 見極める ご近所さんを 探せ やらないこと リスト 何を諦めるのか はっきりさせる 何がどれだけ 必要なのか 解決案を描く 価値を創り出す「要求」はどのように導き出せば良いか? 技術構想プロジェクトの方向性 ステークホルダー リスク 計画・優先順位
  17. 17. XP(eXtreme Programming) 顧客 ・ストーリーの作成 ・リリース計画 ・受け入れテスト ・短期リリース 管理者 ・責任の受け入れ ・援護 ・四半期毎の見直し ・ミラー ・最適なペースの仕事 ・テスト駆動開発 ・ペアプログラミング ・リファクタリング ・ソースコードの共同所有 ・継続的インテグレーション ・YAGNI 開発者 ・反復型開発 ・共通の用語 ・開けた作業空間 ・振り返り ストーリーカード(要求) 価値を創り出す「要求」はどのように導き出せば良いか? 懸念点:導き出した要求の検証根拠が曖昧になりがち?
  18. 18. DDD ドメインエキスパート 開発者 ドメイン モデル抽象化 ドメイン 知識 共通理解 共通理解 実装 前提:ドメインエキスパートが価値を生み出す要求を把握している →属人的 価値を創り出す「要求」はどのように導き出せば良いか? ※ DDD=Domain Driven Design
  19. 19. 価値アイデア 要求 要件 設計 実装 知的創造 物的創造 スクラム 要求を創り出す方法論が抜けている 直結 重要 USM USM=User Story Mapping ID = Inception Deck XP = eXtreme Programming DDD=Domain Driven Design ID XP DDD ←要求の検証根拠に疑問 ←プロジェクトの方向性を統一することが目的 ←要求の 検証根拠に疑問
  20. 20. アジャイル開発宣言 アジャイルソフトウェアの12の原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に 提供します。 Q. アジャイル開発を実践すれば、 価値のあるソフトウェアをつくることができる? A. アジャイル開発を実践するだけではつくれない! (運が良ければつくれる)
  21. 21. アイデア 要求 「企画」 カタチにする 知的創造 製品企画 システム企画 経営企画 etc…. 要求をつくりだす= 企画と考えるとわかりやすい
  22. 22. 企画でよくある問題 アイデア アイデア ・ビジネスモデル ・対象顧客 ・機能 ・優先順位 空中戦 ①終わらない議論 企画書 プロトタイプ ②企画の属人的検証 ③的外れなプロトタイプ ノリでつくる ④戦略なき単発の戦術
  23. 23. どうすれば よい企画ができるのか? (=要求をつくりだす)
  24. 24. 価値アイデア 要求 要件 設計 実装 知的創造 物的創造 スクラム 価値を創り出すプロセスを学ぼう 直結 重要 USM ID XP DDD 要求開発 USM=User Story Mapping ID = Inception Deck XP = eXtreme Programming DDD=Domain Driven Design
  25. 25. 「モデリング」手法によりアイデアを「見える化」し 真の「要求」を創り出す手法 要求開発(匠メソッド)
  26. 26. モデリングを主体としているので、直感的でわかりやすい。 そのため発想がわきやすく、合意形成しやすい 「一枚の絵は1024の単語に値する」 高い視点から俯瞰できる 「ソフトウェア要求」 Karl.E.Wiegers著 少ない表現で多くの情報量 文字主体の情報
  27. 27. モデル=旅行の写真 旅行のシーン がよみがえる チームの対話が よみがえる モデル
  28. 28. 要求開発(匠メソッド) 「要求開発アライアンス」発足→Openthology策定 ↓ 2006年書籍出版 ↓ 匠BusinessPlaceの萩本順三さんが、Openthologyを進化さ せた「匠メソッド」を開発。 ↓ 匠Net、匠道場などを通じて、普及活動中。 匠道場=2013年1月〜、毎月参加(33回中、32回参加) 新しい価値あるものを創り出す方法論・考え方を 学び、身につけるために参加
  29. 29. 特徴1:合意形成のしやすさ アイデア 納得感 対話しながら、アイデアをかたちにしていく ①終わらない議論
  30. 30. 特徴2:企画の検証しやすさ 価値 目的 ビジョン コンセプト 解決策業務戦略 ビジネスモデル <イメージ> <実現> ・議論が空中戦にならない ・手段の目的化を防ぐ ・トレーサビリティによる検証 ②企画の属人的検証
  31. 31. 特徴3:効果的なプロトタイピング プロトタイプ プロトタイプアイデア 的を外し、プロトタイプがやり直しになることも アイデアに一貫性があり、的に近いプロトタイプになる可能性が高い アイデアの洗練 思考、言葉 行動 <要求開発によるプロトタイピング> ③的外れなプロトタイプ
  32. 32. 特徴4:戦略にもとづいた効果的な施策実現 選択と集中→ 必要充分でミニマムなリリース ④戦略なき単発の戦術
  33. 33. ①観察 ⑥計画・実行 ②価値のイメージ ③ビジョン コンセプト ④検証 ⑤プロトタイピング フェーズ・進め方 イメージ 実現
  34. 34. ①観察する 現状を観察する。関係・問題点を抽出する(AsIs)
  35. 35. ②価値のイメージ ステークホルダーの立場に立ち、嬉しい気持ちをイメ ージし、未来の価値を描く(ToBe) ポイント:視点を自分→他人に変える
  36. 36. 価値をイメージする 製品 サービス 嬉しい つくる 提供する 価値 届ける (デリバリー) 効果 (インパクト) 価値のイメージ アイデア
  37. 37. ③ビジョン・コンセプト オンライン上であらゆるものを 発見し、購入できる場をつくること 地球上で最大級の品揃え <ビジョン> <コンセプト> <言葉> <意味> <ストーリー> <デザイン>
  38. 38. ビジョン/ミッションの例 Google 1クリックで世界の情報へアクセス可能にする Facebook よりオープンに繋がれた世界をつくり、シェアすることで、 人々に力を与えること Linkedin 激しい職場競争において全てのプロ達にチャンスを提供する Salesforce ソフトウェアの終焉 WikiPedia 誰でも参加できる共同参加の百科事典
  39. 39. ビジョンの重要性 Evernoteのビジョン みなさんのための 第2の脳になる 全ての施策はビジョンにつながる コンテキスト機能 文章を書く バックグランドで 自動検索 ・過去のノート ・日経、ITProなど
  40. 40. ④プロジェクトの実現手段を検討する 課題 問題点 ビジョン コンセプト 目的 戦略要求 業務要求 IT要求 解決策
  41. 41. 要求の4象限 戦略 要求 業務 要求 IT 要求 システム 開発 <経営者の視点> <現場の視点> <ITの視点> <開発の視点>
  42. 42. プロジェクトの実現手段を検討する 戦略要求 業務要求 IT要求 顧客とのコミュニ ケーションによる ファンの育成 顧客に直接 お礼の連絡 をしたい 顧客へのメ ール送信機 能 <経営者の視点> <現場の視点> <ITの視点> 目的 手段 目的 手段 What How What How システム設計 <開発> 設計・実装
  43. 43. 要求分析ツリーの事例
  44. 44. connpassでの企画・戦略(抽選機能) 必要充分でミニマムなリリース
  45. 45. connpassでの企画・戦略(グループ機能フェーズ 2) 1次リリース後に明らかになった課題を 1次リリース時の要求分析ツリーに追加 1次リリースの要求分析ツリーをもとに2次開発を検討
  46. 46. 「要求の爆発」の恐怖からの解放 赤色のIT要求 =要求分析ツリーをつくってから アイデアとして出たIT要求 (通常) 優先度を決める段階の新しいアイデア → 議論を収束させたいので敬遠されがち (要求の爆発への恐怖) (要求分析ツリーによる方法) 「ツリーに葉を足すだけ」 ↓ 精神的負担が軽く、新しいアイデアに対し ても、前向きに議論できる
  47. 47. つくるものは小さく、価値は大きく 時間、リソースは常に不足している ↓ 全てをつくることは不可能 ↓ 何をどの順番つくっていくか=戦略(優先順位づけ)が必要 価値 つくるもの
  48. 48. connpassでの企画・戦略(抽選機能) 必要充分でミニマムなリリース
  49. 49. 建設的な議論が可能に 枝葉のレベルだと議論が収集しない Aさんの アイデア Bさんの アイデア 取捨選択の議論がしやすい (そもそもの価値に近い) プロジェクトの目的A プロジェクトの目的B <個人の価値観> <Projectの価値観>
  50. 50. 戦略における「攻め」と「守り」 <攻めの戦略要求> <守りの戦略要求> ユーザー向けの大きな機能開発 etc 小改善、運用向け改善 etc ・「前回のフェーズは攻めて効果が出たから、引き続き攻める」 ・「前回は攻めて一定の効果が出たから、今回は守りを固める」 戦略要求レベルで 取捨選択する
  51. 51. Howからの突き上げ ② ① (例) 人工知能(AI)は、 〜のようなことができる そのようなことが可能なら 〜したい 業務要求 IT要求戦略要求
  52. 52. Howからの突き上げをするには 技術 技術 エンジニア 技術の進歩 エンジニア 技術が追いつかず 未実現 技術が進歩し、実現可能に IT(How)の専門家 ツールの充実 ツール 良い要求を創り出すためには、技術の継続学習が必要 (= イノベーションのための継続学習) 価値
  53. 53. 匠メソッドのフォーマットを埋めて モデルをつくれば、 プロジェクトは成功するのか?
  54. 54. プロジェクト(企画)を 成功させるのに最も重要なもの → 持続的なモチベーション(情熱)
  55. 55. 持続的なモチベーションが無いと失敗する 価値アイデア 要求 要件 設計 実装 製品・システム モチベーションが無いと ・関心が薄い→行動の発想が湧かない・気づかない→浅い思考 ・行動しない ↓ 判断ミス/行動の失敗を繰り返し、負の結果が蓄積される ↓ 最終的に失敗する プロジェクトは長い
  56. 56. 持続的なモチベーションを引き出す プロジェクトの成功には持続的なモチベーションが必要 ↓ メンバーの持続的なモチベーションを引き出す リーダーシップが必要
  57. 57. リーダーシップの変化 リーダー(ボス) メンバー メンバー リーダー メンバー メンバー社外 社外 ビジョン 仕事 実行 ビジョン 仕事 実行 チーム
  58. 58. 持続的モチベーションをうみだすもの ・当事者意識/参加意識 ・共感 ・納得感
  59. 59. ①空白のキャンバスのリーダーシップ モデリング 未来 アイデア 空白のキャンバスに、共に未来を描いていく 当事者意識/参加意識を生み出す 持続的モチベーションを引き出す リーダーシップ
  60. 60. ビジョン ストーリー 共感 共感 現状 将来の姿 リーダー メンバー ビジョンを価値 で検証 魅力のあるビジョンやストーリー → 共感
  61. 61. 一貫性のある戦略 → 納得感 ビジョン 行動 どのような道筋(戦略)で 進めて行くかを論理的に見 えるかたちにする ↓ これならやれるかもしれな いという納得感 「良い戦略は、十分な根拠に立脚したしっかりした基本構造を持ってお り、一貫した行動に直結する」 「良い戦略、悪い戦略」 リチャード・P・ルメルト著
  62. 62. 未来の価値を描くと、意識がシフトしていく ①絶対にできない(あきらめ) ②きっとできない ③たぶんできない ④ひょっとするとできるかもしれない ⑤もしかするとできるかもしれない ⑥おそらくできるかもしれない ⑦たぶんできるでしょう ⑧きっとできるはずだ(自信) ⑨必ずできる ⑩できないとおかしい(確信) 心境の変化 未来の価値を描く
  63. 63. ①ダウンローディング ②観る(Seeing) ⑦実践(Performing) ③感じ取る(Sensing) ④プレゼンシング ⑤結晶化 ⑥プロトタイピング 自分達は何者なのか(Self) 自分達の為すべきことは何か(Work) 創造へと導くリーダーシップ 持続的モチベーションを引き出す リーダーシップ 「U理論」C オットーシャーマー 著 対話によるプロセス Uの一番底にあるもの
  64. 64. 入力 (収穫) 要求開発 (匠メソッド) ③チームという畑を耕し 価値を生み出すリーダーシップ 価値 製品・サービス システム (種) (畑) アイデア 土壌=HRTの原則 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) 持続的モチベーションを引き出す リーダーシップ 「Team Geek」Brian W. Fitzpatrick著
  65. 65. アイデア
  66. 66. 製品 サービス 嬉しい つくる 提供する 価値 届ける (デリバリー) 効果 (インパクト) アイデア:何に取り組むか? アイデア
  67. 67. NGパターン: 儲かりそうだという理由で手を出す 儲かっている ジャンル ¥¥$$ お金 = 外発的動機 ↓ 長続きしない
  68. 68. 経験 経験 経験 強み 興味 機会 人生 取り組むべきこと × 時代の流れ・ニーズ 自分(会社) 自分をつくってきた経験 自分の内から出て来たので 情熱が長続きする ↓ 成功する 社会 自分(強み、興味、経験) × 社会(機会) = アイデア(取り組むべきこと) 「立志」
  69. 69. イノベーションの7つの機会 1. 予期しない成功と予期しない失敗をチャンスと捉える 2. 不調和(ギャップ)を探す 3. プロセスニーズを発見する 4. 産業や市場の構造の変化を知る 5. 人口構造の変化に着目する 6. 認識の変化を捉える 7. 新しい知識を活用する 「イノベーションと起業家精神」P・F・ドラッカー著
  70. 70. 忘れがちなこと
  71. 71. 届ける(デリバリー)を忘れない 製品 サービス 嬉しい つくる 提供する 価値 届ける (デリバリー) 効果 (インパクト) マーケティング 販売チャネル
  72. 72. 世界に価値を創り出す エンジニアになるには
  73. 73. 設計 実装要件 ビジョン、目的 コンセプト、戦略 ビジネスモデル… 要求 世界に価値を創り出すエンジニアの技術 アイデア 価値 取り組むべきこと= (強み+興味+経験)× 機会 (=イノベーション) アジャイル開発、設計技術、実装技術 →Howからの突き上げ+継続学習 マーケティング (顧客の創造) 価値を描く 持続的モチベーションを ひきだすリーダーシップ 要求開発 届ける (デリバリー) ※赤字に取り組む/意識を向ける
  74. 74. 全部やるのは 時間がないのでは?
  75. 75. ①観察 ⑥計画・実行 ②価値のイメージ ③ビジョン コンセプト ④検証 ⑤プロトタイピング 要求開発:④までで3日〜7日 イメージ 実現 1H 2H〜 1H〜 4H〜
  76. 76. connpassでかかった時間 かかった時間:約1日 ・午前中:価値分析モデル(2時間) ・午後:要求分析ツリー(4時間)
  77. 77. 効果:PVが4倍に! 3年間横ばい 1年半で4倍に 匠メソッドによる 要求開発
  78. 78. 設計 実装要件 ビジョン、目的 コンセプト、戦略 ビジネスモデル… 要求 意識を向けるだけでもOK → 視野が広がる アイデア 価値 取り組むべきこと= (強み+興味+経験)× 機会 (=イノベーション) アジャイル開発、設計技術、実装技術 →Howからの突き上げ+継続学習 マーケティング (顧客の創造) 価値を描く 持続的モチベーションを ひきだすリーダーシップ 要求開発 届ける (デリバリー)
  79. 79. 私が今後やりたいこと
  80. 80. エンジニアが自ら価値を創り出す組織を創る エンジニア 価値 自分 エンジニア 導く 創造する
  81. 81. まとめ
  82. 82. 設計 実装要件 ビジョン、目的 コンセプト、戦略 ビジネスモデル… 要求 世界に価値を創り出すエンジニアの技術 アイデア 価値 取り組むべきこと= (強み+興味+経験)× 機会 (=イノベーション) アジャイル開発、設計技術、実装技術 →Howからの突き上げ+継続学習 マーケティング (顧客の創造) 価値を描く 持続的モチベーションを ひきだすリーダーシップ 要求開発 届ける (デリバリー) 価値を創り出すプロセスを学ぼう
  83. 83. ご清聴ありがとうございました!

×