記事を書くにあたって
エンジニアの方々が専門領域について、Advent calendarに記事を書く中、
非エンジニアの私の記事で良いのか！？と思いつつ。
モノづくりの１つの体制（組織構造）として、
弊社では、Planner、Designer、Engineerが、1つのチーム内に存在しており、
その中で、非エンジニアの私が、Managerを担い、経験したこと、感じている事を書こうかと思います。
1つのチームに異なるロールが属する組織構造
弊社のモノづくり体制は、以前、企画部・開発部があり、似た領域のメンバーがチーム内に属していましたが、
約２年ほど前から、プロダクトの担当領域毎に責務を担うチームとして、チーム内にPlanner、Designer、Engineer（フロントエンド、バックエンド、機械学習）が属する構造に変化しました。
この構造によって、担当プロダクトの課題をチーム内に閉じて進めることができるため、課題解決までのスピードが比較的早まったと感じます。
一方で、Plannerと機械学習Engineerの対話など、ロールや専門領域が異なるメンバー間のコミュニケーションが増加するなど、従来の組織とは、異なるハードルがあることも確かです。
ロールが異なるメンバーが集まった協業
まず、「ロールが異なる」と書きましたが、同じロールでも過去の経験や得意領域、価値観等が異なるため、それぞれのメンバーと向き合い、相互理解、敬意を持った言動が必要なことは、どのような組織でも同じです。
それを前提としても、専門領域に尖ったメンバー同士が集まり、同じ課題・方向性に向かって進んでいたとしても、目先の課題、対話で利用する単語の違い（俗にいう「プロトコルの違い」）によって、コミュニケーションコストが高まったり、認識齟齬が生じやすい環境であると思います。
また、対話する先や内容、タイミングによって、求められる粒度が異なるため、担当領域の垣根を超えた周辺知識が求められる環境であると思います。
より成果を挙げていくために考えること
先にも書いた通り、弊社の組織構造は、開発スピードをあげる１つの手段として有効と考えます。
そのメリットを享受するために、個人的に心がけていること、組織としてサポート頂いている事を書きます
※ 以下は、個人的に感じていることです。
イキイキ仕事ができる環境を整備
1日の活動時間のうち、多くを費やす仕事時間。
その時間が例えば、苦痛であり、時間の経過をまつ状態であれば、新しいアイデアが生まれたり、価値提供ができる状態とはかけ離れた状態であり、チームの成果は上がりません。
Baseにあるのは、それぞれのメンバーのパフォーマンスが最大化されること、そして、その相乗効果によって、1+1が2以上を生み出すと思っています。
「イキイキ仕事をする環境」は、書いたり、表現するのは簡単ですが、各チームメンバーのWillや今のPhase、（仕事以外も含む）置かれている状況によって違い、今日・明日・明後日でも変化するので、そう簡単に構築できる物ではないですし、構築完了のゴールがないものかもしれません。
ただ、変化する状況の中、イキイキ仕事ができる舞台を整えることが、マネジメントの仕事の１つと思っています。
個々人のStyleを理解
弊社に参画し、私が学んだ大きな１つ。
マネジメントに係わる方であれば、「当たり前」なことで、"何をいまさら！？"かもしれませんが。
人それぞれ、得意・不得意があったり、綿密な計画を立ててから行動する人やまず行動する人、最低限のコミュニケーションで黙々と成果を挙げていく人・・・様々な方々で構成されているのが現状です。
これは、人それぞれのStyleや個性、価値観であって、全く同じ人は居ないという断言をしても良いぐらいだと思います。
一方、PlannerやEngineerというラベルのようなものがロールとして付いています。
気をつけていることは、「Styleを重視出来ているか！？」ということです。
"PlannnerだからXX"や"上司だからXX”と言われると、言われた本人はどんな気持ちになるでしょう？
ユーザーの課題解決やチーム運営をしていく中で、必要な領域がありますが、その領域を（ロールに関係なく）メンバーがカバーしあえれば良いのではないかと考えています。
イメージ的には、「◯◯さんは、XXが得意だから、この部分お願い出来ます？□□は私がやろうと思います」のように、領域の垣根を超え、価値提供をしていければと思っています。
弊社行動指針（Scientific）
俗に「プロトコル」の違いによるコミュニケーションコストの増加や、認識齟齬、そもそも"話が噛み合わない"状態を感じることがあります。
弊社の行動指針の１つ。
- Scientific
数字をビジネス、プロダクトの共通言語として、すべての事象や方針決定においてできる限り数字の裏付けを基に実施され、評価され議論が行われる
この行動指針（Scientific）を意識することで、「プロトコル」の違いによる課題を一定割合、解決することができると考えています。
最低限の知識を有する努力と、相手に解る様に説明する努力
対話する上で、前提知識が異なることで、話が合わなかったり、検討や理解が進まないことがあります。
担当領域の垣根を超えて、メンバー間で協業しカバーしあう関係性を作るには、担当領域だけでなく、周辺知識や最低限の知識を学ぶ努力は必要だと思っています。
また、話す側は、相手の立場や課題解決に対し論点にしている事を理解し、相手向けの話し方、内容を心がける努力が必要だと思っています。
一言でいうと「ホスピタリティ」になるかと思います。
目標達成支援と成長支援
私自身も元Engineerでしたが、それ以降の十数年は、企画職やマネジメント職を担ってきたので、
DesignerやEngineerに対して、最新技術やトレンド、今後のキャリアに関する積極的なアプローチが難しくなっています。
そのため、弊社では、EM（Engineering Manager）やTL（Tech Lead）と連携をして、目標設定および、成長支援をサポートしています。
期末の評価時には、EM, TLとの連携はもちろんのこと、各メンバーと一緒に仕事をしたチーム内外の方々にお話を伺って、様々な角度から情報を集めることで、正当な評価ができるような仕組み、体制で臨んでいます。
さいごに
専門領域の違うメンバーが集まるチームのマネジメントについて、経験し、感じている事を書きました。
私自身、マネジメントが得意なんて言えないですし、今後も言える状態にはならないでしょう。
なぜなら、個性も違う、価値観も違う、その上、それぞれの強み、専門領域も違うからです。
マネジメントに、成功パターン・勝ちパターンというものは存在せず、過去に似た経験があっても、全く同じ状態ではなく、そのまま適用することはできないことが多いです。
この状況の中でどうするか！？それは、人と向き合い、各チームメンバーのStyleを理解し、それを尊重したマネジメントが重要ではないかと思っています。
優秀な現メンバーと、イキイキ仕事ができる環境で、ユーザーの課題解決ができればと思います。