nozayasu

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

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

前置き

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

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

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

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

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つを忘れずにありたいと考えます。

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

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

そこにスペシャリストの必要性はあるか

多様な人材が必要とされる中でも、スペシャリストを特に確保したいと位置付ける企業も多いのではないでしょうか?

ここで言うスペシャリストはエンジニアに対するもので、局所的な高い技術的課題解決力のある人と自分の中で定義しています。

この定義は以前に、エンジニアを理解するためのパタンの1つとして表現しました。

nozayasu.hatenablog.com

数多の企業が確保したい人材であることは、事業を作る過程に何らかの必要性が存在することを示唆していると考えられます。

その一方で必要性を提示し続けれずに、ミスマッチとなる体験を聞くことも少なからずあるのが実情です。

この実情は、ひとえに期待値のすり合わせ不足が要因にあるのでは?と感じるようになりました。

そこで今回は、スペシャリストへの期待値考察を通して、どんな必要性が存在するのか?何をすり合わせたほうが良いのか?をイメージできるように、自分の考えを整理したいと思います。

スペシャリストがもたらすもの

単に高品質の仕事をこなす人材であることが、スペシャリストの魅力ではありません。

事業に影響を与える範囲が大きいことこそが、魅力の本質ではないかと捉えています。

表層的な期待値と深層的な期待値という2つの観点で、その魅力と必要性の度合いを主観で探ってみます。

表層的な期待値

経験値に対する期待値とも言い換えられます。

スポットで在籍する場合と、フルで在籍する場合での違いを考えながら整理します。

スポットで在籍する場合

技術顧問や業務委託、外注等といったものも含んでいるものとします。

以下のような期待値を持ちます。

  • 技術的課題を深くイメージできる立場からの意見により、いつ事業に技術的投資するかの判断基準の幅が広がる
  • 対外的な評価を得ている方も多く、広報面の魅力が増える
  • 共に働く環境があることで、メンバーのロールモデルや成長への内発的動機付けに繋がる

フルで在籍する場合

スポットで在籍する場合の内容に加えて、深く内部にいてもらえることで、以下のような期待値を持ちます。

  • 高い実行力を定常的に確保できることで、事業推進力が高まる
  • 実現性の高い技術選択肢が増えることで、事業戦略の幅が広がる

読み解けること

表層的な期待値からわかることは、スペシャリストの実行力が定常的に欲しいかで、フルである必要性が変わることです。

優秀な人材ほど流動性が高くなってきている傾向がある中で、本当にフルで在籍してもらうほどに求めているか?何をしてほしくて求めているか?

雇用形態や拘束時間への必要性を分解して採用を考えること、ミスマッチを減らすために大事にしたいです。

立ち上げて間もない企業にとって、スペシャリストにフルで在籍したいと思ってもらえる条件を提示しきれない場合。

たとえスポットでの在籍であっても、企業との関係性を持ってくれるスペシャリストが増えてくれることに意味がある。と判断できるケースもあるだろうと思います。

深層的な期待値

「高品質の仕事」という曖昧な表現に隠れた、事業フェーズや人数規模等の状況で変化する、実務に対する期待値とも言い換えられます。

事業フェーズ毎の違いを考えながら整理します。

立ち上げ時期

とにかく色々なものが足りていなく、試行錯誤をしながらプロダクトの方向性を確かめていく時期と捉えます。

何かを解決すればそれで確度が高まるという課題が見つかっていなければ、投資判断を引き出しきれずに、短期視点での泥臭い仕事も多いフェーズでしょう。

プロダクトの課題解決となるかどうかで、優先度も頻繁に変わることが予想できます。

この時期では、以下のような期待値を持ちます。

  • プロダクトの価値検証の速度と精度を高めるため、メンバーが試行錯誤に没頭できる運用基盤を技術で実現してくこと
  • 未来に実現しにくくなりがちな事柄の検討、短期的によしとして長期的に払う技術的代償の認識合わせを先導していくこと

