Actier COO なブログ

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

Gunma.web にドメイン駆動設計で遠征してきた 〜ドメイン駆動設計は「男の料理」

勉強会 DDD 登壇

2018/1/20 に Gunma.web #30 という勉強会に遠征してきました。

f:id:k_takasaki:20180206000018j:plain

 こんな感じのおしゃれな喫茶店の 2 階で開催されました。

Gunma.web とは

WEBサイト作成に関わる人が集まる勉強・研究・交流の地域コミュニティです。
WEBサイト作成に関わる プログラマー、SE、HTMLコーダー、WEBデザイナー さんなどが集まります。

東京や関西で　webサービスに関わる人が集まっての研究、懇談会が行われ、WEBサイト作成のスキル、意欲向上の大きな手助けとなっています。

群馬県でも地元の技術者、サービス関係者を集めWEBサイトの作成スキル、意欲向上の手助けになればと思い開催しています。

といった群馬の web 系勉強会 & コミュニティです。
2010 年に第 1 回目を実施され、今回が 30 回目というかなり長いこと継続して活動されている勉強会です。

遠征の経緯

今回、Gunma.web #30 のテーマとして、DDD「ドメイン駆動設計」を扱いたいとのことで

といった感じで、Gunma.web を主催されている @kanayannet さんから、DDD Alliance にツイッターでお声がかかりました。
基調講演でゲストとして誰か話に来てくれないかといったお誘いです。

DDD Alliance は、

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

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

 

を書かれた有限会社システム設計の増田さんと、株式会社アクティア、そら製作所、井上屋で立ち上げたドメイン駆動設計の実践経験を基にしたワークショップやオンサイトワークショップ、コンサルティングを展開しているコミュニティです。*1

ドメイン駆動設計をシステム開発の現場で活用することにお悩みの方々の一助になればと日々活動している団体なので、こちらとしてもぜひ！とゲストのお誘いにのって増田さんと僕で遠征してくることになりました。

発表内容メモ

「基調講演＋LT＋懇談会」といった構成で、非常に盛り上がった勉強会でした。
メモ形式＆ちょっと感想等（※ 部分）を入れつつ、各発表の内容をまとめてみます。
あ、自分の発表だけは解説っぽい感じです。

基調講演「ドメイン駆動設計とは何か　入門編」

基調講演として、増田さんがドメイン駆動設計とは何かについて話されました。

ソフトウェア開発の難しさ

  • 複雑さに設計で立ち向かう。
  • 2年後、3年後にシステムがどう使われているかを見据えることは難しく不確定。
  • その確実さの無いものに、どうアプローチしていくか考えることが大事。

ソフトウェア設計の考え方とやり方

  • 複雑なのはドメインそのもの。納期あり、コストありの中でも拘る。
  • モデルと実装を一致させることは相反するので、相当難しい。
    だが、そこに拘ることでソースの分かりやすさ、変更をする時のポイントの捉えやすさが全然変わってくる。
  • 決まってしまった設計を変えようとするのは大変だが、危険だからやらないに振ってしまうとドメインが育っていかない。
    そのため、インクリメンタルな設計とする必要がある。
  • 会話とラフスケッチの中で、うまく言語化できたものを実装にしていく。

ドメインに焦点を合わせる

  • 知識を獲得し、整理、コードで表現する。
  • インクリメンタルに設計していく際に常にうまくいくとは限らない。
    同じインプットでも表現が異なったり、もっといいものがあるんじゃ、もっと工夫できるのではと常に考える。
  • 人間は、言葉でやり取りする。言葉は重要なツール。
  • 会話とラフスケッチで言葉を捉えているか確認。
    ドメインの言葉をきちんと話せていないエンジニアは怖い。自信がないより、そこが分かってすらいない人が一番怖い。

スタイル

  • アップフロントで決まったことを変えないというのはやめるべき。
    あの日に決めたから変えないはやめる。たった一行の変数名かもしれないが変える。
  • 綺麗な資料は整理できた気になってしまう。

※ ここの話は、僕も陥りがちだったなぁと非常に思うところでした。
SIer の頃の癖が抜けないというか、前に決まったのでコレで行きましょうとか、既にテスト済のところなので変数名の変更はやめておきましょうとか。ついついドメインをインクリメンタルに成長させるということよりも目の前の納期や品質の方にばかりウェイトを置いてしまうというか。
また、資料もついつい綺麗なものを作りたくなっちゃいますｗ
コレはもう性分なので、ある程度抜くということを常に意識しながら取組む日々です。

モデルと実装を一致させる

  • モデルと実装を行ったり来たりする。
  • モデルで要点、軸を捉えて、コードでカタチを作る。
  • モデルを踏まえてコードレビューすると要点を捉えてレビューが出来る
  • ユーザー定義型。
    人が作った型を利用するのはみんな得意になったが、自分でもっと目的に特化したものを作り上げるべき。

※ モデルと実装の行ったり来たり、というのは、抽象と具体の行ったり来たりということになりますが、これは物事を考える時に非常に大事だなと僕も最近特に思っていることです。ついつい目の前の具象にとらわれがちになるので、行ったり来たりで、ちゃんと俯瞰した目線でも見ないといけないなと。モデリングをする時に特にそう思います。

モデルと実装の一致を難しくさせる問題

  • オブジェクトの永続化とか仕組みに引っ張られる。
  • それぞれ、ケースバイケースで考えるべき。

※ 画面やテーブルアクセス、ファイルフォーマットとか仕組みや既存のモノに引っ張られがちで色々とモデルがおかしくなるなというのが、最近の僕の悩みだったりするので、この難しくさせる問題は本当に難しいですｗ

ブレークスルーが起こるとき

  • ドメインモデルの軸となる【要点】がみつかった
  • 区分の構造のリファクタリングの中で
  • テーブルアクセス、画面表示を分離できたとき

境界付けられたコンテキスト　異なるコンテキスト間のマッピング

  • 悩んでいる背景、文脈が違うことを意識する。
    生々しい文脈（エンジニアにとってはプログラミングや設計）。
  • 濃い文脈間でどう捉えているかを把握する。

質問

Ｑ．

インクリメンタルな設計をする際に、テストコードについてどの様に扱っているか？

Ａ．

ソフトウェアの言語タイプによると考えている。動的型付け言語であれば必要と思われるが、使用している静的型付け言語だと書かないことが多い。（言語が保証してくれている側面が大きいから）

 

Ｑ．

実際、会話という面だと日本語で会話しているので、プログラミング言語とのギャップが生まれないか？
それを、どう埋めるのか？

Ａ．

ある部分については、日本語でやっている。
基本は、英語に変換しているが、要点を深堀しきれなかった(表現できなかった)時に使っている。ただ、フレームワーク的な制限等もあるので使える所は使ってみているという状況。

 

Ｑ．

現場のシステム担当と話す際に、担当者が分かるレベルで変更の履歴が知りたいといった様なドキュメントが必要とされる様な局面では、どの様にされているか？

Ａ．

コードから分かりやすいドキュメントを出力するようなツールを作るなど実験中。Git の変更履歴をビジュアライズ化するなど。

 

といった感じで、増田さんの基調講演が終わりました。
基調講演ゲストとして伺ったというのもありますが、質問も活発で、DDD Alliance としても伺った甲斐があったなといった展開となりました。

 

続いて、LT 枠。

Easy Array

というタイトルの @yterajima さんの LT だったんですが、「怒られるので書かないでｗ」とのことなので、ヒミツですｗ

こういう発表がたまにあるのも、勉強会会場へ行った人だけの特典だと思います。

DDDから得たもの

というタイトルで、主催の @kanayannet さんの発表。

元酒屋さんでプログラミングは独学という @kanayannet さん。

  • 10年近く前に酒屋から転身 3 年目の頃、DDD 本は分からんかった
  • 原因としては、単純に経験不足、ドメインに囚われすぎていた

10年経って

  • 名前空間の理解
  • 可読性の大切さを知った　一月経っても読めるコードを

  • 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 を読んだ
    設計の大切さをどう学んだらと困っている中、入りやすかった

  • ドメインモデルというキーワードがそもそも分かりにくい
    何のためにから入ると分かりやすかった
  • 共有してわかりやすくしていく
  • 実装に集中してしまったら、たまに振り返ってみる
    つまづいた時に振り返ってみる、隣の席の人に相談してみる
    そうすると気づくことがある
  • ユビキタス言語
    同じ意味の複数の言葉が乱立することを防ぐ
  • DDD が考えるキッカケを与えてくれた

