【#STRIVE勉強会】開発現場におけるスタートアップの技術課題と解決法を学ぶ

2019.11.18STRIVEby STRIVE

投資先の方々向けに毎月実施している「STRIVE勉強会」。専門分野のプロフェッショナルの方を招き、各社が実践的に使えるノウハウ・スキルを身につけられる講義とワーク型のイベントです。

10月のテーマは「開発現場におけるスタートアップの技術課題」。“うまくワークしない開発”に対して問題意識を抱くスタートアップは少なくありません。その原因は経営層とエンジニアサイドの意識のズレや正しいフレームワーク運用の誤解があります。

今回は、元株式会社nanapiCTOであり、現在はアル株式会社CTO和田修一氏にお越しいただき、いままでの技術顧問の立ち位置から見てきた開発現場で起こりがちな問題のパターンと解決策についてお話いただきました。実践的なノウハウの一部をレポートします。

◆講師和田修一氏プロフィール
2009年に株式会社nanapiを立ち上げ、取締役CTOに就任。
2014年に同社をKDDIへ売却。得意分野はiOS/RoR/PHP/マネジメント/採用/技術広報など。CTO退任後は、はコンサル・技術顧問などで複数の会社と関わる。2019年2月にアル株式会社取締役CTOに就任、現在に至る。

技術課題の本質とは

プロダクト開発に関わる悩みを抱える経営者は少なくありません。そして、「バグが多い」、「開発が遅い」などの問題の理由は「技術レベルが低い」とひとくくりにまとめられがちです。一方、実際の開発現場ではレベルの高いエンジニアが在籍しており、うまくワークしていないことが本質的課題というケースもあります。

こうした問題の原因は、3つに集約されます。

プロダクト開発にはPjM(プロジェクト・マネージメント)、PdM(プロダクト・マネージメント)、PpM(ピープル・マネージメント)が関わりますが、それぞれの役職が混同すると開発現場の課題の本質を見失いがちです。

また、マネージャーが進めているプロジェクトと、メンバーが期待していた方針がずれてしまうこともあります。達成すべき結果そのものが違えば、開発は予定通りに進みません。そもそもエンジニアの採用基準が間違えている場合も、こうした問題につながる人選が行われているかもしれません。

これらの問題が起こりがちな原因を、より詳細に考えていきましょう。

ピープルマネジメントは最優先事項ではない

第一に、問題はそもそもどのマネジメントに課題があるのか正しく理解できないところから始まります。

多くの場合、問題が起こるとピープルマネジメントに目を向けてしまいます。プロダクトよりも人の問題はわかりやすく、語りやすい傾向があるからです。

本来、プロダクト開発はプロダクトが最優先事項となるべきです。それを実現するためのプロジェクト、プロジェクトを支えるピープル（人）という順位で課題を見つけていきましょう。

特に、経営層はプロダクトや事業のことを重点的に議論することが大切です。プロダクト開発には複合的な課題がつきものですから、プロジェクトと人材の課題を混合してしまわないよう、根本的な課題に向き合う姿勢を心がけてみてください。

エンジニアが語る技術的課題を鵜呑みにしない

次に、コンセンサスが取れないプロジェクトは、エンジニアと経営層の視点のすれ違いが起こっているかもしれません。

エンジニアの強みはミクロな視点で課題発見できる鋭さです。したがって、彼らの見る技術的課題は事業の全体像を捉えたものではないことがしばしばあります。

近年はこうした方針のズレを「技術的負債」という言葉でまとめてしまいがちですが、経営者はその負債の詳細が何であるか理解するよう努め、エンジニアもまた、説明するよう心がけることが大切です。

課題のズレや不明瞭さを感じた場合は、「Patterns and Shift」という手法が役立つかもしれません。点在する課題をすべて出したうえで、それをグルーピングしていく方法です。解決策ごとにグループを分けてみることで、課題の本質を捉えるための糸口を見つけることができるでしょう。

エンジニアの技術力と課題解決力を切り分ける

こうした要因を振り返ればわかるように、技術的課題を解決するのは技術力ではなく課題解決力であるケースがほとんどです。また、仮に課題を一つひとつの点で解決しても、同じ問題が再び起こるでしょう。再発を防ぐためには、根幹の問題を把握する考え方や手法を取り入れられる人材が求められるのです。

