Actier COO なブログ

株式会社アクティアのCOO(くぅ〜)による「くぅ〜!」と思って貰えるような何らかを提供していきたいブログ

ある1つのコミュニティの最後と新たなる旅立ち 〜 さよなら、匠塾

匠塾のクローズへの思い

匠塾という、8年間塾長として引っ張ってきた愛すべき勉強会コミュニティが今月の実施回(5/11)をもって活動終了しました。

これまで一緒に学び、成長し、共に価値を創り出してきた皆さんへ、心からの感謝を伝えようと思いポエムを書きます。 結構、バタバタと決まったので、最終回がひっそりと終わってしまったこともあり、ここで一つの区切りをつけれたらなという思いもあります。


匠塾とは何だったのか

そのビジョンと活動内容

匠塾は、

「価値から物事を考え、現状にとらわれずに価値を生み出すビジネスモデルを導く思考が身につく場を皆で作り上げる」

をビジョンに掲げ、匠Method という方法論を学ぶ場でした。

参加者は全員が紹介制。 紹介制とすることで、広くコミュニティに人を集めるというよりは、つながりのある高い志を持つ人々だけを集め、共にレベルアップするという思いのビジョンを追求しました。 結果として、想いを持った人が集まり、濃いコミュニティを作り上げることができたのではないかと思っています。

匠Method って?

匠Method は、匠BusinessPlace の萩本さんが創られた

価値から戦略・業務をデザインする

ことをビジネス企画やプロジェクトデザイン、システムデザインやキャリアデザインと幅広く様々な企画やデザインの領域で適用することができる方法論です。

思考法でもあるため、匠Method の普段使いといった言葉もあるとおり、日常生活の中で活用していくこともできます。

過去に、このブログでも以下の記事を書いているので、ご参考ください。

actier-coo.hatenablog.com

actier-coo.hatenablog.com

匠塾の3つのコンセプト

「価値から物事を考え、現状にとらわれずに価値を生み出すビジネスモデルを導く思考が身につく場を皆で作り上げる」

このビジョンを下支えするために、私たちは 3 つのコンセプトを掲げていました。 「1回完結」、「レベル分け」、「一歩上へ」。

途中で見直しして、シン・「ビジョン、コンセプト」としてコレを打ち出していたのですが、皆さんそれぞれのビジネスに活かすため、一歩上のレベルを目指して参加いただいていました。

このビジョンやコンセプトも、匠Method を使って「コミュニティの価値あるあり方」をモデリングして定めていました。 結果として、このデザインした通りの活動を行うことができていたかなと思っています。


匠塾の軌跡

開催履歴とメンバー数

2015年5月に匠塾の開催が確定し、同年7月に初回が実施されました。 ふと、Facebook を見ていたら、ちょうどピッタリ 8 年前に萩本さんが匠塾のアナウンスをしていたという奇跡のようなタイミングで、このポエムを書こうという思いになりました。

萩本さん匠塾アナウンス
萩本さんの匠塾アナウンス

毎月第二木曜日を活動の基本の日(祝日等でズレる)としていました。 それから 8 年間で、通算 88 回もの勉強会が開催され、合計 254 名のメンバーと共に学び続けることができました。

以下の Facebook ページにて、過去の活動の一部を発信していたので、どんな会だったかの雰囲気はコチラを参照してください。 https://www.facebook.com/takumijyuku

大LT大会

活動の中で、想い出深い勉強会イベントとしては、匠塾生を中心としてオープンに実施した LT 大会・交流イベントがありました。 半年か 1 年に 1 度の LT 大会・交流イベントでは、匠Method の原点であるシステム企画&開発の事例以外の、 「IT系以外のお仕事で使ってみた」「日常で使ってみた」「匠Methodってこんな意外な側面が!」などなど、 普段、匠Methodの真髄を探求し続ける塾生ならではの体験談を(お酒を飲みながら)熱く暑く語る場でした。

以下の connpass のイベントページから、当時の熱いイベントでの発表資料を参照いただけます。

匠塾 大LT忘年会 2017 ビジネスをデザインする匠Method - connpass

匠塾 大LT大会 2018夏 ビジネスをデザインする匠Method - connpass

匠塾 大LT大会 2018冬 ~みんなの「嬉しさ」をデザインする匠Method~ - connpass

匠塾 大LT大会 2019夏 ~みんなの「嬉しさ」をデザインする匠Method~ - connpass

匠塾 大LT大会 2019冬 ~みんなの「嬉しさ」をデザインする匠Method~ - connpass

【オンライン開催】匠塾 大LT大会2020夏~みんなの「嬉しさ」をデザインする匠Method~ - connpass

【オンライン開催】匠塾 大LT大会2020冬~みんなの「嬉しさ」をデザインする匠Method - connpass

そして、コロナ禍に入り集まっての開催が厳しくなり、実施した「匠らじお塾」。

新たな価値を追求しようという試みとして、ラジオ風イベントを開催してみたりもしました。 参加方法として、

  • リスナー参加…耳だけ参加メイン。職場からの帰り道や、家事をしながら聞きたい人向け。Twitterを通じたお便り投稿もできます。
  • スタジオ参加…徹底討論への参加権がある。がっつりイベントに参加する人向け。もちろんTwitterでのお便り投稿も可能。

が選べるという一風変わった勉強会イベントに仕立て上げました。

匠らぢお塾 - connpass

「匠らじお塾」開催模様を Togetter でも追えるようになっています。

togetter.com

勉強会への色々な参加の仕方や関わり方ができるように、実施してくる中でレベルアップしながら、新たな価値を提供し続けてきました。

執行部への感謝

匠塾 執行部メンバー

「匠Method を広く学べる場を継続したい!」という僕の勢いだけの想いに共感してくれて、執行部のメンバーが匠塾や僕を支えてくれました。 写真の通り、最初の決起集会からメンバーが変わったり増えたりする中で、新しい集合写真を撮るタイミング無く終わることになりました。

こうして写真を見ていると、「執行部メンバーが関わってくれたおかげで続けられたな」とヒシヒシと思うので、ホント感謝しかありません。 この場を借りて、歴代の執行部メンバー皆さんにお礼させてください。


新たな旅立ち:匠Methodユーザーグループ

匠塾としての活動は終了しましたが、実は私たちの旅は終わりません。 新たに「匠Methodユーザーグループ」として、引き続き学びの旅を続けます。 同じ価値観を共有する皆さんと一緒に、新たな一歩を踏み出すことを楽しみにしています。

まだ、細かい話は準備中なのでお伝えできませんが、以下のTwitter アカウント等で続報をお届けします。

twitter.com

また、匠塾だった Facebook グループは、引き継ぐ形で、すでに「匠Methodユーザーグループ」へと変更されています。

www.facebook.com


5. まとめと次への一歩

長いようで短い時間、皆さんと共に過ごし、共に学んだ経験は僕にとって貴重な宝物です。 皆さん、そして執行部メンバーによって支えられ、共に成長できたことに、心より感謝しています。

匠塾という舞台が幕を閉じ、匠Methodユーザーグループとして新たな旅が始まる今、これまでの経験を胸に、みんなで新たな一歩を踏み出しましょう。 これからも共に成長し続けるために、皆さんの支えが引き続き必要です。

ぜひ、私たちの次回作にご期待ください!


RDRAで学ぶ要件定義から設計へ その2−2

この記事について

弊社のある社員の教育として、プログラミングだけでなく、要件定義から設計といった上流工程と呼ばれる領域について、一度体系的に話をした方がいいよねというシチュエーションが生まれました。どうせレクチャーするなら、自分の知見をまとめなおすことも合わせてやってしまおうと、レクチャーしつつ、その中で出てきた要点や Tips を記事にまとめた一石二鳥な連載記事の 3 回目です。

過去の投稿は、こちら↓

RDRA って何?って人は、その1へ actier-coo.hatenablog.com

システム外部環境レイヤーの第一弾は、その2−1へ actier-coo.hatenablog.com

今回の「その2−2」では、システム外部環境レイヤーの業務フロー図、利用シーン図、バリエーション・条件図について、僕が RDRA を使用している中で思っている Tips を含めて書いていこうと思います。

システム外部環境レイヤー

RDRA全体像

おさらいしておくと、システム外部環境レイヤーは、以下のダイアグラムで構成されています。

  • ビジネスコンテキスト図
  • ビジネスユースケース
  • 業務フロー図
  • 利用シーン図
  • バリエーション・条件図

これらのダイアグラムで、システムがビジネスや業務の中でどのように使われるか、業務や利用シーンを考えた時にどの様な環境で使われるか、使っていく中でどのようなビジネス要素やビジネスルールが関係してくるかといったことを表現します。これらによって、システムを使う上での環境を表現するレイヤーとなります。

前回説明したビジネスコンテキスト図でビジネスの全体像を描き、ビジネスユースケース図で業務をブレークダウンしてビジネスで提供する価値を描いてきました。 今回は、ビジネスユースケース図を元に、業務の詳細を業務フローや利用シーンによって、より明確にすると共に、業務とシステムがどのように繋がっているか、どのようなビジネスルールがあるかを分析していきます。

あらためて繋がりを意識する

おさらいですが、システム外部環境レイヤー以降を進めていく中で、各 RDRA の要素やダイアグラムがどう繋がっているかを意識しておくと、連続性をもって要件を分析・整理していくことができます。 以下の図を意識しながら、常に繋がりを意識いただくと良いです。

繋がりを表現している矢印の色は、それぞれ次のような意味を持って表現しています。

  • 水色:矢印の根元の対象要素が、矢印先のダイアグラムへ単純に引き継がれる
  • 緑色:矢印の根元の対象要素ごとに、矢印先の新たなダイアグラムが作成される
  • 黄色:矢印の根元のダイアグラムを作成している中で出てきた要素を抜き出したり、要素の内容について考えてまとめる

RDRAの各要素やダイアグラムの繋がり

業務フロー図

業務フロー図

「業務フロー図」は「ビジネスユースケース」単位に作成します。価値を実現する一連の仕事(アクティビティ)の流れを記述し、関わるアクターを明示します。価値をとどけるアクターは誰で、それを支援するアクターが誰なのかを示し、価値を届ける一連のフローがスムーズに連携していることを確認します。同時に仕事の中でシステムを使う部分に「ユースケース」をつなぎ、システムの使われ方を示します。
 〜 RDRA2.0 ハンドブック から引用 〜

「ビジネスユースケース図」で抽出した「ビジネスユースケース」ごとに、この「業務フロー図」か後述の「利用シーン図」を作成していきます。 「業務フロー図」では名前の通り、フローで「ビジネスユースケース」がどのような業務の流れになっているかを記載していきます。 上記の図のように、その業務フローに関わるアクターごとにスイムレーンを用意して、そのアクターが実施すること(仕事=アクティビティ)の連鎖をフローとして記述していきます。 開始から、各アクティビティを経て終了まで至るといった業務フローが描かれます。

また、その業務フローの中で、システムを使うアクティビティに「ユースケース」を紐付けて記載します。 ここで出てくる「ユースケース」は、ビジネスユースケースではなく「(システム)ユースケース」です。 「(システム)ユースケース」は、システムがどのように動作し、ユーザーに価値を提供するかを表す単位になります。 例えば、「見積を登録する」、「見積を参照する」、「見積を編集する」、「見積を削除する」といったようなシステムを意識したものになります。