仕様とは

  • 仕様は課題と設計を繋ぐものです　by 酒匂 寛さん
  • シンプルとイージーの違い　by 和田 卓人さん
    シンプルは一つのもの、イージーは人の数だけ存在する
  • 何か通じるものがあると感じた

まとめ

  • 10年ごしに理解が追いついた

 ※ 10年ごしに理解が追いついたとのことですが、色々な知識があってはじめて見えてくる世界があるということを改めて感じた LT でした。最初は点でしか分からなかったものが、線となり、面となり、立方体になるといった感じで、日々の学びがその先に繋がっている。設計は、多角的に色々と知らないといけないので、こういった学び方になるのかなと思います。

ドメイン駆動設計を始めるために必要なチームのつくり方

というタイトルで、@TsukasaGr さんの発表。

世の中には、いろいろな現場の悩みがあるという @TsukasaGr さん。

良いチームとは？

その１　いいたいことが言える
  • オブジェクト指向もアジャイルも正解がない
    なので、言える環境が大事
  • 言いたい時に言いたい事が言える場所を作る
    分報：Slack で言いたいことを言える場を作った
    なんでもOKな何やっているかとかを連携する場
  • 問題の早期解決などに繋がる
その２　だれかのせいにしない
  • チーム全員で動く
  • だれかのせいにしない仕組み
  • KPT＋G
    GKPT でGoodを可視化　なんでもOK
  • みんなで決めるので誰かのせいにしない
その３　情報を楽しめる
  • 情報を楽しめる文化を作る
  • 情報共有 ＋ コミュニケーション
  • パブリックだとハードルが高いのでクローズドな場として Slack でチャネル
  • その日のニュースネタをキッカケに議論
まとめ

※ 良いチームをつくることで、DDD を始める場を作るといった手段と目的が分かりやすいまとめの図だったので、スライドの中を見て頂くといいかと思います。

ドメイン駆動設計するための脱！受身エンジニア心得

というタイトルで、僕も LT してきました。

ドメイン駆動設計に自分が取り組んでいる中で感じた過去の自分との違いや、意識しないと中々ドメイン駆動設計にならないなと思っていることをまとめようと思いました。

伝えたかったこと

今回の LT の中で伝えたかったことは、

ドメイン駆動設計は、「一品もの」を意識して設計すべし

ということでした。

そのための表現として、「工芸的」や「男の料理」といった表現を使ってみたのですが、振り返ってツイートを見てみると反応してくれていたので伝わったのではないかな〜と思います。

 脱！受身エンジニア

そんな「一品もの」を作るということに対して反しているものは何かと考えた時に出てきたのが、「よくある SIer 構造」でした。自分も、その構造の中で働いてた時もあったので色々と自分自身にも染み付いてしまってます。*2

ただ、振り返ってみると悪いのは構造そのものではなく*3、その中で漫然と受身になってしまっているエンジニアなのではないかなと思い、今回の「脱！受身エンジニア」というタイトルとなりました。

受身のエンジニアとなると、ちょっと極端に言うとコードモンキーといった感じで、何も考えず、ただ漫然とコードを書くといった感じのエンジニアになってしまいます。
やはり、頭を使わないとドメインを捉えることもできませんし、それをモデルとして表現したり、コードに落としたり、そもそも顧客の価値は何なのかといったことも分かっていない状態になります。

これでは、ドメイン駆動設計をやれる状態ではない*4ので、受身エンジニアを脱しないといけません。

工業品と工芸品

SIer でよくやるピラミッド型の下請けモデルでの開発やウォーターフォールでの開発といったやり方は、いかに部品を分解して機械的に同じように生産するかといった構造になりがちです。パッケージ開発なども、ほとんど同じものを横展開して、大量生産しようといった考え方から来ているやり方だと思います。工業品を作る時のやり方ですね。

一方、ドメイン駆動設計での開発に取り組んでいて思うのが、そのドメインの知識を獲得して、モデルやコードを作っては、また新たな気付きで作り直してといった手間暇をかけたやり方をしていかないと、ドメインを理解したり実装したりすることはできません。
一品一品丁寧に、同じ点や違う点を見極めて作り上げていくといったやり方だと思います。工芸品を作る時のやり方ですね。 

この違いがあるので、今まで工業品を作ってきた時と同じようにやろうとしても、うまくいくはずがありません。
初期に手間暇がかかるリスクがあったとしても、ゆくゆくのビジネス変化や変更に柔軟に対応できるモノを作ろうとするのかどうかで、ドメイン駆動設計に取組むかどうかといったことを関係者でしっかりと認識合わせする必要があると思います。

まとめ：男の料理

これは、一緒にドメイン駆動設計で開発をしているメンバーと話している時に出てきた言葉なのですが、

ドメイン駆動設計は、男の料理

だねと。

主婦は冷蔵庫の中身で、ササッと料理して提供してくれるパターンが多いと思いますが、男の人が料理する時は、レシピ通りになるように具材を仕入れてきて、若干無駄かもしれないぐらいしっかりと飴色玉葱になるように炒めてみたり、包丁もいいものを使ってといった形から入ったりと、手間暇かけて料理するパターンが多いかと思います。

ドメイン駆動設計での開発というのは、そんな感じで捉えて、じっくりと料理が出てくるのを待つ必要があるのではないかというたとえです。

まあ、男の料理が手間暇かかったからといって、美味しいものが出てくるとは限らない所が恐いところですがｗ
逆に、主婦がササッと作ってくれたけどメッチャ美味しいのもありますしねｗ

Vue.jsによるSPAのDDDについて考える(導入編)

というタイトルで、@t_pori418 さんの発表。 

  • ドメイン駆動設計の説明は、割愛ｗ
  • 実装でどういうアプローチしているかについて
フロントエンドの DDD

まとめ

  • 画面とデータ主体の実装にはならないように
  • ドメインモデルにわけて
  • 増田さん本の 7 章がオススメ

ドメイン駆動設計と関数型プログラミング with TypeScript

というタイトルで、 @childhooooo さんが発表。

元ロケットの組込み関係エンジニアだったという@childhooooo さん。

参照透過性が破壊されるもの
  • 再代入　→　変数を破壊
    const 宣言をして再代入禁止とする
  • 副作用のある関数
    何回か呼ぶと結果が違ってくる
ドメイン駆動でモデルの構成要素
  • 値オブジェクト
    残高をオブジェクト化
  • エンティティ
    関数型で使う時は、新しいオブジェクトを生成して返すと良い
  • サービス
    2つのアカウントを取って書き換えるのではなく、2つのアカウントを主として2つの結果を返す
  • モナドとかも話したかったが・・・時間がないので

最後に

LT まで終了した後、その場で懇談時間があり、基調講演や LT の内容で盛り上がりました。

その後、二次会があったので、増田さんと僕も参加してきました。

といった感じで、皆さんと熱くドメイン駆動設計についてや、集約の捉え方、設計や仕事をする上で心理学といった人を知る学問の重要性、勉強会は懇親会も出ると学べることが増えるよねといった色々と多岐に渡るお話ができて楽しかったです。

 

まとめると、群馬*5に遠征できて、すごく楽しかったです。
Gunma.web のみなさま、お声がけ頂き、ありがとうございました。

 

DDD Alliance にご相談がある方がいらっしゃいましたら、http://www.ddd-alliance.org/ のページや Twitter アカウント等へお気軽にご連絡ください。

*1:協賛として、UMLモデリングツール Enterprise Architectでおなじみのスパークスシステムズ ジャパン株式会社にもご協力頂いています。

*2:よく一緒に仕事している時に増田さんに怒られますｗ

*3:ま、構造もよくない（少なくとも僕は嫌い）ですがｗ

*4:というか、そもそもきちんとした設計をやれる状態じゃないですね

*5:しかも、高崎！

ドラマ『陸王』最終回に書籍「ビジネスモデル症候群」が目指す経営者の姿を見た

仕事論 ビジネスモデル症候群 起業 スタートアップ

f:id:k_takasaki:20180108005536p:plain

ドラマ『陸王』最終回、見ましたか？
僕は熱いドラマが大好きなので、ドラマ『陸王』も非常に楽しませて貰いました。その『陸王』を見ていた際に、書評を書こうと思っていた書籍「ビジネスモデル症候群」で、僕が思い描く経営者の姿を主人公「宮沢紘一（役所広司）」に見ました。
なので、それを中心に「ビジネスモデル症候群」について書きたいと思います。

