nozayasu

仕事全般/マネージメントで考えたこと

エンジニア組織のマネージメントを思考する

前置き

今回は、エンジニア組織のマネージメントを自分がどのように考えてきたのか?の備忘録です

思考した結果、チームのアウトプットを最大化することを目指し、構造化・モニタリング・レバレッジ期待値の3つでマネージメントを捉えています という話をします

何をモニタリングする?何を基準にレバレッジ期待値を判断する?考えるベースとなるものが構造化

以下の3項目で整理していきます

  1. 事業と価値とエンジニアの関係性
  2. 損益と資産と要求と生産の関係性
  3. モニタリングとレバレッジ期待値

1. 事業と価値とエンジニアの関係性

最初に考えるのは、会社に所属するエンジニアは何を作っているのか?について

プログラム?システム?サービス? いえ、事業 を作っていると考えています

そのため、スタートは事業のことから理解していきます

労働とお金の話

皆さんは、お金をどのように手にしていますか?

大抵の人は労働の報酬として、お金を手にするんじゃないでしょうか

自分の頭にある労働とお金の構造を表現してみます

時間や技術を使って 作りだした資産価値が お金に変換される
👷 💎 💰

人とお金の間に価値が存在しています

極端に言うとガムシャラに働いたとしても、無価値なものを作り出してしまうと、お金には変換されないのですね

次は価値について考えていきましょう

価値とお金の話

自分が価値があると考えて作り出した資産が、他者から見たら無価値である状況は、どう理解するとよいでしょうか?

ちょっと別の視点をいれます、価値観という言葉がありますね

価値観(かちかん、英:sense of values[1])とは、何に価値があると認めるかに関する考え方[2]。
価値(善・悪、好ましいこと・好ましくないこと、といった価値)を判断するときの根底となる ものの見方[2]。
ものごとを評価・判断するときに基準とする、何にどういう価値がある(何には価値がない)、という判断[3]。

引用: wikipedia

人は価値を各々の基準によって判断している、他者が価値を認める資産を作り出せれば、お金を獲得できることがわかってきました

であれば、多くの人が価値だと認める資産を作り出せれば、多くのお金が獲得できそうです

事業とは 多くの人が価値だと認める資産を仮定し、作り上げ、収益をあげる ことだと捉えられました

また 多くの人が価値だと認める ≒ 社会的価値 とも考えられるので、多くのお金を稼げる事業を作ろう!とする行為は、社会的価値のある事業を作ろう!と同義なのかもしれません

事業とシステム価値とエンジニアの構図

ここまでの情報を使ってまとめ直します

エンジニア システム価値 経済的価値 社会的価値 事業価値
🏃‍ 💎 💰 🌏 ⛳️

※ 以降の説明の図で登場するアイコンの解釈です

構図 説明
💎 ⬅︎ 🏃‍ エンジニアは
システム価値を生産する
🌏 ⬅︎ 💎 システム価値は
社会的価値を生産する
💰 ⬅︎ 💎 システム価値は
経済的価値を生産する
🌏
⬆︎
💰 ⬅︎ 💎 ⬅︎ 🏃‍
上3つを重ねると
エンジニアはシステム価値通して
社会的価値と経済的価値を生産する
f:id:nozayasu:20201214115000p:plain 大きな経済的価値は
社会的価値になりえる
逆もまた然り
f:id:nozayasu:20201214115018p:plain 事業価値というものは
社会的価値からくる要求と
経済的価値からくる要求が
引っ張り合い生産された
システム価値から繋がる物

最後の図が、自分の中で構造化した事業と価値とエンジニアの関係性です

2. 損益と資産と要求と生産の関係性

事業と価値とエンジニアの関係性の章では、最も根底となる概念のような話になったので

次は、事業運営の要素を使ってもう少し具体性をつけていきます

note.com note.com

※ 上記2つの記事が自分の考え方の骨子というか元ネタです、とても有益な記事を公開して下さって感謝致します 🙏 これに自分の解釈を加えるような形で表現していきます

※ G/P(総生産力)につきましては「CTOの頭の中:技術を財務で表現する」を参照されると深く理解できます

損益と資産と生産の話

💰 P/L(損益計算書) / 💎 B/S(貸借対照表) / 🏃‍ G/P(総生産力)という登場人物がいます

エンジニア組織という生産力によって、システム価値である資産と負債が生産され、それを運用することで損益が発生する構図を表現してみました

f:id:nozayasu:20201214122004p:plain

この図にもう少し付け足したいものがあるなと考えました、それは要求の出所です

開発というのは要求の出所がなければ始まりません、次はその観点を盛り込んでみます

二つの要求と生産力の話

開発における要求とは、どのようなシステム資産をつくりたいのか?どうやって事業成長をさせたいのか?というものと捉えられます

Growth Request (G/R) とでも名付けて図にしましょう

f:id:nozayasu:20201214123513p:plain

