フラーで新設されたプロジェクトの技術責任者『テクニカルマネージャー』はどんな役割？ 技術面でプロジェクトにコミットするための取り組みを聞いてみた！

本当に必要とされるものを創る『デジタルパートナー事業』を営むフラーでは、エンジニアを含む開発チームの全員が遠慮なくプロダクトの仕様や方向性に対して意見し合う文化があります。
そしてこの度、その文化をより強固にするべく、「テクニカルマネージャー」という役割の新設を行いました。

「テクニカルマネージャーの意義」や「実際の現場でテクニカルマネージャーがどう動いているか」について、テクニカルマネージャー新設を提案したメンバーに、話を聞いてみました。

目次

1. ——経歴やフラーでの役割を含め、簡単な自己紹介をお願いします
2. ——「テクニカルマネージャー（以下、TMと表記）」とは、どんな役割ですか？
3. ——アプリ開発の現状と、そこでTMが必要とされる理由について教えてください
4. ——テクニカルマネージャーを務めてみて、どんなことを実感しましたか？
5. ——具体的な良かった点や改善点を教えてください
6. ——畠山さんによるモデルケースを経て現在、正式に『テクニカルマネージャー』を配置するしくみが新設されましたが、組織としての手応えはいかがですか？
7. ——最後に、どんな人がテクニカルマネージャーに向いているか教えてください
8. お知らせ

——経歴やフラーでの役割を含め、簡単な自己紹介をお願いします

畠山：
エンジニアの畠山です。開発では主にフロントエンドを担当しており、フロントエンドユニットのテックリードも務めています。
また、VPoEとしてマネジメントや採用関係の業務も行っています。

VPoEについて：

——「テクニカルマネージャー（以下、TMと表記）」とは、どんな役割ですか？

畠山：
プロジェクトの開発責任者です。各プロジェクトに原則1名割り当てられます。フラーではもともと「プロジェクトマネージャー（以下、PMと表記）」と呼ばれる役割がチームに1人存在していたのですが、それに加えて技術的な指揮をとる役割を新たに設置した形です。

開発が滞りなく進むよう、あらゆる手段を講じる人、とも言えます。プロジェクトの立ち上げ時から参画し、計画、見積もり、リスク管理、技術仕様の策定推進などに関わります。

一般的なクライアントワークでは、クライアントとの会議にエンジニアが積極的に参加することは、あまり無いんじゃないかと思います。
すると、どうしてもエンジニアのメンバーが開発するものやその背景をあまり理解していない状況が生まれてしまいます。その結果、製品に対して「なぜこんな仕様になっているんだ」とか「もっと良い仕様があったのに」という不満に繋がってしまい、品質にも影響が出てしまいます。

フラーではそうならないよう、これまでもエンジニアが自分たちの開発する製品に対して意見し合う文化がありました。エンジニアは意外と製品のいいアイディアを持っていることも多いんですよ。
でもそれらをまとめる正式な役割が明確になっているわけではありませんでした。それに加えて、技術的な背景を理解した上でアイディアを提案や要件に落とし込むのには、それなりの専門スキルが必要でした。
そこで今回、改めて正式な役割を定義することに決めたんです。
プロジェクトの初期からエンジニアがちゃんと製品にコミットするというのが、弊社で大切にしている姿勢のひとつです。

前述のとおり、チーム内のマネージャーはTM以外にも、プロジェクトマネージャー（PM）がいるのですが、そちらは技術的なバックグラウンドを必須要件としていません。
フラーのPMはセールスのスキルに長けたメンバー、マーケティングの知識が豊富なメンバー、チームビルディングが得意なメンバーがいたりと様々です。また、複数のプロジェクトを掛け持ちしている場合もあり、技術的な要素が絡む意思決定を迅速に行うのが難しい場合も多かったです。
そこで、リーダーシップがあるエンジニアをTMとして正式に任命し、開発の指揮をとってくれることを期待したというわけです。

——アプリ開発の現状と、そこでTMが必要とされる理由について教えてください

畠山：
まず前提として、アプリの開発は難しいんです。
クライアントワークではそれに加えて、ステークホルダーが多いことや、予算やリリースの計画をプロジェクト開始前にある程度決定する必要があることから、難易度が更に高くなります。また、クライアントの業界のドメイン知識が全くない状況からプロジェクトが開始する場合もあります。

この難しい仕事をこなすためには、クライアントのことを深く理解し、チームが共に学びながら開発を進めていく必要があります。
TMを配置する以前は、開発の計画を立てたり進捗を管理したりなどの役割もPMが担っていましたが、明らかに責任が集中しすぎておりうまく進行できないことが多々ありました。
また、プロジェクトによっては重要な議論の場にエンジニアが同席していないということが稀に発生していました。エンジニアが開発で忙しそうにしていると、会議の同席を依頼するのが憚られるという状況があったそうです。

しかし、そういう状況では大抵、忙しいのはエンジニアだけではありません。そこでPMの判断に時間が掛かるものが蓄積すると、あらゆるもののボトルネックになってしまいます。
すると最悪、リリースは迫っているのにあれも決まってないこれも決まっていない……という状況になってしまうんです。これは決してPMの力不足ということではなく、難しい仕事が1人に集中しすぎていることが問題なんです。事業の成長に伴い製品に対する要求が高度になってきている昨今では特に深刻な課題でした。

こういった状況の解決策として打ち出したのが、「エンジニアリングの視点を持ってプロジェクトに初期から参画し、製品のドメイン知識や仕様をよく理解するエンジニアを各プロジェクトに必ず1人配置する」こと、すなわち今回の『テクニカルマネージャー』の新設です。

そして、モデルケースとしてまずは自分がその役割を担ってみることにしました。

——テクニカルマネージャーを務めてみて、どんなことを実感しましたか？