そのため、このブログの内容は TBS のドラマ『陸王』の最終回ネタバレを含みます。

www.tbs.co.jp

既に最終回が放送されてから、しばらく経っているので、もうネタバレ含んでも大丈夫かなとは思いますが、ちょっと待て〜という人はドラマ『陸王』を見てから、この先に進むようにしてください。

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

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

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

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

 

Blu-ray と DVD でも BOX が 3 月 30 日に発売するみたいです。

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

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

起業するからには、イノベーションを起こすような突飛なビジネスモデル（アイディア）を持ってチャレンジするといったことが一般的なスタートアップのイメージなのではないかと思います。ただ、そのキラキラした感じ全開でやると失敗する確率が上がるので、いかに経営を軸としてスタートアップをやるかといった解説している本です。

 

ビジネスモデル症候群という言葉自体は、

leanstartupjapan.co.jp

2015 年にこちらのブログで和波さんが発表され、そこから和波さんが色々と活動された内容を盛り込んでいき、2017 年に満を持して書籍化されたといったものです。

なぜ、ビジネスモデル（アイディア）を持つと失敗する可能性が高くなるのかといったことへ心理学を活用して解説する所から始まります。そこから、ビジネスモデル症候群に感染していってしまう流れや環境や背景が紹介され、どうやって脱却していくかといった内容の書籍になっています。

 

僕の人生訓として、「3 人の師匠を持て」というのがあるのですが、その 3 人の中の一人が和波さんなので、この本が生まれていく過程をそばで見ながら、活動のお手伝いをしてきたりしました。

「再現性のある起業プロセス」を科学的に追求していくという和波さんのスタイルや想いが、この本には詰まっています。

あきらめなければ失敗は確定しない

『陸王』最終回

『陸王』最終回のあらすじですが、

シルクレイを手に入れるために「こはぜ屋」買収をもくろむフェリックスの御園社長（松岡修造）だったが、宮沢（役所広司）から業務提携を提案されたことで両者は袂を分かつ。

<中略>

茂木に自分たちの想いを届けることもできず、陸王開発再開のメドも立たず、八方ふさがりのこはぜ屋だったが、そんなある日、御園から宮沢へある提案が投げかけられる。一体、その提案とは！？*2

といった内容です。
ここに至るまでに、「こはぜ屋」という足袋製造会社の四代目社長・宮澤紘一（役所広司）が、足袋だけでは年々先細っていく売上に頭を悩ませ、そこからの脱却を図るために足袋屋として培った技術を活かしたランニングシューズを開発しようとする所からものがたりは始まり、色々と紆余曲折を経て、その新規事業だけでなく会社そのものの存続すら怪しいといった危機的な状況となりました。

その状況の中で、御園社長（松岡修造）から提案された内容について社内で検討している際に、宮澤紘一（役所広司）が語った中に「ビジネスモデル症候群」が目指す経営者の 1 つの姿を見ました。*3

俺は、フェリックスからの融資を受けたいと思う。
途中、返済出来なくなるリスクは確かにある。やり遂げるのは決して簡単じゃないということは重々承知だ。


だけど、挑戦しなけりゃ、負けもなければ勝ちもない。
何一つ成長せずに、ただ生き延びたって、そんなのは、意味がない。
俺は勝負をしたい。
このこはぜ屋を守るためには、挑戦するしかないんだ！


もしも上手く行かずに、全部失ったとしても、まだ死ぬわけじゃない。
この体一つ、心一つ、残っていれば、必ずまた這い上がれる！
そのことを俺は、飯山さんと茂木選手から教わった。
諦めずに挑み続ければ必ず道は開ける。
それを大地から教えられた。
本当の負けってのは、挑戦することをやめた時だ。

融資を返済できなければ、会社が買収されてしまうかもしれないという局面で、宮澤紘一（役所広司）は、あきらめません。

症状その３：経営破綻

ビジネスモデル（アイディア）を持つから失敗するという所が、書籍「ビジネスモデル症候群」としては強調されがちじゃないかと思います。
ですが、僕がこの本で感じた重要なメッセージとしては、症状その３として語られている「アイディアよりも先に経営が行き詰まる」の部分にあると思っています。

長期間「ネバれる」スタートアップの違いは、単純に「思い込みを脱し、真のニーズを掘り当てるまで、経営が継続できるかどうか」です。
ビジネスを成功させることができるかどうかは、アイディアがイケてるかイケてないかではなく、経営がイケてるかどうかです。
スタート時のアイディアの精度はまったく関係ありません。

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

経営が行き詰まるというのは、金銭面もそうですが、経営者のモチベーションが無くなってしまうといったことでも行き詰まりはやってきます。アイディアを試している途中で終わってしまうのです。

実際、自分の会社でもサービス開発をしているので思うのですが、そんな簡単には売れません。また、中々いい結果も出てこない中で、時間は過ぎていくし、お金はかかるといったことが起こります。

そんな中でも、『陸王』の宮澤紘一（役所広司）の様にあきらめず挑み続けて真のニーズを掘り当てれば、失敗となりそうだったことも、すべてはその成功までの糧だったということになります。

 

あきらめなければ失敗は確定しないのです。

地味（地道）な本

あきらめずに失敗を確定させないためには、経営をイケてる状態にしなければなりません。

スタートアップは経営と事業の二重構造だと思っています。
より正確にたとえるなら、1 階が経営、そして 2 階にビジネスが乗っかっている、2 階建ての家のような造りです。1 階の構造が強固であればあるほど、2 階では必要に応じたビジネスが展開できるようになります。

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

といったように、どうイケてる状態にしていくかといったことも触れています。

こういった経営を軸にスタートアップをやるといった話になると、

  • スタートアップを成功させるためのたった○○つの方法　とか、
  • 成功するビジネスモデル徹底図解　とか、
  • イノベーションを起こすアイディアの出し方　とか、

といったようなキラキラしたタイトルの本*4と比べると、地味な内容と取られることがありそうだなと思います。

実際、知人経営者から同時期に読んだスタートアップの他の本と比べて「ビジネスモデル症候群」は地味だよねといった感想を聞いたりもしました。

ですが、本質をついたものは基礎や基本となる型の部分について語ることが多くなるので、そういった印象を持たれやすいのではないかなと思います。

『殺し屋のマーケティング』の作者が本気で選ぶ、ビジネスマンなら読んでおかなければならない「２４冊の特選マーケティング本」《天狼院書店／WRITING LIFE》 | 天狼院書店

という記事で、天狼院書店店主の方も「ビジネスモデル症候群」を取り上げていますが、同じ様なことを書かれています。

 

僕もキラキラしたのは好き*5ですが、やはり地道にやらなければならない所、基礎や基本となる型は大事にしないといけないと思っています。

まとめ

ということで、キラキラした『陸王』の中で熱く語られた内容は、地道にやってきたことに裏打ちされていたが故に宮澤紘一（役所広司）がカッコイイということだと思います。経営者として苦悩・葛藤したり、その中でちょっとした喜びがあったりという日常の中で、地道ながらもあきらめずに挑戦し続けるということが習慣化された経営者としての姿が、そこにありました。

そんな経営者に憧れた人は、スタートアップを始める始めないに関わらず、ぜひ「ビジネスモデル症候群 ~なぜ、スタートアップの失敗は繰り返されるのか?」を読んでみるといいかと思います。
仕事をする中でも経営者的視点を持って仕事をした方が、よいパフォーマンスを出すことが多いと思いますので。

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

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

 

また、師匠である和波さんと話していると、この本の中では少なかった HowTo よりの話などを実施されている Lean Action Program の中などで、今後展開されいくみたいです。こちらも、乞うご期待です！

もう少し、『陸王』と絡めて「ビジネスモデル症候群」を語りたい所ですが、長くなったので、また別の機会に。

*1:色々と書籍「ビジネスモデル症候群」に繋がる所があったので、その辺りもそのうちブログで書きたいと思います

*2:あらすじ｜TBSテレビ：日曜劇場『陸王』より

*3:最終回の 12 分 10 秒ぐらいの所からです

*4:適当にそれっぽい名前を即興で書いてみたので、もし似通ったものがあったとしても dis ろうという意志は無いですが、ちょっとHowTo より過ぎかな〜とは思いますｗ

*5:まあ、陸王で盛り上がってる時点でキラキラ派ですねｗ

記録に残るか？記憶に残るか？ 〜BPStudy #124 で高崎健太郎愛あふれる LT 登板をした際の発表アイデアの練り方