この図を言葉に変えるのであれば

  1. 社会的価値を Vision として描き
  2. 事業戦略(プロダクト戦略)に変え
  3. エンジニアの生産力を使って
  4. システム資産を作る
  5. システム資産を運用して収益にする

とったような形でしょうか?すこし普段現場で考えていることに近くなってきました

この中で、エンジニアが密接に関わる項目はどこでしょうか?色付けしてみます

f:id:nozayasu:20201214124503p:plain

B/S と G/P ですね、個別に言葉を補足していきます

分類 項目 補足
B/S Asset/資産 プロダクト戦略に基づくシステム開発
事業成長にダイレクトに効く
最も生産力が使われる
B/S Debt/負債 資産と対になって生まれるシステム負債
開発効率やスケーラビリティに悪影響
エンジニアが最も正しく認知できる
G/P Reducer/減速要因 システム資産以外に使われる生産力
育成や会議といったもの
G/P Accelerator/加速要因 開発プロセスの最適化やDevOps
生産力のエンハンスメント
G/P Power/生産力 エンジニア組織そのもの

Asset/資産 はプロダクト戦略という要求の出所が見えてきましたが、他の要求はないでしょうか?

Debt/負債 はエンジニアが最も正しく認知できるため、この負債を返済したい!といった要求が生まれます

開発効率やスケーラビリティに影響するので、事業運営上も無視はできないものです

プロダクト戦略と対となる、システム戦略と便宜上呼びます

システム負債を返済する要求なので、Repayment Request (R/R) とでも名付けて再度図にしましょう

f:id:nozayasu:20201215001531p:plain

事業運営の要素に要求と重ねて考えてみると G/P の投資先が、プロダクト戦略とシステム戦略の二つとなる構図となりました

この構図が、自分の中で構造化した損益と資産と要求と生産の関係性です

システム戦略とプロダクト戦略を実行するためには、それぞれのタスクを比較した時の有用性が判断できないと、生産力を行使することができない のです

やっと、事業運営におけるエンジニア組織を構造化できました

次は、どこから情報を集めるのか?レバレッジをどう判断するのか?についてです

3. モニタリングとレバレッジ期待値

今回話してきた構造におけるエンジニアが密接に関わる対象の中で、お金を産む可能性があるのはシステム資産だけです

そのため、事業におけるシステム開発というものを考えた時には、システム資産に効率的に変化を与え続けられてるかどうか?

このように集約されていくのが、今の自分に見える世界です

変化量を基準に打ち手を作り、再度変化量を観測する、エンジニア組織のマネージメント全体像になりました

打ち手をいかにして考えるのか?をもう少しみていきます

モニタリング対象の話

エンジニアが密接に関わる B/S に関連する部分を、構図で色分けしてみましょう

f:id:nozayasu:20201215010346p:plain
  • プロダクト戦略として表現される、事業要求の変化
  • システム戦略として表現される、開発要求の変化
  • 事業収益として表現される、各種事業数値の変化
  • 総生産力として表現される、エンジニア組織の変化

4つのモニタリング対象が存在することが理解できました、これらの変化に伴って生まれるのが課題感です

その課題感に対して解決する打ち手を考えていくのがベターそうですね

レバレッジ期待値の話

複数の課題感が生まれてくることが想像できます、何を基準に打ち手に優先順位をつけるのでしょうか?

システム資産に変化を与え続けたい前提に立った時に、打ち手がどのくらい影響を与えるのかと必要となる生産力

それがレバレッジ期待値なのだと解釈しました

まとめ

  1. 事業価値というものは社会的価値からくる要求と、経済的価値からくる要求が引っ張り合い生産されたシステム価値から繋がる物 f:id:nozayasu:20201214115018p:plain

  2. 事業運営の要素に要求と重ねて考えてみると生産力の主な投資先が、プロダクト戦略とシステム戦略の二つとなる f:id:nozayasu:20201215001531p:plain

  3. 4つのモニタリング対象の変化を観測し、変化に伴って生まれる課題感を解決する打ち手を考えていく

  4. システム資産に変化を与え続けたい前提に立った時に、打ち手の影響度と必要となる生産力によってレバレッジ期待値を判断する

大変長くなりました、最後までお読みいただいた方はお付き合い頂きありがとうございます

おしまい

エンジニア組織の認知拡大をリードするために考えたこと

前置き

エンジニア向け自社イベントを企画したことはありますか?

一般的なイベント企画の動機として浮かぶのは、次のようなものでしょうか。

  • 知見の共有
  • 発表機会の提供
  • コミュニテイ発展への貢献

自分が自社イベントを企画する際にも、上述したことを考えていました。

しかし時間をかけて考えていくと、それらは建前だと気付きます。

自分がエンジニアとして自社イベントを企画する本心は、採用探究心を満たすことの2つでした。

加えて純粋な知識探究のためなら、会社の名前をつけたイベントにしなくても良いです。

以上のことから、結局は自分が自社イベントをする目的は採用。 すごくシンプルになった。

というところで本題へ。

