ビープラウド社長のブログ

株式会社ビープラウドの社長が、日々の思いなどを綴っていきます。

「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書

日本のDDD(ドメイン駆動設計)界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

本書をおすすめしたい人

本書は、システム開発で以下のような問題を抱えている人におすすめです。

  • 既存システムのソースコードの可読性が低く、理解に時間がかかる
  • 機能追加・改修時の影響範囲調査に時間がかかる
  • 機能追加・改修時の工数が予想以上にかかる
  • テストコードが書きにくいソースコードになりがち
  • 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる
  • デグレの確認に気を使い、多くの時間をかけている
  • 不具合が発生したときに、調査・解決に時間がかかってしまう
  • 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる
  • これらの問題のために、生み出す価値以上に、仕事時間が増えている

このような問題を解消し、変更に強いソフトウェア開発をするために、著者の増田氏が説明しているのが、ドメインモデル駆動設計によるオブジェクト指向プログラミング(以下、オブジェクト指向プログラミング)です。

オブジェクト指向プログラミングのメリット

従来からの手続き型プログラミングとオブジェクト指向プログラミングは、何が違うのかという方もいらっしゃると思います。

その違いが分かるように書籍の全体像を、私なりにまとめてみました。

以下の図は、書籍第3章に掲載されている図です(P.90 図3-4)。

シンプルな図ですが、この図を理解することが、オブジェクト指向プログラミングの全体像を理解することになるでしょう。

f:id:haru860:20170715140757p:plain

さらに説明を加えたのが以下の図です。

f:id:haru860:20170715141240p:plain

オブジェクト指向プログラミングは、現実世界を抽象化し、ソースコードで表現します。

本書では「関心事」という重要なキーワードが数多く登場しますが、「関心事」とは、ソースコードで記述しようとする対象のことです。

ドメインモデルの関心事は、現実世界の業務です。

ドメインオブジェクトには、カプセル化(情報隠蔽)*1の考え方をもとに、現実世界の業務データ、業務ロジックを記述します。そして、オブジェクト同士の相互作用として、ドメインオブジェクト同士のメソッド呼び出しを記述します。

そのとき、技術環境、たとえばWebアプリ、スマートフォンアプリなどのアプリの種類や、実装技術(アプリケーションフレームワーク、データベース、HTML5など)は、ドメインモデルの関心事ではありません。

一方、3層(プレゼンテーション層、アプリケーション層、データソース層)の関心事は、実装技術の操作です。

ドメインモデルとは逆に、3層には実装技術に関係するコードを記述し、現実世界の業務に関するロジックは書かないようにします。

このように、オブジェクト指向プログラミングでは、オブジェクト指向プログラミングの世界(ドメインモデル)と実装技術の世界で、関心事が明確に分かれているため、ソースコードが理解しやすくなり、全体の見通しが良くなります。

その結果、改修も楽になり、ソースコードの変更コスト、テストコスト、デグレのリスク低減など、さまざまな効果がうまれ、さらにその効果は長期にわたり続きます。

手続き型プログラミング

一方、手続き型プログラミング*2はどうでしょうか。

以下の図は手続き型プログラミングの全体像を表しています(図3-4をもとに私が作成)。

f:id:haru860:20170717130313p:plain

手続き型プログラミングでも、オブジェクト指向プログラミングと同様、現実世界の業務が関心事です。

しかし同時に、実装技術の操作も関心事なので、うまく共通化などを図っていたとしても、時間とともに、現実世界と実装技術という2つの関心事がソースコード内に混在してしまうことは避けられないでしょう(特に複数人での開発時)。

その結果、ソースコードも可読性がさがり、見通しが悪くなってしまいがちです。

以下の図を、オブジェクト指向プログラミングの図と比べると、手続き型プログラミングでは、開発が進むにつれ、ソースコードが次第に複雑になっていくイメージがつくのではないでしょうか。

f:id:haru860:20170717133126p:plain

【オブジェクト指向プログラミングの図を再掲】 f:id:haru860:20170715141240p:plain

テストコードの書きやすさ

ドメインモデルと3層で関心事が分かれていて、ドメインモデルは実装技術(Webやデータベースなど)から切り離されているので、システムで最も重要な、業務ロジックのテストコードが書きやすくなります

「テストコードが書きやすいプログラム設計」を模索している人は、本書で説明されているオブジェクト指向プログラミングを学ぶとよいでしょう。

本書の構成

では、オブジェクト指向プログラミングで、3層+ドメインモデルをどのように設計し、プログラミングしていけば良いのでしょうか。