登壇 仕事論 勉強会 野球

f:id:k_takasaki:20171226203953j:plain
12月19日(金)に BPStudy*1で LT をさせて頂きました。・・・と前回とまったく同じ書き出しからスタートしますw

が、今回は、LT で伝えたかったことのまとめと共に、どの様に LT に向けてアイデアを練っていったかという所にフォーカスして書いてみたいと思います。どこかで発表をしようという人へ参考の一つとなればと。

bpstudy.connpass.com

BPStudy の毎年 12 月と 3 月の回は、名称が Baseball Play Study になって、野球好きのエンジニアとそのフレンズたちが集まる野球の祭典回となります。
データサイエンス、サイバーメトリクス、テキストマイニング、機械学習などを絡めたエンジニアリングしているネタから、四象限で分析をしたもの、ただただ野球愛を語るものといった色々な野球 LT があって、野球好きにはたまらない回です。

詳しくは、以下の togetter を見て頂くとライブ感ある雰囲気を感じ取って頂けるのではないかと思います。

togetter.com

で、今回、僕は「記録に残るか？記憶に残るか？」といったタイトルで、横浜DeNAベイスターズの投手「高崎健太郎」さんについて熱く語ってきました。

資料は、以下です。

LT登板決定まで

発表に至ったキッカケ

既にお気づきかもしれませんが、「高崎健太郎」投手と僕は同姓同名です。
彼がドラフト希望入団枠で横浜ベイスターズ*2入りが決まった翌日に、出社したら上司から「高崎さん、ドラフト一位おめでとうございます」と言われました。当時あまり野球をウォッチしていなかった僕はググって、同姓同名の選手が横浜に入ったということを知ったのが最初の出会いでした。

が、スライドの通り僕は巨人ファンなので、まあ同姓同名の選手が活躍して巨人に移籍したらいいなぁと思った程度でした。

それから、気にはなって、たまにチラチラと成績を見ていたり、勉強会やイベントで横浜ファンの人に名刺を渡すと喜んで貰えるといった程度の繋がりがありました。
そんな中、ついに今年、現役引退されるとの発表が出たのです！

少しして Baseball Play Study の募集が始まり、このタイミングを逃すと、この同姓同名というおいしいネタを使って話すタイミングが無くなる！という焦りｗと、今までは参加した際に聞く側だけだったけれども、アウトプットすることの大切さを

このブログでも書いてますが、最近非常に大事だと考えているので、「発表することがあるから発表する」のではなく「発表すると決めてからテーマを探す」ということを常々言っている佐藤 治夫さん ( @haru860 )の言葉に従って公募 LT に真っ先に申込みました。

LT登板への準備

さて、そんな展開で LT 登板を決めたので、「高崎健太郎」投手という掴みのネタは決まっているものの話す内容・テーマは決まっていませんｗ

また、チラチラ見ていた程度なので、それほど深く「高崎健太郎」投手を知っている訳でもありません。

まずは調べる

ということで、キチンと知るためにインプットをしなければならないと考え、まずは、「高崎健太郎」投手を改めて深く調べることにしました。

チラチラ見ていた際にも、見た記事ではあったのですが、

column.sp.baseball.findfriends.jp

といった元 SMAP の中居くんが「高崎健太郎」好きらしいです。巨人ファン繋がりもあるので、コレは発表する際のネタの一つになるのではとストックしました。*3

www.baseballchannel.jp

また、引退の発表後でしたので、引退に関するニュースが多く出てきました。
ココで、DeNA の黎明期*4を支えたという活躍の歴史や成績を情報として仕入れ、この辺りがキーワードとして何か使えるのではないかと考えました。

そんな活動をしていた中、何か虫の知らせが届いたのか

 と、BPStudy 繋がりのにがうり ( @nigauryyy )さんからステキなリンクが送られてきました。
この記事も読んで、前述の中居くん同様に「高崎健太郎」投手は、かなり愛されていた様だということをヒシヒシと感じました。

集めた情報からメインとなるキーを探す

色々と調べていく中で、いくつか情報やキーワードが集まってきましたが、その中でもインパクトがある何かキーになるようなモノがないかなといった視点で、集まったモノを整理していきました。

その中で、

www.baystars.co.jp

この現役引退のお知らせの中にある本人のコメントの書き出し

一番の思い出は、球団が横浜DeNAベイスターズになり、新球団としての第一球目を投げられたことです。

この部分が、やはり彼を語る中で一番のキーになるのではないかと思いました。

メインとなるキーと伝えたいこと（何らかの価値）をリンクさせる

エンジニアや経営者などが集まったビジネス的*5な勉強会なので、ビジネス話や仕事論に繋がると何らかの価値が生まれるだろうと考えました。
なので、その見つけたキーとなる部分が何か伝えたいこと（何らかの価値）に繋がらないかと、さらに思考を巡らせました。*6

ふと、直近の新球団*7になった他の球団の開幕投手は誰だったんだろう？という疑問が自分の中に生まれ、自分が気になったということは他の野球好きの人も興味を持ってくれるネタになるのではないかと思いました。

で、福岡ソフトバンクホークスと東北楽天ゴールデンイーグルスを調べてみたら格のあるピッチャーばかり。さすが開幕投手。
ということで、コレはメインに使えそうなネタだなと改めて思いました。

実際、そのネタはツイートされていたので狙いはあっていたのかなと。

新球団で開幕投手という記録に残ると、みんなの印象に残るんだなという、今回伝えたいこと（何らかの価値）がおぼろげながら見えてきました。

タイトルを決める

伝えたいことを更に洗練させようと、「言葉」としてまとめることにしました。
「言葉」としてまとめると、自分の考えがはっきりと形になり、自分の中でもテーマをしっかりと捉えられるようになります。結果として、それがそのままタイトルになることが多いです。

タイトルになるので、ある程度はキャッチーな方が聴衆を引き込めると思っています。
今回は、

新球団で開幕投手という記録に残ると、みんなの印象に残る

といった伝えたいことを軸に、よく「記録よりも記憶に残る選手」といった言葉を聞くので、その言葉に絡めることでキャッチーさを出し「記録に残るか？記憶に残るか？」といった言葉にすることにしました。
記録に残ることで記憶に残るというテーマが明確に固まりました。

伝えたいことに繋がるエピソードや事例を盛り込む

テーマが決まったら、それに対してのスライドを作っていきますが、そのテーマを肉付けするエピソードや事例があると、より伝わりやすくなります。

ビジネス的な方への肉付けとして、自分が研修講師をやっている時があるのですが百人規模の生徒がいると申し訳ないですが全員を覚えることができないといったエピソードがあったので、それを盛り込むことにしました。中間のボリュームゾーンに入ってしまい目立たないぐらいであれば、成績悪いトップ層で記録に残ると、まずは名前を覚えて貰えます。そこから V 字回復すると人間の印象とは不思議なもので、あいつは頑張ったからスゴイとなります。目立たないままでいるより、良い展開になります。
まあ、そのまま成績悪いと駄目ですし、成績良いトップ層になれるなら、そっちの方がいいですがｗ
記録に残ると記憶に残って、諦めなければ逆転のチャンスがあるよって話だと思っています。

また、「高崎健太郎」投手との名前以外の共通点や、今年、人生初の 2 軍戦を横須賀スタジアム（スカスタ）に見に行くということをした*8のですが、その際に先発「高崎健太郎」投手だったという奇跡をエピソードとして盛り込み、愛あふれる内容も肉付けして発表内容にストーリー性を持たせました。

ネタの検証をして面白そうなことを盛り込む、もしくは冗長なモノを削る

そんな内容がだいぶ固まって来た所で、「高崎健太郎」について話そうと思っているという話を BPStudy の 1 週前のタイミングで機会があったので、ちょっと小出しにして話をしてみたりしました。自分がやろうとしてるネタが面白いと思って貰えそうかといった検証です。

その会話の中で、高崎愛のためにやろうか迷っていたネタの一つ「高崎健太郎」選手の名前入りユニフォームを着て登板するがウケそうだということが判明したので、その日のうちにメルカリで手配しましたｗ*9
そして、当日、ユニフォーム生着替えというネタが完成しました。

f:id:k_takasaki:20171228015846j:plain

逆に、中居くんのネタや、また、記録に残って記憶に残るという所で、中途採用面接や面談に来た人が資格を持っていると「あー、あのネットワークスペシャリストの人ね」といった感じで印象に残ることが良くあるから資格も役に立つ所があるよというエピソードもあったのですが、その辺りは時間の都合もあり削りました。

 

