2014年8月29日に開催されたBPStudy#84（ http://bpstudy.connpass.com/event/7857/ ） の発表資料です。

1. 2014/8/29
BPStudy#84
BPStudy７周年記念発表
アイデアをカタチにする方法
～ 要求・組織・人・キャリア
株式会社ビープラウド
佐藤治夫

2. 自己紹介
• 佐藤治夫（Sato Haruo）
• 株式会社ビープラウド 代表取締役社長
（2006年5月23日設立）９年目
• 大手SIer → 30人くらいのSIer → 個人事業主
• 技術記事執筆：DBマガジン、JavaPress,Codezine、@IT など
• Twitter: @haru860

3. ソフト開発
python研修
コンサルティング
BPStudy
BPRD
(BePROUD
Remote Day)
ビープラウドの取り組み

4. ビープラウドの取り組み
Pythonによる
開発ノウハウを凝縮
2012年3月出版
Pythonチケット
チーム開発
チケット駆動開発
mercurial
継続的インテグレーション
テスト
パフォーマンスチューニング

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

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

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

8. 経緯・背景
2011年8月
初の自社サービス liblarリリース
本を友達と共有、すばらしい本に出会うためのサービス

9. liblar
2011年8月liblarリリース
→ リリース直後招待制
→ １日で5000人が会員と登録
→ 日経新聞にもリリース記事が載って
→ はてなブックマークも500超
→ その後….
→長続きしなかった….

10. 「とりあえずつくる。動くものをリリースしてユーザーの反
応をみながら改善していけばいい！」
とはいうものの….
一次開発だけで
・エンジニア２名×４か月
・デザイナー１名×４か月
・企画担当者１名×４か月→ 16人(1000～1500万）

11. 経営者の叫び
小企業には軽くはない金額
資本金より大きい金額…胃が痛い….
!
「とりあえず」で始めてしまっていいの！？

12. 走りながら考える
価値の発揮
目的の達成
間違った方向に
ロケットスタート
プロジェクト
スタート
途中で力尽きる…
走りながら…でも成功する例
・センスがよかった
・運がよかった

13. 経営者の叫び その２
小企業には軽くはない金額
資本金より大きい金額…胃が痛い….
!
センスとか運にかけてもいいの！？
「まずはやってみろよ」とかでいいの！？

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

15. 似たようなことがシステム開発の現場でも
売上の推移を
画面でグラフで
みたい
<開発期間１か月>
顧客現場担当者開発者
言われた
ままつくる実はCSVでダウン
ロードして、Excel
でグラフを表示す
れば充分だった！

16. 何が起きているか？
・考えられないからつくりはじめる
・いきなり要件定義
開発者
価値の無いものを
アイデアつくってしまう

17. では、どのように思考すればよいのか？
価値
目的達成
・～があったらよさそう
・～に困っているので、～
のようになったら助かる
・製品
・サービス
・システム
アイデア
実現したいこと

18. 要求の把握が大事なのではないか？
価値
目的達成
要求を製品・サービス・システムに反映するこ
とで価値が得られる
アイデア要求要件 設計実装
・製品
・サービス
・システム
～がしたい
～ができる必要がある
要件定義以降は「要求」を満たすために行われる
アイデアをカタチにするには、
要求の的確な把握が最も大事なのではないか！？

19. 直感で考え、ロジックでサポートする。そして決断する！
→松下幸之助氏（松下電器産業、現パナソニック創業者）
の考え方
直感
（右脳）
ロジック
（左脳） 決断・実行
アイデア
要望要求実行（つくる）
（直感） （ロジック）

20. 要求とは何か？
ステークホルダー
価値の提供
～がしたい
～ができる必要がある
アイデア
要望要求
「求」められていて重「要」なこと

21. 要求を導く方法

22. 1. リーンスタートアップ
MVPをなるべく早くユーザーに提供し、
フィードバック・計測を繰り返しながら、
より良い製品に近づいていく方法
アイデア構築
MVP
(Minimum Viable Product)
ユーザー
要求提供
フィード
バック
計測
ユーザー
学習
・インタビュー
・ブログ反応
・プロトタイプ
使用
リーン
キャンバス

23. 2. 要求開発（今日のメインテーマ）
「要求開発アライアンス」発足
↓
Openthology策定
↓
↓
2006年書籍出版
匠BusinessPlaceの萩本順三氏が、Openthologyを進化させた「匠
メソッド」を策定
↓
匠Net、萩本匠道場の活動などを通じて、普及活動中。

24. 要求を開発する

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

26. ステップ0. アイデアを得る
・ひらめき、偶然、気づき
・発想法（オズボーンのチェックリストなど）
（転用・応用・変更・拡大・縮小・代用・再利
用・逆転・統合）
・SWOT分析
（強み・弱み・機会・脅威）
・問題意識（日頃の困っていること、課題）
アイデア
・シーズ型開発の予期せぬ間違い
…など多数

27. ステップ1. ステークホルダーを洗い出す
鉄則：
ステークホルダーを見落とすことは要求を見落すこと

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

29. ステップ3. ビジネスモデルを考える、検証する
ステップ２で描いた価値・設定した目的が、
ビジネスモデルとして成り立つか検証する
ビジネスモデル図（匠メソッド）
○
￥
要求開発以外の方法
ピクト図（3W1Hメソッド)
ビジネスモデルキャンバス