業務として成り立っているかということを意識して業務フローを記載するので、ユースケースに紐づかない(システムを使わない)ところも記載します。 初学者の中には、システムに関連する部分だけを記述してしまう傾向がありますが、業務の全体像を理解するためには、システムが関与しない業務活動も含めて全てを記述することが重要です。

業務フローを記載してユースケースを紐付けることで、以下を明確にすることができます。

  • 業務の一連の流れ
  • 業務の中でシステムを使う所、使わない所が「ユースケース」と紐づくかで見える

業務の流れを捉えることはドメインの理解を促進するのと、システムが業務にどう絡むかが見えてくる図なので、RDRA で分析をする中でもかなり重要な図です。

システムが小規模である場合などに、システム全体を一覧で見ることが容易になるよう「ユースケース複合図」*1と合体した業務フロー図を作成することがあります。

業務フロー図 高崎Tips

  • 分析をしている中で、一個一個のキーワードをそのまま落として作るのではなく、シナリオをイメージして書いていくのが良いです。 頭の中でシナリオとして業務の流れをイメージして、あれをやんなきゃ、これをやんなきゃを出していきます。 そのシナリオが出てこないということは、その業務について分かっていないということなので顧客に聞くなどして調べていく必要があります。

  • 初学者のうちは、作成していく際に、上記の説明の通りに業務の流れをまずは意識して業務フローを記載する。 業務フローができあがった所に「(システム)ユースケース」を紐付けてシステムをどこで使うかを意識していくといった分離した進め方を徹底すると良いです。

    業務の流れを捉えるという関心ごとと、その中のアクティビティでシステムを使用する所を捉えるという関心ごとの 2 つを実施しているので、関心ごとを分けて考えた方が考えることがシンプルになり捉えやすくなります。

  • 業務フロー図を書くとき、業務の流れを一つの業務フローとしてまとめることが困難な場合があります。 よくある理由の一つとして、各ビジネスユースケースがうまく整理できておらず業務フローが描きにくい状態になっていることがあげられます。 ビジネスユースケースを抽出した際に、内容が抽象的すぎることでも業務フローに落とし込むことが難しくなります。 このような場合は、ビジネスユースケース図にも立ち戻り、まず業務を細かく見直します。あわせて業務フローの中で、別の業務が出ていないか、一連の業務として成り立っているかも確認します。 これらを踏まえ、業務が実施できるかを考えて業務フロー図を書くことが重要です。

  • 業務フロー図をプログラマーが書いていると、ついついココで分岐があるはずとか、ココでループするといったような条件分岐や繰り返しを入れて複雑な業務フローを記載してしまいがちです。 各条件パターンをすべて網羅して書いていくとノイズになってしまうので、主要な業務フローについて記載するのが良いです。 条件分岐することが主要で重要なのであれば記載しますが、基本的には複雑になるのであまり描かないといった感覚です。 また、主要という程ではないけれど条件分岐や繰り返しがあることを伝えたいといった場合には、よくノート(注釈)として対象のアクティビティにコメントを付与して伝わりやすくするといったことを実施しています。

  • 「(システム)ユースケース」を記載していく中で、具体的すぎることは記載しないというのもポイントの一つです。 細かい具体的なことまで書いてしまうと、システムでの実現方法が固定的になって縛られてしまうということに繋がっていきます。 ここで出てくる「(システム)ユースケース」は、「システムが提供する価値って何だろう?」といったレベルで書いていくことを意識します。 例えば、「連絡をする」といったものがあった場合に、連絡のやり方として「メールで」とか「チャットツールで」といったようなことまでは書かなくて良いといった感じです。 ただ、連絡をするという行為やシステム価値自体は必要なので、アクティビティやユースケースとして抽出するようにはしてください。

  • 業務フローを記載していく中で AsIs (現状)の業務フローを完全踏襲する(縛られる)必要はないのですが、把握はしておいた方がよいです。 将来像だけを意識して作るべきものだけを聞いて作った業務フローだと、現状からの飛躍が大きくなりすぎたり、作ったものの納得感が無くなったり、業務が回らなくなってしまうことがあるためです。

  • 初学者は、ビジネスユースケースと(システム)ユースケースをしばしば混同してしまいがちです。 これらは「ユースケース」という共通のキーワードを持っているためです。 これらが混じってしまうと分からなくなってしまうので、まずは違うものだという意識を持つことが重要です。 ビジネスユースケースは、ビジネスにおける提供価値で、システムユースケースは、システムが提供する価値です。

利用シーン図

利用シーン図

「利用シーン図」は業務を仕事の流れとして表現できない場合に「業務フロー図」の代わりに使用します。「ビジネスユースケース」単位に一つの「利用シーン図」を作成し、その中に一つまたは数個の「利用シーン」を描きます。
 〜 RDRA2.0 ハンドブック から引用 〜

「ビジネスユースケース図」に抽出した「ビジネスユースケース」ごとに、この「利用シーン図」を作成していきます。 「業務フロー図」は業務の流れについて図示していくものでしたが、そういった流れを表現できない際に「利用シーン図」にて図示します。

「利用シーン図」は、業務の中でシステムを利用するシーンである「利用シーン」を思い浮かべ、上図のように記載します。 その「利用シーン」は、どのような使われ方なのかといった詳細を「シナリオ」としてシナリオ形式で記載します。 また、その利用シーンの中では利用する対象者がいると思いますが、その対象者を「アクター」として紐付けます。 同様に、利用シーンの中で利用するシステムの機能=「ユースケース」が出てくるので、それを紐付けます。

これらの要素(アクター、ユースケース、シナリオ)を組み合わせることで、

「誰(アクター)がどのように(シナリオ)何(ユースケース)を利用するか」

という形でシステムの利用シーンを明示することが可能になります。これにより、要件をイメージすることが容易になります。

利用シーン図 高崎Tips

  • RDRAで要求分析を実施するとき、全ての要求分析に同等の時間とリソースを投入するのではなく、重要なポイントに絞って要求分析を行うことが推奨されています。 これはRDRAが効率的に要点を把握することを目指す手法だからです。 利用シーン図については、全部の利用シーンを描きたくなりがちなのですが、RDRAの原則に従い、重要なポイントに絞って描くことが望ましいです。

    重要なポイントに絞る際に、以下については記載した方が良いです。

    • その利用シーンが、システム検討のなかで非常に重要である
    • その利用シーンが、非常にフワっとしていて曖昧なので認識を合わせたい
    • 将来的に対象のシステム機能を使うので、現在の知識からはイメージしにくいため将来像の認識を合わせたい
  • 業務フローが書きにくいので、よく利用シーンで書くものとしてマスタ管理について記載することが多いです。 前述の「要点を絞って」といった点からすると、マスタ管理は別に書かなくてもいいといった対象にはなってくるのですが、

    • 規模が小さいこともあり、ドキュメント記載の関係等からマスタ管理についても網羅的に要求分析しておきたい
    • 対象となるマスタの使われ所が特徴的だったり、使われ方のイメージがつかないので定義しておきたい

    といった点から利用シーン図を描く時があります。

  • 初学者が利用シーン図を作成するとき、多くの時間を費やす割には内容が薄く、その効用について不安を感じることが多いです。 単純な登録・更新・削除のような基本的な利用シーンや、内容の薄い「シナリオ」を書くと、結果として意義の薄い内容ができあがることがあります。 そのため、前述の重要なポイントを絞ることを意識して基本的過ぎる利用シーンは避け、「シナリオ」には詳細と具体性を持たせることを意識しましょう。 これにより、具体的で役に立つ利用シーン図が完成します。

バリエーション・条件図

バリエーション・条件図

ユースケースはシステムとの接点を示し、画面やイベントで入出力が分かり、情報とつなぐことで操作対象が分かります。しかし、これだけではどのような条件で操作するのかが分かりません。入出力が分かり操作対象が分かれば、後はそれらの条件が示されればユースケースでやらなければならないことがほぼ類推できます。その条件がビジネスルールです。そのための出発点が「バリエーション」の分析です。そしてそれを組み合わせたものを「条件」として整理します。
 〜 RDRA2.0 ハンドブック から引用 〜

「バリエーション・条件図」は、図っぽくないので、一見するとダイアグラムのように感じないかもしれません。しかし、これはビジネスルールを示すための非常に重要なものです。 なぜ重要かというと、上記のハンドブックの記載にもあるとおり、この「条件」や「バリエーション」がビジネスルールになるためです。 ビジネスルールはビジネスロジックとして、システムに記述されます。

システムを作る際に、どのようなビジネスルールを実装するべきかということがきちんと整理できていると、方々にビジネスロジックを書き散らすといったことがなくなります。 まとめてビジネスルールを把握することで、ビジネスロジックとして集中管理した状態で実装できるためです。 方々に書き散らしたビジネスロジックは、拡張や修正をする際に抜け漏れが発生しやすくなるので、集中管理できた方がシステムの保守性といった点でメリットが出てきます。

バリエーション・条件図として、システムに出てくる「条件」や「バリエーション」を集中管理していきます。

「条件」には、以下の 2 種類があります。

  • 名前つけられた式
  • 表形式の条件

「名前つけられた式」とは、「消費税計算」のように特定のビジネスロジックや計算方法に名前がつけられているものを指します。 「表形式の条件」は、「バリエーション」を組合せてマトリックスになったものです。例えば、「映画館の料金計算」という表は「年齢」と「上映時間帯」というバリエーションによってマトリックスが描かれ、金額が決まります。 条件を書く際には、実装上の条件を記載するのではなく、あくまでも仕事を進める上での業務的な条件を記載します。

「バリエーション」は、上記の「年齢」であれば「小学生」「中学生」「高校生」「大学生」「大人」「シニア」といったような形でバリエーションが形成されるものです。 「ビジネスコンテキスト図」や「ビジネスユースケース図」で「ビジネス要素」が出てきた際に、その要素にバリエーションが無いかを検討してあった場合は「バリエーション・条件図」へ記載していきます。 また、「情報」のバリエーションが無いか、取引先の種類など業務を進める上でのルール軸になるようなものが無いかといったことを検討して記載していきます。

「条件」や「バリエーション」が集まってくると、どのようなビジネスルールがあるかが可視化され、結果としてシステムの複雑度を掴むことに繋がっていきます。

バリエーション・条件図 高崎Tips

  • 図っぽくないので、今までのダイアグラムと比べて描きにくいです。 ビジネスルールになっていくための「バリエーション」や「条件」がまとまってきているかということを意識しながら、ともかくそれらを集めていくようにしてください。

  • 要求分析をしている会話の中で、「バリエーション」や「条件」になりそうというものがポロポロと出てきます。これは「バリエーション」や「条件」なんじゃないかな?と思ったものは、とにかく「バリエーション・条件図」に集めておいてください。後々、俯瞰して見た際に違っていたら消せばいいだけなので。それよりも、その会話の中でせっかく出ていたものをロストしてしまう方がもったいないです。

  • ビジネスルールの源泉は、その業務の説明資料である契約書やパンフレット、就業規則や約款などに記載されています。それらから、「バリエーション」や「条件」を抜いてくることもできますし、抜けるように練習しておくと良いです。

  • 色々と「バリエーション・条件図」に集まってきたら、それらについてビジネスルールに関わりそうかどうかといった点で判断して要らないものは消したり、同じような分類になりそうなものは集めてみてグループを形成したりと、整理整頓していくと、どのようなビジネスルールがあるかというのをより掴みやすくなります。