今回は、認知拡大に対するアクションと採用をどのように線にして考えるのか?を整理した話です。

認知拡大ワークフローの考え方

大目的

エンジニア組織の採用へ繋げる認知拡大を目的とする

3つの重点項目

  1. 採用をフェーズで理解する
  2. 対象スコープでのアクションを定義する
  3. アクションの評価方法を設計する

個人で闇雲に外部向けアクションを行っても、継続性が生まれにくいです。
組織的に動けるフレームにどう落とし込むか?誰をどれくらい巻き込むか?そんな観点を大事にして考えていきます。

1. 採用をフェーズで理解する

f:id:nozayasu:20191129015740p:plain

図1. 採用のステップ / リクルートメント・マーケティング入門:あたらしい採用の常識 / Recruitment Marketing 101 より引用

採用フローは、引用させて頂いた図1のような4つのブロック、8つフェーズで捉えることができます。

これをベースに、 自分たちがするアクションの前後関係を意識し、対象とするスコープはどこまでなのか? の考え方を共通認識にしていきます。

具体的には、自分たちは図1における Lead Generation のブロックをスコープ とし、前後関係として後ろに Lead Nurturing のアクションが続いていくと理解しました。

2. 対象スコープでのアクションを定義する

自分たちは1で言葉にした、図1における Lead Generation のブロックをスコープとしました。

具体的なアクションとしては、以下を設定します(よく言われているようなものに落ち着いた)

  • イベント登壇
  • イベント会場提供
  • イベントスポンサード
  • イベント開催
  • ブログ運用
  • SNS活動
  • OSS貢献
  • 書籍類の執筆

個人だけでできること、チームや会社を巻き込んでできること、社外も巻き込んでできること、様々な粒度のアクションリストですね。

3. アクションの評価方法を設計する

1で前後関係を意識することを言葉にしました、これを評価を考える時の観点に利用します。

Lead Generation と Lead Nurthuring の境目にあるアクションを目標に置き、そこに繋がる中間点や、出発点となる2であげたアクションリストを繋いでいくことで、図2ができあがります。

f:id:nozayasu:20191129024823p:plain

図2. アクションと目標を繋ぐ

この図より、以下の2点が全アクションに対する到達点の指標であるとイメージできました。

  1. エンジニア募集への反響
  2. エンジニアのリファラル紹介数

会社としてブログをするのも、イベントを開催するのも、外部登壇するのも、認知拡大を目的とした場合にはこの2つにいかに影響を与えられたか?なんですね。

また、到達点だけでなく中間点や出発点のアクションも定点観測することで、改善サイクルを細かく回せるでしょう。

まとめ

エンジニア組織の認知拡大アクションには、多くのアプローチがあります。

闇雲にやっても継続せずに、アクションをしなくちゃ!という気持ちすら生まれてしまうのをよく見てきました。

そこで改めて採用構造理解と評価手法を考えることで、個々のアクションを線として捉え、目的につながる形が見えるようにしました。

認知拡大には継続と改善サイクルが必要だから、しっかりと考えていきたいですね。

これはあくまで自分の状況による一例ですが、戦略を練るための道筋をつくれたことが成果だなと考えています。

そんなところで、今回はおしまいです。

お知らせ

自分がメイン担当として企画したイベントが来月開催されます。

テックリードに興味のある人、このブログ内容のようなエンジニア採用へのアクションを語りたい人👇のイベントでお話しましょう!

tkrb-studios.connpass.com

意識的に成長実感を得るために必要なこと

前置き

皆さんは、どんな時に成長を感じるでしょうか?

近くで見ていた人のできることが増えたタイミングで

「成長しましたね」と伝えたことがあります

その時に次の様な言葉が返ってきました

A さん f:id:nozayasu:20190107194258p:plain まだまだ、あの人と比べると自分は何もできていないんです、成長なんてしたなんて言えないですよ...
B さん f:id:nozayasu:20190107194251p:plain 昨日の自分よりまた1つできることが増えた、毎日のように成長している気分ですよ!

何故こんなにも解釈は違うのでしょうか?

今回は言葉の裏にある事実を考察する過程から、意識的に成長実感を得るために必要なことを探っていきたいと思います

言葉の裏にある事実を考えると

前置きの具体例から、事実を拾いましょう

対象者 事実
A さん & B さん 経験を積み、できることが増えた
A さん 自分と他者を比較している
B さん 自分の過去と比較している

整理してみたところ A さんと B さんでは、成長を判断するための事実が異なることに気づきました

異なる点である比較する対象とは、自分の変化量をどう見るかの現れであり

つまりはその人の重要視している評価視点なのではないか?

次は評価視点という観点で、もう少し深掘りしていきましょう

評価視点について

今回は、変化量と達成時の実感値を軸にして考えていきます

自分の過去と比較した評価視点の場合

  • 変化量を累積値で評価している
  • 変化量にかかる変数が自分だけなのでコントロールしやすい
  • 変化量は停滞か増加になる