30. ステップ4. 製品のビジョン・コンセプトを考える
ビジョン
コンセプト
言葉（キャッチコピー）
意味（意義）
デザイン
ストーリー

31. ステップ5. 要求を構造化する
要求を目的（What）と手段（How）で考える
ビジョン
財務
戦略要求業務要求IT要求解決策
コンセプト目的

32. ステップ6. プロジェクトの戦略を決める
ビジョン
財務
コンセプト目的
優先度A
優先度B
戦略とは、何をどのような順番で戦っていくかの作戦のこと

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

34. ステップ7. プロジェクトのゴール、目標を決める
「何が」「いつまでに」「どうなる」
目的を達成できたかどうかの
尺度、目標値を定量的、定性的に定める

35. 要求開発の価値
1.アイデア、価値、ビジョン、要求、戦略、行動のつながり
をトレースできる
2. モデリングを主体としているので、直感的でわかりやす
い。そのため合意形成がしやすく、発想がわきやすい
3. 右脳と左脳を両方使った手法である
!
4. 短時間でアイデアが検証できる

36. アイデア、価値、ビジョン、要求、戦略、行動のつながり
をトレースできる
ビジョンコンセプト目的
業務
要求
IT
要求
解決策
価値
そもそもの価値に
立ち返ることができる

37. モデリングを主体としているので、直感的でわかりやすい。
そのため合意形成がしやすく、発想がわきやすい
高い視点から俯瞰できる
「一枚の絵は1024の単語に値する」
「ソフトウェア要求」

38. 右脳と左脳を両方使った手法である
③ビジネスモデル
解決策
直 感
価値価値価値
プロジェクト 戦略
の目的
ロ目的
ジック
業務IT
要求
要求
目的
要求
要求
要求
優先順位A
⑥戦略の決定
優先順位B
要求
目的要求要求優先順位C
④価値デザインモデル
コンセプト
コンセプト
コンセプト
ビジョン
財務目標
ビジョン
財務目標
行動計画
経営者営業担当者業務担当者顧客
価値を実現するために
プロジェクトで果たすべきこと
価値
目的
プロジェクトによって
もたらされる価値
目的
ビジョン
コンセプト
コンセプトコンセプト
デザイン
意味ストーリー
言葉
↓
②価値分析モデル
←①ステークホルダーモデル
⑤要求分析ツリー
Why What ⑦プロジェクトゴール記述書

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

40. connpassのチーム体制
＜よくあるチーム＞ ＜connpassのチーム＞
要求要求
要求決定者
エンジニア
エンジニアデザイナーエンジニアデザイナー
デザイナー
→ 価値・要求について考えないようになりがち
エンジニア・デザイナーが、どのようなサービスが良
いのか？（価値・要求）を考える
価値・要求=ビジネス寄りの企画者が考える
エンジニア、デザイナー = つくるひと
要求決定者の決定には基本従う
→ 要求仕様の決定については、もめにくい
要求の決定=合議制
→ 各メンバーの思い入れがあるほど、もめる

