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

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

なぜ人は複雑なリモコンのようなWebサイトをつくってしまうのか

「複雑!すべての機能をとても使いこなせない」

数多くボタンが並んだAV機器のリモコンを見て、過去に思ったことがある人も多いでしょう。

f:id:haru860:20170805174313j:plain

しかし、いざ自分がWebサイトを企画する側になると、複雑なリモコンと同じものをつくってしまいがちです。

誰もが、シンプルで使いやすいWebサイトをつくりたいと思っているはずなのに、なぜ、そのようなことになってしまうのでしょうか。

順に考えていきます。

小さな労力で大きな価値を

Webサイトを開発するリソース(お金、時間、人)は、どのような企業でも有限です。

そのため、なんでもかんでも思いついたものを、つくるわけにはいきません。

小さな労力でWebサイトをつくり、大きな価値を生み出す努力が必要です。

f:id:haru860:20170805174356p:plain

そのためには、当然ながらWebサイトの開発スコープを絞ります。

顧客の対象を絞る

スコープを絞るには、顧客の対象を絞るのが1番手っ取り早い方法です。

たとえば、顧客の対象候補として、Aさん、Bさん、Cさんがいたとします。 (この場合のAさん、Bさん、Cさんは同一のステークホルダー*1です)

勝負の分岐点

結論をいうと、Aさんだけに顧客の対象を絞れるかどうかで勝負が決まります。

なぜ顧客対象を絞らないといけないか」を考えます。

下図のように、Aさん、Bさん、Cさんを対象顧客とした場合(線の上側)と、すべてのリソースをAさんに投資した場合(線の下側)で、それぞれ「6」のリソース(水色の四角)をサイト開発に使えるとします。

f:id:haru860:20170805174418p:plain

上側は、Aさん、Bさん、Cさんそれぞれに「2」しか開発できず、「2」の価値しかもたらされません。

一方、下側は、Aさんに対し「6」を開発でき、「6」の価値が生まれます。この時点で「4」の差が生まれます。

次のフェーズで、下図のように、さらに「6」のリソース(青の四角)を投資します。

f:id:haru860:20170805174442p:plain

上は合計「4」の開発、下は合計「12」の開発です。

差は「8」になり、差は2倍になりました。

Aさんに特化したWebサイトは、Aさんと同じようなタイプの顧客を増やしていけば良く、Aさん向けにリソースも集中投下できますので、今後ますます差は広がります。

数多くのWebサイトが存在する時代に、このように差がついてしまったら、顧客には二度と選択してもらえないでしょう。

多くのステークホルダーを取りに行く弊害

Aさん、Bさん、Cさんを対象としたほうが、量が稼げて、ビジネスを拡大(スケール)できる可能性はあると考える人もいるかもしれません。

例として、Aさん、Bさん、Cさん向けのWebサイトをつくったとします。

Aさんがサイトを訪れた時に、Bさん向けの機能、コンテンツが目に入った場合、自分のためのサイトではないと思い、離れてしまいます。

こうなっては、せっかく広告で誘導しても、離脱率は上がり、広告費はムダになります。

逆に、Aさん向けにつくられたサイトに、Aさんと同じようなタイプの人「Aさん②」が来た場合は、自分のためのWebサイトだと直感するため、使い続けてもらえる可能性は高くなり、リピート率が上がるでしょう。

ビジネススケール戦略

どのようにビジネスを拡大していくかですが、Aさんの次に、似たようなタイプのAさん②、Aさん③と展開していくのがもっともやりやすい進め方です。

そのあとに、Aさんで成功したら、Bさん、Cさんに顧客層を横展開していくという進め方もありえます。

しかし、最初からAさん、Bさん、Cさんを顧客対象にするのは、上記の理由からおすすめしません。

顧客を絞れない理由

しかし現実には、Aさんに顧客を絞ることはなかなかできません。

考えられる理由をいくつかあげてみます。

クレームを過剰に恐れてしまう