本書では「ドメインオブジェクト」「ドメインモデル」「データソース層とドメインオブジェクト」「アプリケーション層の組み立て方」「プレゼンテーション層とドメインオブジェクト」など、実装パートごとに分割し、それぞれの考え方やテクニックを具体的な事例を示しながら説明しています。

必要に応じて、実装パートごとに読んでいくのもよいでしょう。

本書の構成について、以下にまとめたので、読み進める際の参考になればと思います。

  • ドメインオブジェクト

    • 1章:小さくまとめてわかりやすくする
    • 2章:場合分けのロジックを整理する
    • 3章:業務ロジックを分かりやすく整理する
  • ドメインモデルの設計

    • 4章:ドメインモデルの考え方で設計する
  • アプリケーション層

    • 5章:アプリケーション機能を組み立てる
  • データソース層

    • 6章:データベースの設計とドメインオブジェクト
  • プレゼンテーション層

    • 7章:画面とドメインオブジェクトの設計を連動させる
  • その他

    • 8章:アプリケーション間の連携
    • 9章:オブジェクト指向の開発プロセス
    • 10章:オブジェクト指向設計の学び方と教え方

f:id:haru860:20170715141854p:plain

本書の特徴

本書を読んで感じた特徴をあげていきたいと思います。

すぐに始められることから説明されている

オブジェクト指向プログラミングというと、システムの全体設計から始めないといけないのかと、身構えてしまう人もいるかもしれません。

本書では、クラスやメソッド、変数の名前の付け方、メソッドの抽出の仕方など、すぐに始められるところから説明が始まっています。

オブジェクト指向プログラミングを経験しながらすぐに学び始めることができ、段階的に身につけることができるでしょう。

実践的で具体的なエッセンスが網羅されている

オブジェクト指向を説明している書籍は、抽象的な説明が多い傾向があります。

本書では、具体的にソースコードを提示し、なぜそうするのか、どのような効果があるのかも合わせて説明されていますので、実践でのイメージが湧きやすくなっています。

また、ドメインモデル、ドメインオブジェクトの設計だけではなく、プレゼンテーション層(画面)とドメインオブジェクト、データベース設計とドメインオブジェクト、APIの設計など、現場ですぐに使えるテクニックが網羅されています。

豊富な実践経験、日頃の研究・試行、思索が凝縮されている

著者の増田さんは、大規模システム開発などで長年にわたりオブジェクト指向プログラミングを実践し、そこでの経験に基づき本書を執筆されています。

本書には「エリック・エヴァンスのドメイン駆動設計」「実装パターン」「リファクタリング」など16冊の参考書籍が掲載されています。

増田さんはこれらの書籍と自分の理論を突き合わせ、実践で試行し、さらに実践から自分の理論を構築する、という過程を経て生み出されたのが本書ではないでしょうか。

また、増田さんのTwitterのアカウント@masuda220からは、日頃からDDD、オブジェクト指向プログラミングについての思索が流れてきます。

そのように日々、オブジェクト指向プログラミングのことを深く考えている増田さんの説明には納得感を感じられます。

オブジェクト指向プログラミングを学ぶ時のインデックスとして活用できる

各章の終わりには、参考書籍の該当章が示されています(たとえば3章の末尾には『エンタープライズアプリケーションアーキテクチャーパターン』「第1章 レイヤ化」「第9章 ドメインロジックパターン」『ドメイン駆動設計』「第4章 ドメインを隔離する」、『改訂新版Spring入門』「第1章 SpringとWebアプリケーションの概要」が提示されています)。

深く学びたい方は、参考書籍の該当章を読むことで、さらに理解を深めることができます。参考書籍は、それぞれボリュームがありますので該当章が提示されているのはとても助かりますし、オブジェクト指向プログラミングを学ぶときのインデックスとして使えるでしょう。

オブジェクト指向プログラミングを始めることで得られるもの

オブジェクト指向プログラミングを身につけると、さまざまなものが得られます。

時間

冒頭であげたシステム開発における問題点、たとえばソースコードの可動性が低い、全体を把握するのに時間がかかる、影響範囲の調査に時間がかかる、などによってシステム開発の作業時間は少しずつ伸びていきます。

これらが当たり前になっているのは、手続き型プログラミングのシステム開発時代の時間感覚です。

オブジェクト指向プログラミングを実践すると、影響範囲の調査、プログラミング、知識の伝達、テスト、不具合調査など、さまざまな時間が短縮されていきます。システム開発チームは正のスパイラルで成果を出し続けることでしょう。

「現場で役立つシステム設計の原則」を読み、オブジェクト指向プログラミングを学び、実践すれば、システム開発にかかるさまざまな時間を短縮できます。