今回は、ここまで。

次回は、「システム境界レイヤー」についてまとめていこうと思います。

*1:ユースケース複合図」については、「システム境界レイヤー」で説明します

RDRAで学ぶ要件定義から設計へ その2−1

この記事について

弊社のある社員の教育として、プログラミングだけでなく、要件定義から設計といった上流工程と呼ばれる領域について、一度体系的に話をした方がいいよねというシチュエーションが生まれました。その中で、どうせレクチャーするなら、自分の知見をまとめなおすということも合わせてやってしまおうということで、レクチャーしつつ、その中で出てきた要点や Tips を記事にまとめておこうという一石二鳥な連載記事の 2 回目です。

その1は、こちら↓

actier-coo.hatenablog.com

その1を書いてから、すっかり1年ちょっと経ってしまいました。。。 最近、また別の社員にもガッツリと時間取って教えているというのもあり、その2から先はサクッと連載していきたいと思います。

今回の「その2−1」では、システム外部環境レイヤーについて書いていたら長くなったので、まずはビジネスコンテキスト図とビジネスユースケース図について、僕が RDRA を使用している中で思っている Tips を含めて書いていこうと思います。RDRA って何?って人は、↑のその1へ

要件定義で意識したいこと

最近、1日1金言的な感覚で、バルタザール・グラシアンさんという聖職者の人生訓をまとめた本を読んでいたら、これは要件定義、そして RDRA を進める上で意識した方が良い言葉だなと思った一節があったので紹介します。

083 よく考える
 何かをいつも考えるくせをつけよう。無分別な人が手に負えないのは、物事をあらゆる側面から検討しないために全体像が理解できないからだ。理性的に考えることで、状況は正しく判断できる。
 ただし、さほど重要ではない細部にこだわりすぎると、判断や行動を誤ることになる。深く隠れていた真実が表面化するのを待っていれば、やがてすべてが理解できるようになることも多い。

〜バルタザール・グラシアンの賢人の知恵 エッセンシャル版 プレミアムカバーから抜粋〜

上記人生訓と同様に、要件を定義したり、設計をしたりといった中では、いろいろな側面から考えを巡らせ、全体像を掴むことが重要です。

その全体像を掴もうとする中で、重要ではなくただ気になってしまった所だけを深掘りしたり、網羅的にすべてを洗い出そうとすると、時間の無駄へと繋がっていきます。枝葉の部分も含めて、一度にすべてを知ろうとすると時間がかかるので、進めていく中で少しずつ見ていく方が周辺理解もしているため効率よく内容を把握することができます。

RDRA での要件定義・設計は、作り上げていく中で全体像を複数のモデルダイアグラムで関連付けながら掴めるようになります。進める際には、あるモデルダイアグラム一つで深掘りや網羅して考えようとせず、先のモデルダイアグラムに進んで分析をして、そこでの気づきを元のモデルダイアグラムに反映してといったように、行ったり来たりしながら精度を高めていくのが良いです。まさに、この人生訓の考え方が重要になってきます。

これを意識して、この先の RDRA のレイヤーやダイアグラムを理解して進められるようになっていると良いかと思います。

今回は、システム外部環境レイヤーについて意識しながら見ていきましょう。

システム外部環境レイヤー

RDRA全体像

システム外部環境レイヤーは、以下のダイアグラムで構成されています。

  • ビジネスコンテキスト図
  • ビジネスユースケース
  • 業務フロー図
  • 利用シーン図
  • バリエーション・条件図

これらのダイアグラムで、システムがビジネスや業務の中でどのように使われるか、業務や利用シーンを考えた時にどの様な環境で使われるか、使っていく中でどのようなビジネス要素やビジネスルールが関係してくるかといったことを表現します。これらによって、システムを使う上での環境を表現するレイヤーとなっています。

前回説明したシステム価値レイヤーで、システムの最上位のオーバービューを捉えましたが、それをベースにビジネスの全体像を描きシステムへと細部を描きます。 システムを活用しようとしているビジネスや業務がどのようになっていて、その中でシステムをどこで、どう使うかといったことを整理して表現していきます。

それぞれの要素やダイアグラムの繋がりを意識する

システム外部環境レイヤー以降を進めていく中で、各 RDRA の要素やダイアグラムがどう繋がっているかを意識しておくと、連続性をもって要件を分析・整理していくことができます。 以下の図を意識しながら、ここから先に紹介するものの繋がりを捉えていただくと良いかと思います。

繋がりを表現している矢印の色は、それぞれ次のような意味を持って表現しています。

  • 水色:矢印の根元の対象要素を矢印先のダイアグラムへと単純に引き継ぐ
  • 緑色:矢印の根元の対象要素ごとに、矢印先のダイアグラムを作成する
  • 黄色:そのダイアグラムを作成している中で出てきた要素を抜き出したり、要素の内容について考えながらまとめていく

RDRAの各要素やダイアグラムの繋がり

ビジネスコンテキスト図

ビジネスコンテキスト図

「ビジネスコンテキスト図」はシステムが使われる環境を明らかにするための最上位のダイアグラムです。システム化対象の「業務」を明らかにし、「ビジネスユースケース」へと分割することで「業務フロー図」、「利用シーン図」の作成単位とします。同時に業務に関わるビジネス要素(商品、取引先...)を明示し、ビジネスルールを整理するための源泉とします。
 〜 RDRA2.0 ハンドブック から引用 〜

ビジネス全体を一番ざっくりとまとめたものが、ビジネスコンテキスト図です。 システムコンテキスト図で描いたアクターや外部システムが、どのようにビジネス要素や業務に関わってくるのかといったことも、この図の中で表現していきます。

ビジネスの全体像をざっくりとまとめていく中で、

  • 業務としてどのようなものがあるか
  • 業務にアクター(組織や人)や外部システムがどのように関わるのか
  • どのようなビジネス要素が絡んでくるのか
  • 業務やアクター、ビジネス要素は、どのような組織や範囲で使われるのか

といった開発するシステムを使用するビジネスを俯瞰してみることができる様になっていきます。

システム外部環境レイヤーの起点となってくるダイアグラムなので、これをしっかりと抑えて、ビジネスイメージを高められる様にしておくと、後々の他の図でも統一感を持って要件定義や設計をしていくことができる様になります。

ビジネスコンテキスト図 高崎Tips

  • システム外部環境レイヤー以降で分析・整理していく各図は、繋がっていきます。ビジネスコンテキスト図で描いたものを踏まえてビジネスユースケース図を描いたり、検討をしている中でバリエーション・条件図に出てくる「バリエーション」や「条件」、システムレイヤーに出てくる情報モデル図の「情報」などが出てくるのでメモしておいた方が効率が良かったりします。それぞれの繋がりを意識して体得していくと、より深い要件分析ができるようになっていきます。

  • ビジネスコンテキスト図ぐらいから、「アクターやビジネス要素と業務の関係はどうなっているか?」といった様に関係性をしっかりと分析していきます。 そうすると、途端に完璧な関係性を描きたくなってくるので、「これとこれは繋がっているかなー?」と考え込み時間がどんどんと経っていきます。 この先のステップである業務フローなどで細部を考えた際に、この繋がりがあったというのが見えてくるものなので、ここで時間をかけてすべてを洗い出そうとせずに、先に進んで戻ってきて反映するといったように行ったり来たりしながら関わりを明確にしていくといった進め方にすると効率が良いです。

  • 分析・整理していく中で、気づいた「情報」などの各要素をメモ*1しておくと効率が良くなります。ただ、一方で、その進め方をすると、どれが「アクター」でどれが「情報」でといったことが初学者のうちは混乱してしまいがちです。

    出てきた名詞が何の役割をはたしているのかといった観点で整理することが多いのですが、その際に、その名詞の適切な役割を理解することが重要です。たとえば、「営業部」という名詞が出てきた場合、それがシステムを操作する「アクター」として扱われるべきか、それとも「情報」として扱われるべきかを判断します。どのような文脈で話に出てくるかにもよって変わりますが、「営業部」はシステムを操作する人々を表していることが多いので、「アクター」として扱います。「アクター」は、システムを操作する人や組織だからです。 一方、「注文情報」や「商品リスト」という名詞は、システムで扱う「情報」です。これらの区別は、ビジネス全体の理解と要件の明確化に不可欠です。

    RDRAでは、作図をして当てはめていく中で、その明確化を行っていきます。 最初は「アクター」として扱っていたものの分析を進める中で、図の中のおさまりが悪くて「情報」なのかもと気づくといったように、よりビジネス全体を理解した中では要素の位置付けが変わっていったりします。 やはり、分析を進める中で、細かくこだわりすぎずに進めてみて反映するといったことが重要になってきます。

ビジネスユースケース

ビジネスユースケース

「ビジネスユースケース図」は「ビジネスコンテキスト図」で明示された「業務」をブレークダウンした「ビジネスユースケース」を洗い出すダイアグラムです。「ビジネスユースケース」は価値を届ける単位になり、「業務フロー図」、「利用シーン図」の記述単位となります。
 〜 RDRA2.0 ハンドブック から引用 〜

ビジネスコンテキスト図で洗い出した「業務」ごとに、ビジネスユースケース図を書き、ビジネスユースケース*2を洗い出していきます。 ビジネスユースケースは、基本的には業務を細分化することで洗い出していくことができます。 また、関係者によってフローが変わる様な会社の中身のプロセス*3だと別のものとして表現します。関わる人によって価値が変わってくるためです。

「業務」をブレークダウンして細分化することで、「ビジネスユースケース」、「アクター」、そして「ビジネス要素」がその「業務」の中でどのように絡み合っているかを図示します。 その「業務」が、どの様なことを実施しているかをオーバービューで捉えられるようになります。

ここで定義したビジネスユースケースごとに、この後紹介する「業務フロー図」や「利用シーン図」を記載するので、その繋がりも意識しながら整理していきます。

ビジネスユースケース図 高崎Tips

  • 初学者にとって、この「ビジネスユースケース」が分かりにくいです。以下の Tips も意識して貰いながら、「ビジネスコンテキスト図」、「業務フロー図」、「利用シーン図」を何度も行ったり来たりしながら実践していただくと掴んでいけると思います。

  • 「ビジネスコンテキスト図」の「業務」とほぼ同じ場合は、作成しないことも可能です。

    ほぼ同じであれば作らなくて良い
     〜 RDRA2.0 ハンドブック から引用 〜

    といった様にハンドブックにも記載されている通りで、規模が小さいシステムだと「業務」と「ビジネスユースケース」が、ほぼイコールなので「業務」=「ビジネスユースケース」として扱います。 いきなり規模の大きいシステムについて初学者が RDRA トライすることは少ないので、「ビジネスユースケース図」や「ビジネスユースケース」の必要性が分からなくなりがちですが、規模の小さいシステムだと必要ないことが多いといった点がハマりポイントの一つです。

  • 「ビジネスユースケース」の粒度をどの程度に設定するかは難しい問題で、また、「業務」との違いを意識しつつ適切な言葉を使用して表現することも難しいです。

    業務 ≧ ビジネスユースケース > アクティビティ*4

    といった粒度の関係性を意識しておくと、ビジネスユースケースの粒度を捉えていきやすいです。

    例えば、「販売管理」といった「業務」で考えてみましょう。「販売管理」は大枠の業務で、具体的な価値を生む「ビジネスユースケース」は「見積作成」、「注文受付」、「売上計上」等です。 より具体的な作業として、「見積作成」には「見積依頼」、「見積書作成」、「見積書送付」といったアクティビティが出てきます。

    「ビジネスユースケース」レベルで整理する際に、登録、編集、削除、確認といったシステム機能を直接的に示唆するような表現を用いると、粒度が細かすぎる可能性がありますので注意してください。