調整時期

プロダクトの価値の方向性をある程度見出せており、拡大時期を見据えての一定の投資判断を引き出せるようになる時期と捉えます。

大きめの次期開発を進めつつ、日々の調整や販促サポート、技術的負債を返すことも検討事項に上がってくるため、関わる人が増え出すフェーズでしょう。

この時期では、以下のような期待値を持ちます。

  • 拡大期にスピード感を落とさないため、メンバー増加に耐えうる開発基盤作り
  • 一定規模の運用を支えるため、可用性を担保しながらの技術的課題解決を先導していくこと

拡大時期

プロダクトの価値が一定規模で認められ、積極的に投資をして事業規模をスケールさせる次期と捉えます。

スケールによる負荷対策や品質を保ち続けていくため、アーキテクチャ刷新や大規模リファクタリングといった、難易度が比較的高めの技術的課題が検討事項に上がるフェーズでしょう。

関わる人も数倍になっていくことが予想できます。

この時期では、以下のような期待値を持ちます。

  • 顕在化した大きめの技術的課題を、率先して解決していく技術力と実行力
  • メンバー育成や運用体制の効率化

成熟時期

プロダクトの成長スピードが鈍化し、投資回収等、ある程度堅実な運用をしていく次期と捉えます。

拡大期に比べると顕在化する技術的課題が少なくなってきて、プロダクトのさらなる価値を求めてR&Dの動きが出てこない場合には、再度泥臭い仕事も増えてくるフェーズでしょう。

この時期では、以下のような期待値を持ちます。

  • 利益率増加のために、コストカットを技術で実現する
  • 未知の事業課題を、技術で明らかにしていくこと

読み解けること

深層的な期待値からわかることは、スペシャリストの特性と事業フェーズ毎の期待値が、どれだけ合致しているかで必要性が変わることです。

持ち合わせる特性や好む責任の範囲が人によって違う中で、今実務的に求めたいことを実行できるか?得意としているか?

事業フェーズ毎の必要性を分解して採用を考えること、ミスマッチを減らすために大事にしたいです。

立ち上げ時期を好むスペシャリストにとって、調整時期や成熟時期で活躍を求めた場合。

たとえ技術的な専門性の範囲から採用要件に合致していても、今はお互いにとって良い関係を築けない。と判断できるケースもあるだろうと思います。

何をすり合わせるのか

企業にむけて

スペシャリストに対する期待値に、どれだけの条件(金額面や裁量面)を提示できるか?

これが利害関係一致の土台部分であるため、雇用における基本だと思います。

その上で、他に考えていきたいことも見えてきました。

  • 雇用形態や拘束時間への必要性を分解して考えること
  • 事業フェーズ毎の必要性を分解して考えること

分解していくことで期待値が過大になるのを抑制し、求めることに対しての条件提示を細かく考えられる。

このすり合わせができることで交渉の幅が広がり、よりよい関係に繋がると考えます。

スペシャリストにむけて

金額面や裁量面は最ものこと、付加価値のやりがい(スペシャリストの成長に意味のある技術的課題が存在する等)になり得そうな環境を提示できるのか?

これが利害関係の強い結びつきに繋がるのではないかと考えます。

とはいえ投資できないフェーズでは、期待値はあるものの望むような条件を提示できないケースも理解はできます。

なにが提示できないのか、どういう提示ならばできる可能性があると考えているのか。

このすり合わせを細かくすることで、企業と個人間での公平感に持てれば、よりよい関係に繋がると考えます。

まとめ

スペシャリストの魅力や思考性、企業の投資判断や事業状況を検討事項として、どんな関係性を作れるのか?

何らかの要因があって、結果として合致しそうな条件や環境を提示できないのだとしたら、そこにはスペシャリストへの期待値はあっても、必要性は存在しないということなのでしょう。