なんだかポジティブな実感を長く得られそうに見えます

なんだ最高じゃないか!これでいいじゃん!...と上手くはいかず

得てして、達成時の実感値が低くなります

なぜか?

僕はこれを、メタ認知能力が実感値に影響しているからと考えています

自分自身の蓄積した事実を詳細に認識し、正当に評価することは能力に依存していて

変化量を認識できる能力を育てていないと、この評価視点とは上手く付き合えないのです

自分と他者を比較した評価視点の場合

  • 変化量を他者との差分で評価している
  • 変化量にかかる変数に相手も含まれるので、コントロールしにくい
  • 変化量が減少する(差が大きくなる)ことがある

アンコントローラブルで、減少する可能性も含んでおり、ポジティブな実感を長く得られはしなそうです

ではなぜこの評価を重要視する人がいるのか?

こちらは、達成時の実感値がある程度高くなります

なぜか?

僕はこれを、適度な競争心や闘争心が実感値に影響しているからと考えています

優劣という認識しやすい尺度があることで、評価時に判断がしやすく実感値が高まりやすい

しかし多面的に比較できる能力を育てていないと、総合比較をして劣っていると判断しがちになり

この評価視点とは上手く付き合えないのです

まとめ

2つの事例から考えてきて、以下のことが考察できました

  1. 人にはそれぞれ重要視している評価視点というものがある
  2. 評価視点には、それぞれ上手く付き合うための能力が存在する

ここから、意識的に成長実感を得るためには

専門的な経験を積み重ねていくだけでは足りず、自分の重要視している評価視点を理解し、上手く付き合うための能力も合わせて育てる必要がある

終わりに

重要視している評価視点というのは、自分の欲求からくる素直なもの

評価するための能力は、自分自身だけでなく誰かへのフィードバックのためにも大事なもの

上手く付き合っていきたいですね

といったところで、今回はおしまい

エンジニア組織をリードする人のことを考えた話

エンジニア組織をリードする人に、大きく3つの責務を求めたい

そんな風に考えるようになったという話をします

求める3つの責務

  1. テクニカルマネージメント
  2. ピープルマネージメント
  3. コミュニティマネージメント

1. テックリード

品質、生産性、技術的な承認、技術的な評価等、組織の専門性について責務を持つ人

2. エンジニアリングマネージャー

教育、採用、人事的な承認、人事的な評価等、組織の人間性について責務を持つ人

3. コミュニティマネージャー

提起、反応、支援、新陳代謝等、組織の社会性について責務を持つ人

コミュニティマネージャー?

これが今回話したいことです

エンジニア組織に1と2が重要な事は、多くの方が言葉にしてくれています

プラスで僕はエンジニアコミュニティをリードする責務が必要なのではないか?と思うようになりました

コミュニティをリードするということ

リードすると書きましたが、コミュニティマネージャーの実態は

コミュニティ内に多様なアクションが自生するためのサポートが責務と考えています

  • 疑問や課題提起という種撒き
  • 迅速なフィードバックという育成
  • ムーブメントに実態を与えるという支援
  • 風化した体験の廃止

具体的にはこのようなことを行うイメージを持っています

なぜ独立して必要?

A: あれやりたいなぁ
B: いいね!やろうよ!
A: お!ありがとう、やってみようか!
B: じゃあ会場とかいるね
A: あーそうね、ちょっと周りとかにも相談してみるよ
~数週間後~
C: あれやりたいなぁ
B: あれ、それってAと話してなかったっけ?
A: あー、相談したんだけど具体的に動く時間とりきれてないんだよね
C: あっ、そうなんだじゃあなんか進んでるんだね
A&B: いや、進んでるかっていうと微妙...

コミュニティでこういう場面を結構見てきました

種撒きとフィードバックによる初期育成はできて、ムーブメントになったけど

ムーブメントに実態が与えられなかった、かつ風化してる認識ができた時に、再度進行させるかいっそ一度廃止といった次のアクションの判断もされない

結果としてCさんという新陳代謝も阻んでしまった

この体験から、コミュニティ内に多様なアクションを自生させるのは

それなりのサポートが必要で、一定の時間を使うことなんだなとイメージしました

一方専門性をリードすることも、人間性をリードすることも多くの時間がかかります

そのため、兼任だと優先度が下がりがちになる

だから独立させたい

そんな風に考えるようになりました

最後に

エンジニア組織をリードすることに、3つの責務を求めたい

それはテクニカル、ピープル、コミュニティの3つのマネージメント

特にコミュニティマネージメントという概念を独立させたい

こんなことを言葉にしました

コミュニティでは日々小さなムーブメントが起こっているはずなんです

でもそれは、大きなものになったり、組織での体験にまで到達していないことがある

これがもったいないと思っていて、何かしらそこを担いたい

ムーブメントが起こる瞬間って、とても楽しいんです

でも実態が伴わないと楽しさは持続しなくて、次のムーブメントも起こりにくい

