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

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

ビジョン、コンセプトを導き出すファシリテーション(匠塾(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: 〜新たな価値観でプロジェクトをデザインするために〜

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