アイデアをカタチにする方法～ 要求・組織・人・キャリア

株式会社ビープラウド 佐藤治夫

2014/8/29BPStudy#84

BPStudy７周年記念発表

自己紹介• 佐藤治夫（Sato Haruo）

• 株式会社ビープラウド 代表取締役社長（2006年5月23日設立）９年目

• 大手SIer → 30人くらいのSIer → 個人事業主

• 技術記事執筆：DBマガジン、JavaPress,Codezine、@IT など

• Twitter: @haru860

ソフト開発python研修

コンサルティング

BPStudyBPRD

(BePROUD Remote Day)

ビープラウドの取り組み

ビープラウドの取り組み

2012年3月出版

Pythonによる開発ノウハウを凝縮

Pythonチケット チーム開発 チケット駆動開発mercurial 継続的インテグレーション テスト パフォーマンスチューニング

日経ソフトウェア 2014年2月号

アジェンダ

・取組みの経緯 ・アイデアをカタチにする要求開発 ・要求開発、connpassでの適用事例 ・アイデアをカタチにするための　　組織（チーム）、コラボレーション ・エンジニアのキャリア

但し書き

・「アイデアを生む」方法の話ではないです。 !・当発表は、私が約２年間勉強して来たことと、実践で取り組んできたことの、中間発表です。 !・発表のメインテーマの方法論は、現在進行中で進化しているので、話している内容が正しいとは限りません。 !・生温かく見守ってください !・発表する理由は最後に。

経緯・背景2011年8月初の自社サービス liblarリリース

本を友達と共有、すばらしい本に出会うためのサービス

liblar2011年8月liblarリリース→ リリース直後招待制 → １日で5000人が会員と登録 → 日経新聞にもリリース記事が載って → はてなブックマークも500超

→ その後….

→長続きしなかった….

「とりあえずつくる。動くものをリリースしてユーザーの反応をみながら改善していけばいい！」

