チーム開発とコードレビュー
チーム開発にコードレビューが持たらすものはなんでしょうか？
- コード品質の向上
- ナレッジの共有
- 仕様不備の発見
- 不具合の発見
コードレビューの成果物として、パッとこのようなものを思い浮かべました。
上記のような成果物を得ることは、望ましい姿と言えます。
しかし同時に、自分にとってこれらの成果物=目的ではありません。
あくまでコード品質の向上等は、コードレビューという体験を通して発生した副次的なものです。
コードレビューの目的は、XPのプラクティスにて示されている、コードの共同所有権 (Collective Code Ownership)の実感と熟成であると自分は捉えています。
今回はなぜコードの共同所有権を必要とするか、コードレビューがそれにどう関係するのかを言葉にしておきたいと思います。
コードを通したプロダクトへの貢献
一般的に業務としてコードを書く場合には、コードの総体であるプロダクトへの貢献が求められます。
コードを通したプロダクト貢献を、定性的・定量的という2軸にわけて考察してみます。
定性的貢献 : プロダクトコードへの責任感、品質への探求心、etc…
定量的貢献 : プロダクトコードの理解範囲、詳細理解の深さ、etc…
ここでいう定性的と定量的とはこのようなものを考えており、さらにそれぞれの貢献度合によって、メンバーのチームにおける立ち位置を四分類として表現すると、以下のようになります。
| 定性的貢献 小 | 定性的貢献 大 | |
|---|---|---|
| 定量的貢献 大 | 作業者 | 自立者 |
| 定量的貢献 小 | 依存者 | 学習者 |
この分類を、チーム構成に当てはめて考えを膨らませてみます。
ぎくしゃくしたチーム
作業者と依存者で構成されたチーム
定性的貢献を重視するメンバーが少ないことで、チームとして自己タスク範囲外に興味が薄く、たとえ障害時であっても作業範囲が明確に分離されていることが多い。
学習者と依存者で構成されたチーム
定量的貢献を重視するメンバーが少ないことで、チームとして理想像は掲げるものの実行力が弱く、やりきれず目の前の仕事に追われることが多い。
ぎくしゃくしたチームには、精神的にも実務的にも、余裕が不足しているようにイメージできました。
なめらかなチーム
自立者が主となり構成されたチーム
チームとしての理想を、個人の実行力で支え合っており、チームとしての余裕を作り出し、プロダクト価値探求に時間をとれていることが多い。
なめらかなチームには、精神的にも実務的にも、意図的に余裕を作り出しているようにイメージできました。
チーム開発の課題
ぎくしゃくしたチームと、なめらかなチームとの違いは、変化への対応能力です。
プロダクトを運用をしていくことは、障害・レガシー化・体制変更・ピボット等の大小あれど何かしらの変化に直面します。
価値探求と安定稼働を、変化を受け入れながらこなせなければ、チームはぎくしゃくしだすのだと思います。
そこに健全なプロダクト運営のため、なめらかなチームを目指す必要性と、自立者をいかに育てるのか？というチーム開発の課題がうまれました。
自立者とコード所有感
さて次は、率先してコードでプロダクトへ貢献する、自立者を育てる仕組みの考察をしていきたいと思います。
定性的貢献 と 定量的貢献 の両立をしているメンバーのことを、自立者として分類しました。
- プロダクトコードへの責任感、品質への探求心、etc…
- プロダクトコードの理解範囲、詳細理解の深さ、etc…
これらを両立することは、プロダクトに関連するコード*1であるという一点が満たされるのであれば、それを自分のものとして向き合うことではないか。
つまりは自立者に近付くということは、プロダクトに関連するコードの自己所有感を拡大することだと自分では解釈しています。
ならばチームとして取り組むべきは、コードの自己所有感を最大化し、自立者であり続けるための環境整備だとイメージできました。
そしてその環境整備の1つが、コードレビューです。
コードの共同所有権
コードの共同所有権 (Collective Code Ownership)の理解を深めるために、概要を引用します。
チームの誰もがコードを改善するために変更を加える権限を持つ必要があります。全員がすべてのコードを所有する、すなわち全員がコードに対し責任を持つことになります。この技法では、開発者は、個人のコード所有者を気にすることなくコードを変更することができます。全員が責任を持つという事実により、コードが誰にも所有されずに混乱状態が起こることもありません。
XP の真髄 より引用
なるほど、分かりやすい。コードに対してメンバー全員が権限と責任を持つことだと理解しました。
責任について少しだけ突っ込むと、共同所有とした結果、個人の責任感が希薄になりうる危険性を含んでもいると感じています。
実体験として責任が曖昧な状態となり、無視されるようなコードを見てきました。これは望む形ではありません。
そこでチームとして運用責任の比重を、個人的には明確にしたほうが良いと考えています。
具体的にはリーダー・主担当といった役割の表現をすると共に、責任の比重を役割に関連付けて最終防衛ラインを設定するようなことです。
参考: コードの共同所有に弱点はあるか？
コードレビュー
コードの共同所有権を目的とした場合、コードレビューはどのように捉えたらよいでしょうか？
共同所有を前提とすると、以下のようなことが考えられます。
- 技術レベルやプロダクト理解度の差異による、個人間のコード所有感に違いがあっても、向き合うコードは同じものである
- 他者が作成したコードを自分も運用することである
- 運用するということは、メンテナンス、障害対応、概要説明責任を粒度あれど担うことである
共同所有を前提にするということは、現在の状況を考慮しつつも同じ土俵にあがることだなと自分は捉えています。
同じ土俵にあがることで、徐々に個人間の差異を埋められて、自己のコード所有感は広がっていくことでしょう。
徐々にを許されるのであればよいですが、チームや会社からはより早い貢献が求められることも多いと感じています。
コードの共同所有権を目的とした場合のコードレビューとは、自分がこのコードを運用するならばどうするか？を考えるための機会提供と継続性のサポートなのだと思います。
継続的に考え、フィードバックを得ることで、個人間の差異を効果的に埋めていくことに繋げる。
なので自分としては現在の状態（技術レベルやプロダクト理解度）で、自分が運用するのなら？という観点で堂々と疑問を投げかけたり、理解するための行為を推奨したいです。
まとめ
- プロダクト運用は変化が伴う、それにうまく対応するのはなめらかなチーム
- なめらかなチームであるために、自立者にいかに近付くのかが課題となる
- 自立者に近付き、維持するためにコードの自己所有感を拡大していきたい
- コードの自己所有感の拡大サポートを、仕組みにしたものがコードレビュー
- なのでコードレビューの目的は、コードの共同所有権の実感と熟成と捉えた
このような観点と、思考の流れを整理できました。
とすればコードレビューはメンバーに等しく意味のある仕組みなので、技術レベルが高いといった特定の人だけが担うものではなくなり、チームメンバー全員で担うものとなりますね。
おしまい。
情報を共有するということ
人と会話をしたことはありますか？想いを伝えたことはありますか？
「ご飯が食べたい」「外出の準備をしてほしい」こんなことを口にすること。
理解してもらうために、何かをしてもらうために、人は人に情報を共有しているのだとイメージしています。
大きく捉えると情報共有という行為は、皆が日常的に行ってるものです。
なぜ改めて情報共有の必要性を考えるのか？単純な理由ではありますが、円滑な仕事をできるようにありたいからです。
構造の理解を通して、情報共有の指針を模索していこうと思います。
情報共有と距離
まず最初に情報共有と距離、一見関連性が見えにくい２つの概念ですが、個人的に大事な観点だと考えているので言葉にしていきます。
情報共有における距離とは、次のようなものをイメージしています。
物理的な距離
- 同じオフィス (近距離) <=> (遠距離) オフィスとリモート
心理的な距離
- 1対1 (近距離) <=> (遠距離) 1対多
文化的な距離
- 日本のみ (近距離) <=> (遠距離) 日本と海外
- 社内のみ (近距離) <=> (遠距離) 社内と社外
知識的な距離
- エンジニアとエンジニア (近距離) <=> (遠距離) エンジニアとセールス
- ベテランとベテラン (近距離) <=> (遠距離) ルーキーとベテラン
時間的な距離
- 同期的 (近距離) <=> (遠距離) 非同期的
- 短期的 (近距離) <=> (遠距離) 長期的
これらの掛け合わせから成る、情報発信者と受信者の距離感によって、情報共有に求める詳細度(円滑な個人の活動を維持する条件)が変化すると考えています。
詳細度を高めることは、受信者の違和感をなくすために情報をより作りこむことであり、共有に必要なコストの増加を伴います。
具体例をあげて、イメージを膨らませてみます。
1on1ミーティングは発信者と受信者が1対1であり、互いの時間が同期する。表情や身振りによる付加情報、個人向けに選択された言葉、質疑応答、これらを通してお互いの理解度を容易に補完できる。結果として、一次情報としての求める詳細度は低くなる。
共有ドキュメント投稿は発信者と受信者が1対多であり、互いの時間が非同期になる。概ねドキュメントからの情報が全てであり、一般化した言葉、非連続的な質疑応答、お互いの理解度の補完が容易ではない。結果として、一次情報としての求める詳細度が高くなる。
では補完が容易な、1on1ミーティングのような手法だけで全ての情報共有をできるか？というと、運用コストが高くなりすぎて現実的とは思えない。
つまりは受信者との距離感を手掛かりに、どの程度の情報詳細度が求められるかをイメージし、作成コストと理解度が合致するバランスはどこか？という判断をしていくことだと捉えました。
情報を共有するということは、どれだけの人に、どれだけのコストをかけて、どれだけの共通理解をつくるのかということであると、自分では解釈をできました。
組織における情報共有
行為そのものへの理解が深まったので、次に特定の組織に範囲を狭めて、会社における情報共有の理解を深めて行こうと思います。
会社で行われる情報共有とはどんなものでしょうか？
- 業務資料（企画書、手順書、計画書、報告書、議事録…）
- 作業進捗
- 会社運営に基づく想い（会社として、メンバーとして…）
- 知見やノウハウ（売上を作る、コストを下げる、新技術、効率化…）
ざっとこのようなものが思いつきました。
大きくわけて実務に短期的に影響するものと、中長期的に影響するものの2つがみてとれます。
業務資料や作業進捗は、短期的に共有する必要性が感じられ、払うコストに肯定感があり、意識しなくても共有がされていく情報。
想いやノウハウは、短期的には共有する必要性が感じにくく、払うコストに抵抗感があり、意識して行わないと共有されにくい情報。
それぞれの分類に対して、この様なイメージを持っています。
例外としてインシデントのような直近の実務に影響がでた場合には、しばしば積極的に想いやノウハウが共有される状況になることがあります。これは短期的な情報の必要性とコスト感のバランスが変わり、一定のコストを払ってでも想いやノウハウを共有することに、認識しやすい価値が生まれた結果と捉えています。
ここまでで会社内で実際に生まれやすい情報共有と言う意味では、短期的な必要性が払う共有コストを上回るかどうか？という視点が加わりました。
では例外が発生しない限り、短期的な必要性を伴いにくい想いやノウハウは、本当に共有コストを払うだけの価値がないのでしょうか？
これはひとえに、組織としてどうありたいかが関わってくる部分だと考えています。
次は組織規模と絡めて、想いやノウハウ共有が担う役割を整理したいと思います。
情報共有と組織規模
想いやノウハウは、共有コストを払うだけの価値がないのか？の問いについて、先に自分はどう思うかを書くと、払う価値があると考えています。
組織としてのアウトプットが、ここに書かれているような処理能力の一番低いラインに影響を受けることを前提とすると、ボトルネックを解消する行為は組織としてのアウトプットに寄与する。
想いやノウハウの共有にコストを払う価値は、そこにあると感じています。
会社における想いやノウハウといったものは、短期的な実務の推進力UPのためではなく、中長期的な育成や効率化に繋げていくために共有をしたいのです。
ただここで考えなくていけないのは、この共有コストは常に一定ではないということ。
会社が大きくなっていくということは、新たな拠点がうまれ、多様な働き方を許容し、個人が関わる人数が増えていくことになります。
これは情報共有の距離が広くなっていくことと、同義だと感じています。
円滑な個人の活動を維持するための情報が多岐に渡っていくのと同時に、距離が広くなったことで共有コストも高まっていく。
見渡せるくらいの人数であれば、情報共有フローを整備しなくても、ある程度ノウハウが行き渡るのかもしれません。ある程度想いを吸い上げられるのかもしれません。
しかし組織規模が拡大していく過程で、同じような共通理解を維持したいと願う時には、共有コストとの戦いが常につきまとうことになるのです。
情報共有とどう付き合うか
さて、最後にどう付き合っていこうか？という部分まできたので、まとめていきたいと思います。
理想を言えば、組織内全員の共通理解となれるような情報共有が行われて欲しいです。
しかし組織が拡大していくにつれ、詳細度の高い情報の共有コストは個人で担いきれないものへとなると考えます。
そこで、情報共有の捉え方を変える必要があると感じました。
情報の種をまき、フィードバックを与え、組織として育てていくもの。
組織として必要な共通理解を、組織としてコストを払い、情報共有の詳細度を保っていく。そんな風なイメージが今回できました。
このイメージに簡単な指針をつけて、おしまいにしたいと思います。
- 情報共有のコストを払って情報の種を巻いてくれる仲間を賞賛したい
- 情報はメンバーの参照とフィードバックを与えて組織で育てるもの
- 無駄にも見えがちな想いやTIPSも、距離感によって価値になることもある
- フロー型の情報は新陳代謝と効率化を、ストック型の情報は分類と詳細度を意識する
情報、育てていきましょう。
おしまい。
だから僕はあなたと働きたい
最近エンジニアチーム向けにキャッチコピーを作りました。
- 経営層と採用・人事・組織に対する振り返り
- エンジニア間の期待値を理解するワークショップ
- 過去の所属エンジニアへ在籍時の会社に対する心象ヒアリング
- 自分のありたい姿を再考
これらを通して見えてきた、現在の状況下における架空のロールモデルを表現する言葉ともいえます。
今の組織における抽象的な価値として、エンジニアの何を見ていくのかを提示するのが趣旨です。
今回はそれに自分の込めた想いを加えながら、まとめていきます。
前提条件
10人規模の組織、エンジニア業務を担っているメンバーは3~4人。
12:00~17:00がコアタイム、週2回リモート勤務OK、週1回全社会議あり。
一般的な勤務体系よりも比較的自由度が高く、ある程度多様な働き方を許容している組織です。
同じ時間帯に同じメンバーが顔を合わせて働くことは、全社会議がある日以外では基本的にないのが日常です。
この少数かつ多様な労働環境を支える、という視点がある程度加味されています。
この前提条件のもと、3つのことを言葉にしました。
3つのキャッチコピー
- 技術で違和感をなくす
- 技術を言葉にできる
- 技術と人に向き合う
1. 技術で違和感をなくす
何をするか
- 技術で既知の課題を解決する
- 技術で未知の課題を捉える
- 技術で課題解決の選択肢を増やす
継続するために
個人の専門性による思考、解決のアプローチを信じる
込めた想い
個人の専門性に自信を持つことは、自発的な行動の支えとなると考えています。
ここでいう自発的な行動とは、個人の考えを発言をすること。
人は自信がない状態では意欲的に発言せず、自信がある状態では意欲的になりやすい。
ある組織の中で、発言をした体験を積み重ねることが、組織内での発言行為そのものの心理的障壁を低くすることに繋がっていく。
個人が発言を継続的に行うことを通して、フィードバックの連鎖をチームに与え、全体としての課題解決の質を高めていく。
個人の自信がいかに課題解決へ繋がるかのイメージから、エンジニアとして自分の専門性を信じれることに、組織におけるエンジニアの価値の1つを見ています
2. 技術を言葉にできる
何をするか
- 文章だけでもコミュニケーションを成り立たせる
- 専門性を正確に文章にする
- 専門性を魅力的に表現する
継続するために
個人の影響力や共感力を過信せず、専門性の適切な表現方法を模索する
込めた想い
個人の専門性を文章で正確に、魅力的に伝えることが、多様な労働環境を維持することの支えとなると考えています。
ここでいう多様な労働環境とは、時間や場所の拘束をしない働きかたをすること。
時間や場所を固定せずに働く環境では、メンバーとの文字によるコミュニケーションが主となる場面が比較的多い。
視覚や聴覚から得られる情報量が低下する中で、質を落とさないための技術が必要となる。
良い文章の書ける人というのは、裏を返すと文章の読む力がある人でもあって、文章力を高めることが他者の想いを理解することに繋がっていく。
個人が文章表現の試行錯誤することを通して、チーム理解の深度を維持し、全体としての協働の質を高めていく。
多様な労働環境において、個人の文章力がいかに相互理解へ繋がるかのイメージから、エンジニアとして専門性の文章表現を模索することに、組織におけるエンジニアの価値の1つを見ています
3. 技術と人に向き合う
何をするか
- 技術を楽しむ
- 人に興味をもつ
継続するために
メンバーの専門性や思考性、成果に興味を持つ
込めた想い
個人とメンバーとの接点を増やし、個人間のフィードバックの量や質を増やすことが、成長実感を得ることの支えとなると考えています。
個人の限界値を拡大していくためには、いかにして良いフィードバックを獲得し、専門性向上のための行動を自分が継続できるかを考えていくことになる。
メンバーとの接点を増やす中で、メンバーが何に興味を持ち、いかに考え、どんな成果を残してきたかの理解を深めると、やがてそれが緩く期待値となって現れ、他者は期待に応え続ける事自体が、専門性を高める動機の一つとなる。
メンバーとの接点を増やすことを通して、緩く期待値の表面化を行い、自学への動機付けに寄与することで、全体としての成長実感を高めていく。
個人としてメンバーとの接点を増やすことが、いかに成長実感に繋がるかのイメージから、メンバーに興味を持ち、一定の刺激的な関係性を作れることに、組織におけるエンジニアの価値の1つを見ています
まとめ
専門性を磨き、磨いてきたものを信じて、それを魅力的に伝え、メンバーを巻き込んで、成果と成長を作っていく。
と言った一文に、まとめ直せるのかもしれません。
多様な働き方を維持するために、技術力だけではなく、文章力を持っていることを望む。
この部分が、今回の言葉にした中でも独特だなと感じています。リモート勤務が日常になければ、恐らく浮かび上がらなかった視点です。
独特な部分があることは、今の組織における価値観が良く表現された結果なのだろうと思います。
また、マネージャーとしてはこういった抽象的な概念を掲げた場合には、自分が実行していくこと、メンバーをいかに精神的に1人にさせないか、その２つを忘れずにありたいと考えます。
エンジニアの専門性に対する普遍的な評価とはまた少し違った、特定の組織内における価値観からくる評価を言葉にすることで、だから僕はあなたと働きたいを伝えられるポイントを増やしていきたいです。
タイトル回収をしたところで、今回はおしまい。
そこにスペシャリストの必要性はあるか
多様な人材が必要とされる中でも、スペシャリストを特に確保したいと位置付ける企業も多いのではないでしょうか？
ここで言うスペシャリストはエンジニアに対するもので、局所的な高い技術的課題解決力のある人と自分の中で定義しています。
この定義は以前に、エンジニアを理解するためのパタンの1つとして表現しました。
数多の企業が確保したい人材であることは、事業を作る過程に何らかの必要性が存在することを示唆していると考えられます。
その一方で必要性を提示し続けれずに、ミスマッチとなる体験を聞くことも少なからずあるのが実情です。
この実情は、ひとえに期待値のすり合わせ不足が要因にあるのでは？と感じるようになりました。
そこで今回は、スペシャリストへの期待値考察を通して、どんな必要性が存在するのか？何をすり合わせたほうが良いのか？をイメージできるように、自分の考えを整理したいと思います。
スペシャリストがもたらすもの
単に高品質の仕事をこなす人材であることが、スペシャリストの魅力ではありません。
事業に影響を与える範囲が大きいことこそが、魅力の本質ではないかと捉えています。
表層的な期待値と深層的な期待値という2つの観点で、その魅力と必要性の度合いを主観で探ってみます。
表層的な期待値
経験値に対する期待値とも言い換えられます。
スポットで在籍する場合と、フルで在籍する場合での違いを考えながら整理します。
スポットで在籍する場合
技術顧問や業務委託、外注等といったものも含んでいるものとします。
以下のような期待値を持ちます。
- 技術的課題を深くイメージできる立場からの意見により、いつ事業に技術的投資するかの判断基準の幅が広がる
- 対外的な評価を得ている方も多く、広報面の魅力が増える
- 共に働く環境があることで、メンバーのロールモデルや成長への内発的動機付けに繋がる
フルで在籍する場合
スポットで在籍する場合の内容に加えて、深く内部にいてもらえることで、以下のような期待値を持ちます。
- 高い実行力を定常的に確保できることで、事業推進力が高まる
- 実現性の高い技術選択肢が増えることで、事業戦略の幅が広がる
読み解けること
表層的な期待値からわかることは、スペシャリストの実行力が定常的に欲しいかで、フルである必要性が変わることです。
優秀な人材ほど流動性が高くなってきている傾向がある中で、本当にフルで在籍してもらうほどに求めているか？何をしてほしくて求めているか？
雇用形態や拘束時間への必要性を分解して採用を考えること、ミスマッチを減らすために大事にしたいです。
立ち上げて間もない企業にとって、スペシャリストにフルで在籍したいと思ってもらえる条件を提示しきれない場合。
たとえスポットでの在籍であっても、企業との関係性を持ってくれるスペシャリストが増えてくれることに意味がある。と判断できるケースもあるだろうと思います。
深層的な期待値
「高品質の仕事」という曖昧な表現に隠れた、事業フェーズや人数規模等の状況で変化する、実務に対する期待値とも言い換えられます。
事業フェーズ毎の違いを考えながら整理します。
立ち上げ時期
とにかく色々なものが足りていなく、試行錯誤をしながらプロダクトの方向性を確かめていく時期と捉えます。
何かを解決すればそれで確度が高まるという課題が見つかっていなければ、投資判断を引き出しきれずに、短期視点での泥臭い仕事も多いフェーズでしょう。
プロダクトの課題解決となるかどうかで、優先度も頻繁に変わることが予想できます。
この時期では、以下のような期待値を持ちます。
- プロダクトの価値検証の速度と精度を高めるため、メンバーが試行錯誤に没頭できる運用基盤を技術で実現してくこと
- 未来に実現しにくくなりがちな事柄の検討、短期的によしとして長期的に払う技術的代償の認識合わせを先導していくこと
調整時期
プロダクトの価値の方向性をある程度見出せており、拡大時期を見据えての一定の投資判断を引き出せるようになる時期と捉えます。
大きめの次期開発を進めつつ、日々の調整や販促サポート、技術的負債を返すことも検討事項に上がってくるため、関わる人が増え出すフェーズでしょう。
この時期では、以下のような期待値を持ちます。
- 拡大期にスピード感を落とさないため、メンバー増加に耐えうる開発基盤作り
- 一定規模の運用を支えるため、可用性を担保しながらの技術的課題解決を先導していくこと
拡大時期
プロダクトの価値が一定規模で認められ、積極的に投資をして事業規模をスケールさせる次期と捉えます。
スケールによる負荷対策や品質を保ち続けていくため、アーキテクチャ刷新や大規模リファクタリングといった、難易度が比較的高めの技術的課題が検討事項に上がるフェーズでしょう。
関わる人も数倍になっていくことが予想できます。
この時期では、以下のような期待値を持ちます。
- 顕在化した大きめの技術的課題を、率先して解決していく技術力と実行力
- メンバー育成や運用体制の効率化
成熟時期
プロダクトの成長スピードが鈍化し、投資回収等、ある程度堅実な運用をしていく次期と捉えます。
拡大期に比べると顕在化する技術的課題が少なくなってきて、プロダクトのさらなる価値を求めてR&Dの動きが出てこない場合には、再度泥臭い仕事も増えてくるフェーズでしょう。
この時期では、以下のような期待値を持ちます。
- 利益率増加のために、コストカットを技術で実現する
- 未知の事業課題を、技術で明らかにしていくこと
読み解けること
深層的な期待値からわかることは、スペシャリストの特性と事業フェーズ毎の期待値が、どれだけ合致しているかで必要性が変わることです。
持ち合わせる特性や好む責任の範囲が人によって違う中で、今実務的に求めたいことを実行できるか？得意としているか？
事業フェーズ毎の必要性を分解して採用を考えること、ミスマッチを減らすために大事にしたいです。
立ち上げ時期を好むスペシャリストにとって、調整時期や成熟時期で活躍を求めた場合。
たとえ技術的な専門性の範囲から採用要件に合致していても、今はお互いにとって良い関係を築けない。と判断できるケースもあるだろうと思います。
何をすり合わせるのか
企業にむけて
スペシャリストに対する期待値に、どれだけの条件（金額面や裁量面）を提示できるか？
これが利害関係一致の土台部分であるため、雇用における基本だと思います。
その上で、他に考えていきたいことも見えてきました。
- 雇用形態や拘束時間への必要性を分解して考えること
- 事業フェーズ毎の必要性を分解して考えること
分解していくことで期待値が過大になるのを抑制し、求めることに対しての条件提示を細かく考えられる。
このすり合わせができることで交渉の幅が広がり、よりよい関係に繋がると考えます。
スペシャリストにむけて
金額面や裁量面は最ものこと、付加価値のやりがい（スペシャリストの成長に意味のある技術的課題が存在する等）になり得そうな環境を提示できるのか？
これが利害関係の強い結びつきに繋がるのではないかと考えます。
とはいえ投資できないフェーズでは、期待値はあるものの望むような条件を提示できないケースも理解はできます。
なにが提示できないのか、どういう提示ならばできる可能性があると考えているのか。
このすり合わせを細かくすることで、企業と個人間での公平感に持てれば、よりよい関係に繋がると考えます。
まとめ
スペシャリストの魅力や思考性、企業の投資判断や事業状況を検討事項として、どんな関係性を作れるのか？
何らかの要因があって、結果として合致しそうな条件や環境を提示できないのだとしたら、そこにはスペシャリストへの期待値はあっても、必要性は存在しないということなのでしょう。
今は絶賛立ち上げ時期であり、泥臭い仕事はそれなりにある。実際に技術的課題解決として任せたいのはこの部分。裁量面ではある程度好きにやってもらえるように環境を用意したい。今提示できる条件はこれくらいです、事業が拡大期になったのであれば、特定の技術的課題を任せることと、そのフェーズとしての必要性を考慮した条件の再提示を約束する。といったようなすり合わせをする意味をイメージできました。
お互いの期待値と不足点を整理し、正直に話した上で落とし所を見つけるフロー、大事にしていきたいですね。
おしまい。
エンジニアの個性を理解するために必要なこと
エンジニアの個性とはなんでしょうか？
一緒に働いているメンバーであっても、ひいては自分自身のことであっても、表現することが難しいと感じています。
そんな最中、採用に携わってきた方に頂いた言葉がとても強く印象に残りました。
これまでずっと企業の採用に携わってきて、特にエンジニアやプログラマの人は、他の職種の方に比べてこだわりポイントみたいのが多種多様かつ明確な人が多いと感じていました。
この言葉を受けて明確なこだわりがあってこそのエンジニアらしさであり、そのこだわりのベクトルがエンジニアの個性たるものなのではないかと考えることができました。
エンジニアの個性が少し具体化したように感じます。しかしまだ多様なこだわりのベクトルは曖昧です。
このベクトルの部分を、エンジニア以外でも認知しやすい表現に落とし込めるのであれば、組織とエンジニアのミスマッチが減るのではないか。 エンジニア間の期待値理解、エンジニアのモチベーション起因把握に役立つのではないか。
そんな想いを胸に、エンジニアの個性を今より少しでも深く、認知できるための何かを探ることが今回の趣旨です。
エンジニアの個性を探るための手がかり
サーバーサイドやフロントエンドといった、扱う技術領域による分類は個性でしょうか？
技術領域の違いも、個性であると思います。
技術領域は、組織内におけるエンジニアのパタン・ランゲージ*1になり得ているため、個性の表現に値すると考えています。
また事業価値を成長させていく過程で、チーム開発において繰り返し起きる課題（事業に直接的な課題だけではなく品質低下・レガシーシステム・モチベーション低下等の、開発を継続する上での包括的な課題のことを考えています）を解決するエンジニアというものが存在します。
この部分こそが、エンジニアの個性を表現する上での、重要な要素ではないかと感じています。
しかしこの部分は、技術領域や役職による分類だけでは、うまくイメージしきれていません。
そこでエンジニアの専門性・役職・活動・思考といったものをパタンとして名前をつけ、エンジニアの個性がパタン間の関連で表現されると捉え、今より少しでも深くエンジニアの個性を認知できるための手がかりにしていきたいと思います。
パタン
一般に知れ渡っている概念や、役職として定義されているものも含めて、エンジニアが業務上貢献している側面と性質に、主観ではありますが名前付けをしていきたいと思います。
スペシャリティパタン
- フロントエンド（サービスの表現に対して技術的解決をできる能力を持つ）
- バックエンド（サービスの処理に対して技術的解決をできる能力を持つ）
- インフラ（サービスの安定稼動に対して技術的解決をできる能力をもつ）
テクニカルパタン
- プログラマー（局所的に技術的解決をできる能力を持つ）
- ゼネラリスト（広範囲に技術的解決をできる能力を持つ）
- スペシャリスト（局所的に高い技術的解決をできる能力を持つ）
- エキスパート（広範囲に高い技術的解決をできる能力を持つ）
マネージメントパタン
- リーダー（局所的に組織的解決をできる能力を持つ）
- マネージャー（広範囲に組織的解決をできる能力を持つ）
- ディレクター（広範囲に高い組織的解決をできる能力を持つ）
チャレンジングパタン
カバーリングパタン
- コラボレーター（職務領域にとらわれず企画やセールス等の支援もする）
- メンター（エンジニアに適切なフィードバックを与える）
- メンテナー（エンジニアの継続的なアウトプットや効率性の支援をする）
インフルエンスパタン
- リアクター（発信された技術や想いに反応を示す）
- パフォーマー（社内外に技術や想いを発信する）
- タレント（社外に発信した技術や想いで評価される）
思考パタン
- サービス思考（ユーザー価値がある事業、好きな事業に貢献したい）
- 技術思考（新しい技術領域、好きな技術領域を通して貢献したい）
- 成長思考（責任を負える、適切なフィードバックを得られる環境にいたい）
- 協働思考（友人、尊敬する人といった自分の好きな人と働きたい）
- 独立思考（自分の生活、個人の時間を大事に働きたい）
- 評価思考（評価、業務貢献度による対価を正しく与えてほしい）
パタンの可能性
今回あげたパタンは、多様な組織に属するエンジニアに見られる、普遍的なものとも捉えられます。
このようなエンジニアの個性パタンを定義することは、組織としてエンジニアの評価軸・課題設定・フォローアップ・チームビルディング・採用方針といったものにも応用が利く可能性があると感じています。
もう少し具体化した例をあげていきます。
パタンを通してロールモデルとの差分を課題設定にする
ロールモデルと設定しているエンジニアは、バックエンドにおけるスペシャリスト。 技術思考と成長思考に裏打ちされた、イノベーターな側面とタレントな側面もある。
一方現状自分はバックエンドにおけるゼネラリストであり、ロールモデルと比較するとスペシャリストとしての活動量がたりていない。 またスペシャリストとしての探究心を保つために、定期的なフィードバックを得られるようにパフォーマーとしての活動も必要かもしれない。
大枠としてロールモデルとの差分を認知しやすくすることで、どうロールモデルに近づくか？自分らしく課題と向き合い目標をたてるか？指針としての可能性があるかもしれません。
パタンを通してエンジニア採用の方向性の理解を深める
ある程度自立しているエンジニアでかつ、よりチーム開発を円滑にしてくれる様なエンジニアがほしいという裏側にある想い。
現在のチームにはゼネラリストでかつ、コラボレーターとして活躍している主要なエンジニアがいる。
さらにコラボレーターの側面を持ったエンジニアを採用して、そこの掛け合わせによってチーム開発の円滑さを高めるのか？
メンテナーの側面を持ったエンジニアを採用して、エンジニアチームのアウトプットを向上させる形で、エンジニア主導の円滑さを高めるのか？
採用したいエンジニア像を、イメージするための問いかけになる。
エンジニア採用の方向性として、エンジニアチームと採用チームとの相互理解に繋がる可能性があるかもしれません。
終わりに
単純にパタンの組み合わせで成り立つだけでなく、関連性の強いパタンと弱いパタンがあると思います。随時新たなパタンも生まれることと思います。
そんなパタンの関係性を捉えて、チームとして掛け算になるよう調整をとることが、マネージメントの腕の見せ所なのかもしれません。
今回の話は、エンジニアの個性をより深く捉えるための表現方法の模索が主旨でした。
エンジニアの個性を理解するために必要なこととして、愚直に向き合い続ける姿勢を持つこと。エンジニアらしさに沿ったアプローチをとること。少なくともこの2点を、自分の中で大事にしていく考えを作れました。
エンジニアを精神的に一人にさせる様なことを、少しでも減らせるように、継続的に考えていきたい課題です。
おしまい。
感情を日報にする
日報に何を書くでしょうか？
作業報告、成果報告、課題報告といったものが一般的な内容ではないかと考えています。 やることリストと捉えて、自己のタスク管理とする人もいるかもしれません。
今回は一般的なものとは少し違う形で日報をつけはじめたら、頭の中の不安が減ってきた。何を不安に感じて、なぜそれが減ったのかを整理しておこう。というのが趣旨です。
今回取り上げる日報を、便宜的に感情日報と呼ぶことにします。
感情日報に何を書かないのか、感情日報に何を書くのか、感情日報を続けてみてどうなったのか？という構成で進めていきます。
感情日報に何を書かないのか
進捗や成果、課題等は基本的には書きません。
日々の進捗や成果報告は、チームにおける進捗管理を確認できることで満足できます。
日々の課題報告は、朝会やチャット上ですぐにフィードバックが得られることで満足できます。
感情日報は、いわゆる日報が担う役割については求めていないことになります。
感情日報に何を書くのか
その日の行動による所感を文字に起こし評価することで、日々の感情のゆらぎを表現します。
なぜそんなことをするのかを、背景含めて書いていきます。
チームとしての進捗や成果共有、課題の解決においてはそこまで不自由していない。 それでも自分の中で、まだ表現できてない何かがあると感じていました。
単純にそれは小さな不安であり、忘れては思い出しを繰り返すことで、心の中で大きく積み重なっていきます。
このままではよくないと感じて、何が足りないのかを考えていくと
- 今日は楽しく働けただろうか？
- 今日は何か貢献できただろうか？
- 今日は自分らしく振る舞えただろうか？
このようなことと日々向き合えていない状態を、自分は不安視しているのだと理解しました。
自分らしく振る舞えていたか？ということは、人によっては少し幼稚に思えるのかもしれません。 しかし自分には、日々のタスクと向き合い続けるために、不安を取り除くための大切な要素です。
これはつまり何かというと、自分がありたい姿でいれているのか？という問いなのです。
この問いに対する変化を客観視できるようにすることが、感情日報の役割です。
感情日報の構成
所感を文字に起こす
思うがままに、その日の行動から感じたことを文字に起こします。
例). とある日に書いた所感
全体的な方針決めをしていった issueかくのむずかしい でもこういう環境を整備してくのは嫌いじゃないなとおもった issue作りとかフローの提案して、思った形で一旦進められることになってよかった 何かを聞かれたときにすぐフィードバックするの大事 ガガガっと決済ほしいときには、事前準備がすごい大事 人の思考の拘束時間を短く、違和感をすぐなくすように！の精神で動くのがキモだ
所感を評価する
文字に起こした所感を手がかりに、その日の感情を評価します。
以下の問に対する評価を5段階で行っています。（）内の補足は評価の軸を表しています。
- 自分らしく振る舞えていた？（行動の選択権の有無、意志の表明の有無）
- 高揚感があった？（緊張の有無、好奇心の有無）
- 充足感があった？（尊重の有無、フィードバックの有無）
- 達成感があった？（貢献の有無、責任の有無）
続けてみてどうなったのか
日々の感情のゆらぎをつけていくと、自分の浮き沈みの傾向、感情と感情の関係性等を捉えられるようになります。
- 不安に感じてたけど、案外楽しい感情の日が多い
- 充足感を持ったときほど、貢献したとも感じてる
- ある項目は評価3が続いて浮き沈み自体がない期間がある
変化を見れるようになったことで、もっと自分に刺激を与えようか？沈んでる原因はなんだろう？を考える時間が増えました。 考える時間が増えた結果として、自分のありたい姿に繋げる行動のイメージが膨らみました。
漠然としていた不安を、自分の考えられる粒度に変えられたことが、不安の減少になったのでしょう。
まとめ
- 自分の感情を評価することを、日報のフォーマットを使うことで定期的な仕組みにする
- 評価する行為や評価結果を通して、自分らしく振舞うために何をするかのイメージを作る
以上、感情日報でした。
チームの文化とは何なのか？
チームの文化は何を与えてくれるのでしょう。
ある文化のなかで働くということは、価値観や慣習を共有しながら働くことであり、チームにおける暗黙知を与えてくれる。 共通の暗黙知をメンバーがお互いに持っていることで、コミュニケーションの基礎となりチームの意思決定を早める。
つまりはチームを円滑に機能させるための必要条件（十分条件ではない）なのではないかと思っています。
- そもそも文化とはどんな概念なのか？
- 意識的にチームの文化を作るとはどういうことなのか？
- なぜチームの文化を良いものにする必要があるのか？
という3つでチームの文化を考えてみたいと思います。
そもそも文化とは？
文化（ぶんか、英語: culture、ラテン語: cultura）にはいくつかの定義が存在するが、総じていうと人間が社会の成員として獲得する振る舞いの複合された総体のことである。社会組織（年齢別グループ、地域社会、血縁組織などを含む）ごとに固有の文化があるとされ、組織の成員になるということは、その文化を身につける（身体化）ということでもある。人は同時に複数の組織に所属することが可能であり、異なる組織に共通する文化が存在することもある。もっとも文化は、次の意味で使われることも多い。
* ハイカルチャーのように洗練されたもの
* 象徴的な思考や学習による信念やふるまいのパターン
* ある社会組織に共有されている価値観
なにやらすっと入ってきにくい言葉が並べられていて、うっ…となるので自分の言葉に噛み砕いていきます。
チームを通して人と人が関わることで抱く想いや価値観、言葉や行動の積み重なりがそのチームにおける文化と呼ばれるようになる。
こう解釈すると悪しき文化も良き文化も、自分達で積み重ねた結果でしかありません。これは自分達の歴史とも言い表わせるのではないでしょうか。
過去の文化はある時点まで積み重ねた行動の結果
今の文化は現時点まで積み重ねた行動の結果
未来の文化はこれから積み重ねていく行動の結果
チームの文化というのは時間軸上のある断片のようなものとも捉えられます。 その断片は、チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。
流動的な性質をもった概念であり、その時々の条件を受け止めて継続的なフィードバックをすべきものだと理解しました。
文化の輪郭が少しつかめた気がします。
この考え方をもとに、意識的にチームの文化を作るとはどういうことなのか？を考えていきたいと思います。
意識的にチームの文化を作る
組織的な取り組みの構造を理解する
チームの文化を作る上で、どのような組織的な取り組みが良い効果をあげているのかは、著名な方々や企業が数多くの事例を示してくれています。
数多ある取り組みのなかの1つに共感し、所属チームでも同じように取り組んで良い文化を作っていこう！と考えた時に、果たして同じような効果は得られるものでしょうか？
ここでチームの文化が、もう一度どんなものであったかを思い返します。
チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。
これはつまり、チーム毎の構成要素には様々な違いがあることに他なりません。
違いがあることを前提に持つと、自分達が同じような効果を得るには、取り組みの構造を捉えることが大事になってきます。
その取り組みは、何をチームに与えるのだろうか？なぜ良い方向に働くのだろうか？結果として自分達の望むチームの文化形成に寄与するだろうか？
構造を理解することで、今のチームに与えるべきものだろうか？チームに落とし込む際に大事な観点はなんだろうか？という問いが明確になるからです。
「チームのあるべき姿を言葉にすること」という例を取り上げながら、組織的な取り組みの構造を考えることをやってみたいと思います。
チームのあるべき姿を言葉にすること
チームのあるべき姿・価値観を表すための取り組みとして、ミッション・ビジョン・バリューを設定しよう！というのをよく目や耳にします。
なぜこのような取り組みをするのでしょうか？
過去に一度考えたことのあるテーマで、その時の所感としては
日々の業務レベルにおいて判断基準の1つになり得るものである。
エンジニアが経営理念について考えた話 - nozayasu
というものでした。
チームのあるべき姿を設定することで、メンバーに行動の判断基準を与える
メンバーに行動の判断基準を与えることで、メンバーやメンバー間に健全なフィードバックを促す
一定の基準に基づいたフィードバックの積み重なりが、結果としてチームの文化を望むものへと緩やかに調整する
というような構造を自分のなかで解釈できました。
共通の理想像は、チームの継続的なフィードバックにおける指針となり、日々の積み重ねの方向を無意識下に調整してくれるのでしょう。
実際にチームのあるべき姿を言葉にする際には、チームにおける行動の判断基準になりえているか？フィードバックを生んでいるか？を観点として持つことができました。
ルールや慣習に向き合う
組織的な取り組みの構造を解釈し、チームに落とし込むために必要な観点を持つことをしてきました。
どんなに良い取り組みも、定着することなく中途半端で終わってしまってはチームの文化形成には繋がらないでしょう。次は定着させるために何ができるのか？ということを考えていきます。
イメージを湧かせるために「ユーザーファーストに徹すること」を例にしてみましょう。
ユーザーファーストを組織的な取り組みとして実現するために、職種の垣根を超えてユーザの声を日々の行動や施策に活かすことを推奨する。
この時、チームでは何が起きるでしょうか？
エンジニアが営業同行して直接ユーザーの声を聞きにいく、営業がSQLを駆使してユーザーの行動ログを分析する。ユーザの声をより深く知るために、職種や職能の垣根も超えてどんな向き合い方ができるのか？をメンバーは模索するかもしれません。
しかしこれはあくまで、メンバーの意欲に依存する形です。定着を目指す場合には、ある程度のルール化を検討する必要があると考えています。
ルールにするということ
具体的なルールとは「月一回エンジニアは営業同行をすること」といったものです。強制力を持つルールは、メンバーを行動させることに直結するため、取り組みを定着させることに強い影響力を持つと思います。
行動を起こさせるではなく、行動をさせるという言葉を使いました。ルールというものは個人が納得感を持っているかは関係なく、行動という結果を引き出すような力も持ち合わせるため、それが苦痛であると受け取られた場合強い反感を買うことでしょう。
メリットとデメリットを考えた上で、どのような場合にルールにすべきなのでしょうか？自分のなかの基準を考えておこうと思います。
- チームの理想とする価値観を共有するため、それが望ましい強制である場合
- 立場・職種・職能を超えたフィードバックや指摘をしやすくなるよう、メンバーに公平性を与えたい場合
1について
たとえルールの設定者側が望ましいと思っても、最悪の場合それを理由に辞められるかもしれない。ということはあり得るだろうと思っています。
なので、なぜそのルールが望ましいと思っているのか？をチームやメンバーに繰り返し言葉にすることを、合わせて行うべきと考えています。
2について
チームに取り組みを定着させるためには、メンバー間での監視が機能することが必要です。人間は忘れる生き物であり、ミスをする生き物だと捉えています。だからこそ、フィードバックを日常的に行えることが定着に強い意味を持ちます。
しかしフィードバックというのは、職種や立場を超えて行うことに心理的障壁が伴うものであるというのが一般的です。 そこでルールです。ルールという共通の基準を逸脱したか？で判断できる状態を与えることは、フィードバックをするという行為の心理的障壁を和らげるだろうと考えています。
慣習の扱いを決めるということ
チームにはルールのように明言されていないが、メンバーが同じようにとる行動である慣習と呼ばれるものが存在します。
ある行動を他者が真似する形で生まれたもの、メンバー特性によって生まれたもの、ルールの副作用で生まれたものといったような自然発生するものです。
慣習は自然発生したものであるがゆえに、チームの文化にとって望ましいものであるとは限りません。扱いとして、認める・認めない・黙認するという3つの選択肢が考えられます。
価値観にマッチしているか？メンバーの自由度を妨げないか？何か問題が起きているか？という観点で、いかに扱うべきかを判断する必要があると考えます。
特に黙認する選択肢をいれることが大事だと思っていて、慣習を認める・認めないと明言することはルールを作ることと同義であり、メンバーに前述したようなストレスをもたらす可能性のある行為です。直近問題がないのであれば、あえて黙認することにも意味があると感じています。
なぜチームの文化を良いものにするのか？
チームの文化というものは、良くしたことで事業の利益に直接影響するものではないかもしれません。
また事業がうまくいってるときには、得てしてチームの雰囲気も自然といいものです。 逆に言えば、事業が苦難と対峙したときほどチームの雰囲気が悪くなります。
ここで考えなければいけないことは、チームの雰囲気が良いこととチームの文化が良いことは別であるということ。チームの雰囲気が良くても組織的負債は貯まっていく可能性があるということ。
なぜチームの文化を良くするのかと言われれば、それは事業を継続させより発展させたいから。
事業が苦難と対峙した時にどう切り抜けるか、チームが苦難にきちんと対峙できるようにしておく必要がある。
そのために普段からチームの文化のことを考えていなければいけない。組織的負債を溜め込み過ぎないようにしなければならない。
たとえ事業がうまくいかず雰囲気が悪くとも、それでも必死にチームとして事業に向き合っていれてるのであれば、そこには良いチームの文化があるのだと。そんな風に僕は思うのです。