今は絶賛立ち上げ時期であり、泥臭い仕事はそれなりにある。実際に技術的課題解決として任せたいのはこの部分。裁量面ではある程度好きにやってもらえるように環境を用意したい。今提示できる条件はこれくらいです、事業が拡大期になったのであれば、特定の技術的課題を任せることと、そのフェーズとしての必要性を考慮した条件の再提示を約束する。といったようなすり合わせをする意味をイメージできました。

お互いの期待値と不足点を整理し、正直に話した上で落とし所を見つけるフロー、大事にしていきたいですね。

おしまい。

エンジニアの個性を理解するために必要なこと

エンジニアの個性とはなんでしょうか?

一緒に働いているメンバーであっても、ひいては自分自身のことであっても、表現することが難しいと感じています。

そんな最中、採用に携わってきた方に頂いた言葉がとても強く印象に残りました。

これまでずっと企業の採用に携わってきて、特にエンジニアやプログラマの人は、他の職種の方に比べてこだわりポイントみたいのが多種多様かつ明確な人が多いと感じていました。

この言葉を受けて明確なこだわりがあってこそのエンジニアらしさであり、そのこだわりのベクトルがエンジニアの個性たるものなのではないかと考えることができました。

エンジニアの個性が少し具体化したように感じます。しかしまだ多様なこだわりのベクトルは曖昧です。

このベクトルの部分を、エンジニア以外でも認知しやすい表現に落とし込めるのであれば、組織とエンジニアのミスマッチが減るのではないか。 エンジニア間の期待値理解、エンジニアのモチベーション起因把握に役立つのではないか。

そんな想いを胸に、エンジニアの個性を今より少しでも深く、認知できるための何かを探ることが今回の趣旨です。

エンジニアの個性を探るための手がかり

サーバーサイドやフロントエンドといった、扱う技術領域による分類は個性でしょうか?

技術領域の違いも、個性であると思います。

技術領域は、組織内におけるエンジニアのパタン・ランゲージ*1になり得ているため、個性の表現に値すると考えています。

また事業価値を成長させていく過程で、チーム開発において繰り返し起きる課題(事業に直接的な課題だけではなく品質低下・レガシーシステム・モチベーション低下等の、開発を継続する上での包括的な課題のことを考えています)を解決するエンジニアというものが存在します

この部分こそが、エンジニアの個性を表現する上での、重要な要素ではないかと感じています。

しかしこの部分は、技術領域や役職による分類だけでは、うまくイメージしきれていません。

そこでエンジニアの専門性・役職・活動・思考といったものをパタンとして名前をつけ、エンジニアの個性がパタン間の関連で表現されると捉え、今より少しでも深くエンジニアの個性を認知できるための手がかりにしていきたいと思います。

パタン

一般に知れ渡っている概念や、役職として定義されているものも含めて、エンジニアが業務上貢献している側面と性質に、主観ではありますが名前付けをしていきたいと思います。

スペシャリティパタン

  • フロントエンド(サービスの表現に対して技術的解決をできる能力を持つ)
  • バックエンド(サービスの処理に対して技術的解決をできる能力を持つ)
  • インフラ(サービスの安定稼動に対して技術的解決をできる能力をもつ)

テクニカルパタン

  • プログラマー(局所的に技術的解決をできる能力を持つ)
  • ゼネラリスト(広範囲に技術的解決をできる能力を持つ)
  • スペシャリスト(局所的に高い技術的解決をできる能力を持つ)
  • エキスパート(広範囲に高い技術的解決をできる能力を持つ)

マネージメントパタン

  • リーダー(局所的に組織的解決をできる能力を持つ)
  • マネージャー(広範囲に組織的解決をできる能力を持つ)
  • ディレクター(広範囲に高い組織的解決をできる能力を持つ)

チャレンジングパタン

  • イオニア(新しい技術を活用する)
  • エバンジェリスト(新しい技術を浸透させる)
  • イノベーター(新しい技術で課題を解決する)