オブジェクト指向プログラミングにより、システム開発現場の働き方改革にもつながるのではないでしょうか。

ものごとの本質をつかみ、表現する力

オブジェクト指向は、複雑な現実世界の関心事を、UMLなどのモデルやソースコードとして抽象化します。それを繰り返すことにより、以下のような力がついてきます。

  • 目の前の事象の重要なことは何か、本質は何かを把握する力
  • 自分が理解したことをわかりやすく表現する力

このようなスキルが身につくことによって、急所を押さえた仕事ができるようになり、他の人にも的確に情報が伝達できるので、結果的に仕事が格段に速くなるでしょう。

ソフトウェア開発者としての自信

オブジェクト指向プログラミングを実践すると、日頃の設計の積み重ねにより、機能追加、機能改修のスピードが速くなります。

短い時間で機能追加、改修ができる自分や、それを可能にするシステム設計ができている自分に自信をもてるようになります。

機能追加、機能改修が速く完了すると周りからも喜ばれ、評価も高まりますので、さらなる自信にもつながるでしょう。

まとめ

実装技術は数年で変わっていくものですが、本書で説明しようとしているオブジェクト指向プログラミングは普遍的なものといえるでしょう。

真の実力を身につけ、長期的に価値を生み出し続けたいプログラマーにおすすめの一冊です。

*1:オブジェクトの振る舞いを隠蔽したり、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの実際の型を隠蔽したりすること

*2:手続き型プログラミング(てつづきがたプログラミング、英: Procedural programming)は、「手続き呼び出し」の概念に基づくプログラミングパラダイムの一種。命令型プログラミングと同義に扱われることが多い。「手続き」はプロシージャ、ルーチン、サブルーチン、メソッド、関数(数学の関数とは異なる。)など様々な呼称があるが、実行すべき一連の計算ステップを持つものと定義できる。WikiPedia:手続き型プログラミング

匠の夏祭り2017まとめ〜匠Methodはキャズムを超える

7月5日に「匠の夏祭り」に参加してきました。

it-takumi.connpass.com

17時スタートで、21時まで。

匠Methodオンリーで内容充実、学びが多いイベントでした。

各セッションごとに、まとめを書きました。(まとめると記憶に強く定着します)

第1部〜第5部の構成もストーリーになっているそうです。そのストーリーを感じながら読んでみてください。

全体の感想

匠のイベントには毎回参加していますが、年々、成功事例のレベルが高くなって来ています。

特に今年は、IoT+農業+飲食業のイノベーション、大手企業の新規ビジネス開発の成功事例など、印象に残る事例でした。

リアルイベントの醍醐味は、人の話を直接聞いて、その人の熱量を感じられることです。

足を運んで、話を聞いて、熱を感じて、同志と話をしてと、リアルイベントの醍醐味を味わうことができました。

そして実際に成果を出している人の話を聞くと、自分もやれるという気になってきます。

アーリーアダプターの成功事例が増え、また昨年末には匠Methodの書籍が出版され、書籍を読み、匠Methodの考え方に共感する人が増えています。

匠メソッドに触れた人の多くが「やってみたい」「取り組みたい」と思い、取り組み始める。つまりキャズムを超えるのも間近な気配を感じたイベントでした。

匠Methodの書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠の夏祭り2017〜第5部 パネルディスカッション

未来の匠Methodの使い手によるパネルディスカッション

登壇者

  • パネラー

    • ビープラウド 西川 公一朗氏
    • インフォテック 中村 洋介 氏
    • エヌ・ティ・ティ・コムウェア 友澤 比香 氏
  • モデレータ

    • 匠BusinessPlace 山形 友佳子 氏
    • 株式会社匠BusinessPlace 清水 康平 氏

匠Methodの本のポイント

  • 匠Thinkの説明が役に立った
  • ロールプレイを読んで匠塾などで実践すると理解が深まる
  • 価値とは、戦略など人によって理解があいまいになりがちな用語の定義がされているので、内容が理解できた
  • 勉強会などで匠Methodの説明を聞くだけだと理解が追いつかないが、自分の時間で、ゆっくり読めて良かった

仕事以外での活用

  • 価値分析を一人でつくり、家庭の洗脳活動で使っている(嬉しいをオブラートに包んで伝える)
  • 家庭:子供の将来、今後の将来を、夫婦2人で匠Methodを使って合意形成

    • 匠Method以前:慣れ、プライド感情的になる、お互いに疲弊する
    • マンション購入の箇所を読んでもらってから、夫婦で価値分析モデルをつくった
    • 感情的になると「匠Method的にアウトなんじゃないの?」と煽られるようになった