こうして、振り返ってみると LT で 5 分喋るために、色々と準備しているなぁ。

まとめ

【LT で伝えたかったこと】

記録に残ると記憶に残ります。
2位じゃ駄目なんですよ。忘れ去られちゃうｗ*10

【発表アイデアの練り方】

僕流な要素が強い所もありそうですが、「発表すると決めてからテーマを探す」ことへの一つのやり方として参考になればと思います。
ここまで読んでくれた人が、参考にしてくれて、どこかで発表をしてくれると、面白い話が聞けるんじゃないかと僕も楽しみです。

  1. まずは調べる
    発表する内容のインプット大事。
  2. 集めた情報からメインとなるキーを探す
    何らかインパクトがあった方が伝わりやすいのでキーとなるものがあるといい。
  3. メインとなるキーと伝えたいこと（何らかの価値）をリンクさせる
    そのキーと、伝えたい何らかの価値を結びつけて、テーマとする。
  4. タイトルを決める
    タイトルを決めることでテーマで伝えたい事が「言葉」としてイメージしやすくなる。
  5. 伝えたいことに繋がるエピソードや事例を盛り込む
    伝えやすくなるように、肉付け。
  6. ネタの検証をして面白そうなことを盛り込む、もしくは冗長なモノを削る
    やろうとしていることが間違っていないか検証して反映する。
　※ 発表に向けての準備は大事。

最後に

 といった様に「高崎健太郎」さんは、横浜DeNAベイスターズの球団職員として第2の人生を歩まれるとのことです。

第2の人生でも、記録に残って記憶に残るご活躍のお話が流れてくる日を楽しみに、応援しています！

追記 (2018/1/7)

いい記事が出ていたので、追記。
1軍での引退試合はクライマックスが絡んでたから、固辞したとのこと。

過渡期を支えた高崎健太郎の存在がなければ、ＤｅＮＡの２年連続Ａクラス入りは成しえなかっただろう

sports.yahoo.co.jp

追記２ (2021/12/21)

今年のニュースをふと振り返っていたら、あれから10年という記事が出ていたので、追記。開幕の時のバッテリーが復活。 

www.nikkansports.com

*1:株式会社ビープラウドさんが、2007年9月から毎月１回のペースで開催しているWeb系勉強会。120回を越える実施回数という凄い勉強会

*2:当時は、まだ横浜ベイスターズ

*3:実際には、このネタは発表内容が巨人に広がって時間内に収まらなそうと思ったので使いませんでしたが。

*4:暗黒時代？？

*5:一応ｗ

*6:キーを考えていく中でも「伝えたいことは何か？」は並行して考えてはいました

*7:経営母体が変わった所として定義

*8:もちろん、巨人 2 軍の応援で行ったのですが、「高崎健太郎」投手が出てくると両方応援してしまうので困ったものでしたｗ

*9:結果、人生初の名前入りユニも巨人じゃないものになりましたｗ

*10:イチロー「２位じゃ駄目なんですよ」 代打安打記録にあと１本届かず - 野球 - SANSPO.COM（サンスポ）

一流のエンジニア／経営者になるため基礎力を磨け！ 〜BPStudy #123 で LT 登壇してきた

登壇 仕事論 勉強会

f:id:k_takasaki:20171218025058j:plain
11月24日(金)に BPStudy*1で LT をさせて頂きました。

bpstudy.connpass.com

技術書籍執筆について、著者の方々が、書籍を書くときのコツや、進め方のノウハウ、執筆時のエピソード、体験談などを語ってくださる回でした。
第4部 LT大会パートで登壇しました。
資料は、以下です。

発表内容

伝えたかったこと

今回の LT で、僕が伝えたかったことは、「スポーツと歴史」には、ビジネスやエンジニアリングの（人としての）基礎力を磨くための学びの要素がいっぱいあるよ！ということです。

一流になるためには、やはり基礎の部分（土台）が大切になってきます。
そこに対するアプローチとして「スポーツや歴史」から色々と学ぼうと。

それをスライドの順を追って、辿っていきたいと思います。

一流のエンジニア／経営者 とは、

まず、「一流」という定義を擦り合わせしておかないと LT の聞き手や、このブログの読み手との感覚がズレてしまいそうなので、自己紹介スライドに定義を書きました。*2

原点(コア)となるものを確立していて
常に現状に甘んじることなく
新たなことに挑戦し続ける人で
周りの期待に結果を出していく
そんな人が一流のエンジニア／経営者だと思います。

といった様な所が僕が思う一流感です。ちょうど、今回の LT 内容で伝えたかったことの影響を受けたプロフェッショナル 仕事の流儀*3のような雰囲気が出てきたので、その路線で演出も進めました。*4

一流になるには、学びが必要

どんな分野でも一流になるには、やはり色々なことを学ばなければなりません。
また、日々の積み重ねも大切なので学びを習慣化させることも大事です。

日々の積み重ね＝努力といえば、やはりイチロー選手。

一流のアスリートは、様々な局面を戦って乗り越えてきています。そういった人のやり方や生き方は、自分や自分の周りでの出来事に当てはめてみると色々と気付かされることがあります。
特にイチロー選手は、非常にストイックなので、その要素が足りていない (^_^;) と自覚している僕や、今ちょっとドキッとされた方には物凄く気づきを与えてくれる存在です。

学びを得る要素

学びは、自習、経験、環境といった要素から得ることができると思っています。

  • 自習
    本（技術書*5、ビジネス書など）やネットを調べたり、自分で実践してみたりと黙々と勉強することは、学びを得る要素としては非常に大きな要素です。
  • 経験
    自習するだけでなく、日々の活動の中でも、色々と気づいたり学んだりといった経験からの学びがあります。
    実際、エンジニアだと、ただコードを書いているだけでは気づけないこととして、運用業務やトラブルシュートをしている中で、こういうプログラムにしておいた方がいい、こういう情報の出力の仕方にした方がいいといった様なことに気がつきます。それは、経験しないと中々分かりません。
  • 環境
    そして、学びを得る要素として、あまり普段意識しないかと思いますが、周りの環境も大きな要素となります。
    どんな人と一緒にやるか、どんな人から学ぶか、知らず知らずのうちに人は一緒にいる人達から影響を受けています。
    そのため、何かをやりたければ同じ想いを持つ人達と一緒にいることが、そのやりたい事に対する学びを加速させます。ある技術や方法論について学びたければ、そういったコミュニティや著名人、研究している人と一緒にいるだけでも、その技術や方法論についてが自然と話題の中心になる中で学びに繋がります。*6

イチロー選手で考えると、「自習」として日々黙々と練習をしたり、ストレッチで体の柔軟性を高めたりと学びを得て、「経験」として試合の中での相手投手との駆け引きや、自分の打球の行方がどうなったかなどから学びを得て、「環境」としてメジャーリーグという野球のトップの世界で得る大きな学びがあるといった形です。

原点（コア）、変わらない自分

一流になるために色々と学んでいく際に「守破離」*7の考え方が大事だと思っています。

「守破離」なので、まずは「守」の部分で学んだことをそのまま使いこなせるようになることが最初の段階ですが、いつかは色々と学びながら「破」や「離」に繋げていく必要があります。
その際には、やはり自分らしさ（自分としての原点）が出てこないと「破」や「離」には繋がっていきません。

学びを得ていく中で、挫折や葛藤も必ず出てくるので、その際にも自分の原点に立ち返って、何がしたいのか、何が楽しいのかといった様なことを軸にすると、自分らしさを発揮しながら学んだことを活かしていけます。

ぶれない軸を持って、学びを得て基礎力を高め基盤を固めることが、その上に応用的なことをのせた際にも、ぐらつかずに力を発揮できます。

こういった挫折や葛藤をアスリートは、非常に早いサイクルで繰り返しているので、彼らのインタビューやドキュメンタリーは、そういった面で学びが多いです。自分の原点に立ち返って、挫折や葛藤を乗り切るパターン*8も多いので。

そういった番組として、オススメなのが プロフェッショナル 仕事の流儀 と アスリートの魂。
今回の発表に大きな影響を与えた放送回が以下のモノたちでした。

NHKスペシャルのコレも良かったです。

NHKさんからの学びが多いようですｗ

学びを、あたえてくれるもの