一次開発だけで ・エンジニア２名×４か月 ・デザイナー１名×４か月 ・企画担当者１名×４か月 → 16人(1000～1500万）

とはいうものの….

経営者の叫び

小企業には軽くはない金額 資本金より大きい金額…胃が痛い….

!「とりあえず」で始めてしまっていいの！？

走りながら考える価値の発揮 目的の達成

プロジェクトスタート

間違った方向にロケットスタート

途中で力尽きる…

走りながら…でも成功する例 ・センスがよかった ・運がよかった

経営者の叫び その２

小企業には軽くはない金額 資本金より大きい金額…胃が痛い….

!センスとか運にかけてもいいの！？ 「まずはやってみろよ」とかでいいの！？

「つくる」前の考え方がわからないから思考停止に陥ってないか？

売上の推移を画面でグラフで

みたい

似たようなことがシステム開発の現場でも

顧客現場担当者 開発者

言われたままつくる 実はCSVでダウン

ロードして、Excel

でグラフを表示すれば充分だった！

<開発期間１か月>

何が起きているか？

開発者

・考えられないからつくりはじめる

・いきなり要件定義

価値の無いものをつくってしまうアイデア

では、どのように思考すればよいのか？

価値

目的達成

・～があったらよさそう

・～に困っているので、～のようになったら助かる

・製品

・サービス

・システム

アイデア

実現したいこと

要求の把握が大事なのではないか？

価値

目的達成アイデア 要求 要件 設計 実装

・製品

・サービス

・システム

～がしたい

～ができる必要がある

要求を製品・サービス・システムに反映することで価値が得られる

アイデアをカタチにするには、要求の的確な把握が最も大事なのではないか！？

要件定義以降は「要求」を満たすために行われる

直感で考え、ロジックでサポートする。そして決断する！

直感（右脳）

ロジック（左脳）

決断・実行

→松下幸之助氏（松下電器産業、現パナソニック創業者）　の考え方

アイデア要望 要求 実行（つくる）

（直感） （ロジック）

要求とは何か？

アイデア要望 要求

ステークホルダー

価値の提供

「求」められていて重「要」なこと

～がしたい

～ができる必要がある

要求を導く方法

1. リーンスタートアップ

アイデア 構築

ユーザー

要求 提供

計測

フィードバック

ユーザー

学習

・インタビュー・ブログ反応

・プロトタイプ

使用

MVP(Minimum Viable Product)

MVPをなるべく早くユーザーに提供し、フィードバック・計測を繰り返しながら、より良い製品に近づいていく方法

リーンキャンバス

2. 要求開発（今日のメインテーマ）

「要求開発アライアンス」発足↓

匠BusinessPlaceの萩本順三氏が、Openthologyを進化させた「匠メソッド」を策定

↓

匠Net、萩本匠道場の活動などを通じて、普及活動中。

↓

Openthology策定↓

2006年書籍出版

要求を開発する

要求開発の７つのステップ（基本フロー）0. アイデアを得る 1. ステークホルダーを洗い出す 2. ステークホルダーが得る価値とプロジェクトの目的を描く 3. ビジネスモデルを考える、検証する 4. 製品のビジョン・コンセプトを描く 5. 要求を構造化する 6. プロジェクトの戦略を決める 7. プロジェクトのゴール、目標を決める 8. 行動する

２～４はプロジェクトの性質に応じて、やりやすい所から始める

ステップ0. アイデアを得る

・発想法（オズボーンのチェックリストなど）（転用・応用・変更・拡大・縮小・代用・再利用・逆転・統合）

・ひらめき、偶然、気づき

・SWOT分析（強み・弱み・機会・脅威）

・問題意識（日頃の困っていること、課題）

アイデア

・シーズ型開発の予期せぬ間違い

…など多数

ステップ1. ステークホルダーを洗い出す

鉄則： ステークホルダーを見落とすことは要求を見落すこと

ステップ2 ステークホルダーが得る価値を描き プロジェクトの目的を設定する

目的 目的 目的 目的目的の価値を問う 価値を得るための目的を設定する

価値

目的

ステークホルダー

ステップ3. ビジネスモデルを考える、検証する

○￥

ピクト図（3W1Hメソッド)

ビジネスモデル図（匠メソッド）

ビジネスモデルキャンバス

ステップ２で描いた価値・設定した目的が、 ビジネスモデルとして成り立つか検証する

要求開発以外の方法

ステップ4. 製品のビジョン・コンセプトを考えるビジョン

コンセプト

言葉（キャッチコピー）

意味（意義）ストーリー

デザイン

ステップ5. 要求を構造化する要求を目的（What）と手段（How）で考える

ビジョン財務

コンセプト 目的

業務要求 IT要求 解決策戦略要求

ビジョン財務

コンセプト 目的

ステップ6. プロジェクトの戦略を決める

優先度A

優先度B

戦略とは、何をどのような順番で戦っていくかの作戦のこと

良い戦略とは

良い戦略は、十分な根拠に立脚したしっかりした基本構造を持っており、一貫した行動に直結する

「良い戦略、悪い戦略」

ステップ7. プロジェクトのゴール、目標を決める

「何が」「いつまでに」「どうなる」目的を達成できたかどうかの尺度、目標値を定量的、定性的に定める

要求開発の価値

1.アイデア、価値、ビジョン、要求、戦略、行動のつながりをトレースできる

2. モデリングを主体としているので、直感的でわかりやすい。そのため合意形成がしやすく、発想がわきやすい 3. 右脳と左脳を両方使った手法である !4. 短時間でアイデアが検証できる

アイデア、価値、ビジョン、要求、戦略、行動のつながりをトレースできる

ビジョン 目的コンセプト

業務要求

IT 要求

解決策

価値そもそもの価値に立ち返ることができる

モデリングを主体としているので、直感的でわかりやすい。そのため合意形成がしやすく、発想がわきやすい

