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