【イベントレポート】EOF 2019 (Engineering Organization Festival)に参加してきました
はじめに
表題の通りEOF2019に参加してきました。素晴らしいセッションの率が非常に高く、個人的には今まで参加したカンファレンスの中でも、トップレベルで満足度が高かったです。
EOF2019とは？eof-github.github.io
eof.connpass.com
EOFは「エンジニアリング組織をもっとオープンに」をビジョンに掲げるイベントです。
主にプロダクト開発や組織開発をテーマとしたカンファレンスです。セッションがメインではありますが、OSTによる参加型ディスカッションも行われていました。
素晴らしい発表はぜひシェアしたいとおもいつつ、自分の状況や意見も交えながら書いていきたいと思います。
筆者の背景
ここ最近組織開発という分野に熱狂的に取り組んでいるところです。これまでの自分の経験から、自分の力で組織論を組み立て、いざアウトプット、実行を行うときに、言葉選びや表現の仕方にかなり苦戦していました。
ある事象が起こったとき、それは自分の作りたい組織にマッチした、促したい方向性の事象なのか、もしくは逆方向の事象なのか、逆方向の事象が起こった場合に、そっちじゃないよ促さなかったら具体的にどういう組織になっていくのかというものは言葉にできたものの、ではそれはどんなセオリーが背景にあるのか、伝え方としてどういう方法があるのか、このあたりの武器が不足していたと感じることが多かったのです。
それでも何年もかけて、自分の中にはある程度完成されていた考え方を洗練させて、世の中のセオリーと組み合わせながら、ようやくアウトプットと実行をし始めているということろです。
そして最近になり、よくこのジャンルの本を読んだりこういったカンファレンスや勉強会に参加しています（これまでは技術メインでした）。なぜ今なのかという話ではありますが、ある程度自分で完成させてから、「答え合わせ」がしたいという気持ちと、自分が持っていない「言葉や表現」をお借りさせていただきたいなという目的が大きいです。あわよくば自分の知らなかったセオリーや取り組みなどしれたら棚からぼた餅ですね。
「答え合わせ」や「言葉や表現」が出来たときはかなり感動しますし、自信と表現力アップにつながります。
セッション
さてここからは個人的に刺さったセッションを紹介していきます。
正しいものを正しくともにつくる 市谷 聡啓さん(@papanda)
www.slideshare.net
プロダクトを開発するとシンプルにいわれるものを、具体的プロセスに分解して考え、「わからないものをわかる」ようにするために、選択肢に幅をもたせながらも、仮説検証によって絞っていく。それぞれのプロセスで一般的に分業され得るものを「ともにつくる」ことが、チームの多様性を活かすことが出来、プロダクトの視座を高めるために重要ですよという話です。そして多様性が高まったときに低くなってしまうかと思われる機動性をいかにして高めるのかも話されていました。
不確実性曲線と正しいものを正しくつくる各フェーズを同時に可視化したあの図は素晴らしいしぜひ真似させていただきたいなと思います。
そしてさらに一番刺さったポイントが「ともにつくる」ことでプロダクトの視座が高まるという表現ですね。「正しいものを探す」フェーズと「正しく作る」フェーズはたしかにプロダクト開発の現場には存在していて、例えば正しくつくるフェーズでスクラムを導入する場合、「正しいものを探す」ところの責任範囲はプロダクトオーナーになるので、開発チームとプロダクトオーナーチームがフェーズによって分断されてしまうことはあると思います。実際スクラムのルールには全く言及されていないのでそうなってしまうことも想定出来ます。スライド一枚引用させてもらいます。
ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜より引用
そこで課題として出てくるのが、機動力です。多様性と機動力がトレードオフの関係にあるのは想像ができるかと思います。この発表では、その対策法が紹介されていました。
仮説検証のフェーズでは、単に話だけではなくリーンキャンバスなどを用いて、必要なものを必要な分、各々の脳内から整理してアウトプットする。そしてその共有。さらに「正しくつくる」フェーズにおけるプロダクトレビューによる内部探索（これはスプリントレビューとは違い、もう少しスコープの広いもの）、ユーザーテストにより外部探索を行う。
上記プロダクトレビューと関係してると私は解釈しましたが、「ジャーニー」という区切りも素晴らしいですね。ビジョンだけでは遠すぎる、スプリントレビューだけでは近すぎるという課題に対する考え方です。具体的には複数スプリントに該当する一定の区切りでプロダクトと組織の振り返りを行いましょうということです。この振り返りにより、組織のフォーメーションを切り替えるということも出来ます。例えばこのジャーニーではとにかく開発をどんどんやっていこうとか、このジャーニーでは品質をどんどん高めていこうとかです。
プロダクトに対する理解度に合わせてアーキテクチャを選択しましょうという適者生存型アーキテクチャという言葉にも感動しました。こういうのって言葉すらないので、共通言語として使えることができたらスムーズですね。
クライアントワーク企業でもできるエンジニアリング組織のつくり方 永江 耕治さん@Kooozii
お客様先に常駐するSES形態の業務がメインである会社では、エンジニアリング組織をつくることが難しいですが、そんな環境でもエンジニアからマネージャー、人事部長、副社長と長年様々なポジションで活躍され圧倒的な経験を積んだ永江さんセッションです。
残念ながら資料は公開されていないみたいなので、資料を置いながら書くことは出来ませんが、これも感動ポイントがいくつもありましたので断片的ではありますが書かせていただきます。
※2019/11/27に資料が公開されました！
speakerdeck.com
組織レベルとマネジメントの話
序盤では主に組織構造と不確実性の話の流れをされていました。内容としては広木さんのエンジニアリング組織論への招待の1章の内容とかなり関係しています。会社という組織を、すごく抽象度と不確実性の高いものからプロダクトというすごく具体的なものを生み出す処理装置だと考えたとき、マネジメントや組織が不確実性にうまく対処してアウトプットをすることができるのかを永江さんは３つの組織レベルに分けて説明していました。（写真もメモもとってなかったので自分の記憶を頼りに書きますが、間違っていたらすみません、修正します。）
| 組織タイプ | 自己組織化もマネジメントもされていない組織 | マイクロマネジメント組織 | 自己組織化された組織 |
|---|---|---|---|
| 不確実性の削減 | 出来ない | 少しだけしか出来ない | 多くできる |
| 業務指示 | ほぼなし | 具体的で細かい | 抽象的で自由度がある |
自己組織化されたチームはかなりの不確実性に対処できるというのは言わずもがなですが、
ピラミッド型のマイクロマネジメント組織でを考えたとき、ボトルネックは頻繁に発生するものですが、ボトルネックが発生したとき（例えば中間管理職が急にいなくなったなど）、急に仕事の不確実性が上がります。そうなったときスムーズに対処する難易度は上がります。
さらに自己組織化されていないにもかかわらずマイクロマネジメントをしない組織はピラミッド型のマイクロマネジメント組織のボトルネック発生時が常に起こっているという状態になります。
マイクロマネジメントは古いからやらないというだけでは、「すごく抽象度と不確実性の高いものからプロダクトというすごく具体的なものを生み出す処理装置」としてはうまく回らないということですね。マイクロマネジメントのほうがまだ組織レベルが高いということです。マイクロマネジメントしないのが良いマネジメントだと思うのは、組織レベルが低い場合もあるので注意が必要です。
イノベーションとフォロアーの話
私も前々から気に入ってるこの動画の話をされていました。
First Follower Leadership Lessons from Dancing Guy
全社的にとある取り組みを行った際、最初の数人〜十数人はさらっとついてきてくれるのに対し、そこからのフォロアーが伸び悩む。そこで最初のフォロアーに対しこの動画を見せて、リーダーシップを促すことでその壁を突破し、フォロアーの数は臨界点を突破後指数関数的に伸びていく。ということを実際に行った事例を話されていました。
オープンコミュニケーションの取り組み
客先に常駐する社員もいる中、社内でコミュニケーションを取る難易度が非常に高い中、素晴らしい取り組みをされているなと思いました。
なにか集中して議論すべきことがあった場合、飲み会をセッティング（これは簡単に思いつきそう）、その飲み会にアジェンダを設定し、議事録も取るようにする。全社総会を定期的に開催し（これは簡単に思いつきそう）、出席者全員がリアルタイムでWebから質問や指摘を投稿でき、リアルタイムに役員とのディスカッションができる、など。
新米VPoEがまんまと落とし穴にはまったお話 坂井 健治さん( @saka0ken )
素直に失敗を認め、反省しながら改善していくような人柄の良さがにじみ出てくる良い話でした。NetflixのCulture deckでもはっきりと明記されているように、本当に価値のある情報において重要なこととは、「正直かつ率直に間違いを認める」です。心理的安全性の確保をし、自分に都合の悪い失敗したことや失敗しそうなこと、わからないことなどいかなるポジションやロールにおいても正直かつ率直な情報というものが非常に価値があります。というかこれこそが、他者を自律的に動かす材料の一つです。このように透明性の高い状態が保たれると、誰かが困っているときに誰か知見のある人が助けるという行動をとれるわけです。そんなとても正直かつ率直な坂井さんのセッションではところどころに周りの人との関わりや協力体制が感じ取れました。
残念ながらこちらのセッションも内部的にWeb上に資料を公開する許可がまだとれいていないということなので、ざっくりと思い出しながら書きます。
※２０１９年１１月１８日資料が公開されましたので掲載させていただきます。
speakerdeck.com
一つのチームのマネージャーだった坂井さんが、急にVPoEの立場になって組織開発というVPoEの仕事をするもなかなか大変でしたという背景です。
内部的なことをやりすぎないように
途中からこのセッションを聞いたのでセッションでは聞けなかったですが、後に本人に質問したところ、こういう話でした。
１つのチームのマネージャーだった→VPoEになった、という時点で、昔から見てる自分の組織のことにフォーカスが当たりがちです。しかし組織問題や組織開発というのはスコープがさらに広く、全社的にもなる話なので、それぞれの組織間の関係性の問題や、組織構造の問題などもっとフォーカスを当てるべき場所があった。自分が知っている範囲を対処するのではスコープが狭すぎるということでした。
最先端じゃなきゃダメだと思ってしまう問題
今となっては組織開発に関する様々な知見が、本やカンファレンスなどを通じて入手できるようになりました。その中でモダンな組織構造とはこれだ！モダンな開発プラクティスはこれだ！という情報が溢れています。自分の組織と照らし合わせて、しっかりと理論を組み立てずにこの流行に乗っかってしまっても、うまくいかない、という話でした。
チャットコミュニケーションの問題と心理的安全性の課題 中山 ところてんさん (@tokoroten)
www.slideshare.net
SlackにおけるコミュニケーションでDirect messageの割合が非常に高くて困っているという（友人）話から、なぜそうなってしまうのかを、様々な理論から解説し、さらにDirect messageの割合が多くなるとどんな問題が起こるのか、解決方法はあるのか、というセッションです。
SlackにおけるDirect messageの割合データ
非常に困っているという方の実際のデータを見てみると、Direct Message 50%, Public channel 30%, Private channel 20%という結果が出て、これはやばいとなったとのことです。一方で非常に成功している他社のデータはというと、SmartHRさんはPublic channel 96%, Private channel 3%, Direct message 1%。scoutyさんはPublic channel 100%(?)。NextIntさん（中山ところてんさんの会社）もほぼ100% Public channelという結果でした。このデータを見るだけでも、いかにチームでコミュニケーションを取れているか（つまり情報が共有されている）、個人でのみコミュケーションをとってしまっているか（つまり情報共有がされていない）が、会社によって天地の差ほどあるということですね。
Direct messageじゃなくてPublic channelでもしくはチームのチャンネルで発言してくれというのは、私も昔からうるさく言っている人間ですが、それはもちろんDirect messageによるコミュニケーションによって起こる問題を避けたいからです。これに関する説明も次のようにバッチリされていました。
Direct messageによって起こる問題
知識の偏在化、属人化が起こり、トラックナンバーが増えない。
指揮系統の逸脱、業務負荷の偏りが起こる。
社内政治の温床。社内政治が必要と理解しつつも、その環境を作ってしまうのはダメですね、ということです。
確かにこれにつきますね。。。これによって起こる組織問題は計り知れないほど多いですね。
なぜDirect messageで送っちゃうのか
Public channelで発言することを促すためには、Public channelの心理的安全性の確保が必要であるということ。つまり、Public channelでの発言率が高いということは心理的安全性が保たれているということが出来ます。
そしてこの心理的安全性という言葉はかなり重要で、Googleがアリストテレスプロジェクトというものを通じて、チームのパフォーマンスには何が重要なのかを調査しました。そこで出てきたのが、一番重要であり基礎となるのが心理的安全性です。
つまり心理的安全性の欠如からDirect messageの利用につながるのだということを話されていました。
あとはコミュニケーションに対する認識の違い、多知能理論から考えるPublic channelで発言しやすい人のパラメータなどのお話もありました。
ソフトウェアエンジニアはコミュ障だなんて一般的に言われがちではありますが、ソフトウェアエンジニアは論理・数学的知能が高く、言語的知能も高い傾向にあります。じゃあなんでコミュ障なんていわれなきゃいけないのか、それは多知能理論における他の知能、対人的知能が関係しているのではないか、という説を話されていました（マーケ・営業・マネージャは対人的知能が高い傾向）。
そんな理論から、Public channel で発言する・しないは単に習慣の問題ではなく才能の問題もあるのではないか、という話です。
DMM改革の1年、その実際と反省 松本 勇気さん(@y_matsuwitter)
最後にDMMのCTO松本勇気さんのセッション。これはもう感動というか、自分の興味分野にドンピシャ過ぎて、先に答えを見せないでほしいと思いながらつい見てしまうそんな完成度の高い組織戦略のお話でした。
私自身の組織戦略を剣という武器に例えると、全体像や形はできあがったものの、まだ研磨すべきところがあって本などを通じて言葉を身に着け、研磨してってもうすぐできそうだ！というタイミングで、すでにピッカピカに磨かれた切れ味抜群の同じ剣を見せつけられたかのような気分でした。
このうまくまとまったスライドには無数の理論や経験が盛り込まれているので、全体的な紹介は「ぜひスライドを見てください」とさせていただきたいのですが（スライドでも足りないので話を聞くのがおすすめ）、個人的に松本さんが得意なんじゃないかなぁと思う部分をピックアップして紹介したいと思います。
透明性に対する取り組み
透明性を上げるためにどうしたらいいか、具体的なプラクティスは山のように溢れてしかもそれは自分の組織にマッチするかわかりません。しかし松本さんは透明性が低下する原因を４つに分けて考えておられます。
- 伝達時の減衰: 組織感の信頼度や情報伝達文化の不足により、情報が減衰し、末端まで伝わらない。
- 情報伝達アクション不足: そもそも情報を伝達しようとするタイミングが不足し、情報が欠けている。
- 情報公開の不足: 情報の多くに対してアクセス出来ない状態になっている（e.g. slackのprivate channel, direct message）
- 情報整理の課題: 触れられる情報が整理されておらず、複雑。一見して理解がしづらい、情報量が多い
それに対しての対策法。それぞれをくるっと逆サイドに持っていくと
- ネットワークの構築: 暗黙的に出来上がってるコミュニケーションネットワークのハブを見つけ出し、連携
- インナーとアウターの活用: インナー（自分の言葉で即座に）、アウター（第三者の客観的情報を付与）
- 発言の習慣化: タイミングをルール化して発信者と受信者の行動をデザイン
- フォーマット化: 読みやすい整理された情報フォーマットを用意し全体へ公開
またこれらの情報の信頼性を確保することもまた重要。
自己組織化チームにおいて情報の透明性は最も重要と言って過言ではないですが、それに対する対策法をバッチリ言語化されて実行してるのは本当に素晴らしいと思います。また松本さんと話したときに、グノシーにいたときにやっておけばよかったとおもったことを今DMMでやらせてもらっているとおっしゃってたのですが、すでにグノシーにいたときからこれらの対策の基礎となる行動をされていた感じですね。
【連載：エラーに学べ】DMM松本勇気の過去から紐解く「組織のポテンシャル」の引き出し方 - エンジニアtype | 転職type
そうですね。あとは意識的に行っていたこととして、悩みや不満を拾い上げたら、その後定期的に「解決に向けた取り組みがどんな進捗状況にあるのか」を伝えるようにしました。仮に事情があって要望に応えられない場合でも、なぜ今これができないのかをきちんと説明することで、メンバーとの信頼関係を少しずつ再構築していったのです。
これを読んだときに1 on 1というかそれも重要だけども、情報の透明性の確保するスタンスが非常に良いと過去にぼそっとツイートした記憶があります。
おわりに
以上私が見ただけでも非常に素晴らしいセッションばかりでしたし、ほかも見たかったなぁと思うくらい満足度が高かったです。
私の本来の目的通り、こういった方々から知恵や言葉ををお借りして、今後の自分に活かせていただきたいと思います。
運営の方々、素晴らしいイベントをどうもありがとうございました。