企画担当者は、顧客からのクレームを過剰に恐れ「クレームが来たらどうしよう」と考えてしまいがちです(特に顧客サポート担当が、別の部署として分かれている場合)。

クレームが来ないようにするために、その顧客のために過剰にケアしてしまいます。

顧客の声を真に受けてしまう

以前、マクドナルドで客にアンケートを取ったところ「ヘルシーなハンバーガーやメニューがあったら良い」という答えが多かったので、そのようなメニューを追加したことがありました。しかし、そのメニューはまったく売れずにすぐに終了してしまいました。

そのように、顧客は、基本無責任なものです。

顧客の声を聞く必要はありますが、顧客の声を絶対視してしまうと、自分たちの強み、良さ、目指しているもの、求められているものを見失ってしまいます

顧客、売上が少なかったらという恐怖

「マス」に対してWebサイトを売り「皆が同じものを買う」時代は終わり、顧客は「自分のためにつくられた製品やサービスを購入する」というのは、企画担当者は頭では理解しています。

しかし、顧客を絞ると、売上が少なくなってしまうのではという不安に襲われます。

そして、安全を取り、顧客の範囲を広めに取ってしまいます。

そうなると「マス」に対して商品を売ることに逆戻りするので、当然、顧客に対しての訴求が弱くなります

企画担当者の不安

上記の顧客を絞れない理由に共通することは「企画担当者の不安」に根ざしていることです。

ここで起きる不安は以下のようなものです。

  • クレームがSNSに広がって、サービスの評判が落ちたらどうしよう
  • クレームが来て、自分が責められたり責任を問われたらどうしよう
  • せっかく興味を持ってくれた顧客が離れていったらどうしよう
  • 製品の売上が少なくて、成果があがらなかったらどうしよう
  • 失敗して、出世に響いたらどうしよう(出世を気にする人の場合)

この不安は人の本能であり、大部分の人がこのように反応します。

そして防衛本能が働き、安全策で無意識に顧客の幅を広げ、あれもこれもと、機能がほしくなります

その結果、複雑なサイトができあがります。

このようにならないために、どうすればよいのでしょうか。

顧客の幅を広げない(余計な機能をつくらない)思考法

まずNoという

37 Signals社の「Getting Real」小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則」に載っている方法ですが、何か機能を追加したくなったら「まずNoという」方法です。

「No」というとネガティブでディフェンシブなように思えますが、「No」といったあとに「なぜNoなのか?」を考えることで、妥当な理由があれば「No」は正しかったことになります。

アイデアは無限に湧いてきます。

まず「No」ということで、生まれたアイデアを「良さそうだね」という軽いノリで、つくり始めてしまうことを防ぐことができます。

YAGNI

YAGNI(ヤグニー)とは、"You ain't gonna need it”の略で、「機能は実際に必要となるまでは追加しないのがよい」とする、エクストリーム・プログラミング*2における原則です。

なくても、実用上困らない機能を、必要な人もいるかもしれないという理由で作り込んでしまうことがあります。

このような機能は、要望が増えたときに作るべきです。

要望が出たときではなく、要望が増えたときです。

YAGNIの思想を頭に留めておけば、不必要な機能をつくってしまうことは、かなり減らせます。

「まずNoという」とYAGNIで、顧客の幅を広げてしまったり、余計な機能をつくってしまう可能性はだいぶ減ります。

しかし、「企画担当者の不安」という根本的な問題は解決されていません。

どのようにすれば、企画担当者の不安は減らせるのでしょうか。

事業責任者、経営者を巻き込む

事業責任者や経営者が、企画担当者に、機能の仕様や使い勝手などを全任しているケースも多いと思います。

しかし、上記で説明した人の防衛本能により、担当者は顧客の範囲を無意識に広げてしまいます。

その結果、複雑なリモコンのようなWebサイトが出来上がります。

そのようにならないために、事業責任者・経営者は「その顧客には嫌われよう」「そのクレームは気にするな」「その機能は要望が多くなったら考えよう」などと、都度、意思を伝える必要があります。「誰に嫌われるか」という意思決定です。

この意思決定は事業責任者・経営者レベルの意思決定です。

