まずは自己紹介
ナレッジワークでエンジニア組織の仕組み作りなどを担当しているsedoと申します。
Enablement Groupという部署に所属していて、社内のプロジェクト管理の仕組みを整えたり、社外への情報発信イベントの運営サポートなどをしています！
なんか、うまくいくチームって「理由」があるよね
「天才はいらない」なんてちょっと極端かもだけど、
チームでうまくいってるときって、実は「誰かひとりがすごい」よりも、
「それぞれの強みが噛み合ってる」ことが多いんですよね。
逆に、「スキルはあるはずなのに、なぜかうまく回らない…」ってときもある。
この違いって、意外と「個人の特性」と「役割のマッチ度」が関係してたりします。
今回は、自分が大事にしたい「理想の組織づくり」について、ちょっとまじめに書いてみようと思います。
イネーブルメントって、ただの支援じゃない
組織づくりの中で、すごく大事だと思っているのが「イネーブルメント（Enablement）」という考え方。
これは単なる支援じゃなくて、その人が成果を出しつつ、ちゃんと成長できる状態をつくるということ。
特にポイントだな〜と思うのは、以下の2つ。
- 得意なことを活かして成果が出ること
- 苦手なことにも小さく挑戦できて、成長につながること
つまり、「活かしながら育てる」。この両輪がまわる組織が、いいチームなんじゃないかなと。
そして、ナレッジワークはこの「イネーブルメント」をプロダクトを通して本気で実現しようとしている会社なんです！
個人の特性を活かすってどういうこと？
「強みを活かす」って言葉はよく聞くけど、それって具体的にはどういうこと？って話。
たとえば、プロジェクト管理の仕事で言うと…
Aさん：丁寧さが強みの人
- 進捗確認や細かいチェックが得意
- ただし、大まかなスケジュール設計は苦手
→ そんなAさんには、誰かがざっくり描いたスケジュールをもとに、
抜け漏れなく進めていく「安定運用」フェーズで力を発揮してもらうのが合ってそう。
Bさん：戦略が得意な人
- プロジェクト初期のロードマップ策定が得意
- ただし、細かいタスク設計や実行管理は苦手かも
→ 逆にBさんには、企画初期〜中期にかけて、全体の道筋を描く役割が向いてる。
小さく試せる環境が、成長には不可欠
どれだけ「合ってそう」なことでも、やってみないと分からないことも多い。
むしろ「やってみて初めて、自分の強みに気づく」ってよくある話。
だからこそ、小さく試せて、失敗しても大丈夫な場を用意することが大事。
たとえば、懇親会の企画を「プロジェクト管理の練習台」にしてみる
- ゴール設定：「なぜ開催するのか？どうなったら成功か？」
- 制約確認：「会社から近い場所・1人5,000円以内・アレルギー配慮」
- ロードマップ：「いつまでに何をやる？」（日程調整→予約→準備 etc）
こういう身近なタスクでも、ちゃんとプロジェクトマネジメントになるんですよね。
スキルの違いが活きるのは、プロジェクト管理だけじゃない
ここまでプロジェクト管理の例を中心に紹介してきましたが、
こうした「特性を活かし合う関係」って、もちろん他の領域でもめっちゃ大事なんですよね。
特に、エンジニアリングの世界ではその傾向がより顕著。
たとえば「設計が得意」とひとことで言っても、その中身って人によって結構違います。
ということで、次はエンジニアリング領域での例として、
システム設計における「得意・不得意」の違いを見てみたいと思います。
システム設計だって、得意・不得意があっていい
エンジニア視点で言うと、プロダクトのシステム設計もまさに「得意・不得意が分かれる領域」。
必要な知識も経験も多いから、
「いきなりゼロから理想的なアーキテクチャを描け！」って言われたら、
たいていの人は「無理っす…」ってなると思いますｗ
まずは「構成図を書いてみる」ところからでOK
- 既存のプロダクトの構成図を自分で描いてみる
- 「なんでここでバッチ処理？」みたいな疑問をコメントに残してみる
- 少しずつ「設計の背後にある意図」を考えるクセをつける
設計にもいろんなタイプの「強み」がある
設計ってひとことで言っても、得意なフェーズって人によって違います。
大まかな設計が得意な人
- サービス分離・データフロー設計・アーキテクチャ選定が得意
- でも、ログ設計や障害対応の細かい詰めは抜けがち
非機能要件などの整理が得意な人
- セキュリティ要件、冗長化、モニタリング設計などが丁寧
- でも、全体の構成をざっくりと描くのは苦手だったり
これって、どちらも設計に必要な力。
「誰が正解か」じゃなくて、「どう組み合わせるか」が大事。
「違い」を活かすには、すり合わせがめっちゃ大事
特性が違うってことは、見ている視点やチェックポイントも違うということ。
認識を合わせないままだと、ちょっとしたやり取りでもすれ違いが起きやすくなります。
認識ズレがあると、こうなる…
- Aさん：「たたき台を出したのに、細かい指摘ばっかり来る…」
- Bさん：「なんでこんなざっくりしたものが出てくるの？考えが足りないのでは…？」
どちらも悪くない。それぞれが自分の視点で「良くしよう」と思って動いているだけ。
「期待値合わせ」は、設計のIFみたいなもの
すれ違いを防ぐには、事前の「期待値合わせ」＝お互いのIF設計が必要です。
- 自分はどこまでを担当するのか
- どんなアウトプットを出すつもりか
- どういうフィードバックがほしいのか
これをちょっと合わせておくだけで、批判じゃなくて「補完」の関係になれる。
やりとりのイメージ
- Aさん「まずはシステム全体の設計のたたき台作るので、細かいところ気になるとこ追記してもらえると嬉しいです」
- Bさん「了解です！あとで非機能要件とかログ周りとか詰めますね」
これだけで、空気めっちゃ和らぎますｗ
最強のチームって「集合天才」なのかも
「Collective Genius（集合天才）」っていう言葉があります。
ひとりの天才じゃなくて、それぞれの強みがかみ合って、チーム全体として天才になるって考え方。
- 得意を持ち寄る
- 苦手を補い合う
- 成長を支え合う
そんなチーム、めちゃ良くないですか？
ちなみにこの「Collective Genius（集合天才）」ってナレッジワークが掲げるポリシーのひとつで、特に好きなポリシーなんですよね。
最後に：あなたはどんな特性を活かしたい？
この記事を読んで、もし「自分の特性ってなんだろう？」って思ったら、
それってもうすでに、チームをよくしたいっていう気持ちの証拠だと思います。
あなたは、どんな特性を活かしてみたいですか？
あるいは、誰かのどんな強みを活かしてあげたいですか？
よかったら、あなたの体験談を身近な人に話してみてください！
あとがき
こういう話って、現場でのちょっとした会話や1on1の中でこそ活きると思ってます。
この記事が、そんな対話のきっかけになったら嬉しいです！
最後にちょっと紹介
他にも以前に私が投稿した記事を紹介しておきます。ご興味あれば読んでみてください。