41. 解決策のリスト化
議論の末、解決策（機能）候補は一覧化（チケット化）完了
※ チケット番号(#XXXXX)がないものは後の議論で新たに生まれた機能
チケット群
最終的に、19個の解決策 → 全部を開発していたらリリースできない！
→優先順位をつけ、ミニマムでリリースしたい

42. 優先順位付けをどのようにするか？
解決したい課題
実現したい価値
＜解決策＞
企業戦略
市場コスト
対象ユーザー
ビジョンチケッ
タイミング
効果
自分が絶対に必要だと考えてい
る機能あったとして、他の機能
より優先度が高いということを、
どのように説明し、納得しても
らうか？
ト群

43. 要求の優先順位のつけかた（参考情報）
第３章 要求のトリアージ
「要求のトリアージは、製品の次のリリースに含めるのに
ふさわしい要求を選び出すための技術である」
「成功する要求仕様、失敗する要求仕様」
アラン・M・デービス著
萩本順三、安井昌男 監修 高嶋優子 訳
2006年11月 出版

44. 要求の優先順位のつけかた（参考情報）
「成功する要求仕様、失敗する要求仕様」
第３章 要求のトリアージ に紹介されていた手法
100ドルテスト
各自が100ドルずつ持っていると想像してもらい、その100ドルを要求候補にス
テークホルダーが分配し、優先度を決める
イエス・ノー投票
要求を一つひとつ挙げていき、要求に関心がある場合は、ステークホルダーに挙手しても
らい、優先度を決める。
５段階プライオリティ方式
ステークホルダーに要求ごとに５段階で投票してもらう。要求を次回のリリースに含めることに賛成
ならプラス１～２票。どちらでもよいなら０票。反対ならマイナス１～２票を投票する。

45. 要求分析ツリー
→ 要求分析ツリーで優先度を決定
XXXXXXXXX
XXXXXXXXX
＜戦略要求＞ ＜業務要求＞ ＜IT要求＞
＜解決策＞
＜課題＞
チケッ
ト群

46. ステップ1. 価値分析モデル
価値
目的
質問：グループ機能は、各ステークホルダーにとって、どのような価値があるのか？
「価値」を抽出
↓
「目的」を抽出。目的 ＝ 価値を実現するために成し遂げるべきこと

47. ステップ2. フルセットの要求分析ツリー作成
①戦略要求に、価値分析モデルの「目的」を並べる
②戦略要求 - 業務要求 - IT要求 のツリー構造を作成
目的
価値を実現するために
成し遂げたいこと
手段（ユーザーの要求)
「～したい、～できる」
（目的） 手段（システム機能）

48. ステップ3. 戦略要求の優先順位づけ
質問：１stリリースで、必須の要求はどれか？
①戦略要求に色づけ②必要な
業務要求に色づけ
③IT要求に色づけ

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

50. 今回の結果と成果
かかった時間：約１日
・午前中：価値分析モデル（２時間）
・午後：要求分析ツリー（４時間）
成果
・１９個のIT要求→ ７個のIT要求
・メンバーの納得感→高かった
議論が迷走したり、行ったり来たりしなかった
議論に疲弊したり、もめたりしなかった

51. Howからの突き上げ
①議論中に生まれた
アイデア（IT要求)
②
②「そのIT要求はどのよう業務要求につながるのか？」という質問
→新たな業務要求を抽出 = 要求を開発
①

52. 「要求の爆発」の恐怖からの解放
赤色のIT要求
=要求分析ツリーをつくってから
アイデアとして出たIT要求
（通常）
優先度を決める段階で、さらに新しいアイデアを出す
→ 議論を収束させていきたい段階では敬遠されがち
＝議論が終わらない（要求の爆発への恐怖）
（要求分析ツリーによる方法）
「ツリーに葉を足すだけ」というのが目
に見えるので、精神的負担が軽く、新し
いアイデアに対しても、前向きに議論で
きる

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

54. 組織（チーム）

55. 昔からの組織
考える
意思決定者
（企画担当者）
つくるもの
エンジニアデザイナーエンジニア
納得感が
ないまま
につくる
・１人の天才が引っ張る製品開発タイプ
・上意下達の組織
（企画者が上で、エンジニア／デザイナが下？）
＜考える人＞
＜つくる人＞
いつまでたっても考
える力がつかない

56. これからの組織
つくるもの
納得感
エンジニアデザイナーエンジニア
リーダー
考える
＜考えてつくる人＞
メンバーが考えるよう
導き、まとめ、力を引き出す
・個の力を合わせる製品開発
・フラットな組織