「一枚の絵は1024の単語に値する」

高い視点から俯瞰できる

「ソフトウェア要求」

右脳と左脳を両方使った手法である

目的

要求

要求

目的

要求

要求

業務 IT

要求

優先順位A

優先順位B

戦略プロジェクトの目的

目的 要求 要求 優先順位C

解決策

要求

コンセプト

コンセプト

コンセプト

ビジョン

財務目標

ビジョン財務目標

行動計画

業務担当者 顧客経営者 営業担当者

価値を実現するためにプロジェクトで果たすべきこと

価値

目的

プロジェクトによってもたらされる価値

目的

価値 価値 価値

ビジョン

コンセプト

コンセプト コンセプト

デザイン

ストーリー意味

言葉

④価値デザインモデル

↓

②価値分析モデル

←①ステークホルダーモデル

⑤要求分析ツリー

⑦プロジェクトゴール記述書Why What

③ビジネスモデル

⑥戦略の決定

直　感

ロジック

connpassでの要求開発による 優先度決定の事例

connpassのチーム体制

要求決定者

エンジニア デザイナー エンジニア デザイナー

エンジニア

デザイナー

要求 要求

→ 価値・要求について考えないようになりがち

エンジニア・デザイナーが、どのようなサービスが良いのか？（価値・要求）を考える

価値・要求=ビジネス寄りの企画者が考えるエンジニア、デザイナー = つくるひと

＜よくあるチーム＞ ＜connpassのチーム＞

要求決定者の決定には基本従う→ 要求仕様の決定については、もめにくい

要求の決定=合議制→ 各メンバーの思い入れがあるほど、もめる

議論の末、解決策（機能）候補は一覧化（チケット化）完了

解決策のリスト化

最終的に、19個の解決策 → 全部を開発していたらリリースできない！→優先順位をつけ、ミニマムでリリースしたい

※ チケット番号(#XXXXX)がないものは後の議論で新たに生まれた機能

チケット群

優先順位付けをどのようにするか？

解決したい課題実現したい価値

＜解決策＞

自分が絶対に必要だと考えている機能あったとして、他の機能より優先度が高いということを、どのように説明し、納得してもらうか？

対象ユーザー

タイミング効果

企業戦略

コスト市場ビジョン チケッ

ト群

要求の優先順位のつけかた（参考情報）

アラン・M・デービス著萩本順三、安井昌男 監修　高嶋優子 訳2006年11月 出版

第３章 要求のトリアージ「要求のトリアージは、製品の次のリリースに含めるのにふさわしい要求を選び出すための技術である」

「成功する要求仕様、失敗する要求仕様」

要求の優先順位のつけかた（参考情報）

第３章 要求のトリアージ　に紹介されていた手法

100ドルテスト 各自が100ドルずつ持っていると想像してもらい、その100ドルを要求候補にステークホルダーが分配し、優先度を決める

イエス・ノー投票 要求を一つひとつ挙げていき、要求に関心がある場合は、ステークホルダーに挙手してもらい、優先度を決める。

５段階プライオリティ方式 ステークホルダーに要求ごとに５段階で投票してもらう。要求を次回のリリースに含めることに賛成ならプラス１～２票。どちらでもよいなら０票。反対ならマイナス１～２票を投票する。

「成功する要求仕様、失敗する要求仕様」

→ 要求分析ツリーで優先度を決定

要求分析ツリー

XXXXXXXXX XXXXXXXXX

＜解決策＞＜戦略要求＞ ＜業務要求＞ ＜IT要求＞

＜課題＞

チケット群

ステップ1. 価値分析モデル

質問：グループ機能は、各ステークホルダーにとって、どのような価値があるのか？

「価値」を抽出↓「目的」を抽出。目的 ＝ 価値を実現するために成し遂げるべきこと

価値

目的

ステップ2. フルセットの要求分析ツリー作成①戦略要求に、価値分析モデルの「目的」を並べる②戦略要求 - 業務要求 - IT要求 のツリー構造を作成

目的価値を実現するために成し遂げたいこと

手段（ユーザーの要求)「～したい、～できる」