今回は、ここまで。

次回は、「システム外部環境レイヤー」における「業務フロー図」、「利用シーン図」、「バリエーション・条件図」についてまとめていきます。

*1:対象となる各ダイアグラムに、とりあえずその要素を書いて配置しておくことが多いです

*2:ビジネスで価値を届ける単位

*3:ビジネスプロセス=業務フロー

*4:「アクティビティ」は、この後の業務フロー図にて登場します

RDRAで学ぶ要件定義から設計へ その1

この記事の背景

弊社のある社員の教育として、プログラミングだけでなく、要件定義から設計といった上流工程と呼ばれる領域について、一度体系的に話をした方がいいよねというシチュエーションが出てきました。

その背景として、作って貰った課題となるシステムについて、コーディングが絡む設計面については問題なかったのですが、

  • システムの全体感が捉えきれていない
  • 捉えるためのドメイン調査が足りていない
  • 業務(ビジネス)とシステムの境界があやふやに捉えて表現してしまっている
  • 業務フローの粒度がちぐはぐになっている
  • 業務の全体像が見えていないので、派生して必要になる機能が漏れてしまっている

といったような問題点があったので、これらをしっかりと身につけてもらうには、要件定義から設計を一度インプットした上で、実際に業務でイメージしながら活用・経験してもらうことで伸びていって貰おうということになりました。

要件定義から設計を一度インプットする際に、弊社でよく活用している体系だってまとまっていてライトに進めやすいので RDRA を軸にレクチャーしていくことになりました。 一つの方法を知ると、他にも応用が効くので、RDRA で学んだことは要件定義から設計をするといったプロセスにおいて活きてくるハズです。

また、どうせレクチャーするなら、自分の知見をまとめなおすということも合わせてやってしまおうということで、レクチャーしつつ、その中で出てきた要点や Tips を記事にまとめておこうという一石二鳥な連載記事になる予定です。

今回の「その1」では、RDRA とはどんなものなのかといったことと、システム価値レイヤーについて、僕が RDRA を使用している中で思っている Tips を含めて書いていこうと思います。

RDRA とは?

RDRA は、神崎善司氏が考案したリレーションシップ駆動要件分析(Relationship Driven Requirement Analysis)の略語で、「らどら」と読みます。 要件を素早く決定するために、網羅的で整合の取れた要件を組み立てられる仕組みを提供するモデルベースの要件定義手法です。

詳しくは、神崎さんの以下のホームページを見ていただくのと

http://k-method.jp/k-method.jp

こちらの神崎さんが書かれた本を読んでいただくと、より深く知れます。

RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法

この記事では、神崎さんの本から少し引用させていただきつつ、僕が RDRA を活用している際の思いやテクニックを中心に書いていきます。

要件定義では何を定義するのか

要件定義とは、名前の通り、何をシステム化するか要件を決めます。

どういったビジネスを展開していて、どういった業務の中で、どんな要求があってといったところから要求を分析して、その中からシステム化する要件を機能要件や非機能要件として、まとめていきます。

RDRA では、要件定義書といった文書化をするのではなく、モデルで要件を定義しています。 なぜ、モデルで定義していくかといった点について神崎さんの本では、

システム機能(画面、機能、データなど)のことしか書かれていない要件定義書では、具体的な仕様化ができずシステム化はうまくいきません。「なぜ」このような機能が必要なのかが書かれておらず、画面や機能を深掘りしようにも、そのための判断材料が欠けているからです。 〜 RDRA2.0 ハンドブック から引用 〜

と書かれています。

要件定義をしていく中で、どうしてそれをシステム化するのか、どうしてその機能は必要なのか、といったような要求や業務やビジネスといった背景がない状態だと、ただただその機能だけを見て開発してしまったり、書かれたことが要求からすると足りなかったりと、作ったものがあまり価値の無いものになってしまいます。

根拠があって、システム化することが大事です。

「なぜ」このような機能が必要なのかが遡れるようになっていると、その根拠を踏まえて設計やプログラミングを実施していくことができるようになり、価値があるものを作りやすくなっていきます。

RDRA では、その遡りができるように 4 つの視点で分類をしながら、システムの要件定義を捉えています。

RDRA が提供する 4 つの視点

f:id:k_takasaki:20220209230333j:plain
RDRA全体像

RDRA は、全体像に記載した通り、以下の 4 つの視点で分類しています。

  • システム価値
  • システム外部環境
  • システム境界
  • システム

「システム価値」は、

  • システムコンテキスト図
  • 要求モデル図

といったダイアグラムで、システム化することの価値を表現するレイヤーです。

システム外部環境は、

  • ビジネスコンテキスト図
  • ビジネスユースケース
  • 業務フロー図
  • 利用シーン図
  • バリエーション・条件図

といったダイアグラムで、システムがビジネスや業務の中でどのように使われるか、業務や利用シーンを考えた時にどの様な環境で使われるか、使っていく中でどのようなビジネス要素やビジネスルールが関係してくるかといったシステムを使う上での環境を表現するレイヤーです。

システム境界は、

といったダイアグラムで、システム化する単位の「(システム)ユースケース」と画面やイベント、情報と条件を組合わせることで、開発対象となる入出力、情報、条件といったものを明確に表現するレイヤーです。

システムは、

  • 情報モデル図
  • 状態モデル図

といったダイアグラムで、ビジネス上で使っている用語を構造化して情報や状態をシステム化対象として表現するレイヤーです。

このようなダイアグラムで要件を定義することで、ダイアグラムを階層化して繋がりのある形でシステムを俯瞰することができると共に、以下の様にコミュニケーションの土台ができることによる認識共有がしやすいといったメリットが生まれます。

図の利点は、打ち合わせで使いやすいことです。ダイアグラムは「作って終わり」というドキュメントとして捉えるのではなく、要件を定義するためのコミュニケーションツールと捉えることが大事です。つまり、要件定義を「ドキュメント作成作業」と考えるのではなく、「要件を可視化し、合意し、定義する作業」と捉えることです。RDRAはコミュニケーションを促進し、素早く要件を合意するための仕組みを提供しています。RDRAの目的はドキュメントを作ることではなく、コミュニケーションの土台を作ることです。 〜 RDRA2.0 ハンドブック から引用 〜

ダイアグラム表現の方法

RDRA は、

などで表現が可能となっています。

miro などのツールを活用して同様に描いていくこともできますが、これらを使って表現すると関係性を持った形でモデルやダイアグラムが管理できるので、RDRA の本質である関連性を持って要件や機能を管理することができるようになります。

根拠があって、システム化

前段で書きましたが、

「なぜ」このような機能が必要なのかが遡れるようになっていると、その根拠を踏まえて設計やプログラミングを実施していくことができるようになり、価値があるものを作りやすくなっていきます

RDRA は、この「なぜ」について、下図の様にダイアグラムやモデル要素の関連(リレーション)で遡っていくことができます。より上流で検討したものに依存している形になっています。

そのため、根拠を踏まえて機能や情報を考えていくことができるようになります。

f:id:k_takasaki:20220209231301j:plain
RDRAの「なぜ」のつながり

この様にそれぞれがつながっていくことで、

  • 要求に沿ったシステムであるか否かを確認
  • 影響度の分析や整合性、網羅性を確認できる

といったことが、RDRA ではできる様になっています。

システム価値レイヤー

システム価値レイヤーは、

  • システムコンテキスト図
  • 要求モデル図

といったダイアグラムで、システム化することの価値を表現するレイヤーです。

最上位のオーバービューになるので、この先、システムを考えていく中で、立ち返ってくる原点が表現されたものとなります。 なぜ、このシステムを作るのか、誰が関わるのか、誰がどういった要求を持っているのか、そういったことを表現していきます。

システムコンテキスト図

f:id:k_takasaki:20220210000052j:plain
システムコンテキスト図

要件定義の最初の時点でプロジェクトメンバーの認識を合わせるために作成するのが「システムコンテキスト図」 〜 RDRA2.0 ハンドブック から引用 〜

システムコンテキスト図を描くことで、システム化の目的や、システムに関わる人(アクター)や外部システムを洗い出します。

  • システムスコープを決めるための認識を合わせる
  • システム化するにあたっての判断基準となる目的を明確にする

といった効果があります。

全て洗い出すと、情報が多くなりすぎてしまうこともあるので、重要なものだけにフォーカスして上げていくものになります。

システムコンテキスト図 高崎Tips

  • アクターはロール名で上げるものだが、描いたアクターが抽象的な名称になっていたりすると、どの様な関係者か分からなくなる。そのため、その人に対する説明やコメントを残しておくと良い。そのアクターの認識合わせがずれてしまっていると、何をやっている人かがズレたまま話が進んでしまうので、具体化もしておくと共有しやすい。その際には、抽象的なロール名から、実際に担当している具体的な人物名を出したりして、顧客と認識合わせをしています。

  • 外部システムについては、どう連携させるか、していくのか、メモがあると良い。そういった連携方法が分かるとイメージもつきやすいです。

  • 外部システムってどんな機能を持っているかを把握しておかないと、後々、機能を考えていく際にも分かりにくい。外部システムを知るには、そのシステムのマニュアルやヘルプ等の説明を見ると情報を得ることができイメージもつきやすいです。どんな機能があるか分かっていると、そこから将来の連携や機能追加とかにも繋がっていくと思っています。

全体的に、色々と付加情報をつけていくことでシステムコンテキスト図を育てると、より伝わりやすいかなと思っています。もちろん、書きすぎちゃうとどの情報が重要なのか分からなくなるので、重要な情報を簡潔に記載しておくのが良いですが。

要求モデル図

f:id:k_takasaki:20220210000123j:plain
要求モデル図

プロジェクトを始める段階で要求一覧のようなものは用意されているはずです。それらの要求から重要なものを選び出し、要求の関係を整理することでシステム化の方向性を明らかにする 〜 RDRA2.0 ハンドブック から引用 〜

要求モデルを描くことで、要望レベルなのか、要求レベルなのか、要件レベルなのかといった要求レベルと、誰がその要求を持っているのかといったアクターとの関係を整理できます。

システムコンテキスト図で洗い出されたアクター(ステークホルダー)をベースに、どの様な要求を持っているかを紐付けて整理していきます。

それらを整理することで、システム化の方向性が明らかになってくるので、

  • 重要な要求の整理と実現する要件を明らかにする
  • 重要なステークホルダーの要求を把握する

といった開発するシステムにとって、重要なものは何かということが洗い出されてきます。