畠山：
実際にやってみるととにかく大変でしたね……。自分のマネジメント能力が足りていないことを何度も思い知らされました。
以前にも小さなプロジェクトで開発を指揮した経験があったので、うまくいくイメージはあったのですが、たくさんの未知の課題に直面することとなりました。

「こんなに大変な仕事なんだから、やはり誰かが片手間でやるべきものではない」と強く確信しました。

また、現場で痛感したのは、問題は必ず起こるということです。しかも、問題の火種は至る所に潜んでいて、全てを事前に見通すことも不可能です。
そういった現実を前提にして、開発体制を整えたり、計画を見直したりしなければなりません。

問題が起こったときに良い判断をするには、専門知識と適切な情報が不可欠です。
マネジメントをする人間がその両方を持っているのがベストですが、専門知識が足りなければそれを持っているメンバーと共に対処してもらえる信頼関係を築くことが大切だと感じました。

——具体的な良かった点や改善点を教えてください

畠山：
自分としては反省点も多かったのですが、メンバーからは「仕様やスケジュールを常によくわかっているエンジニアが、全体を見渡してくれたことが本当によかった」という評価をもらえました。

また、アプリの仕様についてクライアントと議論する際に、技術的な制約をその場で指摘できることで重要な意思決定がスピーディに進んだ点も良かった点に挙げられますね。
もしその場にエンジニアがいなかったら、「エンジニアに確認します」と持ち帰りになっていたでしょうし、そういうことが積み重なると開発が遅延してスケジュールが圧迫されてしまいます。

それから、クライアントには「持ち帰りにならずその場で意見をもらえるから、気軽にアイディアを言いやすい」とも思っていただけたのかなと。この点は、いいものをつくるという面においても良かったことですね。

改善点……というか、やはり実感することになったのは、この役割の難しさですね。計画の調整がうまくできず、開発が遅延してしまいました。
コントロールすべきところをできませんでしたし、問題が起こるという前提もきちんと持てておらず、「あった方がいいけど必須じゃない機能」を勇気を持ってバッサリ捨てる意思決定が上手くできなかったため、中途半端にしてしまったと反省しています。自分含めてマネジメントのスキルを更に身につけていくことが今後の改善点です。

また、自分は実装のタスクをいくつか担当していたのですが、作業の時間が全くと言っていいほどありませんでした。
マネージャーがコードを書くことは、技術仕様を解像度高く理解することができるメリットがありますが、現実的には時間の確保がなかなか厳しいです。コードレビューや設計レビュー、それから細かい改善タスクやバグ修正に留めて、他は極力メンバーに任せるべきだったかもしれません。

……いや、正直ここはジレンマですね。開発チームのマネージャーが全くコードに対して無頓着だったら自分もやっぱり良い気持ちはしません。だけどいざ自分が務めてみると、コーディングに関与する時間がなかなか確保できず、自分がボトルネックになってしまいました。それがすごく申し訳なかったです。

落とし所としては、計画段階では自分に実装タスクを割り振らないことにして、もし時間と心に余裕があれば積極的に……といったあたりでしょうか。これについては自分の中でもまだ正解は見つかっていません。
ともあれ、個人的な反省点として言えるのは、計画段階からもっとチームのそれぞれの専門知識を持ったエンジニアを頼るべきだったということです。

このように、アプリ開発をリードするのは難しい仕事でした。この難しさは、ソフトウェア開発における難しさそのものでもあると思います。
だから、これをうまくやっていくための知見を貯めていけば、フラーはもっと素晴らしい製品をつくれるはずだと思っています。

——畠山さんによるモデルケースを経て現在、正式に『テクニカルマネージャー』を配置するしくみが新設されましたが、組織としての手応えはいかがですか？

畠山：
良くなった点としては、各プロジェクトにおいて今まで曖昧になっていた責任範囲が、より明示的になったことが挙げられますね。これまでは曖昧になって停滞している課題があったときは、献身的なメンバーが積極的にカバーしてくれない限り放置されて遅延の原因になっていましたが、この問題が軽減されたと思います。

また、PMからは「技術についてなんでも相談をしていい相手」がはっきりしたので、遠慮なく頼ることができるようになったという声を聞きます。エンジニアからは、仕様の背景を把握しやすくなって作業がしやすくなったというフィードバックをもらっています。

課題は、TMのマネジメント能力の育成と、難しい仕事がTMに集中してしまうことです。
それから、PMとの連携が難しいという課題もあります。TMがどう動くべきかはPMの得意領域によって変えていく必要があります。このあたりは改善する方法を考えていて、まだまだ伸びしろがあるなと感じていますね。

他に改善を検討している点としては、評価制度の話が挙げられます。エンジニアのマネジメントスキルを評価する仕組みが十分でないと感じています。これについては現在CTOと協力して取り組んでいます。

——最後に、どんな人がテクニカルマネージャーに向いているか教えてください

畠山：
向いているのは……優しい人でしょうか。クライアントワークでは様々な人々と協力して仕事をする必要があるので。時には難しい判断をしなければいけないときもあります。だからこそ、いろんな気持ちや立場を思いやって理解してくれる優しい人がいいんじゃないかと思います。

あとは「まずやってみる」という行動力も重要だと思います。あれこれ心配して時間だけ過ぎていくのはもったいないですから。失敗を恐れず、どんどん行動できる人だと、チームも学びを得ながら成長できていいのかなと思います。

お知らせ

畠山さん、ありがとうございました！

フラーではエンジニアをはじめ一緒に働くメンバーを積極採用中です。

フラーやフラーのエンジニアにご興味お持ちいただけましたら、お気軽にご連絡ください。

なお、この記事は、フラー公式note「フラーのデジタルノート」に掲載中の記事を転載したものです。