手段（システム機能）（目的）

ステップ3. 戦略要求の優先順位づけ質問：１stリリースで、必須の要求はどれか？

①戦略要求に色づけ ②必要な業務要求に色づけ

③IT要求に色づけ

要求分析ツリー全体（最終形）

今回の結果と成果

かかった時間：約１日・午前中：価値分析モデル（２時間） ・午後：要求分析ツリー（４時間）

成果・１９個のIT要求→ ７個のIT要求・メンバーの納得感→高かった 議論が迷走したり、行ったり来たりしなかった　議論に疲弊したり、もめたりしなかった

Howからの突き上げ

①議論中に生まれたアイデア（IT要求)

②「そのIT要求はどのよう業務要求につながるのか？」という質問→新たな業務要求を抽出 = 要求を開発

②

①

「要求の爆発」の恐怖からの解放赤色のIT要求=要求分析ツリーをつくってからアイデアとして出たIT要求

（通常）優先度を決める段階で、さらに新しいアイデアを出す→ 議論を収束させていきたい段階では敬遠されがち＝議論が終わらない（要求の爆発への恐怖）

（要求分析ツリーによる方法）「ツリーに葉を足すだけ」というのが目に見えるので、精神的負担が軽く、新しいアイデアに対しても、前向きに議論できる

アイデアをカタチにするための 創造的な組織（チーム）、コラボレーション

組織（チーム）

昔からの組織

意思決定者（企画担当者）

エンジニア デザイナー エンジニア

つくるもの考える

・１人の天才が引っ張る製品開発タイプ

・上意下達の組織（企画者が上で、エンジニア／デザイナが下？）

＜考える人＞

＜つくる人＞

いつまでたっても考える力がつかない

納得感がないままにつくる

これからの組織

リーダー

エンジニアデザイナーエンジニア

つくるもの

考える

メンバーが考えるよう導き、まとめ、力を引き出す

納得感

＜考えてつくる人＞

・個の力を合わせる製品開発

・フラットな組織

コラボレーション

チームでよりよいアイデアをうむための考え方

新しいアイデア

私のアイデア

あなたのアイデア

悪い例

二者択一的

チームでよりよいアイデアをうむための考え方

新しいアイデア

私たちのアイデア

シナジー

私のアイデア

あなたのアイデア

全体は部分の総和より大きい 第３の案～成功者の選択

よい例

アイデアをカタチにするチームコラボレーションの基盤

謙虚（Humility)

円滑な人間関係、健全な対話とコラボレーションの基盤

Team Geek ～Googleのギークたちはいかにしてチームを作るのか

尊敬（Respect)

信頼（Trust)