要求モデル図 高崎Tips

  • 話を聞いていて要求が想定された際に、すぐに追加するのではなく、深掘りして聞く。Q&A 的に深掘りしていく中で、その要求が要望なのか、要求なのか、要件なのかといったレベル感を把握したり、今欲しいのか将来で良いのかといった時期感をしっかりと把握する。そうすることで、要求の重要性が見えてくる。

  • その要求が重要なのか、システムコンテキスト図の目的に立ち返って判断する。

目的は意思決定の最上位の判断基準なので、これが定まると意思決定が早まります。複数の案があった時にも目的に一番沿ったものにすれば、判断に迷いがなくなります。従って、地味ですが目的を決めることはとても重要なことです 〜 RDRA2.0 ハンドブック から引用 〜

といった様に、システムコンテキスト図の目的があることで、要求を整理して、やるべきことを判断する際の指針となっていきます。

  • 将来的に追加するものも情報を残しておく(諸説あり)

この話を考えた時に、RDRA の産みの親である神崎さんや、深く使用されている増田さんらとも Twitter で議論になったので、そのスレッドトップを掲載しておきます。

今回は、ここまで。

次回は、「システム外部環境」についてまとめていこうと思います。

*1:詳しくは、 要件定義の散歩道 - RDRAにビジネスルールを盛り込むためにxTextやドローツールを試してみたが、PowerPoi... を参照ください。ダウンロード先は、RDRA2.0 ハンドブックに記載されています

*2:詳しくは、 Enterprise ArchitectでRDRA 2.0を利用する - UML/SysML/BPMNモデリングツール Enterprise Architect を参照ください

*3:神崎さんが絶賛開発中なので、そのうち公開されてくるのではないかと思います

匠Methodでクリスマスプレゼントを考えてみた

この記事は、匠塾 Advent Calendar 2021 の24日目の記事です。

adventar.org

はじめに

この物語は、匠Method という方法論を活用して、2021 年のクリスマスに向けて戦った男の物語である。

匠Method は、匠BusinessPlace の萩本さんが創られた

価値から戦略・業務をデザインする

ことをビジネス企画やプロジェクトデザイン、システムデザインやキャリアデザインと幅広く様々な企画やデザインの領域で適用することができる方法論です。

思考法でもあるため、匠Method の普段使いといった言葉もあるとおり、日常生活の中で活用していくこともできます。

f:id:k_takasaki:20211221225238p:plain
匠Methodの適用領域

今回は、この匠の普段使いとして、【家庭内プロジェクト】を行った流れを赤裸々に記載することで、匠Method でどの様に考え、どの様にサイクルを回して洗練していったかというビジネスで匠Methodを活用する際にも活きてくる記事になればと思っています。

なぜ、クリスマスプレゼント?

11月11日(木)は、第二木曜日である。

第二木曜日は、匠塾*1 の開催日である。

開催後には、ふりかえりも兼ねて懇親会を実施することが多いのですが、そこで12月の匠塾の内容をどうするかといった話になりました。 例年、12月はイベントとして LT大会(以下、参考)を実施するというのが恒例だったのですが、昨今の世の中情勢から、なかなかやり難い状況になっています。

it-takumi.connpass.com

そんな中、今年はアドベントカレンダーをやってみよう!という話にその場で決まりました。*2

さっそく、その場で作成したカレンダーに日付を設定。とりあえず、24日に設定したまではいいが何を書くかは考えてなかったので、日付的にもクリスマスに絡めれたらいいな〜ぐらいなところから、この記事は始まりました。

匠Methodでクリスマスプレゼント

11月12日(金)

さて、勢いに乗って24日に設定したはいいが何を書くかまったく考えていなかったので、何を記事にしようかということをボンヤリと考え始めました。その際もやはり、匠Method の普段使いです。

プレゼンテーションや記事を考える時にも、もちろん匠Methodを使って考えていくことができます。詳しい進め方については、以前記事にした以下の匠Presentation を読んでいただくとやり方含めて分かるかなと思います。

actier-coo.hatenablog.com

で、ボンヤリと考えていく中で、頭の中では価値デザインモデルを描いていきます。きっと、他の人がアドベントカレンダーで真面目な話をしてくれるであろうから、ちょっと柔らかい感じの内容にしようといったところから、コンセプト①を導き出していきました。それをどうしたら面白く伝わるかなと考え、コンセプト②が導き出され、外向きのコンセプト*3だけでなく内向きのコンセプト*4も入れようと思い、コンセプト③が出てきました。

f:id:k_takasaki:20211223143226p:plain
記事の価値デザイン

価値デザインモデル としては他にも要素(言葉、デザイン、意味、ストーリー)はあるのですが、思考法として使う時はこの辺りまでを頭の中で考え、ささっと価値をデザインすることが多いです。で、本来であれば価値分析モデルをこのあと考えて、価値の検証を行うのですが、この記事に興味を持つ人であれば、まあ楽しんで貰えるだろうと思い、考えることすらもスキップしましたw

11月18日(木)

さて、ブログとしてどんな記事を書こうかということは決まった所から、ボンヤリと頭の中でクリスマスに何しようか検討していきました。 ちょうど、その頃、妻と喧嘩をしていたという状況だったのもあり、何らかご機嫌取りw含めて考えていたところ、クリスマスプレゼントを送るのがいいんじゃないかと思いました。 昔は夫婦でプレゼントしあっていたりもしたのですが、結婚してかなり経つと、そういった風習もあんまりなくなっていたというのもあって。

で、何となくイメージされてきたので初期のモデルを考えてみます。*5

まずは、どういったことをしていくかといったシーズを考える価値デザインモデルを検討します。

ビジョンとしては、プレゼントを送ることによって夫婦円満になることを掲げました。 最近、コロナ禍の影響で家の中に籠っていることが多く、代わり映えのしない日々が続いています。なので、何かいつもと違うことができたらいいなというのがコンセプト①。 コンセプト②は、そりゃ欲しいものをあげるのがいいだろうということで、コンセプト③は、コンセプト①にちょっと近いところもありますが、サプライズでビックリさせると僕も楽しいといったところで上がってきました。 *6

f:id:k_takasaki:20211224093410p:plain
初期の価値デザインモデル

シーズとなる価値デザインモデルができたところで、今度はニーズを検証するために、価値分析モデルを書いていきます。 匠Method は、シーズとニーズがぶつかり合わさったところに価値が生まれるといった考え方です。

価値分析モデルには、価値記述として、

「(どの様な背景の中で、)どの様な仕組みにより、どう嬉しいか」

といったフォーマットで書いていきます。*7

f:id:k_takasaki:20211224182003p:plain
価値分析モデルを活用して価値を検証

まあ、夫婦間で特別な日にプレゼントをするということは価値があるに決まっているので、「〇〇をもらえて嬉しい」という中での仕組みの部分*8をどうするかがポイント*9になってきます。この仕組みが無いと、後々、要求分析ツリーを書いていく際*10にも、どのような手段で実現していくかといったところが見えてこないこともあり、全体的なモデルとしても重要な部分となります。

今回、この仕組みの部分の候補として、

  • どこかに連れていくのがいいかな
  • お気に入りの食べ物とかがいいかな
  • 何か最近欲しいものないかな
  • 日々の家事とか大変だから1日全部やってあげたりするのがいいかな

あたりをボンヤリと候補にならないかなと考えていました。

11月20日(土)

この日は、妻と横浜におでかけ。 時間を潰す必要があったので、久しぶりにウィンドウショッピングをすることに。

これは、仕組みの部分について何か欲しいものは無いかヒアリングするチャンスです。

ということで、ふらふらとウィンドウショッピングしている中で、これ良さそうじゃない?とか美味しそうじゃない?とか色々と聞いてみました。 この辺の意図を持ってヒアリングする様な能力は、要件定義などの仕事の中で磨かれた能力だし、こういった普段使いでも共通した能力になってきます。

で、ヒアリングをしていて改めて気づいたのですが、うちの妻は、物欲がほとんどなかった。。。 プレゼントを考える上では、非常に難易度が上がります。

靴が欲しいといった話が出てきましたが、靴は履いたときの感じやサイズのフィット感などサプライズプレゼントには向きません。

さらにウィンドウショッピングを続けていくと、子供達や僕が喜びそうな物ばかりを見に行っていることに気がつきました。 うちの妻は、他者が喜んでくれるのが嬉しいんだなということに改めて気づかされます。

そのヒアリングとウィンドウショッピングの状況を踏まえて、価値デザインモデルと、価値分析モデルを見直ししていきます。 この辺り、普段使いじゃないビジネスで使う時でも同じ様なことをして価値を洗練化していくになります。

f:id:k_takasaki:20211224122656p:plain
見直した価値デザインモデル

見直した価値デザインモデルは、下線を引いたあたりを変更しており、ビジョンが夫婦だけでなく家庭に広がり、それに伴ってコンセプトも本人が喜ぶだけでなく家族が喜ぶことを狙っていくこととしました。

f:id:k_takasaki:20211224182108p:plain
見直した価値分析モデルと価値デザインモデル

価値分析モデルの方には、ステークホルダーとして娘たちを追加。 娘たちの価値記述も、「○○で妻と一緒に楽しめて嬉しい」といったものを見い出しました。

となると、あとは〇〇の部分に当てはまる何か物なのか、食べ物なのか、体験なのかを考えないとなーといった感じでした。

11月27日(土)

妻と娘たちと近くのイオンで買い物に出かけました。 イオンの中に整骨院があったりと、ちょいちょい利用するところです。

娘が本屋に行きたいというので、本屋に来ていたのですが、パズルコーナーがありました。 本屋でパズル売っているんだーと物珍しさから見ていたのですが、妻がふと

「子供の頃、パズル好きだったんだ」

という話をし始めました。 そういえば昔聞いたことあったけど、家にパズルはないのであんまり意識したことがありませんでした。

色々なパズルがあったので、娘たちもパズルの絵柄を色々と見ながら楽しんでいます。

これだ!

最後のピースがハマった気がしました。 仕組みの部分に「パズル」を当てはめることで、子供の頃を懐かしみながら楽しめるプレゼントになる。 娘たちも一緒に作っていくことで、家族みんなで楽しめる。

冬休みを活用して、非日常的な共同作業をみんなで楽しみながらできるなと。

そして、できたモデルが以下です。

f:id:k_takasaki:20211224182214p:plain
最終形のモデル

12月11日(土)

あとは、どうこっそり買うか。 気付いた日には買えないので、機会を伺っていたのですが、この日に一人でイオンの中にある整骨院に行ったのでチャンス到来。

サプライズに向けて購入しようとしたんですが、フレームがでかい。。。 これは買えない・・・ということで、パズルだけを購入。フレームは25日の朝着で Amazon で購入することとしました。

12月24日(金)というまとめ

ここまでで、匠Method をどう普段使いするかということを追体験いただけたのではないかと思います。

匠Method を思考法として活用することで、価値デザインモデルと、価値分析モデルを活用することでフレームワークの様に当てはめながら、価値を求めて思考整理していくことができます。 今回は、プレゼントを考えるぐらいのあまり大きな話ではなかったので、価値デザインモデルと、価値分析モデルだけを活用していますが、もっと大きな話で目的と手段を連鎖させて複数の手段によって実現するようなことを考えるときは、このあと要求分析ツリーも考えていくと、より精緻な思考を深めていくこともできます。 その辺りも含めて興味を持った人は、ぜひ匠Method を一緒に学んでみましょう!