匠Methodでは「こたつモデル」という考え方があります。

「こたつモデル」は、経営者・事業責任者、業務担当者、システム担当者が、こたつに入るように身体を突き合わせ、お互いにプロジェクトの方向性について意思統一を図ります。

企画担当者は、事業責任者・経営者に「こたつ」に入ってもらい、意思統一を図り、Webサイトの顧客の幅を日々つとめて狭めるようにしましょう。

(事業責任者・経営者が、「マス志向」であったり決断できない人だと、こたつに入ってもらってもつらいのですが)

まとめ

上記の話は、ひとことでいうと「選択と集中」の話です。

しかし「企画担当者の不安」により、「選択と集中」は難しくなります。

それは、顧客を絞れなくなることから来る、機能過多を引き起こします。

そのためには、事業責任者・経営者と同じ土俵で意思統一をはかることです。

事業責任者・経営者は「誰に嫌われるか」の意思決定を日々伝えましょう。

おもいきって顧客を絞り、その顧客に最大の価値をもたらそうとすると以下のメリットが得られます。

  • 市場での立ち位置の確立(専門Webサイトとしての差別化)
  • 顧客の定着(リピート率の向上)
  • 低い新規顧客獲得コスト(広告費が少なくて済む)
  • 開発コストの低減(集中的投下)
  • 集客効果(同じようなユーザーが集まっていることにより、同じユーザーが集まる)

「企画担当者の不安」を乗り越え、経営者・事業責任者、企画担当者の意思統一をはかり、顧客の「選択と集中」によって、価値あるWebサイトを創り出しましょう。

以下の2冊は、シンプルなWebサイトをつくりたい方におすすめです。

「まずNoという」が書かれている書籍はこちら

「こたつモデル」が提唱されている、匠Methodの書籍はこちら

*1:ステークホルダーとは、企業・行政・NPO等の利害と行動に直接・間接的な利害関係を有する者を指します。具体的には、消費者(顧客)、従業員、株主、債権者、仕入先、得意先、地域社会、行政機関などです。楽天のようなECショッピングモールサイトを例にすると、Aさん、Bさん、Cさんは「購入者」という同一のステークホルダーです。「出店者」は別のステークホルダーです。

*2:ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。WikiPedia

勉強会で話すと何が良いのか〜Developers Summit 2017 Summerで登壇しました

7月28日に開催されたDevelopers Summit 2017 Summer で、「コミュニティを長く続ける秘訣」というセッションでお話させて頂く機会をいただきました。

f:id:haru860:20170727170224j:plain

BPStudyは、2017年8月の開催で、丸10年(2007年9月開始で、12か月☓10年=120回)になるということで、BPStudyをテーマに発表しました。

セッションで話した中でも「勉強会で話すと何が良いのか、どのようなことを話したら良いのか」ということをあらためてブログに書きたいと思います。

このエントリーが、勉強会でこれから発表してみようと思っている人のヒントになればと思います。

私が言いたいことを、少しおおげさにいうと「勉強会で発表すれば人生が変わる」ということです。

そのように思うようになったのは、私が勉強会やカンファレンスなど人前で発表することを繰り返してきたことによって、以下のような経験をしたからです。

  • 自分の経験やノウハウがカタチとしてまとまり、自分の財産になり活用できた
  • カタチとしてまとまったことが土台となり、更に新しい発想につながった
  • 発表を聞いた人や、スライドを見た人から新たなオファーがあるなど、自分の予期しないところで、さまざまな効果が生み出された

勉強会で話すためのポイントを3つお伝えします。

ポイント1 やりたい→やるへの変化(心が変わる)

勉強会で発表するには、まず自分が発表しようと思い立つところからです。

「いつか発表したい」と思っていても、その時は永遠に訪れません。

「やりたい」から「やる」と決心した瞬間が、人生が変わるスタート地点です。

ポイント2 話すテーマ

勉強会で話すといっても、話すことがないという人もいると思います。テーマを見つけるコツをお伝えします。

視点を変えるとネタが生まれる