匠Methodの難しい所

  • 価値デザインモデル:ポエマー不足、魅力的な言葉に成長しない

    • 6月の匠塾でビジョン・コンセプトの出し方を検討した。いきなり言葉を出そうとするのではなく、具体的なやりたいことをグルーピングなどしながら、徐々に抽象化して、言葉をラベル付するという方法
  • 要求分析ツリー:妄想は得意。妄想を論理的に集約していくところが苦手。

匠Methodの良いところ

  • 「嬉しい」をデザインするので、みんなが前向きにディスカッションできる
  • 価値創造セッションのあとに、チームという感覚ができる。一緒につくっていくことができるので、お客様の満足度が高い。トラブルが起きにくくなる。価値創造セッションをやっていないとトラブルが起きやすい
  • みんなで嬉しいことを考えるのは嬉しい。そのあと、ロジカルなところに結びついていくところが気に入っている

感想

匠Methodは気軽に使い始められるように進化してきているということを感じました。

私が匠Methodを本格的に学び始めてから2〜3年(2013年〜2015年くらい)は萩本さんの話を何度も聞いてメモを取り、匠道場の同志と、ああでもないこうでもないと議論し、匠道場や実際の仕事で実践していくなかで、匠Methodを時間をかけて身につけていきました。

そのような苦労を数年したために(笑)、匠Methodを理解するのは、時間がかかる、社内に普及させるのも時間がかかるだろうとおもっていました。

しかし、萩本さんが多くの人に匠Methodを普及させるために、わかりやすくシンプルに進化させてきた結果、匠Methodを始めて日が浅い人でも取り組みやすいようになってきたと思われます。

また、書籍が昨年末に出版されたので、書籍を読めば概念を知ることができるというのも、自分のペースで学べますし、大きいことだと思います。

また、パネラーの人たちをみていて、匠Methodを使う上で大事な姿勢は、まずは取り組んでみようという素直で柔軟な姿勢だと感じました。

最後に萩本さんから

  • 匠Methodは自分を問うメソッド
  • 自分の価値観をデザイン
  • 問うべきは、自分は何者かということ
  • 匠Methodを使って、見失っているものを見つけ出してください
  • 匠Methodはシンプルで本格派。簡単だけど、難しい、難しいけど簡単。是非つかってみてください。

全体へ

匠Methodの書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠の夏祭り2017 まとめ 第4部 匠Method社内活用事例

第4部は、匠Methodの社内活用事例です。

it-takumi.connpass.com

前半は匠ビジネスプレイス篠原さん、後半は匠ビジネスプレイス清水さんでした。

実践 匠Method はじめの一歩~匠BP社員による普段使い事例~

ビジネスを実践するチームの活動をデザインする

登壇者

株式会社匠BusinessPlace 篠原 幸太 氏

内容

  • 不定期に行う活動でモデルを使い分けるコツ
  • チーム(ビジネススタートアップイノベーション事業部)の活動をデザインした事例

進めかた

  • 合宿の進め方をデザインする
  • 話したいこと・全体像/関係性を描く

    • シーズ(どうなりたい)→ニーズ(どうなって欲しい)を描く
    • ニーズの例:リモートワークの在り方、案件の取り回し
  • 個人のキャリアデザインを描く(シーズ)

    • 数年後(3年後)のなりたい自分を描く
    • なりたい自分のストーリーを描く
  • 部門のデザイン(ニーズを描く)

    • ステークホルダーは、価値を感じて欲しいステークホルダー+部員全員(By Name)
    • ByNameの価値(嬉しいこと)は、本人以外が描く

半年前につくったモデルを見直す

  • 過去、現在、未来がテーマ

    • 個人の悩み、阻害要因、解決策(過去)
    • チームの課題、今、何が必要か(現在)
    • 各人が成し遂げたいこと(未来)

まとめ

  • 活動とディスカッションが重要:モデルは手助けしてくれる道具である
  • ディスカッションしたいことに着目。必要に応じてモデルを取捨選択する
  • モデルにこだわらない:活動することで価値が生まれる

    • 活動がよくなるために、モデルを使う
    • モデルを書いて満足しない!
    • モデルを書いて励まし合う(顧客のイノベーションを支援するという事業の性質上、新意識に達したいが達せないジレンマがつきものでストレスがたまるため)

感想

部門の価値分析モデルで、価値を感じて欲しいステークホルダー+部のメンバーをByNameで並べるという手法、そしてそのByNameで書いたメンバーの嬉しいことは他の人が書く、という手法が斬新でした。

普段の生活では、自分の仕事に精一杯になりがちで、他の人が考えていることを考える機会は、思ったより多くありません。お互いに嬉しいことを考えることによって、チーム力や結束力がアップするのではないでしょうか。