普段使いで匠Method を使いこなせる様になると、ビジネスで使っていく際にもこなれた技として活用していける様になります。

おまけ

さて、このあと、本日の夜にサプライズプレゼントしますが匠Method のモデルで描いた価値は正しかったのかどうか??

価値があると妻や娘たちに感じてもらって、喜んでもらえることを、皆さんも祈っておいてもらえればと思います!

*1: 匠塾は、匠Method を学べる勉強会。紹介制の勉強会ですが、この記事を読んで参加してみたいと思われた方は「塾長の記事を読んで」って参加希望出してみてください

*2:紆余曲折あったが、 ユニクロを匠Methodでリバースエンジニアリング - ゆるゆるメモ の作者からいいアイデアとして出た。そこに至るまで、やはり匠Methodでモデリングして企画を考えたり等々と色々としていた

*3:周りの人が価値を感じるコンセプト

*4:自分やプロジェクトであればプロジェクトチームなど内部の人が価値を感じるコンセプト

*5:詳しい匠Methodのモデリング方法を知りたい方は、本や他の人のブログを読んでいただくか、匠塾へ遊びにきていただければと。僕もそのうち記事書こうかしらとは思っています

*6:例によって、言葉や意味、デザイン、ストーリーなどは、自分の思考レベルでやるときは何となく思い浮かんでいること、他者に明確に伝えなくてもいいことからスキップしています

*7:あと、目的を書いて紐付けといった辺りの話もありますが、詳細は匠Methodの書き方を見てください

*8:「〇〇をもらえて」の部分

*9:場合によっては、背景の部分もしっかり考えます

*10:今回の思考レベルの匠Methodでは書いていませんが

匠Presentation 〜匠Methodを活用して価値あるプレゼンテーションを〜

f:id:k_takasaki:20180610221333j:plain

このブログでも以前に

個人ブログはじめました 〜情報発信の大切さ - Actier COO(くぅ〜)なブログ

記録に残るか?記憶に残るか? 〜BPStudy #124 で高崎健太郎愛あふれる LT 登板をした際の発表アイデアの練り方 - Actier COO(くぅ〜)なブログ

といった記事で、発表をすることでの学びや気付きの大切さ、発表アイデアの練り方について書きました。

今回は、発表=プレゼンテーションする際に欠かせない【準備】に匠Method という方法論を活用することで、価値あるプレゼンテーションを作りやすいと僕が提唱している匠Presentation についてお話したい*1と思います。

匠Method とは?

匠Method は、匠BusinessPlace萩本さんが創られた

価値から戦略・業務をデザインする

ことをビジネス企画やプロジェクトデザイン、システムデザインやキャリアデザインと幅広く様々な企画やデザインの領域で適用することができる方法論です。

ステークホルダモデル、価値分析モデル、価値デザインモデル、要求分析ツリーといった様な様々な各モデルを描いていくことで、価値から戦略・業務、そして活動へと繋がっていきます。
匠Method の詳細をキャッチアップされたい方は、以下の書籍を読んで頂くのが今だと一番早道かと思います。 

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

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

 
ビジネス価値を創出する「匠Method」活用法

ビジネス価値を創出する「匠Method」活用法

 

匠Presentation

匠Presentation は、その匠Method の主要となる 4 つのモデルを活用してプレゼンテーションの内容をまとめる術です。そのプレゼンテーションで提供する価値から、プレゼンテーションの内容に繋がる形でまとまるので、価値あるプレゼンテーションが構成されていきます。

f:id:k_takasaki:20180613013716j:plain

いいプレゼンテーションの三要素

ここで匠Presentation について説明していく前に、そもそもいいプレゼンテーションってどういったものかといった所を振り返って(僕の考えを展開して)おきたいと思います。

f:id:k_takasaki:20180613111328j:plain

いいプレゼンテーションを実施するためには、この三要素が必要だと思っています。

  • 内容
  • テクニック 
  • 準備

まず、内容が良くないといいプレゼンテーションにならないのは当然のことですね。ただ、内容が良かったとしても、それを伝える・表現するためのテクニックがない状況になってしまうと、やはりそのプレゼンテーションは見ていて面白くないものとなってしまうので片手落ちな感じになってしまいます。

それぞれを良くするために、内容を練り込んだり、テクニックを練習して磨いたりといったことを考えると、準備がそれらを下支えすることになります。

皆様も実際にプレゼンテーションを見ている際に、「このプレゼンは、すごい準備しているなあ」と思うようなプレゼンテーションは大概いいプレゼンテーションだったということを経験されているのではないかと思います。

テクニックについて

プレゼンテーションと言えば、TED*2 をご存知の方が多いかと思います。
TED のプレゼンテーションは、内容もさることながら高度な魅せるテクニックを持っている方がプレゼンテーションを実施されているので見ているだけでも勉強になります。

そんな中、内容が面白い上に、いかに魅せるテクニックが大事かということを実践しているプレゼンテーションがあるので、こちらを御覧ください。

www.youtube.com

これ、面白いですよね。
これはテクニック だけで乗り切っている様にも思われますが、おそらくこのプレゼンテーションを作り上げるために内容を相当練り込み、準備をされた上で、この完成度になっているものと思われます。*3

でも、やっぱりテクニックも大事だということを裏付けていますよね。

三要素をまとめて学べるオススメ

テクニックだけじゃなく、内容の作り方、準備の進め方含めて学べる僕のオススメ本がこちらです。

ガー・レイノルズ シンプルプレゼン

ガー・レイノルズ シンプルプレゼン

 

有名な本なので、ご存知の方も多いかと思いますが、このガー・レイノルズさんが プレゼンテーションZEN といったプレゼンテーションの方法をまとめられています。その中でも、この本がまずはエッセンスとして捉えたいという方にオススメです。DVD もついているので、実際のプレゼンテーションイメージも見ることができますし。

なので、この本および何冊か出ているプレゼンテーションZEN 関連の本を読んで頂くとプレゼンテーションの三要素をマスターすることができるのではないかと思います。

じゃ、匠Presentation は?

じゃ、プレゼンテーションZEN 読んだら、この記事の匠Presentation 要らないんじゃない?といった疑問を持たれたんじゃないかなと思います。

ひょっとしたらそうなのかもwですが、ここで振り返って考えたいのが、内容(中身)はやはり自分で何を話すか考えないといけないので、コンテンツを決めるのはプレゼンテーションを実施するあなた自身ということになります。
その際に、思考の整理をするためのフレームワークとして、匠Presentation を活用できるようになっていると、整理がついて価値を描いたプレゼンテーションを実施できるようになるのではというのが、この記事の主旨です。

f:id:k_takasaki:20180613114834j:plain

ちょうど位置関係図的な感じで考えると、こんな感じになるのかなと。

匠Presentation のやり方

匠Presentation でやりたいことを俯瞰してまとめたのが、こちらの図です。

f:id:k_takasaki:20180613115151j:plain

匠Method での主要となる 4 つのモデルを活用してまとめることで、プレゼンテーションで伝える【価値】を明確にして、それを実際の内容に繋げていくといった形で整理していきます。

ここからは、実際に僕が匠Presentation を使って内容を決めて実施したプレゼンテーションを元に見ていきたいと思います。

匠塾*4という匠Method を学べる勉強会にて、LT 大会を実施した際のプレゼンテーションです。

実際のプレゼンテーションスライドがこちらなので、あわせて見て頂けると、この後の話が分かりやすいのではないかと思います。

種となるようなアイデア(価値のもと)を探す

まず、プレゼンテーションの価値を考えるにあたって、モヤモヤと色々発散しながら発表内容の種となるようなアイデアを考えます。*5

この種となるようなアイデアを考える際には、匠Method はあまり使いません。フレームワークという型に当てはめずに、まずは発散して考えたいからです。発散して考える際に、僕はマインドマップを使っています。発散させつつ、少しずつ関係性に基づいてまとめたいためです。この作業をやっている時に匠Method のモデルは使ってはいないのですが、匠Method の方法論が身に付いていると思考のフレームワークとして暗黙的に匠Method のモデルにまとめやすい感じで考えていたりします。

この LT の時はマインドマップを書かなかったんですが、30 分ぐらいの発表をした際のマインドマップは、こんな感じです。

f:id:k_takasaki:20180613142653j:plain

こうして発散させていく中で、種となるようなアイデアを見つけ出していきます。その種となるようなアイデアを軸にマインドマップを軽く整理していく感じで、この後、実際に匠Method のモデルを活用しながらまとめていきます。

価値デザインモデルで価値を描く

匠Presentation で特に重要な価値デザインモデルを使用して、まとめを始めていきます。プレゼンテーションを実施する際には、何か発表したいことがある=シーズがあるという状態から始まるかと思います。

匠Method では、シーズとニーズをぶつける中で価値を検証し、価値を描いていくといった方法論になっています。

匠Method で、このシーズから価値をデザインしていくモデルが【価値デザインモデル】というモデルなので、ここからまとめ始めるのが理にかなっています。
プレゼンターのシーズから、聴衆のニーズへの価値を描いていくことになります。

f:id:k_takasaki:20180613144612j:plain

この価値デザインモデルの中で、上記の様に価値として提供するものは何か、その価値を言葉やイメージで感性に訴えかけるものは何か、深層心理に訴えかけるものは何かといった点を先程発散したマインドマップを軸にまとめていきます。そうすることで、プレゼンテーションの中で提供する価値は何なのかといった所が明確になっていきます。

その中で、何を価値として提供するかと共にプレゼンテーションにはストーリー性が大事になってくるので、価値デザインモデルのストーリーの部分が有効に働いてきます。

実際にできあがった価値デザインモデルは、以下のような感じになります。

f:id:k_takasaki:20180613232703j:plain

価値デザインモデルでは、ビジョンとそれを下支えする 3 つのコンセプトは何か、それを言葉やデザインといった表層的なもので表すとどんな内容か、深層的なものである意味やストーリーで表すとどんな内容かといった形で、提供する価値をまとめていきます。

こうしてまとめることで、プレゼンテーションの価値として何を提供するかが見えてくることになります。

価値分析モデルで価値を検証する

シーズとして提供する価値が何かといったことが見えてきた所で、そのシーズは本当に必要とされているかという所が出てきます。匠Method は、それを検証する方法として価値分析モデルというニーズサイドのモデルをまとめていきます。
ニーズ側をまとめることで、先程のシーズ側である価値デザインモデルとぶつけることで、本当に価値がありそうかということを検証することになります。

匠Presentation でも同様に、プレゼンテーションで伝えようとしていることが聴衆のニーズにとって価値があるかどうかといったことを検証することになります。

ステークホルダモデルというものを描いて関係者を洗い出すのですが、匠Presentation では聴衆のカテゴリはそんなに多くなることは無いことが多いので、ステークホルダを価値分析モデルの中で抽出していきます。
その後、それぞれのステークホルダがどの様なニーズ(期待)を持ってプレゼンテーションを聴きにきているかを考え、それぞれどういった価値が生まれてくるから嬉しいといった形で価値を描いていきます。

f:id:k_takasaki:20180614012203j:plain