日頃の自分の取り組み、環境、経験などは、自分にとって当たり前になっていて、平凡に思えるものです。

人それぞれにさまざまな個性があり、まったく同じ人はいないのと同じように、まったく同じ仕事やチーム、プロジェクトは存在しません

自分の環境やそれまでのキャリアから、人に伝えると役立つものはないか考えてみましょう。

客観的な視点で見つめてみると、ヒトに伝えるネタが生まれるものです。

本に書いてない内容を話す

テーマは本に書いてない内容が良いでしょう。本に書いてあることを説明するだけなら、本を読んだり、Webの記事を読めば良いからです。

本に書いていない内容とは、たとえば以下のようなものです。

  • やってみてどうだったか、実際のところどうなのか?
  • やってみて得た知見
  • チームに導入してチームメンバーの反応はどうだったか
  • 技術の発表されたばかりの最新情報
  • コツ・独自の理論

コミュニティの運営経験、初心者が初心者なりに苦労した話、若手が若手なりに苦労した話、他の人は詳しくないが自分は詳しいこと、異なる分野同士の組み合わせ(掛け算)などもよいでしょう。

ポイント3 勉強会で話すメリット

3点目に勉強会で話すメリットをお伝えします。

スキルアップと財産づくり

発表する1番のメリットは、自分の暗黙知が形式知になることです。

暗黙知とは「経験や勘に基づく知識のことで、言葉などで表現が難しいもの*1」です。

暗黙知が暗黙知のままでは人に伝わりませんし、自分でも認識が難しいものです。

人に伝えようとして、なんとかカタチにしようとすることで、半ば強制的に暗黙知が形式知に変わります

自分の中の暗黙知を絞り出し、形式知にするのは最初はとても時間がかかります。

しかし、何回か発表を重ねていくと、知識のベースがあるので時間が短縮されます。

形式知は自分の財産となり、何度も再利用可能になり、かつ思考の土台になることでしょう。

登壇依頼が来ても、割りと気軽にOKすることができるようになります。

ただし、私は同じようなテーマで登壇依頼が来ても、必ず内容を最新のもの、その場にあったものにバージョンアップして、同じスライドで話さないようにしています。その方が自分にとって成長があるからです。

自分の強みや世の中のニーズが分かる

勉強会で発表をすると、聞いている人の直接の反応をもらったり、Twitterでの反応が大抵あります。

このようにフィードバックを得られると、自分の強みや、世の中でどのような情報が必要とされているかなどのニーズが見えてきます。

プラスのフィードバックは自分の自信につながりますし、マイナスのフィードバックは自分を見直すきっかけにもなります。

自分の強みと社会のニーズを知ることにより、自分は何に力を入れていくべきか、立ち位置はどこか、などが見えてくることでしょう。

自分の新しい可能性が見えてくる

IT業界は「話を聞く」側から「話をする」側になるための参入障壁がとても低い業界です。

さまざまな勉強会がありますし、まずはLTで話し、実績を積んでいくことであるジャンルでの権威としてのポジションを築くことができるかも知れません。また、それらをきっかけに、人のつながりができたり、新しい可能性が見えてくることもあるでしょう。

ただし、これは勉強会で話す副次的効果です。勉強会で話すことの第一の目的は、自分のスキルや経験を他の人に伝えることや、自らのスキルアップに置きましょう。

話をする多くの場はコミュニティなので、自分の名声やポジションを第一の目的にすると、それが見え透いてしまったり、人間関係を壊してしまうなど、ろくなことがありません。

まとめ

勉強会で話すまでのポイントとして、(1)やりたい→やるへの変化(心が変わる)、(2)話すテーマ、(3)勉強会で話すメリットについてお伝えしました。

このエントリーが勉強会で発表してみようと思う人にとって、ヒントになれば幸いです。

日々、人はさまざまな経験をして学習し、それを暗黙知として蓄積しています。自分の仕事での経験、勉強していること、興味をもっていることで人に伝えられることがないか考えてみましょう。必ず見つかるはずです。

