秋のブログ週間2024の1本目です。

はじめに

Technology Innovation Group真野です。

社会人歴15年の中で、自分が業務で実施したことがない領域のマネジメントを求められる場面がありました。

私で言うと、普段はバックエンド（バッチ処理やWeb APIなど）を作ることが多いです。フロントエンド開発・モバイルアプリ開発・ML／データ分析系の領域について、フルコミットで直接開発を行ったことが無く不得手です。実際の開発はそれぞれリーディングできる人材がいるという前提ですが、やったことがない技術領域のチーム も 「見ておく必要がある」という時にどうすべきかの考えをまとめます。なお、ちゃんとした経験者をマネージャーにアサインすべきという話が間違いなく正論ですが、体制上そこまでリッチに組めなかったこととし、計画周りをどうこうする話はこの記事では割愛させてください。

エッセー的な話が多く、普段のフューチャー技術ブログのテイストからは少し引け目を感じるテーマですが、秋のブログ週間は、秋の夜長を楽しむため読み物成分を多めに書くというテーマであるため、この場をお借りさせてもらいます。

想定するチームイメージ

この記事で想定するプロジェクトのイメージは「モバイルアプリ」「バックエンド」「データ分析」の少数ながら複数のチームが存在し、例えば自分は「バックエンド」の設計開発もしつつ、他の技術領域は詳しく無いとします。また、全体スケジュールや利害関係者への報告を含むPjM的な役割を持つとし、「モバイルアプリ」「データ分析」それぞれに技術面ではリードできる人材がいるとします。

わからないからと言って放置して良いことはない

大前提として、チームの自律に任せて放置しても良いことは何もありません。

良く発生しがちなことですが、技術的に設計開発などの観点で自分にできることは無いため、「何かエスカレーションがあれば声をかけてね」、といった態度を取ってしまいたくなります。

分からないなら、分からないなりに踏み込んでいくしか無いと思います。例えば、今着手している作業が何であるか、どこが課題か、チームが複数のメンバーがいればどういう役割分担になっているかなどは、技術が分からなくても把握することが可能です。

ヒアリングを通して、タスク分解が上手くできていないことも多くあります（だからこそ、「だれか見る必要がある」という話になります）。あるいはタスク同士に依存関係があり、先回りして進める必要があるとか、スケジュールを利害関係者と調整する必要が早期に分かることもあります。

技術的な課題であれば、社内外の有識者に知見を求めるというサポートを行うこともできます。「やったことがない技術領域」だったとしても、やれることは無限にあると気がつくでしょう。

どこかで説明可能にする必要がある

進捗報告や、業務的やコスト影響がある設計上のトレードオフの相談など、ITエンジニアではない利害関係者に報告／相談することはよくあるでしょう。どのようにスケジュールや体制、業務やシステム費用などに影響するかなどは、設計や技術要素そのものを知らなくても伝えることは可能で、少なくてもその視点でのマネジメントは可能です。

実作業はお任せできたとしても、そうした「利害関係者に伝わる形」に変換することが、マネジメント対象のチームに能力／リソース的にできないことから、依頼されている背景もあると思うので、そこは支援ないし巻き取ると良いでしょう。

具体的には、今の進め方で利害関係者が欲する進捗報告になるのか。技術サイドとして説明しやすいその進め方が許容できるのか。不都合があるなら何かしらの認識齟齬があるので、理由を整理して明文化し、ハレーションしないようにするなどがあります。説明資料はどっちが準備するかは状況次第ですが、レールに乗るまでは事前にレビューは必須でしょう。

技術的に詳しくないマネージャーってウザがられるのでは？

技術領域に詳しくないのに、マネジメントを実施することで、メンバーに嫌がれるのでは？という感覚があります。

私の経験上は、そういう人もいるかもしれないけど、今のところ見たことがない、という結論です。気にしても仕方がないという事かもしれません。

考えてみれば、私も上長全員が、私が今扱っている技術のスペシャリストではありませんでした。しかし、人格含めて別の部分が優れており尊敬の対象でした。手を動かしている自分が詳しいのは当たり前で、それぞれ活躍のフィールドが異なり協力しながら価値を出すのは当たり前の話で、それでいくとやったことがない技術領域のマネージャーだからといってそれだけで嫌がられることは普通ないはずです。万が一、壁を感じたとするとおそらく別の理由がありそうです（例えば、タスクの無茶振りをしてしまったなど）。