57. コラボレーション

58. チームでよりよいアイデアをうむための考え方
新しいアイデア
私の
アイデア
あなたの
アイデア
悪い例
二者択一的

59. チームでよりよいアイデアをうむための考え方
シナジー
新しいアイデア
私たちの
アイデア
私の
アイデア
あなたの
アイデア
全体は部分の総和より大きい第３の案
～成功者の選択
よい例

60. アイデアをカタチにするチームコラボレーションの基盤
謙虚
（Humility)
円滑な人間関係、健全な対話とコラボレーションの基盤
Team Geek
～Googleのギークたちは
いかにしてチームを作るのか
尊敬
（Respect)
信頼
（Trust)
HRT(ハート）

61. 謙虚（Humility）
世界の中心は君ではない。君は全知全能ではな
いし、絶対に正しいわけでもない。常に自分を
改善していこう。
Team Geek
～Googleのギークたちは
いかにしてチームを作るのか
アイデアをカタチにするチームコラボレーションの基盤

62. 尊敬（Respect）
一緒に働く人のことを心から思いやろう。相手
を１人の人間として扱い、その能力や功績を高
く評価しよう。
Team Geek
～Googleのギークたちは
いかにしてチームを作るのか
アイデアをカタチにするチームコラボレーションの基盤

63. 信頼（Trust）
自分以外の人は有能であり、正しいことをする
と信じよう。そうすれば、仕事を任せることが
できる。
Team Geek
～Googleのギークたちは
いかにしてチームを作るのか
アイデアをカタチにするチームコラボレーションの基盤

64. アイデアとマネタイズ

65. アイデアとマネタイズ（だめな例）
世界を変えるビジネスは、たっ
た１人の「熱」から生まれる
新しいアイデア
アイデアマン上司
市場規模は？
事業計画は？
マネタイズは？などと質問
「ビジネスにならない」と判断し
面白いアイデアも却下してしまう
（リバネス社）

66. アイデアとマネタイズ（良い例）
アイデアマン上司
+ それは新しいの？
世界を変えるビジネスは、たっ
た１人の「熱」から生まれる
新しいアイデア
ビジネスモデル
それは面白いの？
それはやり続けられるの？
などと質問し、情熱を確認
持続可能なビジネスモデル
を一緒に考える
「社員は面白いアイデアを考え、経営者はそれをマネタイズする」
（リバネス社）
価値要求
要求開発

67. エンジニアの
キャリア

68. アイデアをカタチにするために不可欠なスキル・知識・マインド
＜スキル＞ ＜知識＞
・聞くスキル
・インタビューと質問のスキル
・分析のスキル
・ファシリテーションのスキル
・観察のスキル
・書くスキル
・体系化のスキル
・要求工学の理解
・豊かなツールキットを持つ
・プロジェクト管理
・リスク管理
・品質工学
・製品管理の知識
・業務知識
＋ 実現させようというマインド（覚悟）

69. 設計やプログラミングなどのIT技術に加え、
アイデアをカタチにする思考にチャレンジしてみては
いかがでしょうか？
IT技術
スキル知識マインド
要求開発
価値

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

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

72. Special Thanks
1500人以上の方々に参加して頂きま
した
!
130人のIT業界で活躍されている方々
にお話していただきました

73. 是非やったほうがよいこと
自分の
経験・ノウハウを
勉強会で積極的に
発表しましょう

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

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

76. なぜ発表するのか
1. 発表してみようかなと思い立つ
→ 心が変わる
2. 自分の経験・知識を整理し勉強会で話す
→ 行動が変わる
3. 何回かやってみる
→ 習慣が変わる
4. 自分の専門分野がわかる、自信がつく
→ 人格が変わる
5. 周りの人から認められる
→ 運命が変わる
6. キャリアが変わる
→ 人生が変わる

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

78. 人の興味を引く内容
・実際のところどうなのよ？
・使ってみてどうなのよ？
・実践で使ってどうなのよ？
!ということ

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

80. BPStudyが目指すもの
「IT業界のTED」
みたいなもの
BPStudy = 技術者の自己表現の場

81. BPStudyで話せば、人生が変わる！
発表お待ちしております。

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