そのためには、社内でも社外でも仲間内でも勉強会で話そうと思い立つことがスタート地点です。そのためにはLTに参加登録して話すことを確定させてから、内容を考えるのもおすすめです。

自分の知識・経験・知見をカタチにして話すことによって、人に伝わり、それを繰り返すことによって、自分でも予見できないようなことが起こることでしょう。

BPStudyでも登壇者を常時受けつけていますので、Facebookのメッセージで私宛までご連絡をいただくか、Twitter:@haru860でDMもしくは、リプライをいただければと思います。

発表スライド

ビジョン、コンセプトを導き出すファシリテーション(匠塾(2017年6月) 開催まとめ)

2017年6月8日(木)に匠塾*1に参加しました。

7月の開催のまとめと前後してますが、内容をまとめました。

テーマ

私は、匠メソッドの知見・暗黙知をまとめて形式知にするチーム(通称ヘンタイチーム)に参加しました。

価値デザインモデルのビジョン、コンセプトの導き出し方というテーマに取り組みました。

匠メソッドのビジョン、コンセプトとは

  • ビジョン

    将来の目指す姿、ありたい姿を文章、言葉で表現したもの

  • コンセプト

    ビジョンを実現するための構想。3つあげる

必要なスキル

プロジェクトのビジョン、コンセプトを導き出すには、以下のようなスキルが必要です。

  • 想像力

    • プロジェクトメンバーが納得して目指したいと思えるような未来をイメージする力
  • 言葉づくり

    • 目指すビジョン・コンセプトを抽象的過ぎず、具体的過ぎず的確に言葉で表現する力
  • バランス感のあるコンセプトづくり

    • 施策・手段検討につながるバランスの良い3つのコンセプトにまとめる力

これらのスキルはファシリテーター・リーダーだけが必要なものではなく、チームで持つべきスキルです。属人性が高く、暗黙知が大きい領域です。

As-Isの把握

ステークホルダーモデルで、ステークホルダーの洗い出し、各ステークホルダーが抱えている問題点をあげていくことによって、現状を把握します。これが最初のステップです。

f:id:haru860:20170726203916p:plain

未来を描くうえで、現状をしっかりと把握しておくことは重要です。

現状を的確に把握しておかないと、いかに理想的な未来を描いたとしても、ふわっとした絵に描いた餅となってしまう可能性があります。

現状を把握せずに、理想的な未来について話しているリーダーを想像してみてください(よほどのカリスマ型リーダーなら別ですが)。

価値デザインモデルまでの進め方

ステークホルダーモデルで現状(AsIs)を把握したあと、価値デザインモデルを作成するまでの進め方は、以下の2パターンがあります。

  • (1)価値分析モデル→価値デザインモデル
  • (2)価値デザインモデル→価値分析モデル

それぞれの進め方のメリット、デメリットを以下にまとめます。

(1)価値分析モデル→価値デザインモデル

まずは価値分析モデルから始めるパターンです。 f:id:haru860:20170722083254p:plain

  • メリット

    • 施策・手段のアイデアがある程度出ているので、プロジェクト実現のイメージがつきやすい
    • 価値分析モデルは手をつけやすいので、話を進めやすい
  • デメリット

    • テーマ・ドメインが大きい場合、ステークホルダーがつかみづらい。スコープが広がりすぎた価値分析モデルになりやすい
(2)価値デザインモデル→価値分析モデル

次に価値デザインモデルから始めるパターンです。 f:id:haru860:20170722083306p:plain

  • メリット

    • 明確な未来像を既にもっている場合や、長い間構想してきたプロジェクトの場合は、ビジョン、コンセプトがまとまりやすい
  • デメリット

    • 詳しくないテーマ・ドメインの場合や、未来のイメージが湧いていない場合は話が停滞しやすい
2つの進め方の共通課題

ビジョン、コンセプトを導き出すには、上記で書いたように「想像力」「言葉づくり」「バランス感のあるコンセプトづくり」というスキルが必要なので、議論が停滞したり迷走する可能性を秘めています。