組織に所属する上での、1つのエンゲージメントになるくらいに

ムーブメントと体験の連鎖を起こしたい

だから、コミュニティマネージメントがエンジニア組織にはあってほしい

そんなことを考えたという話でした

おしまい

チーム開発とコードレビュー

チーム開発にコードレビューが持たらすものはなんでしょうか?

  • コード品質の向上
  • ナレッジの共有
  • 仕様不備の発見
  • 不具合の発見

コードレビューの成果物として、パッとこのようなものを思い浮かべました。

上記のような成果物を得ることは、望ましい姿と言えます。

しかし同時に、自分にとってこれらの成果物=目的ではありません。

あくまでコード品質の向上等は、コードレビューという体験を通して発生した副次的なものです。

コードレビューの目的は、XPのプラクティスにて示されている、コードの共同所有権 (Collective Code Ownership)の実感と熟成であると自分は捉えています。

今回はなぜコードの共同所有権を必要とするか、コードレビューがそれにどう関係するのかを言葉にしておきたいと思います。

コードを通したプロダクトへの貢献

一般的に業務としてコードを書く場合には、コードの総体であるプロダクトへの貢献が求められます。

コードを通したプロダクト貢献を、定性的・定量的という2軸にわけて考察してみます。

定性的貢献 : プロダクトコードへの責任感、品質への探求心、etc…
定量的貢献 : プロダクトコードの理解範囲、詳細理解の深さ、etc…

ここでいう定性的と定量的とはこのようなものを考えており、さらにそれぞれの貢献度合によって、メンバーのチームにおける立ち位置を四分類として表現すると、以下のようになります。

定性的貢献 小 定性的貢献 大
定量的貢献 大 作業者 自立者
定量的貢献 小 依存者 学習者

この分類を、チーム構成に当てはめて考えを膨らませてみます。

ぎくしゃくしたチーム

作業者と依存者で構成されたチーム

定性的貢献を重視するメンバーが少ないことで、チームとして自己タスク範囲外に興味が薄く、たとえ障害時であっても作業範囲が明確に分離されていることが多い。

学習者と依存者で構成されたチーム

定量的貢献を重視するメンバーが少ないことで、チームとして理想像は掲げるものの実行力が弱く、やりきれず目の前の仕事に追われることが多い。

ぎくしゃくしたチームには、精神的にも実務的にも、余裕が不足しているようにイメージできました。

なめらかなチーム

自立者が主となり構成されたチーム

チームとしての理想を、個人の実行力で支え合っており、チームとしての余裕を作り出し、プロダクト価値探求に時間をとれていることが多い。

なめらかなチームには、精神的にも実務的にも、意図的に余裕を作り出しているようにイメージできました。

チーム開発の課題

ぎくしゃくしたチームと、なめらかなチームとの違いは、変化への対応能力です。

プロダクトを運用をしていくことは、障害・レガシー化・体制変更・ピボット等の大小あれど何かしらの変化に直面します。

価値探求と安定稼働を、変化を受け入れながらこなせなければ、チームはぎくしゃくしだすのだと思います。

そこに健全なプロダクト運営のため、なめらかなチームを目指す必要性と、自立者をいかに育てるのか?というチーム開発の課題がうまれました。

自立者とコード所有感

さて次は、率先してコードでプロダクトへ貢献する、自立者を育てる仕組みの考察をしていきたいと思います。

定性的貢献定量的貢献 の両立をしているメンバーのことを、自立者として分類しました。

  • プロダクトコードへの責任感、品質への探求心、etc…
  • プロダクトコードの理解範囲、詳細理解の深さ、etc…

これらを両立することは、プロダクトに関連するコード*1であるという一点が満たされるのであれば、それを自分のものとして向き合うことではないか。

つまりは自立者に近付くということは、プロダクトに関連するコードの自己所有感を拡大することだと自分では解釈しています。

ならばチームとして取り組むべきは、コードの自己所有感を最大化し、自立者であり続けるための環境整備だとイメージできました。

そしてその環境整備の1つが、コードレビューです。

コードの共同所有権

コードの共同所有権 (Collective Code Ownership)の理解を深めるために、概要を引用します。

チームの誰もがコードを改善するために変更を加える権限を持つ必要があります。全員がすべてのコードを所有する、すなわち全員がコードに対し責任を持つことになります。この技法では、開発者は、個人のコード所有者を気にすることなくコードを変更することができます。全員が責任を持つという事実により、コードが誰にも所有されずに混乱状態が起こることもありません。

XP の真髄 より引用

なるほど、分かりやすい。コードに対してメンバー全員が権限と責任を持つことだと理解しました。

責任について少しだけ突っ込むと、共同所有とした結果、個人の責任感が希薄になりうる危険性を含んでもいると感じています。

実体験として責任が曖昧な状態となり、無視されるようなコードを見てきました。これは望む形ではありません。

そこでチームとして運用責任の比重を、個人的には明確にしたほうが良いと考えています。