結果、上記のような各ステークホルダーの価値(嬉しいこと)が洗い出されてくるので、今回のプレゼンテーションで提供しようとする目的を別途洗い出して、その目的と価値がどの様に結びつくか、上記の様に色分けしながら関係性を洗い出していきます。

要求分析ツリーで価値から内容へ

価値デザインモデルと価値分析モデルを描くことで、シーズ側とニーズ側のイメージが固まってくることになります。それらをぶつけて、シーズがニーズを満足させるかといったことを検証したり、ニーズを満たすためにシーズとして何を提供するかといったことを検討していくのが要求分析ツリーという匠Method のモデルになります。
このモデルで、シーズとニーズをぶつけながら価値を検証し、そこから更に価値を提供するためにどの様な活動を実施していくべきかという戦略から戦術、実際の活動へと広げていくのが要求分析ツリーの役割となります。

匠Presentation では、価値を検証した上で、プレゼンテーションの中に何を盛り込んでいくかといった内容に落とし込んでいくといったことになります。

f:id:k_takasaki:20180614013143j:plain

戦略要求と呼ばれる大方針的な所に、価値デザインモデルのビジョンとコンセプトを並べ、そこに価値分析モデルの提供する際の目的を結びつけ、そこから各解決策としての活動や内容を結びつけながら、価値から活動や内容へと落とし込んでいくモデルを描きます。
シーズとして提供しようとしている価値と、ニーズとして求められる価値が合わない時は、このモデルでの繋がりに違和感が出てくるので、シーズとして提供するものを変えるか、そもそもニーズは想定しているものであっているのかといったことを、それぞれ価値デザインモデルと価値分析モデルに立ち返って考えていきます。

そうして、このモデルや立ち返った価値デザインモデルと価値分析モデルがいい感じにできあがった時には、提供する価値が検証された形で、その価値からどの様に活動や内容を実施すればよいかということがまとめられた形になります。

匠Presentation の流れ振り返り

上記の通り、匠Presentation として価値あるプレゼンテーションをどう提供するかということを再度考えると、

f:id:k_takasaki:20180614013914j:plain

 価値デザインモデルで価値を描き、

f:id:k_takasaki:20180614014002j:plain

価値分析モデルで価値を検証し、

f:id:k_takasaki:20180614014035j:plain

要求分析ツリーで価値から内容へと繋いでいくといった流れで、プレゼンテーションの内容を固めていくことで、価値あるプレゼンテーションを提供できるということになります。

まとめ

プレゼンテーションをする機会というのは、何も LT で発表するとか登壇するといった機会だけでなく、日々の報告や提案、はたまた告白や小遣いアップなど日常の中でもあるかと思います。

そういった際に、内容とテクニックと準備が揃ったいいプレゼンテーションのための三要素を下支えする考え方として、匠Presentation を活用すると価値から内容へと繋がったプレゼンテーションになるという話でした。

で、そんな僕も今日(2018年6月14日)

it-takumi.connpass.com

というイベントで LT をする予定なので、匠Presentation で LT 内容をまとめて挑みたいと思います。
ご興味を持った方は、上記イベントおよびその後の匠塾に遊びに来て頂けると、匠Method を含めて勉強できるかと思います。

*1:サクッと確認されたい方は、プレゼンテーションの魂 -匠Method で価値あるプレゼン- こちらのプレゼン資料を見て頂くだけでも要点は掴めるかと思います。

*2:ご存知無い方は、TED (カンファレンス) - Wikipedia をご確認ください。TED: Ideas worth spreading などで動画として、いいプレゼンテーションを見て頂くことができます。

*3:このプレゼンテーションを匠Presentation で分析してみたものを僕が発表したプレゼン資料として近日中にアップしようと思っています

*4:僕が塾長を務めていて、執行部メンバーと共に運営している匠Method を広く学べる場です。紹介制のコミュニティで、毎月第 2 木曜日を基本の開催日として実施しています。

*5:この辺りの発表内容をボンヤリ考えている所は、以前に書いた 記録に残るか?記憶に残るか? 〜BPStudy #124 で高崎健太郎愛あふれる LT 登板をした際の発表アイデアの練り方 - Actier COO(くぅ〜)なブログ♪ を参照いただくか、別途アップ予定の匠Presentation を実践した際のスライドを参照いただけると、取っ掛かりとなるアイデアを考える際にどんなことを考えているかを掴んで頂けるかと思います。

ドラマ『陸王』で読み解く「ビジネスモデル症候群」

f:id:k_takasaki:20180211172205p:plain

少し前に、

actier-coo.hatenablog.com

といったブログ記事を書いて反響があったので、今度はドラマ『陸王』を見ていた際に感じた書籍「ビジネスモデル症候群」に通じる話を記事にしました。
今回はビジネスモデル症候群に陥りきらなかった主人公である経営者 宮沢紘一(役所広司)の姿から、書籍「ビジネスモデル症候群」の読み解きをしていきたいと思います。

皆さん、ドラマ『陸王』見ましたか?
非常に熱いドラマで、起業や経営に興味がある方は、そこに今回ご紹介するような色々な学びがありますので、ぜひ見て頂くといいのではないかと思います。

www.tbs.co.jp

この先、このブログの内容は TBS のドラマ『陸王』のネタバレを含んでいるので、まだ見てなくて見るぞという方は、ドラマ『陸王』を見てから、この先に進むようにしてください。

陸王 | 動画配信のTBSオンデマンド

で、有料ですが全話見ることができるようです。

陸王 -ディレクターズカット版- Blu-ray BOX

陸王 -ディレクターズカット版- Blu-ray BOX

 

Blu-ray と DVD でも BOX が発売されています。

ビジネスモデル症候群とは?

書籍「ビジネスモデル症候群」ですが、Lean Startup Japan LLC の和波さんが書かれた
ビジネスモデル(アイディア)があるから失敗するという、今までの常識の逆を解説した書籍です。

ビジネスモデル症候群 ~なぜ、スタートアップの失敗は繰り返されるのか?

ビジネスモデル症候群 ~なぜ、スタートアップの失敗は繰り返されるのか?

 

って、この辺りは、前回書いているので、そちらを参照するか、まだ読まれてない方は書籍を読んで頂くのがいいのではないかと思います。

ドラマ『陸王』最終回に書籍「ビジネスモデル症候群」が目指す経営者の姿を見た - Actier COO(くぅ〜)なブログ♪

また、ここから先の章タイトルは特に伝えたいと思った内容に近いタイトルを書籍「ビジネスモデル症候群」の章タイトルから引用してきましたので、気になった方は、そこを更に読んで頂くと伝わりやすいのではないかと思います。

ビジネスモデル症候群からの脱却

書籍では、「ビジネスモデルがあるが故に、そのアイディアに縛られてしまって、立ち直れない失敗へとの道を進んでいってしまう」この状態を『ビジネスモデル症候群』と読んでおり、では、その対策としてどうするべきなのか、どう脱却していくかといったことが第 3 章から解説されています。

「確証バイアス」「ヒューリスティック」「手段の目的化」に対処する

直感的に思いついたアイディア(ヒューリスティック)を信じ込み、アイディアへの賛同者が増えて集団化すると、どんどん視野が狭くなり(バイアス)、やがてなんのために起業したのかがわからなくなる(手段の目的化)ーーこの一連の流れは、必ずセットで対策を打つべきです。起業において、ほとんどのひとが例外なく陥る典型的なこの失敗パターンは、しっかりと原因を理解して、対策を実践してください。

【書籍「ビジネスモデル症候群」P.127 より引用】

と、対策についての書き出しは上記のように始まっています。
この一文が、ビジネスモデル症候群へと陥るメカニズムを的確に表わしています。

  1. 直感的に思いついたアイディアは真実である可能性が低い
  2. アイディアが仮に間違っていたとしても環境によって、それを疑うことが無くなっていく
  3. アイディアで思いついた 1 つの手段に捕われてしまい、課題に対する複数の解決策を見れなくなる
  4. アイディアに固執したスパイラルが生まれた結果、アイディアよりも経営が続かなくなる

なぜ、こういったメカニズムとなっていってしまうのかについての詳細は、書籍を読んで頂くとよく分かります。

実際、『陸王』の第 1 話のあらすじを読んでみると