むしろ、知らないなりに環境構築をやってみたんだけど分からない部分があって～や、チュートリアルをやってみたんだけどここに詰まって～などを聞いてくれる上長には好感を抱く人が多いでしょう。実際にはメンバーもマネージャー双方が忙しいと思うで、本当にメンバーに教えてもらう場を取るかは別として、態度としては興味を示して行くことはプラスでしょう。

メンバーのタスク調整

想定するチームが複数に分かれている場合、全体最適を行う責務があるのは横断的に見ているマネージャーです。例えば、別のチームから一時的にメンバーをヘルプとしていれる、というのは有力なオプションです。もちろん、メンバーとは1on1などを通して志向を確認した上ですが、一時的にテストだけ手伝って欲しいなどはよく発生します。

また、チーム間のシステム的な結合部分（DB共有、ファイル共有、Web APIなど）は、仕様を事前に決めていたとしても内部結合は意外とチェックが甘くなることも多いです（むしろシステム間I/Fの方がきっちり進められたり..）。このあたり、一番戦力的に手薄なチームの調整を巻き取ったり他チームに調整することができると嬉しいでしょう。

所属メンバーが複数のチームに即戦力的な経験があると、本人が納得してもらえそうであればあるより柔軟に意思決定できるようになります。注意として、気軽にチーム間でメンバーを移動させると、所属意識が希薄となり、モチベーションを下げる傾向があります。「自分がそういう扱いをされたらどう思うか」を常に忘れないようにすると良いでしょう。メンバーの移動であれば、「いつから」「いつまで」が大事で、2週間ほど前から、◯◯のタスクが終わる1ヶ月程度、といった言い方が最低限のラインでしょう。

たまに、1ヶ月と言って数ヶ月延長するようなパターンも見ますが、本人にはチリツモで怒りが積もってしまうため、良くないです。フェアに情報開示して依頼する方が、信頼関係を保て長期的な関係を築けると思います。

と、言っても技術的に何かしら手伝えるところは意外にある

最初に、「技術的に設計開発などの観点で自分にできることは無い≒やったことが無い技術領域だから」という話をしましたが、何かしらの技術について1領域でも秀でているのであれば、技術的に支援できる余地があることも多いです。例えば、「データ分析」をやったことがなかったとしても、結局システムに組み込む部分は、通常のアプリケーション開発と変わらない部分が多いです。Terraformなどのインフラ構築も同様ですし、設計観点もです。単体テストの考え方や進め方、何かしら技術的にハマった部分を、分からなりにChatGPTやGoogleなどで調査することも、精度の差はあれど可能です。

得意領域に比べて効率が最大で無いだけで、タスク分解などを通して全体感を把握して動ける分、エントリーレベルより有利かもしれません。最初に分からないから～で壁を作るのではなく、余力があれば踏み込むのも双方良いことがあります。

該当のチームで手薄な部分をこっそりキャッチアップしておいたり、ChatGTPなどAI支援でたたき台を作ったり簡単な技術検証をしておくと、存在感が爆上げだと思います。おそらく自分のタスクもあって手一杯な状態だと思いますし、やり過ぎると良くないですが、食い込める余地を探すのもこういったチャレンジの醍醐味です。

1 on 1

マネジメントをやるのであれば、メンバーに対する1on1は必須です。

コツについてはリモートワークになって始めた1 on 1ミーティングに記載どおりです。

1on1が集中する日は、一日の半分以上が面談であるということもざらでしょう。必要な投資と割り切り、天引きと思うと良いでしょう。

何を話すかはもちろん人によります。例えば以下のような内容です。直近の仕事の話はしても良いですが、中長期的な話を全くしない場合は、開催間隔を短くします。

• 今の業務内容がキャリアなど本人の志向とあっているか
• 困っていることはないか、悩みはないか、不満はないか、成長実感はあるか、楽しいか
• もし、タスクの意義を見失っているのであれば、プロジェクトの大義や目的を再インプットする
• マンネリしていたら、やりたいことを聞いてタスク調整したり、視座を上げるように引っ張ったり
• マネジメント、というか自分の関わり方のフィードバックをもらう

結局、やることはあまり変わらない

結局のところ、得意領域／不得意領域のマネジメントだろうが、やることはあまり変わらないことに気が付きます。