具体的にはリーダー・主担当といった役割の表現をすると共に、責任の比重を役割に関連付けて最終防衛ラインを設定するようなことです。

参考: コードの共同所有に弱点はあるか?

コードレビュー

コードの共同所有権を目的とした場合、コードレビューはどのように捉えたらよいでしょうか?

共同所有を前提とすると、以下のようなことが考えられます。

  • 技術レベルやプロダクト理解度の差異による、個人間のコード所有感に違いがあっても、向き合うコードは同じものである
  • 他者が作成したコードを自分も運用することである
  • 運用するということは、メンテナンス、障害対応、概要説明責任を粒度あれど担うことである

共同所有を前提にするということは、現在の状況を考慮しつつも同じ土俵にあがることだなと自分は捉えています。

同じ土俵にあがることで、徐々に個人間の差異を埋められて、自己のコード所有感は広がっていくことでしょう。

徐々にを許されるのであればよいですが、チームや会社からはより早い貢献が求められることも多いと感じています。

コードの共同所有権を目的とした場合のコードレビューとは、自分がこのコードを運用するならばどうするか?を考えるための機会提供と継続性のサポートなのだと思います。

継続的に考え、フィードバックを得ることで、個人間の差異を効果的に埋めていくことに繋げる。

なので自分としては現在の状態(技術レベルやプロダクト理解度)で、自分が運用するのなら?という観点で堂々と疑問を投げかけたり、理解するための行為を推奨したいです。

まとめ

  1. プロダクト運用は変化が伴う、それにうまく対応するのはなめらかなチーム
  2. なめらかなチームであるために、自立者にいかに近付くのかが課題となる
  3. 自立者に近付き、維持するためにコードの自己所有感を拡大していきたい
  4. コードの自己所有感の拡大サポートを、仕組みにしたものがコードレビュー
  5. なのでコードレビューの目的は、コードの共同所有権の実感と熟成と捉えた

このような観点と、思考の流れを整理できました。

とすればコードレビューはメンバーに等しく意味のある仕組みなので、技術レベルが高いといった特定の人だけが担うものではなくなり、チームメンバー全員で担うものとなりますね。

おしまい。

*1:極端に言ってしまうとRuby等の、プログラム言語自体も関連するコードと考えています。とはいえ個人の意欲と程度問題なので、現実的には必ず深い部分までを求めるということではありません。

情報を共有するということ

人と会話をしたことはありますか?想いを伝えたことはありますか?

「ご飯が食べたい」「外出の準備をしてほしい」こんなことを口にすること。

理解してもらうために、何かをしてもらうために、人は人に情報を共有しているのだとイメージしています。

大きく捉えると情報共有という行為は、皆が日常的に行ってるものです。

なぜ改めて情報共有の必要性を考えるのか?単純な理由ではありますが、円滑な仕事をできるようにありたいからです。

構造の理解を通して、情報共有の指針を模索していこうと思います。

情報共有と距離

まず最初に情報共有と距離、一見関連性が見えにくい2つの概念ですが、個人的に大事な観点だと考えているので言葉にしていきます。

情報共有における距離とは、次のようなものをイメージしています。

物理的な距離

  • 同じオフィス (近距離) <=> (遠距離) オフィスとリモート

心理的な距離

  • 1対1 (近距離) <=> (遠距離) 1対多

文化的な距離

  • 日本のみ (近距離) <=> (遠距離) 日本と海外
  • 社内のみ (近距離) <=> (遠距離) 社内と社外

知識的な距離

  • エンジニアとエンジニア (近距離) <=> (遠距離) エンジニアとセールス
  • ベテランとベテラン (近距離) <=> (遠距離) ルーキーとベテラン

時間的な距離

  • 同期的 (近距離) <=> (遠距離) 非同期的
  • 短期的 (近距離) <=> (遠距離) 長期的

これらの掛け合わせから成る、情報発信者と受信者の距離感によって、情報共有に求める詳細度(円滑な個人の活動を維持する条件)が変化すると考えています。

詳細度を高めることは、受信者の違和感をなくすために情報をより作りこむことであり、共有に必要なコストの増加を伴います。

具体例をあげて、イメージを膨らませてみます。

1on1ミーティングは発信者と受信者が1対1であり、互いの時間が同期する。表情や身振りによる付加情報、個人向けに選択された言葉、質疑応答、これらを通してお互いの理解度を容易に補完できる。結果として、一次情報としての求める詳細度は低くなる。

共有ドキュメント投稿は発信者と受信者が1対多であり、互いの時間が非同期になる。概ねドキュメントからの情報が全てであり、一般化した言葉、非連続的な質疑応答、お互いの理解度の補完が容易ではない。結果として、一次情報としての求める詳細度が高くなる。

では補完が容易な、1on1ミーティングのような手法だけで全ての情報共有をできるか?というと、運用コストが高くなりすぎて現実的とは思えない。

つまりは受信者との距離感を手掛かりに、どの程度の情報詳細度が求められるかをイメージし、作成コストと理解度が合致するバランスはどこか?という判断をしていくことだと捉えました。