基礎力を学ぶ要素として「スポーツと歴史」がいいよ！ということで、スポーツ部分については既にココまでの文章で大分盛り込んできたので、歴史の方についても、ちょっとだけ。

  • 失敗は繰り返す
    人は同じ失敗を繰り返します。
    人間の本質は何年、何百年、何千年と経っても大きくは変わっていません。同じ失敗は繰り返されているので、先人がやった失敗を学んで、それに対しての対策を考える、同じ過ちをしない様にするといったことは、非常に大きな学びになります。
  • 共通の話題になる
    歴史上の出来事や人物は、みんな学校で歴史の勉強をしたり、大河ドラマを見たりしているので共通認識できる話題になります。*9
    そのため、何かをみんなで学ぶ際にその内容をシチュエーションとして当てはめて考えることなどに使え、認識共有の時間を短縮して学びに繋げることができます。
  • 戦略、戦術の勉強になる
    スライドには入れてませんが、歴史は戦国時代や幕末など戦いの話がたくさんあります。その中で、歴史上の人物がどの様な戦略や戦術を考えたか、そういった所は、やはり学びに繋がります。

まとめ

長くなったので、スライドのまとめを見て頂ければとｗ

一番伝えたいのは、 「スポーツと歴史」には（人としての）基礎力を磨くための学びの要素がいっぱいあるよ！ということでした。

最後に：お礼

「発表することがあるから発表する」のではなく「発表すると決めてからテーマを探す」ということを常々言っている佐藤 治夫さん ( @haru860 ) に LT 登壇に誘って頂いたお陰で、最近考えていたことをアウトプットでき整理できるという機会に繋がりました。
アウトプットすることの大切さを、

このブログでも書きましたが、そういった機会に誘って貰える「環境」にいれることが、自分の学びに繋がっているなと思います。
お誘い頂き、ありがとうございました。

ここまで、このブログを読んだ方はスポーツからの学びについて興味を持たれたのではと思いますので、ぜひ、スポーツ（野球）についてエンジニアや経営者が熱く語り合う以下の勉強会に、ご参加されることをオススメします！

今月は、同じ BPStudy でも Baseball Play Study になってますｗ

おまけ

Keynote で作成した スライドを SlideShare にアップしているんですが、Keynote で作ったものは一度 PDF 化して、その後、アップしなければなりません。
そうやってアップした所、日本語部分が一部のフォント以外は消えて無くなるという問題が前から発生していて、僕のスライドはインストールしたフォントを多用しているせいか、ほぼ中身が無くなります。。。そうすると表示されるように、画像化するとか色々と面倒です。
更に、今回は SlideShare にアップしたスライドの差替が機能的にできなくなったりしたタイミングだったこともあり。。。

その際に便利だったのが、以下のブログ。ありがとうございました。

SlideShare さん、早く、この日本語問題解決してくれないかしら。。。

*1:株式会社ビープラウドさんが、2007年9月から毎月１回のペースで開催しているWeb系勉強会。120回を越える実施回数という凄い勉強会

*2:結果、定義部分の話をしていたら自分の名前を言い忘れるという失態をやらかしましたがｗ

*3:NHK の番組。今回の LT に内容的にも演出的にも多大な影響を与えている

*4:コレは、大分いい感じに仕上がったと思う（再現度が高いというツイートもあり）ので、会場で見た方には面白さとして価値を提供できたのではないかと

*5:今回の勉強会テーマに合致したポイントはココだけなので、アピールしときましたｗ

*6:ということで、Java で ドメイン駆動設計（DDD）をやりたい人やモデル駆動型ソフトウェア開発に興味がある人は、アクティアにまずは遊びにくると学びが加速しますｗ

*7:日本での茶道、武道、芸術等における師弟関係のあり方の一つ by Wikipedia

*8:番組編集の都合かもですがｗ

*9:どの歴史論や時代考証が正しいとかは置いておいて、話題レベルでは

DDD Alliance! 現場で役立つシステム設計の原則 Night!を主催した 〜みんなで創ろう勉強会

勉強会 DDD

これは、感謝のものがたりである。
すこし苦言めいたものも含んでしまうかもしれないが、その実態はやはり感謝しかないといった話である。
勉強会を主催していて、改めて気がついた感謝について、まとめておきたい。

僕は、いくつかのコミュニティ*1の主催をやっている。それらについて細かくは、このブログでいつか書いていくだろう。
今回は、少し前に*2開催した「DDD Alliance! 現場で役立つシステム設計の原則 Night!」という勉強会での気付きである。

ddd-alliance.connpass.com 

今回の勉強会の内容

DDD Alliance とは

今回の勉強会は、DDD Alliance というコミュニティが主催している。
DDD Alliance とは、日本でドメイン駆動設計について調べ始めたら必ずたどり着くという有限会社システム設計の増田さんと、株式会社アクティア、そら製作所、井上屋で立ち上げたドメイン駆動設計の実践経験を基にしたワークショップやオンサイトワークショップ、コンサルティングを展開しているコミュニティです。*3

ドメイン駆動設計をシステム開発の現場で活用することにお悩みの方々の一助になればと、日々活動しています。

今回の勉強会

そんな活動の中で、今回はその増田さんが執筆された「現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法」の刊行記念イベントといった位置付けで、書評 LT と増田さんからの書評や感想・疑問へのアンサーといった形での豪華 2 本立ての勉強会でした。

ザッと、まずはどんな勉強会だったかを振り返ってみましょう。

書評 LT

書評 LT は、この本のレビュアや書評をブログに書いた方 3 名と公募枠 2 名の計 5 人に登壇頂いて、それぞれ熱い想いを語って頂きました。

書評LT その１　オブジェクト指向を学んで図解力＆仕事力アップ！

書評LT その１は、株式会社ビープラウド 佐藤 治夫 ( @haru860 ) さんが書籍に関連してオブジェクト指向や UML を業務の中でどう活かしていくと良いかといった話をしてくれました。
書評LT その２　『現場で役立つシステム設計の原則』は一般的なSI現場で役立つのか？

書評LT その２は、書籍レビューをされた株式会社デライトテクノロジーズ 綿引 琢磨 ( @bikisuke )さんが、一般的な SI 現場でどれぐらい役立つのか？といった観点で考察＆評価した話をしてくれました。
書評LT その３　この本は理想の開発を綴ったものなのだろうか

書評LT その３は、野崎 啓史 ( @irof )さんが、本の感想から始まり本の内容をピックアップ、そもそも理想の開発てなんだろうという所と絡めた話をしてくれました。
書評LT その４　「現場で役立つシステム設計の原則」をウェブサービスの現場で役立てたい

書評LT その４は、公募枠で応募頂いた松本 ( @nunulk )さんが、ウェブサービス開発の現場の中でこの本をどう役立てていけそうかといった話をしてくれました。
書評LT その５　現場で役立つシステム設計の原則への感謝
書評LT その５は、当日の朝（！）公募枠が空いていたからと飛び込み応募頂いた石橋 亮 ( @gelegele )さんが、この本に出会うまでの経緯と開発現場の教科書の様なこの本への感謝といった話をしてくれました。

書評や感想・疑問へのアンサー

LT パートに続いて、増田さんが書評や感想・疑問についてアンサーソング的な感じで話をしてくれました。

そして、その後、Q&A タイムとなり、いくつかの質問に対して増田さんが回答していくといった形式で進みました。

感謝 その１　発表者の皆様ありがとうございます！

まず、こうしてスライドを並べてみても思う所ですが、忙しい中、発表への準備としてスライドを作成頂いたり、練習をされたりと多大な労力がかかっているかと思います。それを引き受けて頂いた発表者の皆様へ感謝です。皆様がいないと、そもそも勉強会が成り立ちません。

 

主催者は勉強できない

今回、書評 LT と増田さんの話すパートがあった訳ですが、僕は主催者として、LT でのタイムキープや、発表者のマシン入替えの補助や場合によっては自分のマシンに資料を入れて貸出したりと非常にバタバタしていました。

今回の勉強会は、本に絡めた形でイベントをやりたいと僕が言い出し、企画してといった流れで開催することになった勉強会で、内容そのものに僕も大変興味があり勉強になるだろうなと思っていました。

が、ふと気がつくと、「あれ？オレ、メモしてる時間とマシンがないぞ！？」という状態で。。。

時計とにらめっこして時間管理したり、マシンを貸出しているとスキマ時間が少しになり、いい発言があったからメモしようと思ってもしている時間がないのです！