また、モデルを書いて成果が出たつもりになり(成功の確信へのステップとして、大事なことではあるのですが)、なかなか行動しないというのもありがちなので「モデルを書いて満足しない」という言葉も、心に強く留めておきたい言葉であると思いました。

プロモーション活動をデザインする

登壇者

株式会社匠BusinessPlace 清水 康平 氏

内容

  • 少ない時間の中で価値を出していく活動・実践のコツ

セミナーのテーマを決める:価値デザインモデル

  • 付箋を使ったディスカッション
  • メモは大切。のちのち宝になることも
  • 先行して活動できることを実施してしまう
  • 価値デザインモデルをつくるのは1.5Hくらいで終わった

ニーズを検討する:価値分析モデル

  • 価値を感じて欲しいステークホルダーをあげる
  • 不参加者(来たいけど来れない)というステークホルダーが出てきた

    • イベントをニコ生放送につながった
  • 新たな価値をうみだす重要な活動にフォーカスする

タスク管理

  • 落とし込んだタスクをBacklogでタスク管理
  • 前回のタスクに加え、今回追加される活動をタスクにする
  • ポイントで進捗を確認
  • 匠Methodのモデルを確認し、つながる価値に着目

    • 価値に応じて実施する活動を取捨選択する

感想

匠ビジネスプレイスの方たちが、匠の夏祭りのために、一生懸命に準備しているのをイベント前から感じていました。

清水さんの発表で、匠の夏祭りの企画段階を見せてもらったことにより、イベントの準備から当日までのストーリーを感じ、さらに参加意識が高まりました。

普通に業務をしていて忙しい上に、並行してイベントの準備をするという場面はよくあります。そのときに、どの活動に力を入れるのか、もしくは何を切り捨てるのかを決める指針に、匠Methodを使っている事例は参考になりました。

また「メモは大切、のちのち宝になることも」はファシリテーターとして大事な心構えだと思います。

ちょっとしたアイデアをその場でばっさりと切り捨ててしまうのか、後で使えるかもと思いアイデアをモデルに乗せておくのでは、アイデアを出したメンバーの参加意識が変わってくるからです。

篠原さんと清水さんのセッションは、その前のビジネスの成功事例のセッションから一転して匠ビジネスプレイスでの匠Methodの普段使いの事例でした。

ビジネスの企画以外にも、気軽に普段の仕事から匠Methodを使って、頭を匠脳(大関さんのセッションより)にしていくスタンスは、見習うべき姿勢だと思いました。

なぜなら、これからの時代の人がする日々の仕事は、新しい価値を創り続けることであり、匠Methodは「その仕事は価値を生み出しているのか?」と常に立ち返ることが出来る方法論だからです。

セッション5へ

全体へ

匠Methodの書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠の夏祭り2017 まとめ 第3部 コラボレーション事例

第3部は、匠Methodと企業のコラボレーション事例です。

it-takumi.connpass.com

デジタル化の成功率はこうやって上げろ

登壇者

株式会社ユニリタ 戌亥 稔 氏

事業・プロセス

  • デジタル変革=最新のITを使い、企業のビジネスに直接的に利益を産む仕組みを作り出す
  • 最初から投資してもうまくいくかわからない:リーンスタートアップ

デジタル変革の3要素

  • 企業内・企業間とのインフォメーションフロー(血液)
  • インテリジェンスな素早いリアクション(神経)
  • 継続的な学習(生涯学習し続けるシステム)

ビル・ゲイツの書籍:「ビル・ゲイツ@思考スピードの経営」 より

デジタル変革の成功率をあげる方法

  • (1)データの価値を見極める

    • 自社の持つデータで何が出来るか?そのデータを加えると価値が上がるか
    • データの価値分析→価値分析モデルを使用
  • (2) 継続的デリバリー

    • データの再利用をいろんなシーンで確かめる
    • どうすれば、意思決定のスピードを上げられるか
    • 自動化を進めることができないか
    • 可視化ができているか
    • 不足しているデータはないか
    • オープンデータとマージをすれば新しい知見が得られないか
  • (3)継続的な学習

    • システムに学習させることができるデータとは?

匠Methodとユニリタのコラボ

  • 情報流通

    • 匠Methodを使って価値分析をして、ユニリタのプラットフォームで素早くシステムを構築する
  • リアクション

    • アジャイル開発とDevOpsのプラットフォームでシステムを成長させる
  • 継続的な学習

    • 学習できるデータの価値を様座な角度で分析して、加工、プラットフォーム化する

介護☓IT(介護事業者向け) を匠ビジネスプレイスと取り組んでいる

