匠メソッドをconnpassに導入した話と、SIで使った事例です。

1. 匠メソッドを導入したら
サイトのアクセスが10倍になった話
〜 connpassの事例・その他
株式会社ビープラウド
佐藤治夫
2017/3/7

2. 自己紹介
• 名前 佐藤治夫（Sato Haruo）
• 株式会社ビープラウド代表取締役社長
(http://www.beproud.jp/)
• 職歴
住商情報システム(現SCSK) (3年)
→小規模SIer(3年)
→個人事業主(3年)
→(株)ビープラウド設立（11年目）

3. （株）ビープラウドについて
• 2006年5月設立
• 社員37名（うちエンジニア34名）
• Pythonによる開発の受託開発・コンサルティング
• Python研修
• IT勉強会支援プラットフォームconnpass 運営

4. 私が匠メソッドに取り組む目的
• 良いシステム、製品、サービスを生み出して社会に価値
を生み出したい
• その結果、社員に良い報酬を出したい
• 技術、スキル、経験を活かし、やりがいのある仕事・プ
ロジェクトに取り組んでもらいたい

5. 匠メソッドへの取り組み
2013 2014 2015 2016 2017
匠道場
connpass
SI・開発
社内全導入

6. 2011年までに自社製品開発（４製品）→失敗（なんとかせねば
）
↓
2012年4月、匠ビジネスプレイス萩本さんと出会う（BPStudy）
↓
2013年1月〜匠道場に参加。
（2013年1月〜2017年2月まで50回中、49回参加）
↓
2014年1月、匠メソッド実践投入
（connpass企画・開発）
匠メソッドを始めたきっかけ

7. ・事例による匠メソッド説明
・自社製品・サービスの事例
・SI・受託開発の事例
アジェンダ

8. ・事例による匠メソッド説明
・自社製品・サービスの事例
・SI・受託開発の事例

9. 匠メソッドとは
アイデア
匠メソッド
価値行動
カタチにする
＜第１の創造＞(価値創造サイクル）
＜第２の創造＞
（開発など）

10. 【自社のシーズ】
＜あり＞＜なし＞
【社会のニーズ
】
＜応える＞
＜応えない＞
【魅力的】
・創りたいものがある
・社会に役立っている
【魅力少ない】
・創りたいものなし
・社会に役立っている
【魅力少ない】
・創りたいものあり
・社会に役立たない
【魅力なし】
・創りたいものなし
・社会に役立たない
＜目指すべき姿＞
＜負け犬＞
＜燃え尽き注意＞
＜火の車＞
ビジネスの４象限
創りたいもの=製品・サービス・組織など
シーズ：
自分たちはどうなりたいのか？
何をやりたいのか？
自分たちの強み・経験
ニーズ：
社会がもとめているもの

11. 事例その１ PyCon JP 2016 企画支援
PyCon JP
・Pythonユーザが集まり、PythonやPythonを使ったソフトウ
ェアについて情報交換、交流をするための国際的カンファレン
ス
・2016年の参加人数 720名
・海外からも多数の参加者

12. ステークホルダーモデル
・該当ドメインに関わるステークホルダーを洗い出す
・ステークホルダーが抱えている問題・課題を考える

13. ステークホルダーモデル（拡大版）

14. 価値デザインモデル
ビジョン
コンセプト
キャッチコピ
ー
価値の意味づけ
デザイン
ストーリー
シーズを描く

15. 価値デザインモデル（拡大）
公式サイト・ロゴに反映

16. 価値分析モデル ニーズを描く

17. 価値分析モデル（拡大）
ステークホルダー
価値
誰に対して何が嬉しいのかを考える

18. 価値分析モデルのポイント
ステークホルダー
価値
・〜が嬉しいと感情を書くことによって本当に嬉しいのか？
と考えることができる（〜できるという表現では価値が曖昧になる）
・手段とセットで考えることで、「絵に描いた餅」になりにくい
・価値が１ステークホルダーに集中しないようにする（価値のバランス)
・自分たちの価値も忘れずに考える

19. 価値分析モデル（拡大）：目的
価値を実現するプロジェクトの目的

20. 要求分析ツリー

21. 要求分析ツリー（拡大）
コンセプトビジョン 目的 業務要求
【シーズ】 【ニーズ】

22. コンセプトビジョン 目的 業務要求
【シーズ】 【ニーズ】
要求分析ツリーで
シーズとニーズの
つながりを確認する

23. ・事例による匠メソッド説明
・自社製品・サービスの事例
・SI・受託開発の事例

24. connpassとは
「エンジニアをつなぐ IT勉強会支援プラットフォーム」
→ IT勉強会に特化
・2011年11月サイトオープン（リリースして5年3か月）
URL:https://connpass.com/

25. connpassを使用しているコミュニティ(一部)

26. 匠メソッド導入以前

27. 実装する機能について意見を出しあう（ブレスト）
↓
どの機能を実装するかを議論する
↓
なかなか結論がでない（時間が過ぎていく）
↓
妥協して決定プロセスへ
↓
合意感、納得感が無いまま開発へ突入
↓
効果が出ない（=価値が生み出せていない）
匠メソッド以前の大変さ
＝消耗するような大変さ

28. 匠メソッドも１年学んだし
、実践投入しよう！
５〜６人月くらいの中規模開発で実践

29. 機能を一覧化（チケット化）
19個の解決策 → 全部を開発していたらリリースできない
！
→優先順位をつけ、ミニマムでリリースしたい

30. 優先順位付けをどのようにするか？
解決したい課題
実現したい価値
＜機能＞
対象ユーザー
タイミング
効果
企業戦略
コスト
市場
ビジョン

31. ここから
匠メソッドを導入

32. 価値分析モデル
①誰に、どのような価値があるのか？
ステークホルダー
価値
目的
②ステークホルダーの価値につながる
プロジェクトの目的を抽出

33. 要求分析ツリー（完成）

34. 導入した成果
かかった時間：約１日
・午前中：価値分析モデル（２時間）
・午後：要求分析ツリー（４時間）
成果
・１９個のIT要求→ ７個のIT要求
・メンバーの納得感→高かった
議論が迷走したり、行ったり来たりしなかった
今までは議論に疲弊することがあったが、そのようなことはなかった

35. connpassでの企画・戦略
必要充分でミニマムなリリース

36. connpassでの企画・戦略
１次リリース後に明らかになった課題を
１次リリース時の要求分析ツリーに追加
１次リリースの要求分析ツリーをもとに２次開発を検討

37. ビジョン・コンセプト・キャッチコピーを再定義
（２０１６年）
運営していくうちにサイトが変化→あらためて再定義
サイトのTopページに反映
価値デザインモデル

38. 匠メソッド導入後

39. 消耗する議論から建設的な議論に
枝葉のレベルだと議論が収集しない
Aさんの
アイデア
Bさんの
アイデア
取捨選択の議論がしやすい
（そもそもの価値に近い）
プロジェクトの目的A
プロジェクトの目的B
<個人の価値観>
<Projectの価値観>

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

41. 匠メソッド導入以前
・消耗するような大変さ
・時間の期限で妥協して決定
↓
匠メソッド導入後
・建設的な大変さ＝アイデアを捻り出した感覚（心地よい疲れ）
・納得感、合意感がチームにある
・地図があるので、安心して前に進める感覚
・途中で立ち戻ることができるプロジェクトの安定感
・迷いなく力を出し切れる→モチベーションアップ

42. 匠メソッドによるサイト企画後、アクセス（PV）が10倍に！
匠メソッドによるサービス企画
（２年１０か月）
横ばい期間（２年６か月）
10倍に！

43. 新製品・サービスの開発

44. 弊社 自社製品 PyQ
＜現在開発進行中＞2016年9月クローズドβ募集：100人集まる
Python学習支援プラットフォーム

45. 価値レビューの実施
製品が実現したい価値
開発を続けると
どうしても視点が下がってくる
製品のビジョン・コンセプト
IT
要求
現状と実現したいことの差分を見る
戦略
要求
業務
要求
実現したいこと
価値をひとつひとつ読み、
製品が価値実現できるか、確認する

46. ・事例による匠メソッド説明
・自社製品・サービスの事例
・SI・受託開発の事例

47. 受託開発事例その１ あるECサイトの事例（2016年2月）

48. 偉い人「サイトづくりをそろそろやりたい（漠然としたアイデアはある）」
↓
匠メソッドやってみませんか！
↓
２時間☓６回の要求開発セッション
↓
偉い人「ここまでやったんだからやらないと！」
↓
価値が見える化したからやりたいという気持ちになったのでは
＜現在開発進行中＞
受託開発事例その１ あるECサイトの事例（2016年2月）

49. 受託開発事例その２ ある医院のシステム事例

50. 受託開発事例その２ ある医院のシステム事例
医院長「５年間、議論して来たけど、カタチにならなくて」
↓
匠メソッドやりましょう！（2016年6月）
↓
2時間☓5回の匠メソッドのセッション
↓
医院長「ようやく前に進める！」
↓
2016年7〜8月要件定義・基本設計後
↓
2016年9月、実装開始
＜現在開発進行中＞

51. 受託開発事例その３ 広告事業のサイト（２０１７年２月）

52. 匠メソッドのセッション後に頂いたコメント
「ニーズを明らかにし、マッチングしていくのは新鮮で
すし、良いサイトができそうで嬉しいです。」
・２時間☓５回で実施
・機能一覧は先に頂いたが、機能の目的などが不明確。
匠メソッドの実施を提案。
受託開発事例その３ 広告事業のサイト（２０１７年２月）
＜現在開発進行中＞

53. 匠メソッドを受託開発で使うメリット

54. メリットその１：チームビルディング

55. 匠メソッドを使わない場合（従来の受託開発）
企画 開発
分断されている！
つくるべきものが見えない
・つくりたいもの
を全て表現するノウハウは無い
（文書、ミーティングで伝える）
・作るものが見えていなくて不安
つくるべきものが見えない
・言われたとおりに作るしか無い。
・開発側から提案しにくい
・顧客に役に立ちたい(=価値の実現
）気持ちはあるが役に立てない
アイデア
文書/ヒアリング

56. 企画 開発
価値の実現に向けて一体となったチームになる（こたつモデル）
つくるべきものが見える
・開発者が主体的に動いてくれる
→ 楽ちん！
・作りたいものが見えていて安心
つくるべきものが見える
価値の実現に向け、
→自ら行動できる
→開発側から提案しやすい
→モチベーションアップ
匠メソッドを使った場合
アイデア
つくりたいものを
一緒に描く

57. メリットその２：予算と見積もりのバランス

58. 匠メソッドを使わない場合（従来の受託開発）
アイデア
作りたいものが、
もやもやっとしている
＝つくりことによる価値がみえない
→なるべく安く開発したい
発注側 開発
作りたいものが見えない
優先度がぶれる可能性大なので
バッファを積んだ見積を出したい
見えない

59. 匠メソッドを使った場合
アイデア
作りたいものが、見えている
つくりことによる価値が見える
=費用対効果が見えている
「こんなに価値が生まれるなら
お金をかけてでもやりたい」
→予算アップ！
発注側 開発
作りたいものが見える
・大きな見積バッファが不要
・変更が入った場合でも、
要求分析ツリー上で変更内容を
示せるので「仕様変更」として扱える
つくりたいものを
一緒に描く

60. その他：キャリアデザイン

61. キャリアデザイン
誰をどのように幸せにしたいか
志（熱い気持ちで書く）
・どのようになりたいのか
・何を実現したいのか
具体的な行動
目指すべきものが分かっているので
行き当たりばったりで行動しなくて済む
「自分力」を高める

62. まとめ
製品・サービス開発
・消耗、妥協して価値が生まれない開発
↓
費用対効果が高く、合意・納得しモチベーション高い開発へ
SI・受託開発
・チームビルディング
価値をチームでデザイン（こたつモデル）
チームの一体化・モチベーションアップ・効率化
・予算アップと見積もりの最適化
その他の事例
キャリアデザイン：自分力を高めて効果的なキャリア戦略