埼玉県行田市にある足袋製造会社「こはぜ屋」。その四代目社長・宮沢紘一(役所広司は、年々先細る足袋の需要から今日も資金繰りに頭を悩ませていた。 そんなある日、メインバンクである埼玉中央銀行へ、追加融資の相談に訪れた宮沢。なんとか今回の稟議は受け付けてもらえたが、融資担当の坂本(風間俊介から、新規事業に踏み出してみてはどうかと提案をされる。
突飛な話だったためその場は軽く応えた宮沢だったが、「こはぜ屋」の存続がかかっているテーマだけに、真剣に考えはじめると、ほどなく、あるきっかけで新規事業について閃く。それは、足袋製造会社としてこれまで培った技術が活かせる“裸足感覚”を追及したランニングシューズの開発だった。

といった内容なので、『陸王』も「"裸足感覚"を追求したランニングシューズ」というめっちゃアイディアから始まってしまっていますw
普通だと、ビジネスモデル症候群まっしぐらです。

残念ながら、ビジネスモデル症候群から脱却することは永久にできないと思います。いまだに私自身も、ふとアイディアが浮かんだ際には「やった!」と思ってしまいますから、正確には「脱却」はできません。しかし、しっかりと対策を打っておくことによって「ビジネスモデル症候群による悪影響」からは脱却することができます。要するに、何度、ビジネスモデル症候群に陥ったとしても、必ずそのことに気づくことができる、ふりかえりの仕組みを持っておけばいいのです。

【書籍「ビジネスモデル症候群」P.125 より引用】

書籍でも、アイディアから始まってしまうことからの完全な「脱却」は難しいと書かれています。やはり、これはいいと思ったもの(アイディア)からスタートすることは多いと僕も思います。ですが、ビジネスモデル症候群への対策がなされていることで、アイディアに固執しすぎない形で進めていくことができる様になるハズで、『陸王』もその展開になったと思っています。

その閃いたランニングシューズの開発といったアイディアから始まって、ちょっとうまく行ったら進むべき道を見誤りかけたり、素材や機械の問題でランニングシューズの開発継続が難しくなったり、資金調達がうまく行かなかったりと様々な困難がやってきます。その中で、宮沢紘一(役所広司)は苦悩し葛藤する訳ですが、ビジネスモデル症候群に陥りきらなかった結果、イノベーションへの道が開かれかけた感じで終わります。それは狙って対策をした訳ではなさそう*1ですが、改めて分析してみるとビジネスモデル症候群への対策が行われていた結果、そうなったのではといったストーリーになっています。

アイディアを探そうとするのではなく、問題を理解する

「問題を正しく理解する前に答えを出そうとしてしまうから」

【書籍「ビジネスモデル症候群」P.136 より引用】

ビジネスモデル症候群に陥って失敗する要素として、ニーズのない問題に対してビジネスをしようとして失敗するといった要素があります。

解決策はコレでいけるんじゃないかということを思いつくと、その問題の本質を捉えていない状態で取り組んでしまうといった傾向が、人としては多かれ少なかれあると思います。それでは、実際には必要とされない、方向性がズレたものを提供してしまう可能性があります。ニーズからズレたものを提供してしまうと使われることは無いので、ズレたアイディア(解決策)ではなく、何が問題なのかを正しく理解して解決策を出さなければなりません。

きちんと問題を捉えるためには、その領域にしっかりと踏み込んで、そこで何が起こっているのか、どんな問題があるのか、どんな状況なのかといったことを捉える必要があります。

陸王』でも、宮沢紘一(役所広司)はランニングやマラソンを知らない素人から始まります。その中で、スポーツ用品店の店主でランニングインストラクターの資格を持つ有村融(光石研)から話を聞いたりと、段々とその領域に入り込んでいきます。
実業団に作った靴を持っていた際も、「素人が作った靴を履かせられるか」といった感じで監督に拒否をされていました。足繁く通ったり、それぞれの選手の特性や戦績を把握したりとしていく中で、その業界の一人者であるカリスマシューフィッターや監督の心を動かして、選手に靴を履いて貰えるといった所にこぎつけます。

故障した選手が再度故障してしまうようなことが無いように体に負荷がかかりにくい走法が必要という問題に対して、ミッドフット走法が身体や筋肉への負荷が低い、そのミッドフット走法を自然と行うことができる足袋型のランニングシューズという問題を捉えた解決策を提供できたことが、結果として陸王の成功に繋がったのだと思います。

直感的なアイディアで単純に勝負するのではなく、ニーズを捉えたビジネスをするためには、

  • その領域に入り込み知識を得る
  • 知識を得ていく過程で、その領域のスペシャリストの信頼を得る
  • スペシャリストの助言とかも含めて問題の本質が見えてくる
  • 問題の本質にアプローチする解決策を考える

といった流れで、取り組んでいくことが成功に繋がっていくと思います。

よいメンターを手に入れよう

ビジネスモデルやアイディアに固執しそうになったり、進めていく中で間違った道に進みそうになっていたとしても、客観的に見てくれ伴走してくれるメンターがいると、バイアスやヒューリスティックの罠に陥りにくくになります。

書籍「ビジネスモデル症候群」でも

  • 「成功の後押し」ではなく「大失敗させないためのアドバイス」をしてくれる人
  • 課題の当事者

といったよいメンターになりうる可能性があるタイプについて、2 つのポイントが紹介されています。

陸王』でも、宮沢紘一(役所広司)を支えるよいメンター役となっている人達がいます。最終回で息子である宮沢大地(山崎賢人)の面接シーンで、言葉としてそれぞれのメンターが表現されています。

正直申しまして、最初は足袋屋がランニングシューズを作るなんて夢物語だと思いました。
でも、一つ壁にぶつかるたびに親父の・・・あ、すいません
父の陸王にかける想いに賛同してくれた人達が、力を貸してくれたんです。

時に厳しく、時には自分のこと以上に親身になってこはぜ屋の将来を思ってくれた銀行員、
シルクレイというすごい素材を開発して、それをうちに使わせてくれた特許の持ち主、
大手のアトランティスを辞めて、こはぜ屋に来てくれたカリスマシューフィッター、
そしてなにより、うちを信じて陸王を履いてくれた茂木選手。
他にも沢山の人がうちに力を貸してくれました。
その誰一人欠けても、陸王は完成することはできなかったと思います。

大失敗をさせないためのアドバイスをしてくれた筆頭格といえば、時に厳しく、時には自分のこと以上に親身になった坂本太郎風間俊介)です。先程の第 1 話あらすじの通り、彼がいなければランニングシューズ陸王は生まれることは無かったし、課題の当事者に引き合わせてくれたり、資金繰りや煮詰まったときにアドバイスをくれたのは彼でした。的確なタイミングで「大失敗させないためのアドバイス」をしてくれていました。また、最初は憎まれ役だった銀行員の人達も要所要所で支えてくれるプチメンターの様な存在でした。シルクレイを提供してくれた飯山晴之(寺尾聰)も、特許と技術を提供してくれただけでなく、一度失敗した経営者として感じた心得のようなものを教えてくれるメンターをしていました。

課題の当事者といえば、カリスマシューフィッター村野尊彦(市川右團次)がランニングシューズのスペシャリストとして支えてくれましたし、故障して復帰を目指す茂木裕人(竹内涼真)が取組むべき課題の当事者や体験者およびエバンジェリストとして陸王を支えてくれました。
また、彼らに会わせてくれたスポーツ用品店の店主でランニングインストラクターの資格を持つ有村融(光石研)も課題の当事者であり、物語全体を通して重要なメンター役でした。

宮沢紘一(役所広司)が問題に真剣に取り組んだことで、彼らの信頼を得て、その適切なアドバイスを咀嚼し有効に活かせたことで、陸王は成功に近づいていきました。

やりたいこと・できること・求められること

f:id:k_takasaki:20180212194820p:plain

起業を考えるひとの頭のなかには、当然、自分が「やりたいこと」があります。
<中略>
また、創業者が「やりたい」と思っていても、じつはそれを「できない」という不一致も生まれます。
<中略>
最も重要なのは、「やりたいし、できること」があったとしても、それがマーケットから「求められる」ことでないと、やはりビジネスは成功しないことです。

【書籍「ビジネスモデル症候群」P.175 〜 176 より引用】

アイディアから始めるとビジネスモデル症候群になりやすいということに対して、「では、アイディアなしでどうするのか?」といった疑問が、この本を読むと出てくるかと思います。
僕は、この本を読む中と和波さんと話している中での解として、この P.177 に出てくる図が解だと思っています。パッと出のアイディアに固執するのではなく、やりたいことを見つけ、できることを増やし、求められることとマッチさせるということが成功に近づいていく一つの道だと思います。

陸王』で考えてみると、

  • やりたいこと
    →"裸足感覚"を追求したランニングシューズの開発から始まり、選手のサポート。そして世界一のランニングシューズへ
  • できること
    →足袋屋としての足袋作りの縫製技術などのノウハウ、シルクレイという軽量で固い素材のソールへの適用、耐久力のあるアッパー素材の導入
  • 求められていること
    →身体や筋肉に負荷がかかりにくいミッドフット走法が自然と身につく軽量のランニングシューズ

これらがマッチした結果が最終回へと繋がっていきます。
できることが少しずつ増えていき、やりたいことも少しずつ変化し、最終的に求められている所へ、その熱い想いが伝わった結果が成功へと繋がっていきます。

起業とは「経営者という人生を選択すること」

起業の本質をひとことで表現すれば、「経営者という人生を選択する」こと。それ以外の何ものでもありません。

【書籍「ビジネスモデル症候群」P.169 より引用】

起業するということは、何かのアイディアを形にしたり、製品を売ったりすることではなく、経営者になるということです。
経営者であれば、自己の責任の中で自分と家族の生活を支えねばなりませんし、自分が下した判断の結果で物事が良くも悪くも決まっていったり、従業員や株主などへの社会的責任があったりします。

そういった中でも、やりたいことを追い続け経営者としての人生を楽しみながら、できることを増やして求められていることへマッチしていけるかどうか、それが起業して成功へと歩んでいけるかどうかに繋がると思います。

陸王』の中でも、宮沢紘一(役所広司)が経営者として苦悩している姿が、時に息子にあたったり、資金繰りで苦しんでいる番頭役の社員と議論したりと、家族とのシーンや従業員とのシーンで様々描かれています。そんな中でも彼は楽しんでいましたし、最終回では息子が面接で「こはぜ屋さんでの日々を通して、君はなにを学びましたか?」という問いに以下の様なことを言っています。これは、そんな父親の背中を見てきた息子が感じ取った経営者(仕事)の本質なのではないかと思います。

仕事の厳しさと、そこに逃げずに挑戦する楽しさです。
それが仕事の本当の面白さだと、気付かされました。

やりたいことを追い続け、経営者として日々の人生を地道に歩んでいれば、こういった形になっていくのではないかと思います。

売上ばかりを優先しているとスタートアップでは無くなる?

できることを地道にやって経営者としての売上を求めていくという話になると、「スタートアップ」といったキラキラした感じの言葉でイメージされる組織ではなく、「中小企業」といった地味な言葉でイメージする組織に近づいていってしまうのではないかといった懸念があります。

人数の規模感といった様な所では、別に呼び方が違うだけで組織体としては同じですが、やりたいことが無い中で日々売上を求めていくといったことになると、ここでいう「中小企業」という言葉でイメージする組織に近づいていってしまうと思います。
とはいえ、組織を運営していると日々の活動資金や従業員の給与といった現実的に必要なお金は出てくるので売上は必要です。実際、自分が経営をしている中でも、やりたいことを追うのか、売上を上げることを考えるのかは、悩むポイントの一つになることがちょいちょいあります。

「経営の継続を重視しつつも、売上はテーマに即したビジネスで補う」

【書籍「ビジネスモデル症候群」P.202 より引用】

書籍「ビジネスモデル症候群」では「中小企業」という言葉でイメージする組織に近づかないために、売上を上げながらテーマを追うことの重要性が書いてあります。

陸王』でも資金繰りに頭を悩ませるシーンが多いのですが、その中で陸王のために試行錯誤していたシルクレイのソール技術を応用した「足軽大将」という新しい地下足袋を開発し、ヒットさせることで資金繰りを解決するという展開があります。

自分達のやりたいことを追い、できることが増えていっている中、それを活用することで世の中が求めていた脅威の軽さと丈夫さといった新たな足袋を提供できたことで、売上に繋がり資金繰りに明るい兆しが見えました。陸王開発に反対していた番頭役も、「陸王に挑戦していなかったら、この成功もありませんでした」と陸王開発(やりたいこと)を認めてくれます。

テーマを追いながら、その中で身につけたできることを活用して求められているものを製品化をして売上を上げて、また次の一歩に繋げる。その繰り返しをしていくことで、成功へと一歩ずつ近づいていくことになるかと思います。

その先のイノベーション

そんな一歩一歩を進めていった先に、イノベーションを起こすような何かが生まれることがあるのではないかなと思います。イノベーションが生まれるためにはタイミングや運、巡り合わせといったような要素が必要となります。ただ、それらを捉える前段階として基盤ができていないと、その先は無いということですね。

陸王』でも、最後、イノベーションが生まれていきそうな展開となっていますが、まだまだ色々と苦悩があるのではないかと思います。が、彼らなら、きっとそれを乗り越えて世界一のランニングシューズを作るのではないかといった夢を見せてくれました。
起業をしようという人は、同じように夢を見せる必要もあると思っています。

そんな経営者に憧れた人は、アイディアに固執して失敗しないように、ぜひ「ビジネスモデル症候群 ~なぜ、スタートアップの失敗は繰り返されるのか?」を読んでみるといいかと思います。

前回のブログで、著者の和波さんが、この本の中では少なかった HowTo よりの話などを実施されている Lean Action Program の中などで、今後展開されいくみたいですと書いていましたが、早速、和波さんが動かれました。

leanstartupjapan.co.jp

「起業デビューサポート」というタイトルでトレーニングを、ほぼ毎週展開していくとのこと。
こちらも、楽しみですね!

僕も宮沢紘一(役所広司)の様な熱い経営者になれる様、日々、頑張っていきます!

*1:物語なので語られなかった部分では色々あったかもしれませんが