感想

情報流通、リアクション、継続的な学習を循環させて、デジタルの力を増幅させるというアプローチは、インターネット・ITを使ったサービスを企画する時の考え方のひとつとして、思考の道具箱に入れておくと良いと思いました。特にプラットフォームのようなサービスを考える時に使うと良いのではと思いました。

また、匠Methodを使って、データの価値を分析していくというのも、人の行動、そして企業の活動の中から大量のデータが発生する、IoT/ビッグデータ/AIの時代において有用なアプローチです。

「データがあるけど、何かできない?」と目的がないところから、データによって知見を得ようとするアプローチは、コストもかかり、結局なにも結果を得られないリスクが高いアプローチといわれています。

しかし、匠Methodの価値分析モデルを使って、自社で持っているデータの価値を考えてみることは、短時間でリスクなく取り組むことができます。

そして複数のステークホルダー視点でデータについて考えることで、データ活用の新たな視点が得られることが期待できるでしょう。

セッション4へ

全体へ

匠Methodの書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠の夏祭り2017 まとめ 第2部 コンサルティング事例

第2部は、匠Methodのコンサルティング事例です。

it-takumi.connpass.com

前半の導入部は匠ビジネスプレイス萩本さん、中盤からは東洋ビジネスエンジニアリング入交さんのお話でした。

匠Methodによるプロダクトデザイン

登壇者

匠ビジネスプレイス 萩本順三 氏

匠Methodの特徴・効果

  • 6つのシンプルなモデル
  • モデルが心をどう刺激するかを考える
  • 動機力をUPするためのモデルである
  • 価値は感じるもの(論理的なものではない)
  • 匠Methodのビジョン:みんなの嬉しいを創り出す
  • 嬉しいを演出しないとステークホルダーがビジネスモデルに参加してくれない

    • 価値のバランスが大事
  • プロジェクトの目的は自分たちの下心

  • 価値を考えているうちに、やってるうちに目が輝いてくる。他の会社のことまで考えているので

新製品企画での活用事例

登壇者

  • 東洋ビジネスエンジニアリング 入交俊行氏

匠Method導入の経緯

  • XXX(製品名)を超える次世代mcFrame(自社のERPパッケージ)を4人で作れという経営陣からの指示
  • プロジェクトのコードネームは「Chariot」
  • 新技術検証とモック作成、競合製品調査、社内インタビューを続ける日々
  • イベントで、セカンドファクトリーのブースに行った時に萩本さんを紹介された
  • 方法論大嫌いだが、匠Methodをやってみた
  • 匠Methodの以下の点が良さそうと思った

    • 点在知識(ノウハウ)をつなげる
    • 思考のトレーサビリティが取れる
    • 短サイクルでPDCAサイクルが回せる

匠Method史上最悪の生徒

  • 立ちはだかった高い壁(その1)

    • 現意識が中心でなかなか新意識が出てこない
    • 今までできなかったことを実現したい(=ERPで実現したいこと)との思いの強さがギャップの原因

    • 萩本さんのFacebook「ビジネス慣習という呪いは、なかなか解けないと痛感したセッション」

    • まずは未来の製造業の姿を描くことに変更→良い方向に向かい始めた
  • 立ちはだかった高い壁(その2)

    • ポエマー不在、デザイナー不在(理系集団の悲哀)
    • 価値デザインモデルで要素は出るが、言葉としてまとまらず、いつまで経っても言葉が空白

    • プロジェクトのコードネーム「Chariot」にIoTが入っている→ERPから脱出し、IoTをやろうという新意識になれた

  • 立ちはだかった高い壁(その3)

    • 制御不能となった要求分析ツリーの作成作業

      • 作成過程で次々と噴出したやりたいこと
      • 出来は悪いがメンバーの思いが詰まった要求分析ツリー。いつかきっと役に立つはずと残した

経営陣への企画プレゼン

  • ビジョン:全世界のマーケットニーズに即応するための変革を支援する
  • マイクロサービス型ERP+IoT&BigData
  • 2020年に向けての目標

  • 20以上のサービスを提供する

  • 世界20か国以上で利用
  • カテゴリトップ製品(サービス)を創出

→ 一発OK!

製品リリースと成果

  • 6か月という短期間でリリース(IoTプラットフォームはSORACOMを使用)
  • IoTコンテストの審査委員一押しツールに選定→会社の株価大幅上昇
  • リリース後1年で6か国に導入
  • 明日からできる簡単IoT(2時間で導入できる)で顧客に喜ばれた
  • 社内表彰でNo.1獲得