そんな中、後から振り返ってみると以下のような感じで、皆さんがまとめてくれていたものを発見しました。僕がメモしたかったことを他の人が発信してくれているというありがたい状態になっていたのです。

Twitterでのまとめ

Twitter で参加者の皆さんがハッシュタグ（#dddalliance）をつけて呟いたものを、@fullvirtue さんが togetter でまとめてくれました。
皆さんがこれだけ呟いてくれていると、ライブ感がある状態で勉強会を振り返ることができます。

ブログでのまとめ

vermeer.hatenablog.jp

参加頂いた @_vermeer_ さんは、ブログにまとめてくれていました。
全般の紹介と共に、増田さんが話された内容について @_vermeer_ さんの解釈や思いもまとめられているいい記事です。

 

shacho.beproud.jp

LT で登壇された佐藤 治夫 ( @haru860 ) さんは、話した内容に補足をつけてブログにまとめてくださってます。

感謝 その２　呟いたり、まとめて頂いた皆様ありがとうございます！

まとめて頂いた方たち、Twitter でハッシュタグ付けて呟いてくれた皆様も含め、情報発信をしてくれる人達がいるお陰で、忙しい主催者も後から振返りやすいというありがたい状況になっています。
また、情報発信して頂けることで、その勉強会やコミュニティの内容が広がって広報につながりますし、勉強会やコミュニティが盛り上がったことも伝わってくるので、非常にありがたいです。 

みんなに支えられた

発表者、情報発信者だけでなく、勉強会は色々な人に支えられています。

ステキな質問

今回の勉強会では、Q&A タイムがありました。
この Q&A タイムですが、質問が出てくるといいのですが、日本人の気質か中々出てこないといったことが起きたりします。そんなことになってくると主催者サイドはどうしたものかといった展開になるのですが、今回の勉強会では

 といったような感じの呟きが出たりと良質な質問が次々に出たので助かりました。

会場の設置

また、忘れちゃいけないのが裏方さんたちです。
今回は、会場としてグロースエクスパートナーズ株式会社さんの G's LounGe という会場をお借りして開催しました。
そうすると、会場の設営をグロースエクスパートナーズ株式会社さんの社員の方に手伝って頂いたり、諸々、手配を頂いたりと沢山お手伝いいただきました。
勉強会中にもお礼をしましたが、改めてありがとうございました。

さらに、受付や会場の設営、後片付けを DDD Alliance メンバーや弊社社員が手伝ってくれており、彼らにも感謝です。

感謝 その３　質問頂いたり、会場設営にご協力頂いた皆様ありがとうございます！

質問が出ることで場が活性化したり、そもそも会場が無ければ勉強会はできません。
そういった「場」を提供する所に協力頂いた人達がいるからこそ、おかげさまで勉強会が盛り上がっています。

参加率の問題

ここまで、感謝の言葉いっぱいで進んできたが、ここで悲しいお知らせである。
読んで頂いた通り、勉強会は発表者、参加者、運営側といった様々な人に支えられて成り立っています。
主催者サイドとしては、実施するからにはより多くの人に参加頂いて、価値ある場を作っていきたいと考えています。そのようにして会を開催していると、人気がある内容だと補欠者が出るようなこともよくあります。ですが、そういった状況となった場合でも当日に参加キャンセルやそもそもキャンセルすらせずに来ないといった一部ちょっとどうなのかと思われる参加者*4の方が見受けられるのが運営をしている中で見えます。もちろん、当日体調が悪くなったとか、急な仕事の都合でといったこともあるかとは思いますが、それでもコメント付けてキャンセルするぐらいは礼儀なのではないかなと思ってしまう訳です。*5

他に勉強会をやっている方とも情報交換してみると、だいたい晴れの日で 2 割来ない、雨の日だと 3 割〜 4 割ぐらいの人がドタキャンするといった傾向のようです。
そうなると、実施するなら満席に近い状態にしたいと思う主催者サイドも本当に来てくれる人だけに応募して欲しいと思い、あの手この手を駆使してみようとするわけです。
例えば、有料化することでお金を払ってでも来たいという冷やかしレベルの人を除くようにする*6とか、あまりにドタキャンが多い人をグループのブラックリストに入れると警告するとか、「絶対参加する枠」といった枠を作って優遇するとか、会場のキャパよりも多めに募集する*7とか。
ドタキャンが出ることを見越して、たまに補欠の人でも「来ちゃった♪」って感じでくる人もいたりするので、キャパより多めに募集って対策と組み合わさってしまうと、飛行機でのオーバーブッキングの様に強制的に追い出されるみたいな事故も起こっちゃうんじゃないかなとも思ったりします。

僕らに限らず勉強会を主催する側の人も、こんな対策を考えたくて勉強会を開催しようと思った訳ではないので、気持ちよく勉強会を実施できるように、参加者側も一部どうかと思われる参加者にならないようにして頂けると、良質な勉強会が今後も増えていくんじゃないかなと思っています。

これからも、みんなで創っていこう

と、ちょっと愚痴っぽい苦言を書いてしまったのですが、最初にも書いた通り、みんな（発表者、参加者、運営側）に支えられて勉強会は成り立っているので、みんなに感謝です。

この記事をまとめてみて、改めて、それぞれの立場の人に感謝ポイントがあるということを実感しました。
これからも、その感謝を胸に、色々と勉強会を企画していきたいと思います！
でも、僕一人の力はたかがしれているので、皆さんのご協力もお願いいたします。

みんなで創ろう勉強会！

*1:どんなコミュニティをやっているか知りたい方は、お手数ですがリンクから飛んでください。

*2:2017/8/30 に開催。

*3:協賛として、UMLモデリングツール Enterprise Architectでおなじみのスパークスシステムズ ジャパン株式会社にもご協力頂いています。

*4:正確には応募者か

*5:礼儀正しく、きちんとコメント付けてキャンセルしてくださる方も大勢います

*6:ただ、前金制じゃないとあまり意味が無いことを実証済み。。。

*7:僕の主催イベントではやってないですが

個人ブログはじめました 〜情報発信の大切さ

仕事論

f:id:k_takasaki:20170904002955p:plain

ここに至るいきさつ

なんでブログを書くことになったのか

三日坊主とは僕のためにあるキーワードといった思いがあるぐらいなので、ブログなど始めても続くわけがないと思い、今までブログを書くといったことはしてきませんでした。

遡って考えると、ブログを書いているとカッコイイ、いつかはインフルエンサーみたいなイメージもあり、正直キラキラ好きのミーハーな僕としては食いつきたい所ではあったものの、食いつかない間に、すっかりブログが普及してブログ書くよりインスタに代表する SNS とかやった方がキラキラするよね（って、インスタもほとんどやってませんがｗ）って世の中になっていました。で、ますますブログやらなくなってという流れで。

Twitter で呟いてみる、facebook で発言してみるといったことは、ちょっとやっていたものの、コレだとちょっと情報発信力が足りないなと思い始めた所に知人からのすゝめがあったことにより、自分に継続して書けるかどうか分からないけど、やってないことをやるって意味でもブログを書いてみようというきっかけとなりました。

また、すゝめられただけでなく、自分としての想いもあったので、一回目ということもあり、その辺りをまとめてみます。

@haru860 からのすゝめ

僕にブログをすゝめてくれたのは、佐藤治夫さん(@haru860) で、ご自身も「ビープラウド社長のブログ」というブログを書かれています。

shacho.beproud.jp

最近、治夫さんの中でブログ熱が高まってきている様で、端から見ていると、すごい勢いで良質なまとめ投稿を連続されているなといった感じのブログとなってますので、ぜひ読んでみてください。

 

で、その治夫さんは「発表すれば人生が変わる」といったことをよく言われており、アウトプットの重要性を色々な所で発表されています。一緒に飲んでいる際にも、そんなアウトプットの大切さについてお互い語り合っていた訳ですが、その中で以下の 2 点が僕にブログを書いてみようという気持ちを後押しをした点でした。

 

・社長ブログを書いている人が少なくなっているから逆張りだ！

　大手がやっていることを真似しても中小企業は勝てないといったことを常日頃から語られている治夫さんは Python が流行る前から特化して会社で扱ってきたといった逆張りの人なので、SNS に押されて下火になりつつあるブログを使って情報発信することで、逆張りになって注目される可能性があるよねといった話をされていました。確かに、「社長ブログ」でググってみると、まとめサイトとかも 2015 年辺りが多く、また超有名なブログばっかりだったりするので、ニューエイジ的な感じで入り込む余地があるかもしれませんｗ

 