具体的施策を段階的に抽象化し、
ビジョン・コンセプトを導き出すファシリテーション

ヘンタイチームでは議論の停滞・迷走をなるべく防ぐために進め方をまとめました。

下図は全体像です。

f:id:haru860:20170808071223p:plain

ステップ1 Asisの把握

Asisの把握は上記と同じです。

f:id:haru860:20170726203916p:plain

ステップ2 具体的施策のアイデア出し

現状を把握した上で「やりたいこと、やったほうがよいと思うことは?」という問いで、施策・手段のアイデアをブレストします。

f:id:haru860:20170726222704p:plain

いきなりビジョンやコンセプトを考えるよりも、具体的施策ならアイデアを出しやすいものです。

施策・手段のアイデアを以下の3つの視点で分類すると、さまざまな立場の視座を持てるようになり意外なアイデアが出るかもしれません。

  • (1)すぐにやれそうなこと(現場担当者の視点
  • (2)少し頑張ればやれそうなこと(現場リーダーの視点
  • (3)遠い未来にやれそうなこと(経営者の視点

ここでの施策・手段のアイデアは、後のプロセスの価値分析モデルの手段、要求分析ツリーの業務要求、IT要求、解決策につながってきます。

この段階でアイデアをじっくり出しておくことで、後のプロセスのスピードアップにもつながるという効果もあります。

ステップ3 グループ化、抽象化

ステップ2 で出たアイデアをグループ化したり、グループ間を関連付けたりします。 その上で各グループにタイトル・見出しをつけていきます(言葉づくり)。ステップ2の発散から収束していく段階に入りますが、グループ化、抽象化することで全体が見えてくると新しいアイデアが生まれてくるものです。新しいアイデアが出たら、それも追加していきましょう。

f:id:haru860:20170726222238p:plain

ビジョンやコンセプトの言葉づくりをいきなり始めるよりも、具体的な施策・手段をもとにしているので、言葉づくりの難易度が下がるというメリットがあります。

ステップ4 コンセプト・ビジョンの導出

ステップ3 で徐々に抽象化したものを「やりたいこと・実現したいことはどういうこと?」という問いのもと、ビジョン、コンセプトの言葉づくりをします。

f:id:haru860:20170726222349p:plain

すぐ下の抽象度まで言葉づくりが出来ていれば、ビジョン、コンセプトの言葉づくりもやりやすいのではないでしょうか。

ショック療法(新意識へのシフト)

目の前の問題から見えている施策・手段を抽象化し、そこからビジョンを描いても、現在の延長線上にあるビジョンになってしまう可能性があります。

思考をジャンプし、新意識にシフトしたビジョンを打ち出すには、上記のステップ2、ステップ3、ステップ4 のそれぞれで、新意識へシフトするためのショック療法を施すのが良いでしょう。

たとえば、以下のような問いを発してみると良いでしょう。

  • 技術ドリブンで、Howからの突き上げはできないか?
  • 現意識の延長で考えていないか?
  • 自分たちの強み・パーソナリティと社会的な機会を活かせているか
  • やろうとしていることは他社にとって模倣しにくいか?

うまくいかないファシリテーション

最後に、うまくいかないファシリテーションについて、2つのパターンをあげておきます。

強引な(専制的)ファシリテーション

f:id:haru860:20170722083319p:plain

  • ファシリテーターが「結果イメージの予測」をした方向に議論を強引に持っていってしまう
  • メンバーのアイデアをファシリテーターの判断のもとに切り捨ててしまう

このファシリテーションでは、メンバーが置いてきぼりになり、納得感がない得られないことがしばしばあります。

ファシリテーターは、結果を出そうと力んだり、急いだりするよりも、より良いものが創造される場づくりを重視すると良いでしょう。

問題点→解決策実行の進め方

f:id:haru860:20170726222951p:plain

このファシリテーションは、以下のように進めていきます。

  • (1)現状の問題点を把握
  • (2)問題点を解消するための施策をブレスト
  • (3)施策に優先度をつける
  • (4)優先度の高いものから実行

この進めかたでは、問題点を解消したとしても、根本的な状況は変わらないことが多いでしょう。

それは、目の前のひとつひとつの問題に小手先で対応したとしても、部分最適にしかならず、全体最適につながらないことが多いからです。

全体最適につなげるには、新意識にシフトしたビジョンを描き、それに基いて行動することです。

まとめ

今回書いた、ビジョン、コンセプトを導き出すまでのファシリーテションに正解はありません。

対象ドメインやプロジェクトメンバーによって、変わってくることでしょう。

今回メインに書いた「具体的施策を段階的に抽象化し、
ビジョン・コンセプトを導き出すファシリテーション」は、匠道場*2の課題での経験をもとに、ヘンタイチームで議論された内容が書かれていますが、これはファシリーテートの1パターンでしかありません。

課題の実例については、いずれ書きたいと思います。

匠メソッドに興味があり、匠塾に参加してみたい人は、にFBメッセージでお声がけください。

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

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

*1:毎月開催されている招待制の匠メソッドを学ぶ会です。株式会社アクティアCOO 高崎健太郎さんを塾長とする有志によって開催されています

*2:匠メソッドのライセンスを購入している企業の社員のみが参加できる月1回開催されている匠メソッドの勉強会

匠塾(2017年7月) 開催まとめ〜価値デザインモデル:「コンセプト」の性質について

2017年7月13日(木)に匠塾*1に参加してきました。

価値デザインモデルの「コンセプト」について

私は、匠メソッドの知見・暗黙知をまとめて形式知にするチーム(通称ヘンタイチーム)に参加しました。

テーマは、価値デザインモデルの「コンセプト」についてでした。

コンセプトに関する話題の中でも、私が匠道場6月のまとめで不明点としてあげていた「コンセプトの性質:戦略ベースのコンセプト、コンセプトベースのコンセプト」が話の中心になりました。

プロジェクトデザインのスコープ

匠メソッドのセッションで、どこまでを議論のスコープとするかという話から始まりました。

  • 匠メソッドのモデリング対象は、プロジェクトデザインである
  • 会社-事業-製品-機能(サブシステム)という階層がある場合、匠メソッドでモデリングするプロジェクトは以下の3つに分類できる

    • 企業デザインプロジェクト(会社-事業)
    • 事業デザインプロジェクト(事業-製品)
    • 製品デザインプロジェクト(製品-機能)
  • 企業デザインプロジェクトで、製品や製品の機能までを対象とするのは、スコープを広げすぎ

  • 事業デザインプロジェクトで、製品の機能までを対象とするのは、スコープを広げすぎ
  • 事業デザインプロジェクト、プロダクトデザインプロジェクトで、企業ビジョンは脇において意識はしておく

f:id:haru860:20170714182021p:plain

Howの手探りによる実現性の検証

  • 企業デザインプロジェクト、事業デザインプロジェクトで、製品の実現可能性を考慮せずに、モデルをつくっても、現実性の無いモデルになってしまうおそれがある。
  • その場合、Howの手探りをすることにより、実現可能性を検討することにより、現実性を考慮した検討をすることができる

f:id:haru860:20170714182510p:plain

Howの手探りをどのようにするか(例)

匠道場で、私が入ったチームの課題で、R&D要素が強いプロジェクトをテーマにしていました。

そのとき、価値デザインモデル、価値分析モデル、要求分析ツリーまでつくったところで、以下の図のように画面、処理、データの入出力の関係を検討しました。

それにより、実装(How)について、どのようなデータが必要なのか、どのような技術を使うのか、どのような研究が必要なのか、既にどのような技術があるのか、その技術はどの段階まで進んでいるのかなどというところまで話ができて、プロジェクト実現に向けて具体的なイメージをチームで持つことができました。

f:id:haru860:20170716122235p:plain

コンセプトの性質

戦略ベース
  • それぞれのプロジェクトのスコープに収まる、ビジョン、コンセプト、目的を導き出す
  • 匠Method: 〜新たな価値観でプロジェクトをデザインするために〜に記載されている戦略ベースの説明(「第7章 匠Methodで商店街の風呂屋を復活させる」)

    • プロジェクトで最も重要なことを3つ挙げようといったトップダウン的発想。
    • 業務改革や作業改善などプロジェクトのコンセプトを考える時に活用されるアプローチ

f:id:haru860:20170716164945p:plain

コンセプトベース
  • コンセプトベースについては結論は出ないが以下のような話をしました

    • プロダクトデザインプロジェクトで、会社ビジョンをプロジェクトのビジョンとした場合に、製品のコンセプトが戦略要求の一部分(目的レベルの下)、もしくは業務要求になるのではないか
    • さらに抽象的なコンセプト見出すなど、コンセプトの見直しにより、戦略ベースと同じツリー階層に最終的には落ち着くのかもしれない
  • 匠Method: 〜新たな価値観でプロジェクトをデザインするために〜に記載されているコンセプトベースの説明(「第7章 匠Methodで商店街の風呂屋を復活させる」)

    • プロジェクトにとって非常に重要なアイデアにスポットを当てて、ボトムアップ的にコンセプトを導き出す
    • 製品企画や特徴のあるサービス(ビジネスモデル)の企画のコンセプトを考えるときに活用されるアプローチ
    • 導き出されたコンセプトは、戦略要求の一部分、あるいは下位の業務要求といったように局所的に位置づけられる

f:id:haru860:20170716165004p:plain

IIBAのGUTSY-4における4つのモデルとフェーズ

プロジェクトのスコープの考え方は、IIBAのGUTSY-4における4つのモデルとフェーズに似ているものがあるのではないかという話も出ました。

f:id:haru860:20170716123739p:plain

各チームの発表を聞いて参考になった話

  • 匠メソッドの進め方はブレーンストーミングに近いが、普通のブレーンストーミングはどこまでも議論を深めてしまいがち。匠メソッドはフレームがあるので、アイデアを出しつつも行きすぎにならないのが議論しやすくて良い
  • (テーマ:ファミタクチーム)店舗を始めるのに、従業員を多く雇う、待遇を良くするなどというところから行動を始めるように考えてしまったが、それだと事業が成り立たないということに途中で気づいた。事業をまず成り立たせるというところから始めるようにしてから、アイデアに現実性が出てきた
  • (テーマ:納涼大会)「上下関係の壁を壊す」「ダンス」「Beat the summer」というアイデアが生まれてから、話がスムーズに進むようになった

    • (コメント)匠メソッドのセッションの序盤では、アイデアが出ない、アイデアは出るが、腹落ちしないというすっきりしない時間帯があります。「上下関係の壁を壊す」「ダンス」「Beat the summer」などの「キーアイデア」とも呼べる、チームメンバーの話の呼び水となるアイデアが出るまで、どのようにファシリテートしていくか。セッション序盤におけるファシリテーターの重要スキルの1つでしょう。
  • (質問)匠メソッドのチームは何人ぐらいが良いのか? → A. 多くても8人くらいが良いでしょう

    • (コメント)こたつモデルを形成するために、誰を呼ぶのかという視点が大事。その上で適切な人数を考える

まとめ

約1時間半のワーク時間で、良さそうなアイデアが各チームでかたちになるので、匠メソッドを使うスピードが上がってきているのを感じます。

私自身は、匠メソッドについて考えていること、今までの経験や疑問点などをお互いに話しているうちに、頭の中がまとまったり、新たな知見を得たりと、2時間の時間以上に収獲が大きいです(感謝)。

匠塾によって匠メソッドを経験したことがある人の輪が広がってきています。さらに皆で楽しみながら学んでいきたいです。

匠メソッドに興味があり、匠塾に参加してみたい人は、にFBメッセージでお声がけください。

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

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

*1:毎月開催されている招待制の匠メソッドを学ぶ会です。株式会社アクティアCOO 高崎健太郎さんを塾長とする有志によって開催されています

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

日本の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: 〜新たな価値観でプロジェクトをデザインするために〜