匠Methodを導入した効果

  • モデルをもとにした明確な判断基準を持てた

    • 外部の声をシャットアウト
  • 顧客中心のアプローチができるようになった

    • 共通言語が「お客さんのために」や「顧客の価値」になった
  • 市場ニーズの変化に対応しやすくなった  

    • 要求分析ツリーの中のここをやろう、こことここがつながるというトレースができるようになった
  • 巨大な要求分析ツリーをつくったが、メンバー共通の知識ベースができた

匠Methodに望むこと

  • 匠Methodブートキャンプ

    • リーダークラスが揃うと俺のやり方を通そうとする
    • 匠Methodの型にはめてほしい
  • ポエマー養成講座、デザイナー養成講座

    • エレベータートーク:30秒でシンプルに説明し伝わるように表現する
    • 理系は30秒でとなると、内容を変えずに倍速で話そうとする(NG)
    • 的確な言葉でシンプルな言葉づくりができるように
  • 数値目標アプローチ

    • 匠MethodのValue Metrics に取り組んでいる委員会があって進めている(萩本さん)

感想

萩本さんのセッションの「匠Methodのビジョンは、みんなの嬉しいを創り出す」という言葉は、記憶に残りました。匠Methodを使ったファシリテートの場面で「みんなの嬉しいを創り出すのが匠Methodなんです。他の人にも共感して、その人の嬉しいことを考えてください」というように使えそうな言葉です。

東洋ビジネスエンジニアリング 入交さんのセッションでは、いままでの思考慣習からなかなか抜け出せない理系チームが、ふとしたきっかけから新意識になり、糸口をつかみ、突破口を開き、新規サービスを成功させるストーリーに引き込まれました。

入交さんの話からは、萩本さんを信じて、忍耐強く考える、自分たちなりにやってみるという、やり抜く力=GRIT(グリット)が伝わってきました。

プロジェクトでは、直線的に成功するということはなく、不安に包まれたり、ものごとがうまくいかない瞬間は必ず訪れます。

そのようなマイナスの局面でうまく行くと信じ、忍耐強く粘れるか、平常通りに行動できるか、それがプロジェクトが成功するか、しないかを分ける分岐点であるといえるでしょう。

匠Methodのモデルは、そのような場面で羅針盤の役割を果たし、モデルに立ち返ることで自分たちを見失うのを防いでくれるでしょう。

プロジェクトを成功させるために大事なことと、プロジェクトにおいて匠Methodのモデルが果たす役割を再認識できたセッションでした。

セッション3へ

全体へ

匠Methodの書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠の夏祭り2017〜第1部 イノベーション事例

第1部は、匠Methodによるイノベーション事例です。

it-takumi.connpass.com

食を通じた新たな価値創造・地方活性化へ向けて

登壇者

  • 株式会社セカンドファクトリー 代表取締役 CEO & CVO
  • ブエナピンタ株式会社 代表取締役CEO & CVO
  • 大関 興治(KOJI OZEKI)氏

テーマ

  • IoTプラットフォームによる、生産サイドと消費サイドをつないだビジネスイノベーションの成功事例
  • QOOPa Premium Market、THE NARUTO BASE、地産地食レストラン「FARM to TABLE」

ビジネスモデル

  • 生産サイド(農業、畜産業、水産業、加工業者)には、加工・商品開発の提案・コンサルティング
  • 消費サイド(飲食店、フードコード、ホテル&リゾート、加工業者)商品開発の提案・コンサルティング
  • 幅広い共創プラットフォーム:Stock(デポ)、Kitchen(加工)、Store(販売)、小ロット契約農地

会社、サービス立ち上げ

  • もともと情熱ブルドーザーと言われるほど感性で走る会社だった。それに論理的に可視化される匠Methodを導入
  • セカンドファクトリーというIT企業で地方に行っても「IT企業が何しに来た」と思われるだけなので、新たにブエナピンタという会社をつくった
  • ブエナピンタの立ち上げ企画も匠Methodで。クイックに立ち上がった
  • SI風に進めていたら、やってたら2年位かかるところを、匠Methodを活用し、半年でカットオーバー

匠Method導入以前で起きた問題

  • QOOPa(クーパ)を開発・リリース
  • 飲食業の人にヒアリング→要件定義→開発→賞も取れた→顧客も増えた→行けるのではと思った
  • イノベーションを起こしたはずなのに、収益化できない!
  • 同じジャンルに多くの製品がある→営業力で勝つしかなくなる→別の差別化が必要

  • IT視点でイノベーションを起こそうとしたが結果に結びつかない。