共通するところ：

• タスク分解、依存関係の把握、優先度付、スケジューリング
• チームのリソース配分
• 課題に対する、解決案の調査、設計
• 1on1
• リスクマネジメントを考える、リスクヘッジを取る
• 品質の保証を最終的にどこで取っていくか、ブラックボックス的な視点で考える

おそらく異なる：

• 何か課題が合った場合に最悪自分が巻き取ればよいという選択が取れない
• よくある技術面でのハマりどころなどを事前に潰すなどのリードができない
• メンバーへの設計レビュー、コードレビューなどで直接該当領域の技術レベルを引き上げることは基本的にできない
• コードやテストが良い状態なのか内部品質について、究極的にはチームを信じる形になること

心理的に異なる部分は、「最悪自分がやれば良い」という選択が取れないことでしょう。次に、知っている領域だと内部と外部品質の両面から、何かしらの悪い予兆を察せるところが、限定的になる部分です。そのため、リスクヘッジは厚めに取るしかないです。スケジュール上のバッファー確保、利害関係者への期待値コントロール、不確実性が高いタスクの見極めとその着手を早める、などです。一度、不得意領域を担当すると逆にこのあたりの感覚が磨かれる良い面もあります。

コードレビューどうするか問題

やったことがない技術領域のチームから出た、コードレビューを実施すべきでしょうか？ 例えば、私はSwift／Kotlinを全く実装したことがないし、モバイル開発に明るくないので、そういったレビュー依頼が来ると厳しいです。カメラ周りとかBLE周りとか色々ハマりどころがあるんでしょうが、何も言えないです。最近のアプリ審査だと△△△らしいから気をつけて～とは言えても、それを詳細した実務的なタスク面は正直知らんがなです。ただ、命名など人によって見ることが可能な部分はあるでしょう。どこまで自分がレビューできるものなのか、確認してみないとはじまらないので、なるべく初期は手厚く見ておいた方が良いです。分からないとしても、とりあえず全ての変更に目を通す、ところから始めます。

全くレビュー観点を持てないような場合は、チーム内で任せるか、不安であればレビュアーだけ外部メンバーに依頼するなどの調整を行うしかないでしょう。

個人的には、意外にフォーマッター、リンターが整備されていなかったり、設計ドキュメントやコードコメント、フォルダ構成などの開発規約がちゃんと守られているか、単体テストが実施しているかは、どの領域であっても気になるため、サラッとは見るようにしています（自分をapprove必須にはしていません）。

一般的にメンバーのアウトプットを確認するクセを付けておくと、1on1のときのフィードバックに役に立つこともありますし、メンバーの評価的なところにも具体性が増すでしょう。評価のやり方は組織それぞれだと思いますが、フューチャーでは360度評価で、制度上の直接の評価者でなくても、評価コメントを入力します。単なる私見ですが、評価の納得感が無くして個人／チームの成長は無いと思っているので、これは地味に重要な観点です。

開発環境は作っておくべきか？

画面がある系のアプリケーションは、作っておくと動作確認などの用途で便利です。しかし、主体となって開発しないと個人の経験では、いつの間にか壊れることも多く（依存ライブラリのアップデートなど諸々の理由で）、コストパフォーマンスは悪いかなと思います。

しかし、一度は開発環境を構築しておくとどういう手続が必要か、あるいはどの程度セットアップが整っているかが分かり、また何となく開発の具体的な流れも把握できるようになるため、オススメです（あと、テストやら画面が動くとちょっと楽しいです）。

さいごに

最初からマネジメント視点でキャリアを積んでいる方から見ると、何を今さら？な内容だったと思います。一方でテックリード、アーキテクト的な立場でいることが多い人の中には、やったことがない技術領域のマネジメントについて、拒否反応のようなものを示す人が少なからずいるのでは？と感じたため書きました。

あらゆる技術をフルスタック／フルサイクルで知っているに越したことないのは事実です。それにより技術的観点から事前に効果的な打ち手を出せる価値は計り知れないからです。しかし現実的には手薄な領域が出てくるでしょう。それでも考えるべきこと、やるべきことは無限にあります。「最悪自分が手を動かせば..」という奥の手を封じられるため不安な面もありますが、その分学べることも大きいです。もし、同じような状況になった人にも、より前向きに取り組める人が増えてくれると嬉しいです。