ダイニー Engineering Manager の urahiroshi です。
ダイニーのエンジニア組織は今まさに組織拡大中であり、今後どのような組織にしていきたいのか、そのために何が必要なのかといったところを日々考えています。
現在のエンジニア組織については、以下のページのculture deckを参照ください。
どのような組織にしていきたいか、という点について1つ挙げたいポイントは「成長を加速する組織」という面です。組織が持続的に成長を続けるためには、組織に所属する一人一人のメンバーが成長することが必要不可欠だと考えます。現在のダイニーのエンジニア組織では、顧客目線やプロダクト志向のようなカルチャーが浸透していると感じますが、採用を強化する中でカルチャーが薄まっていくのは避けたいです。そのためには、ダイニーのカルチャーを体現しているメンバーがリーダーシップを担っていってそれを組織に伝播していくこと、新しく入ったメンバーがカルチャーを吸収してまた次のカルチャーの伝導者となることが理想です。そのため、新しいメンバーの採用と既存メンバーの成長の両軸の取り組みを行っています。
成長できる組織として、以下の2点が重要であると考えています。
- チャレンジの機会を増やす
- 卓越性を伸ばす評価・フィードバックを行う
これらの点について、どういった考え方を持ち、現在どのような対応を行なっているかについて紹介したいと思います。
チャレンジの機会を増やす
オーナーシップの重要性
計画的偶発性理論 (Planned Happenstance Theory) というキャリア形成のアプローチでは、「個人のキャリアの大部分は予想しない偶発的なことによって決定されるため、計画外の出来事に好奇心をもって行動し、キャリアのチャンスとして活かす」ことを推奨しています。こうしたチャンスとなる機会に恵まれる組織であり続けることが目指す方向性の一つであると考えます。
組織の中で成長を促進するチャレンジとして重要なポイントは「オーナーシップ」だと考えています。ここでのオーナーシップとは、明確な対象範囲に対して意思決定の権限があるということです。
例えば、GitHubでコードレビューをする場合について考えてみましょう。GitHubでは、ディレクトリやファイルの変更があった際に、自動的にコードレビュー依頼を受け取る ”コードオーナー” を設定できます。通常、コードオーナーの設定は単に作業の自動化だけの意味合いを持っているのではなく、その名の通り「コードに対して責任を負っている」ことを示しています。コードオーナーとなったメンバーは、対象のコード変更をプロダクションコードとして受け入れられるかどうかの意思決定権限があるため、「コードの可読性・保守性が保たれているか」「必要なテストが記述されているか」「妥当な設計がされているかどうか」などの点について判断基準を持ち、受け入れられない場合は基準を示すことが必要となります。
このように、「チームの中で自分がこの決定に対して責任がある」という状況は何かしら自分の考え方に対する指針を持ち、チームの中においてそれを説明することが求められます。技術的な知識については個人でも磨くことができますが、チームの指針を作っていくことは組織の中でしかできないため、オーナーシップの機会を増やすことは重要な成長機会となると考えています。さらに、オーナーシップを通じて特定のメンバーが実質的な決定権を持っている、いわば「最後の砦」になっていると感じられることが重要です。そのように 「自分の後ろには誰もいない」という感覚は人を成長させる鍵になります。
どのようにオーナーシップの機会を増やすか
組織としてオーナーシップの機会を増やしていくために、重要なポイントは役割の明確化と権限委譲です。 役割分担を行う際に用いられる図として “RACI図” というものがありますが、これは複数人でタスクを実行する際に、参加者を４種類の関わり方に分割するというもので、以下の4種類の頭文字をとって “RACI” と呼んでいるものです。
- Responsiblie (実行責任者)
- Accountable (説明責任者)
- Consulted (相談先)
- Informed (報告先)
自分は特に「実行責任 (Responsible)」と「説明責任 (Accountable)」の概念が重要だと考えています。説明責任者がそのタスクの最終責任者であり、タスクの受け入れ基準を定義したり、タスクの成果物を承認するかどうかを判断します。通常は実行責任者と説明責任者を同一に考えるケースが多いかもしれませんが、オーナーシップの機会を増やす・権限委譲をするという観点では、実行責任者と説明責任者を分けることも選択肢とできると良いと考えています。
例えば、チームの中で特定の目標Aを達成するために、タスクB, C, Dを実施することを考えます。このとき、以下の２通りの責任分担が考えられます。
- チームのTech Leadが目標Aの実行責任・説明責任を持ち、タスクB, C, Dの説明責任を持つ
- チームのTech Leadが目標Aの説明責任を持ち、他のメンバーが目標Aの実行責任とタスクB, C, Dの説明責任を持つ
2の責任分担では、Tech Lead以外のメンバーが一定のオーナーシップを持つことができるので、育成の観点では望ましいと言えるでしょう。ただ、(実行責任は持たないが)説明責任を持つというのは、実行責任のあるメンバーに適切なアドバイスを行うために一定の経験が必要となります。そのため、Tech Lead自身の経験が短い場合は1を選択してTech Leadの経験を積む状況が良い場合も考えられるでしょう。
このように、各メンバーにとってチャレンジとなるオーナーシップを持てる機会を増やせるようなアサインを意図的に行なっていくこと、それを実行しやすい組織体制になっていることが、個人の成長を促しやすい組織になっていると言えます。
チャレンジを増やすダイニーの取り組み
ダイニーでは、積極的にメンバーに新しいロールをアサインすることで、個人の成長を加速するような試みも行っています。
もちろん、チャレンジの方向性が個々のメンバーが目指すキャリアにマッチしているかという点は前提としており、ドメイン理解や専門性向上のためにロールは変更しないなど、個人やチームの状況によって対応は異なります。
また、個人だけでなくチームが自律的に動くためのオーナーシップを持っていることも重要です。最近では新しいプロダクトの開発プロジェクトも立ち上がってきており、個々のプロダクト開発チームが要求探索・開発・運用までオーナーシップを持てる体制を整えています。
卓越性を伸ばす評価・フィードバックを行う
フィードバックの方針
組織活動では、定まった期間において個人の目標設定と評価が行われます。個人の成長において、評価やフィードバックは自分の現在地を把握して今後の方向性を定める上で最も重要な仕組みだと考えています。
DIAMOND社「ハーバード・ビジネス・レビュー」に掲載された論文 “フィードバックの誤謬” では、フィードバックについて3つの誤解を指摘しています。
- 誤解1. 弱点は本人よりも他者のほうがよくわかるため、自分では気づかないことを他者に教えてもらうことが、一番自分のためになる
- 誤解2. 獲得すべき能力があなたに欠けているなら、同僚がそれを教えてやるべきだ
- 誤解3. 優れたパフォーマンスは普遍的で、分析可能で、説明可能なものであり、ひとたび定義できれば誰にでも応用できる
この論文ではこれらの誤りを指摘した上で、足りない部分をフィードバックしてそれを埋めるように促すのではなく、自分の卓越した部分がどのようなものかを理解できるように手助けすることによって、気付きのチャンスを与えることを推奨しています。
組織の評価制度やフィードバックにおいても、「良い例」と比較してどのように不足を補うかという方向で考えるのではなく、個々人が優れたパフォーマンスを出している部分に着目し、その部分により再現性を持たせたり、さらにパフォーマンスを発揮できるような方向性を示すことが理想と考えます。
ダイニーのエンジニア評価での試み
こうした考えを前提として、ダイニーのエンジニア組織では、星取表のようにあらゆる側面で良い動きができるような方向性を推奨するのではなく、個々人の卓越性を活かして最終的にどのようなインパクトを出したかという点で評価やフィードバックを行う試みを始めています。
最近のエンジニア評価では、スペシャリストとマネージャーのような2軸の評価基準を設けている会社も増えていますが、ダイニーではインパクトの種類を「個人としてインパクトを出した部分 (=Speciality)」と「チームがインパクトを出すことに貢献した部分 (=Leadership)」に分離し、それぞれのインパクトをベースとして総合的な期待値の設定と評価を行っています。
インパクトをどうやって出したかというHowの部分は問わないとともに、「実装のスピードと質の高さで貢献した」「メンタリングやリーダーシップによってチームのパフォーマンスを上げた」「チームのマネジメントを行いながらも、技術力を活かしてピンポイントで難易度の高い実装を行なった」のように、キャリアの型をはめずに、個人の卓越性により着目した評価をできるようにしたものです。
おわりに
ダイニーでは、組織の成長を支えるメンバーを募集中です！本記事に記載した内容の詳細を聞きたいといった要望でも結構ですので、興味がある方はぜひお話ししましょう！
Discussion