HRT(ハート）

謙虚（Humility）

Team Geek ～Googleのギークたちはいかにしてチームを作るのか

世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。

アイデアをカタチにするチームコラボレーションの基盤

尊敬（Respect）

Team Geek ～Googleのギークたちはいかにしてチームを作るのか

一緒に働く人のことを心から思いやろう。相手を１人の人間として扱い、その能力や功績を高く評価しよう。

アイデアをカタチにするチームコラボレーションの基盤

信頼（Trust）

Team Geek ～Googleのギークたちはいかにしてチームを作るのか

自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。

アイデアをカタチにするチームコラボレーションの基盤

アイデアとマネタイズ

アイデアとマネタイズ（だめな例）

世界を変えるビジネスは、たった１人の「熱」から生まれる

新しいアイデアアイデアマン 上司

市場規模は？ 事業計画は？マネタイズは？などと質問

「ビジネスにならない」と判断し 面白いアイデアも却下してしまう

（リバネス社）

アイデアとマネタイズ（良い例）

世界を変えるビジネスは、たった１人の「熱」から生まれる

新しいアイデア

ビジネスモデル

アイデアマン 上司

+それは新しいの？ それは面白いの？それはやり続けられるの？ などと質問し、情熱を確認

持続可能なビジネスモデルを一緒に考える

（リバネス社）

「社員は面白いアイデアを考え、経営者はそれをマネタイズする」

価値 要求

要求開発

エンジニアのキャリア

アイデアをカタチにするために不可欠なスキル・知識・マインド

・聞くスキル ・インタビューと質問のスキル ・分析のスキル ・ファシリテーションのスキル ・観察のスキル ・書くスキル ・体系化のスキル

・要求工学の理解 ・豊かなツールキットを持つ ・プロジェクト管理 ・リスク管理 ・品質工学 ・製品管理の知識 ・業務知識

＜スキル＞ ＜知識＞

＋ 実現させようというマインド（覚悟）

設計やプログラミングなどのIT技術に加え、アイデアをカタチにする思考にチャレンジしてみてはいかがでしょうか？

スキル 知識 マインド

要求開発

IT技術価値

まとめ

・アイデアをカタチにする要求開発 　　７つのステップ（ビジョン、コンセプト・価値・目的・要求・戦略・目標） ・アイデアをカタチにする組織・考え方 　　フラットなチーム、シナジー、　　コラボレーション（HRT）、アイデアとマネタイズ !・アイデアをカタチにするキャリア 　　IT技術＋要求開発（知識・スキル・マインド）

今日で、BPStudyも84回。 2007年9月から、毎月開催で ７年続けてくることができました

Special Thanks

1500人以上の方々に参加して頂きました !

130人のIT業界で活躍されている方々

にお話していただきました

Special Thanks

自分の 経験・ノウハウを 勉強会で積極的に 発表しましょう

是非やったほうがよいこと

なぜ発表するのか何か話せることはあるかと自分の中で探し始める ↓ 自分で経験したことを整理する（暗黙知→形式知） ↓ 勉強会で話す ↓ 自分の専門分野／得意分野が明確になってくる（自他ともに） ↓ 将来のキャリアにつながる

心が変われば、　行動が変わる 行動が変われば、習慣が変わる 習慣が変われば、人格が変わる 人格が変われば、運命が変わる 運命が変われば、人生が変わる

心が変われば人生が変わる！

なぜ発表するのか1. 発表してみようかなと思い立つ →　　心が変わる

2. 自分の経験・知識を整理し勉強会で話す →　行動が変わる

3. 何回かやってみる →　習慣が変わる

4. 自分の専門分野がわかる、自信がつく →　人格が変わる

5. 周りの人から認められる →　運命が変わる

6. キャリアが変わる →　人生が変わる

・仕事で得たノウハウ ・自分で取り組んでみて成功した事、失敗した事 ・あるある話／本当にあった怖い話 ・自分で追っかけているジャンルの最新情報

何を発表するのか

・実際のところどうなのよ？ ・使ってみてどうなのよ？ ・実践で使ってどうなのよ？ !

ということ

人の興味を引く内容

・Web系エンジニアがiPhoneアプリ開発を１年続けてみて学んだ事 ・後悔しないもんごもんごの使い方 ・１度は心が折れた俺が士気高く仕事するために身につけた技術と工夫 ・Chefで構築するBP-Redmine環境 ・受託開発脳から自社開発脳の切り替えの７つの壁への取り組み（実践編） ・私の履歴書 エンジニアの自分が会社をつくるまで ・エンジニアの自分が会社をつくって５年間で起こったこと、学んだこと !　　　　　　　　　　　　　　　　　　　　　　　　　　　　などなど

どんなテーマ？（例）

「IT業界のTED」 BPStudyが目指すもの

BPStudy = 技術者の自己表現の場

みたいなもの

BPStudyで話せば、人生が変わる！

発表お待ちしております。

これからもどうぞよろしくお願いします！

Special Thanks