レストランオーナー・そして徳島へ

  • 海の家やレストランオーナーをやってわかったこと

    • 従事者の減少
    • 食材の入手の難しさ
    • オペレーションコストの増加
  • ITだけでは片付けられない課題が結構ある→徳島へ

  • 徳島に行ってわかったこと

    • 生産物が余ってる
  • ICT/IoTを活かせば、解決を同時進行できるのでは

    • ものが売れない
    • 規格外品をどうしたらいいかわからない
    • せっかく作ったものを廃棄しなければならない
    • なにを作ったら売れるのかがわからない
    • 加齢で体がしんどい
    • 後継者がいない
  • 農家の立場・レストランの立場になってCX(カスタマーエクスペリエンス)駆動で考えてみる→匠Methodで企画

FARM TO TABLEで解決すること

  • 産地直送ビジネスモデルだけでは難しい課題を解決する
  • 中小外食からみた場合:シェアードのセントラルキッチン
  • 中小生産者から見たトライアル六次産業化施設

生産地と消費を結びつけるモデル

  • (1)首都圏+食材産地直送モデル

    • 賃金が高くなる
    • 大きな物流拠点が必要になる
  • (2)首都圏+食材産地即加工モデル

    • 調理スキル依存型経営から脱却できる可能性
    • 食材費を下げて、賃金を上げることが出来る
    • 産地の加工は以下の4つで請ける

      • 素材加工
      • 複数素材加工
      • 指定調味加工
      • 完全加工
  • (3)食材産地即加工++ モデル(鳴門方式)

    • 農家の収益拡大(おいしいのに捨てているものを使う)
    • スープストックのような経営スタイル(調理師が店にいない)を中小外食で採用可能
    • ITと加工技術の組み合わせで極小キッチンで高品質なメニュー展開も可能に
    • 都心で、シェフがいらない。冷凍の技術の発展のため
  • 生産技術/ ICT・IOT/ 加工技術/冷凍技術/物流のフル活用

  • 生まれた価値

    • 生産物で捨てるものがなくなった
    • 地元に雇用が生まれた
    • 美味しくなった
  • 同じモデルを鳴門以外の地域にも横展開できる

こたつモデルの効果

  • 匠Method導入以前

    • システム屋としての視点☓飲食店の視点☓生産者としての視点
    • それぞれの視点・気持ちは大事だが、それぞれが分断されていた
  • 匠Method導入以後

    • システム屋、飲食店、生産者がひとつのチームになり、利害一致ポイントを抽出
    • チーミングとファシリーテートで想いが共有された

匠Methodによって生まれた現意識と新意識

  • IoTによる農地管理

    • 現意識:栽培管理のため
    • 新意識:マーケットにトレーサビリティデータとして提供
  • 循環農業

    • 現意識:堆肥を生産に活かす
    • 新意識:マーケットが欲しがっているオーガニック堆肥使用の新ブランド野菜をつくる
  • スマホの使用

    • 現意識:生産者用の専用アプリを自ら開発→使ってもらえなかった
    • 新意識:LINE(チャットボット)をインターフェースにした→70%使ってもらえるようになった

匠Method導入によってできたこと

技術起点イノベーション(当初のQOOPa)を、ユーザー起点イノベーション(QOOPa Premium Market、THE NARUTO BASE、FARM to TABLE)に変えることができた

  • コメント

    技術を元にしたソリューション提供(当初のQOOPa)は、技術起点のアプローチ(=Howからの突き上げ)であり問題ではない。ソリューションのアイデアを顧客・ステークホルダー視点から検証していないことが問題であった。

まとめ

  • 匠Method導入のタイミングは早ければ早いほどよい
  • 導入のキーマンを明確にし、本気で巻き込むチームビルディング
  • 匠Methodを難しく捉えない

    • ビジネスメソッドであって論語のようなものである
  • 大事なのはみんなで匠脳になること  

    • 日頃の生活の中で自然に意識できるように
  • 農家もITも関係ない。つくりたいのは笑顔。笑顔なき価値創造なんてありえない

  • コンセプトの共有に時間をかけろ
  • Break The bias
  • 成果を出したければ「想いを紡げ!」

感想

システム屋視点のソリューションが行き詰まったところから、匠Methodを活用して、農業生産者、飲食業の幅広い視点を獲得して、周りを巻き込みながら、ソリューションを広げていくところに、ビジネスのストーリーを感じました。

「嬉しい」かどうかを感じるだけでなく、その解決策は、ステークホルダーが笑顔になるのか、満面の笑みなのかをイメージしてみると、さらに共感力が増し、その後の巻き込み力が増していくのだと学ぶことが出来ました。

巻き込み力をつけていきたい私には、とても参考になる事例でした。

セッション2へ

全体へ

匠Methodの書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