情報を共有するということは、どれだけの人に、どれだけのコストをかけて、どれだけの共通理解をつくるのかということであると、自分では解釈をできました。

組織における情報共有

行為そのものへの理解が深まったので、次に特定の組織に範囲を狭めて、会社における情報共有の理解を深めて行こうと思います。

会社で行われる情報共有とはどんなものでしょうか?

  • 業務資料(企画書、手順書、計画書、報告書、議事録…)
  • 作業進捗
  • 会社運営に基づく想い(会社として、メンバーとして…)
  • 知見やノウハウ(売上を作る、コストを下げる、新技術、効率化…)

ざっとこのようなものが思いつきました。

大きくわけて実務に短期的に影響するものと、中長期的に影響するものの2つがみてとれます。

業務資料や作業進捗は、短期的に共有する必要性が感じられ、払うコストに肯定感があり、意識しなくても共有がされていく情報。

想いやノウハウは、短期的には共有する必要性が感じにくく、払うコストに抵抗感があり、意識して行わないと共有されにくい情報。

それぞれの分類に対して、この様なイメージを持っています。

例外としてインシデントのような直近の実務に影響がでた場合には、しばしば積極的に想いやノウハウが共有される状況になることがあります。これは短期的な情報の必要性とコスト感のバランスが変わり、一定のコストを払ってでも想いやノウハウを共有することに、認識しやすい価値が生まれた結果と捉えています。

ここまでで会社内で実際に生まれやすい情報共有と言う意味では、短期的な必要性が払う共有コストを上回るかどうか?という視点が加わりました。

では例外が発生しない限り、短期的な必要性を伴いにくい想いやノウハウは、本当に共有コストを払うだけの価値がないのでしょうか?

これはひとえに、組織としてどうありたいかが関わってくる部分だと考えています。

次は組織規模と絡めて、想いやノウハウ共有が担う役割を整理したいと思います。

情報共有と組織規模

想いやノウハウは、共有コストを払うだけの価値がないのか?の問いについて、先に自分はどう思うかを書くと、払う価値があると考えています。

blog.tinect.jp

組織としてのアウトプットが、ここに書かれているような処理能力の一番低いラインに影響を受けることを前提とすると、ボトルネックを解消する行為は組織としてのアウトプットに寄与する。

想いやノウハウの共有にコストを払う価値は、そこにあると感じています。

会社における想いやノウハウといったものは、短期的な実務の推進力UPのためではなく、中長期的な育成や効率化に繋げていくために共有をしたいのです。

ただここで考えなくていけないのは、この共有コストは常に一定ではないということ。

会社が大きくなっていくということは、新たな拠点がうまれ、多様な働き方を許容し、個人が関わる人数が増えていくことになります。

これは情報共有の距離が広くなっていくことと、同義だと感じています。

円滑な個人の活動を維持するための情報が多岐に渡っていくのと同時に、距離が広くなったことで共有コストも高まっていく。

見渡せるくらいの人数であれば、情報共有フローを整備しなくても、ある程度ノウハウが行き渡るのかもしれません。ある程度想いを吸い上げられるのかもしれません。

しかし組織規模が拡大していく過程で、同じような共通理解を維持したいと願う時には、共有コストとの戦いが常につきまとうことになるのです。

情報共有とどう付き合うか

さて、最後にどう付き合っていこうか?という部分まできたので、まとめていきたいと思います。

理想を言えば、組織内全員の共通理解となれるような情報共有が行われて欲しいです。

しかし組織が拡大していくにつれ、詳細度の高い情報の共有コストは個人で担いきれないものへとなると考えます。

そこで、情報共有の捉え方を変える必要があると感じました。

情報の種をまき、フィードバックを与え、組織として育てていくもの。

組織として必要な共通理解を、組織としてコストを払い、情報共有の詳細度を保っていく。そんな風なイメージが今回できました。

このイメージに簡単な指針をつけて、おしまいにしたいと思います。

  • 情報共有のコストを払って情報の種を巻いてくれる仲間を賞賛したい
  • 情報はメンバーの参照とフィードバックを与えて組織で育てるもの
  • 無駄にも見えがちな想いやTIPSも、距離感によって価値になることもある
  • フロー型の情報は新陳代謝と効率化を、ストック型の情報は分類と詳細度を意識する

情報、育てていきましょう。

おしまい。

だから僕はあなたと働きたい

最近エンジニアチーム向けにキャッチコピーを作りました。

  • 経営層と採用・人事・組織に対する振り返り
  • エンジニア間の期待値を理解するワークショップ
  • 過去の所属エンジニアへ在籍時の会社に対する心象ヒアリング
  • 自分のありたい姿を再考

これらを通して見えてきた、現在の状況下における架空のロールモデルを表現する言葉ともいえます。

今の組織における抽象的な価値として、エンジニアの何を見ていくのかを提示するのが趣旨です。