・Twitter や facebook だと流れてしまうが、ブログなら残る！

　Twitter や facebook は出したタイミングでは賑わったりするのですが、仕組み的なものもあり、それが継続せずに流れていってしまいます。

前述の通り、Twitter で呟いてみる、facebook で発言してみるといったことは僕もやっていたのですが、何か想いの丈を書いたものが流れていってしまっていいのだろうかといった悩みとなりつつありました。

実際にブログを書いている治夫さんに聞くところによると、ブログであればある日、大昔に書いたものが検索でヒットしてたどり着いてくる人がいるよといった話を聞き、それはいいなと思いました。

会社での発表

株式会社アクティアでは、月に 1 度、全社員（および参加可能なパートナーさん）でビアバッシュ形式の全社ミーティングを実施しています。その中で、社員（役員含む）持ち回りで LT を実施しており、プロジェクトの内容や近況、興味を持っていることや、何らか発表したいことを発表するといった形のミーティングとなっています。

f:id:k_takasaki:20170904001621j:plain

7 月の発表者*1に僕も入っていたので、何を話そうかと思った際に、調度いいタイミングだったので、ブログなどを始めとするアウトプット（情報発信）の大切さについて話そうと思い、発表内容をまとめました。そして、発表内容にはオチが必要だよねという思いとともにラストページに「個人ブログはじめましたす」というページを作ってしまったのですｗ

そうやって自分を追い込むことと、そこでは語りきれなかったことをブログに書こうという思いで、この回を執筆し始めました。

 

と、ここまで、すゝめによって突き動かされてきた話でしたが、更に自分としてもアウトプット（情報発信）の重要性に対する想いが、ちょうどムクムクと頭をもたげてきていたというタイミングだったのがあり、その辺りを続けます。ちょっと長文になってきましたが、もう少しお付き合いください。

インプットとアウトプット

インプットは大事

人は学ばなくなると成長がそこで止まってしまうので、常に学ぶこと（インプットすること）は大事です。

本を読む、勉強会やセミナーに行く、日々の業務の中で蓄積するといったように、量や質に差はあるものの色々な所で情報収集（インプット）していくことを皆さんも意識されて実行されているかと思います。

僕も、知らないことは知りたいという好奇心旺盛なタイプなので、日々の業務や色々な勉強会に参加したりとインプットをする活動は積極的に実施してきました。

そもそも、インプットしないと蓄積されたものが無いのでアウトプットしようにも何も出すものが無いということにもなってきます。

インプットしただけだと整理されない

ただ、漫然とインプットしただけだと、その情報はきちんと蓄積されることなく、再度、必要と思われるタイミングで出てこなかったり、いつの間にか記憶の中から無くなってしまいます。

それは体系化されて自分の中に残る状態になっていない、整理がされていない状況になってしまっているからです。

記憶に残したり、後で活用するために、メモを取ったりもするわけですが、その情報をうまく活かすことができないといったことになりがちです。

アウトプットするためには整理と更なるインプットが必要

インプットを体系化して残せなかったり、うまく活かすことができないのは、それを活用する際のゴールイメージが無いことに起因していることが多いです。

ゴールであるアウトプット内容が見えてくると、そのためにどう体系化して整理するべきかといった事が見え、更に足りない情報があれば的確にインプットしていくといったことに繋ります。

 

f:id:k_takasaki:20170904002149p:plain

インプットとアウトプットは、表裏一体です。

インプットで素材を集めて、料理してアウトプットする、そして、そのアウトプットに対するフィードバックを新たな学びとして、またインプットするといった様に繰り返していくことで、インプットとアウトプット双方の質を上げていくことに繋ります。

また、アウトプットすることで、アウトプットしたものに共感する人やモノとの繋りが生まれていくことにもなります。

アウトプットのレベル感

アウトプットには、レベル感があると思っています。

 

Twitter や Facebook など少しの文章でのアウトプット

　↓

発表用スライドなど文章より見せることを考えたアウトプット

　↓

ブログなど記事としてのある程度の文章でのアウトプット

　↓

本を書くなど、それなりの文章や見せることを考えたアウトプット

 

といった様に、レベル感が進むに連れて、インプットの量も質を増やしたり、しっかりとアウトプットの構成を考えたりといった事が必要になってきます。レベルが上がることで、学びや繋りが生まれていく量も増えていくといったメリットにも繋がるので、レベルが高いアウトプットを出せる様にというのは目指していきたい所です。

もちろん、人によって向き不向きや自分がやったことのあるレベル感もあるので、いきなりレベルが高い本を書くといった様なことは難しいと思いますが、少しずつ段階を上げていくとアウトプット力のレベルも上がっていくだろうと思っています。

 

僕の人生訓として、「3人の師匠を持て」というのがあるのですが（詳しくは、こちらのスライド）、その師匠たちが、タイミングよく、ここ最近本を執筆をされたといった所があり、自分はそのレベルではないものの段階を上げていくとするとブログレベルの文章をアウトプットする訓練をしないとなといったこともブログを始めるきっかけとなりました。

良質なアウトプットを生み出す訓練は日々の仕事（プログラミングや資料作り）にも活きてくる

我々エンジニアは日々の仕事の中で、成果物を出していかなければならないので、良質なアウトプットを生み出せる様になるというのは非常に大切なことです。

ソフトウェアエンジニアとしてはプログラミングをしてソースコードを成果として出すことが多いわけですが、やはり読みやすいコードの方が他者の理解を助けることとなり、チームで仕事をしていることを考えると良質なアウトプットと言えるでしょう。

仕事の中で作成する資料についても同様です。

分かりやすくするために単純化したり構成を考えたり、冗長になりすぎない様に必要なモノは何で要らないモノは何かを吟味して入れたり、入れなかったり、興味を持って貰えるように内容を工夫したりといったアウトプットを考えることが良質なアウトプットへと繋がっていきます。

 

これは、それなりの長さの文章を書いていくこととと一緒です。

短文であればパッと読めてしまったりインパクトだけで引きつけることができますが、ある程度の文章になってくると良質なアウトプットではないと読んで貰えません。かくいう、このブログも果たして、この文章まで読んでくれている人がいるかどうかｗ

そこで、Twitter や Facebook といった短文から始めて、段々と長文であるブログや本にチャレンジしていくのがアウトプット力を高める訓練に繋がり、ひいてはソースコードや資料も良質になっていくことになります。

 

そういった良質なアウトプットを出せる訓練をするために、弊社では全社ミーティングでの持ち回り LT を実施して、メンバーのアウトプット能力を向上していこうと取り組んでいます。

情報発信による評価向上、ブランディング

また、情報発信をすることによって、その人の評価向上にも繋がっていくことになりやすいです。

  • 情報を発信する前向きな姿勢
  • 良質なアウトプットであればアウトプットそのもの
  • 繰り返し情報を発信することでザイアンスの法則（単純接触効果）*2による好意
  • その人がこういうことをやっているんだという認知
  • 興味を持っているんであればやらせてみようというチャンス獲得
  • その情報から人的ネットワークが広がることによって得る機会

といったように、情報発信そのものが評価されたり、アウトプットから話が広がりって機会に繋がり、それに対してまたアウトプットをするといったスパイラルとなっていくと、その発信していることに対する専門家と思って貰えるといったセルフブランディングにも繋がっていきます。

このセルフブランディングは、社内であろうと社外であろうと大きな価値になるはずです。

 

実際、弊社もモデル駆動型開発やオブジェクト指向、ドメイン駆動開発といったことについて、まだまだ情報発信不足なもののコミュニティ活動で勉強会をいくつかやったり、インタビューに答えたり、人材募集の際に打ち出したりとアウトプットを繰り返して来た中で、そういった分野の専門家集団といった認識を持って貰えるようになってきました。

 

まとめ

長文になっちゃったので、ザッとまとめます。

 

  • インプットだけでなくアウトプット（情報発信）しよう！
  • いきなりすごいアウトプットは無理なので、自分にあった形でしよう！
  • 情報発信することでセルフブランディングしよう！

 

気がつくと長々と書いてしまい、もっともっと良質なアウトプットをする訓練をしていかないといけないなと自分自身思っている所ですが、今後、精進していきますので、これからよろしくお願いします！

*1:7 月の発表者だったのに、ブログ書き終わったの 9 月頭。。。遅すぎる。

*2:ザイアンスの法則（単純接触効果）とは、対象と繰り返し接触することで好意度が増したり、印象が高まるという効果。