開発現場における課題解決力とは、課題を的確に把握する場を設け、そこで課題を整理し、優先順位をつける能力です。したがって、技術顧問はもちろん、エンジニアも含め、必ずしも技術力のみを評価して採用しない意識を持ちましょう。

エンジニアのマネジメントと採用に必要な考え方

次に、エンジニアのマネジメントに関わる問題を考えていきます。

開発に関わるマネジメントにはプロジェクト・マネージャーとプロダクト・マネージャーが存在しますが、現場の問題のほとんどはプロジェクト・マネージャーの領域で起こります。

プロジェクト・マネージャーが意識すべき要素とは

プロジェクト・マネジメントは３つの要素が必要です。

まず、「計画通りにプロジェクトを推進する」。この要素はもちろん重要ですが、意識しすぎるとそれ以前のところで問題が生じることもあります。プロジェクト外のメンバーに、そもそも計画内容が正確に伝わっていないケースです。たとえ計画通りにプロダクトが完成したとしても、経営層が想定していたものとまったく違うものであれば意味がありません。

したがって、プロジェクト・マネージャーは推進しているプロセスを明確かつ定期的に伝えることが極めて重要です。また、プロジェクトの方針がずれないよう正しく評価し、内外に伝えるサイクルを回さなければなりません。

マネジメントにおけるフレームワークの活用法

このときに意識してほしいのが、このサイクルに正しいフレームワークを取り入れることです。たとえば、「アジャイルってよくやるんでしょう」と安易に手法を取り入れて楽な要素だけ利用すると、開発現場が混乱します。

特に、複数のフレームワークを乱用すると、それぞれの強みを生かせません。まずはひとつの手法に集中して、正しくサイクルを回すことから始めましょう。

また、プロジェクトがブラックボックス化してしまわないよう心がけてください。プロジェクトは意識的に可視化しなければ、周囲からは自然に理解しづらいものになっていきます。内外への発信を正しいフレームワークに則って行うことが、スムーズな開発を支えます。

エンジニアの採用とCTOの考え方

最後に、採用に関して失敗しないための手法や考え方について説明します。

エンジニアの採用に問題を抱える場合は、採用基準がずれている可能性があります。というのも、経営層とエンジニアの「優秀」の基準がまったく違うからです。

経営層は非連続な事業成長を描くプロダクトを作れるひとを優秀なエンジニアと捉える傾向があります。一方、エンジニアが言う優秀なエンジニアは、より技術面にフォーカスしています。この基準がずれると、採用は失敗します。

エンジニアと経営層の認識を合わせ、人事に採用を一任しないことが採用問題の解決策です。個人的には、はじめのメールのやりとりや面接の段階こそ経営者自身が応募者を判断することが大切だと考えています。面接ステップが進めば進むほど開発現場のメンバーが面接するという流れが好ましいのではないでしょうか。

また、母集団形成ではプロダクトだけでなく、内部事情を知ってもらうための広報を心がけましょう。サービスができるまでの意思決定について共感や理解を得られるよう、定期的なアップデートを続けることが大切です。

最後に、CTOの役割について触れます。ベンチャー企業の場合、創業メンバーがCxOになってしまうケースが多いものです。最初に入ってくれたエンジニアがCTOというように、安易な役割が生まれてしまいます。

やがて事業や会社の成長にその人材がついていけなくなると、自分の仕事を作り出すための仕事をしたり、派閥を作ったりしはじめます。CTOが技術的なトップに居続けることはほぼ不可能ですので、事業成長のフェーズによって役割を変化させていく意識が極めて重要です。併せて、CxOを変える基準や水準を事前に設けておきましょう。

本質的な課題を捉えたうえで正しい手法を取り入れる

開発現場における技術的課題は、正しいフレームワークと認識がそのほとんどを解決してくれます。経営層はエンジニアの考え方や視点を理解しつつ、プロジェクトの方針がずれていないかどうかこまめなチェックをしてきましょう。また、人材採用についても、認識のずれを防ぐ事前準備を心がけてください。こうした意識によって、スムーズかつ要件を満たすプロダクト開発が実現するはずです。

STRIVE

BLOG