今回はそれに自分の込めた想いを加えながら、まとめていきます。

前提条件

10人規模の組織、エンジニア業務を担っているメンバーは3~4人。

12:00~17:00がコアタイム、週2回リモート勤務OK、週1回全社会議あり。

一般的な勤務体系よりも比較的自由度が高く、ある程度多様な働き方を許容している組織です。

同じ時間帯に同じメンバーが顔を合わせて働くことは、全社会議がある日以外では基本的にないのが日常です。

この少数かつ多様な労働環境を支える、という視点がある程度加味されています。

この前提条件のもと、3つのことを言葉にしました。

3つのキャッチコピー

  1. 技術で違和感をなくす
  2. 技術を言葉にできる
  3. 技術と人に向き合う

1. 技術で違和感をなくす

何をするか

  • 技術で既知の課題を解決する
  • 技術で未知の課題を捉える
  • 技術で課題解決の選択肢を増やす

継続するために

個人の専門性による思考、解決のアプローチを信じる

込めた想い

個人の専門性に自信を持つことは、自発的な行動の支えとなると考えています。

ここでいう自発的な行動とは、個人の考えを発言をすること。

人は自信がない状態では意欲的に発言せず、自信がある状態では意欲的になりやすい。

ある組織の中で、発言をした体験を積み重ねることが、組織内での発言行為そのものの心理的障壁を低くすることに繋がっていく。

個人が発言を継続的に行うことを通して、フィードバックの連鎖をチームに与え、全体としての課題解決の質を高めていく。

個人の自信がいかに課題解決へ繋がるかのイメージから、エンジニアとして自分の専門性を信じれることに、組織におけるエンジニアの価値の1つを見ています

2. 技術を言葉にできる

何をするか

  • 文章だけでもコミュニケーションを成り立たせる
  • 専門性を正確に文章にする
  • 専門性を魅力的に表現する

継続するために

個人の影響力や共感力を過信せず、専門性の適切な表現方法を模索する

込めた想い

個人の専門性を文章で正確に、魅力的に伝えることが、多様な労働環境を維持することの支えとなると考えています。

ここでいう多様な労働環境とは、時間や場所の拘束をしない働きかたをすること。

時間や場所を固定せずに働く環境では、メンバーとの文字によるコミュニケーションが主となる場面が比較的多い。

視覚や聴覚から得られる情報量が低下する中で、質を落とさないための技術が必要となる。

良い文章の書ける人というのは、裏を返すと文章の読む力がある人でもあって、文章力を高めることが他者の想いを理解することに繋がっていく。

個人が文章表現の試行錯誤することを通して、チーム理解の深度を維持し、全体としての協働の質を高めていく。

多様な労働環境において、個人の文章力がいかに相互理解へ繋がるかのイメージから、エンジニアとして専門性の文章表現を模索することに、組織におけるエンジニアの価値の1つを見ています

3. 技術と人に向き合う

何をするか

  • 技術を楽しむ
  • 人に興味をもつ

継続するために

メンバーの専門性や思考性、成果に興味を持つ

込めた想い

個人とメンバーとの接点を増やし、個人間のフィードバックの量や質を増やすことが、成長実感を得ることの支えとなると考えています。

個人の限界値を拡大していくためには、いかにして良いフィードバックを獲得し、専門性向上のための行動を自分が継続できるかを考えていくことになる。

メンバーとの接点を増やす中で、メンバーが何に興味を持ち、いかに考え、どんな成果を残してきたかの理解を深めると、やがてそれが緩く期待値となって現れ、他者は期待に応え続ける事自体が、専門性を高める動機の一つとなる。

メンバーとの接点を増やすことを通して、緩く期待値の表面化を行い、自学への動機付けに寄与することで、全体としての成長実感を高めていく。

個人としてメンバーとの接点を増やすことが、いかに成長実感に繋がるかのイメージから、メンバーに興味を持ち、一定の刺激的な関係性を作れることに、組織におけるエンジニアの価値の1つを見ています

まとめ

専門性を磨き、磨いてきたものを信じて、それを魅力的に伝え、メンバーを巻き込んで、成果と成長を作っていく。

と言った一文に、まとめ直せるのかもしれません。

多様な働き方を維持するために、技術力だけではなく、文章力を持っていることを望む。

この部分が、今回の言葉にした中でも独特だなと感じています。リモート勤務が日常になければ、恐らく浮かび上がらなかった視点です。

独特な部分があることは、今の組織における価値観が良く表現された結果なのだろうと思います。

また、マネージャーとしてはこういった抽象的な概念を掲げた場合には、自分が実行していくこと、メンバーをいかに精神的に1人にさせないか、その2つを忘れずにありたいと考えます。

エンジニアの専門性に対する普遍的な評価とはまた少し違った、特定の組織内における価値観からくる評価を言葉にすることで、だから僕はあなたと働きたいを伝えられるポイントを増やしていきたいです。

タイトル回収をしたところで、今回はおしまい。