カバーリングパタン

  • コラボレーター(職務領域にとらわれず企画やセールス等の支援もする)
  • メンター(エンジニアに適切なフィードバックを与える)
  • メンテナー(エンジニアの継続的なアウトプットや効率性の支援をする)

インフルエンスパタン

  • リアクター(発信された技術や想いに反応を示す)
  • パフォーマー(社内外に技術や想いを発信する)
  • タレント(社外に発信した技術や想いで評価される)

思考パタン

  • サービス思考(ユーザー価値がある事業、好きな事業に貢献したい)
  • 技術思考(新しい技術領域、好きな技術領域を通して貢献したい)
  • 成長思考(責任を負える、適切なフィードバックを得られる環境にいたい)
  • 協働思考(友人、尊敬する人といった自分の好きな人と働きたい)
  • 独立思考(自分の生活、個人の時間を大事に働きたい)
  • 評価思考(評価、業務貢献度による対価を正しく与えてほしい)

パタンの可能性

今回あげたパタンは、多様な組織に属するエンジニアに見られる、普遍的なものとも捉えられます。

このようなエンジニアの個性パタンを定義することは、組織としてエンジニアの評価軸・課題設定・フォローアップ・チームビルディング・採用方針といったものにも応用が利く可能性があると感じています。

もう少し具体化した例をあげていきます。

パタンを通してロールモデルとの差分を課題設定にする

f:id:nozayasu:20170405022608p:plain

ロールモデルと設定しているエンジニアは、バックエンドにおけるスペシャリスト。 技術思考と成長思考に裏打ちされた、イノベーターな側面とタレントな側面もある。

一方現状自分はバックエンドにおけるゼネラリストであり、ロールモデルと比較するとスペシャリストとしての活動量がたりていない。 またスペシャリストとしての探究心を保つために、定期的なフィードバックを得られるようにパフォーマーとしての活動も必要かもしれない。

大枠としてロールモデルとの差分を認知しやすくすることで、どうロールモデルに近づくか?自分らしく課題と向き合い目標をたてるか?指針としての可能性があるかもしれません。

パタンを通してエンジニア採用の方向性の理解を深める

f:id:nozayasu:20170405023249p:plain

ある程度自立しているエンジニアでかつ、よりチーム開発を円滑にしてくれる様なエンジニアがほしいという裏側にある想い。

現在のチームにはゼネラリストでかつ、コラボレーターとして活躍している主要なエンジニアがいる。

さらにコラボレーターの側面を持ったエンジニアを採用して、そこの掛け合わせによってチーム開発の円滑さを高めるのか?

メンテナーの側面を持ったエンジニアを採用して、エンジニアチームのアウトプットを向上させる形で、エンジニア主導の円滑さを高めるのか?

採用したいエンジニア像を、イメージするための問いかけになる。

エンジニア採用の方向性として、エンジニアチームと採用チームとの相互理解に繋がる可能性があるかもしれません。

終わりに

単純にパタンの組み合わせで成り立つだけでなく、関連性の強いパタンと弱いパタンがあると思います。随時新たなパタンも生まれることと思います。

そんなパタンの関係性を捉えて、チームとして掛け算になるよう調整をとることが、マネージメントの腕の見せ所なのかもしれません。

今回の話は、エンジニアの個性をより深く捉えるための表現方法の模索が主旨でした。

エンジニアの個性を理解するために必要なこととして、愚直に向き合い続ける姿勢を持つこと。エンジニアらしさに沿ったアプローチをとること。少なくともこの2点を、自分の中で大事にしていく考えを作れました。

エンジニアを精神的に一人にさせる様なことを、少しでも減らせるように、継続的に考えていきたい課題です。

おしまい。

*1:暗黙知の部分に名前をつけ、認知しやすい状態にするという意味でパタン・ランゲージの考え方を参考にし、パタンという言葉を使っています。そのためコンテキストや問題、背景となる因果関係、解決方法、結果、例などから構成される本来のパタン・ランゲージほどに考えきれてはいません。