イントロダクション
Goで開発していたが、途中でPythonに切り替えた件を振り返る。の後日談にもなります。早3ヶ月が経ちました。そして、自分が今回の新規事業に関わり始めてからおよそ半年が経ったことになります。今回、対象ユーザーを絞った限定的なリリースではあるのですが、ともあれ形になったのでいろいろ振り返っておこうと思います。
さすがに社内の内部事情を赤裸々に書くことは出来ないのですが、プロジェクトマネジメントの観点から「良かったこと」「課題のあったこと」などを取り上げて、誰かの役に立つようなものが書ければと思います。
良かったこと
1on1でプロジェクトの安定運営
おおよそ開発が本格化したのが２０２０年４月ぐらいでリリースが２０２０年８月でした。完全にコロナと丸かぶりの状況でほぼフルリモートでの開発となりました。エンジニアだけでも１５〜２０名程度、加えて企画職メンバーとデザイナー１名がプロダクト開発グループといった形です。
基本的に、企画職メンバーとデザイナーと自分が要件を詰めながら、全体のプロジェクトマネジメントをしつつ、開発メンバーへ要件を伝えてQAに答えてという形で進めていたのですが、このプレイングマネージャースタイルだと、どうしても開発メンバーの状況に気を配るといったことがおろそかになります。
個人的には、プレイングマネージャースタイルだと開発メンバーが増えてくると、フルリモートでなくても１０名超えると厳しいなというのが実感なのですが、ここを今回補完するために外部の方々のお力をお借りしました。２名ほど毎週開発メンバーと1on1をしていただく方をアサインさせていただいて、週１でその1on1のサマリを共有していただく形を取りました。
基本、Slackでコミュニケーション、時々Zoomという形で進めていたのですが、特にオフラインだったら開発メンバーの表情とか雑談とかから伺いしれていた各メンバーの心理状況とか課題感が見えにくくなっているところ、専任で1on1をしていただいたおかげでクリアになり良かったなと感じています。
もちろんメンタルケアという側面もあるのですが、各開発メンバーから見たプロジェクトのリスクみたいなものも早期発見できたので、プロジェクトの安定運営にかなり効果的だったなと思います。Slackからでもよくtimesとかでつぶやいてくれるメンバーとかは、コメントからいろいろと伺い知ることができるのですが、そういったメンバーばかりでもないので1on1の重要性を特に感じたプロジェクトでした。
バックエンドをPythonに。
GoからPythonにしてどうだったか、結論、今回のプロジェクトにおいては、あのタイミングで切り替えておいて正解だったと感じています。
- 組織として元々知見のある技術要素だったので見積もり誤差が少なく、ほぼスケジュール通りに行けた。
- 「このぐらいの機能だったらどのぐらいで行ける？」という問いに対して返ってくる開発メンバーからの答えが正確だったので、スケジュールが組みやすく、あれこれリスケの調整をせずに行けました。
- もちろんその代わりに技術的チャレンジという側面では見送った形になるのですが、やはりビジネスなのでプロダクトを期日通りにリリースするという点を優先したことは、今回は良い判断だったのかなと思います。
- 若手エンジニアが多いプロジェクトだったので「Django Rest Framework」でFWに沿った形で実装したことでバグも少なく、統一感のある実装になった。
- バグが少なかったのは、要件も絡んでくるし、メンバーの実力にもよるので一概にはいえないのですが、やはりFWに沿った形で実装することで機能実装により集中できて、統一感のある実装になったのは事実かなと感じています。
- 統一感のある実装になったことでまた保守性やメンテナンスのしやすさといったところにも貢献しているかと思います。
新規プロダクトの要件検討をするなら意思決定に関わるメンバーは少ないほうが良い。
企画職メンバーとデザイナーと自分の３名でほぼ新規プロダクトの要件検討を進めたのですが、意思決定が集約されたことで当然のことながらスピード感が良かったです。また、企画、デザイン、システムと役割が明確に分かれていたこともスピード感の良さにつながったのかなと思いました。
以前は、SIerにいたので身にしみて感じるのですが、意思決定に関わるメンバー（ステークホルダー）が多ければ多いほど、時間がかかり、結果的にプロジェクトが長くなります。組織の論理上、どうしようもないところもあるとは思うのですが、理想をいうと、出来るだけ削ぎ落としたメンバーで意思決定していった方が単に開発スピードが上がるだけでなく、適宜方向転換や見直しのスピード感も高まります。
結果、改善のループも早く周りどんどんプロダクトが磨かれていくのかなと今回のプロジェクトを通じて感じました。もちろん集まったメンバーにもよりけりだとは思うので、１つの理想論という形で見ていただければと思います。
課題のあったこと
プロダクト開発外のメンバーとのコミュニケーションが不足していた。
エンジニアだけでも１５〜２０名程度、加えて企画職メンバーとデザイナー１名がプロダクト開発グループといった形です。
冒頭イントロダクションで記載した通り、だいたい２０人前後で開発をしていたのですが、当然、開発以外にも営業だったり、経営陣だったりがいます。こことのコミュニケーションが不足していたことで、プロジェクト終盤一部手戻りが発生しました。
ここは、プロジェクトマネジメントという意味では、リスクオフできていなかったという点で反省点です。一応、全体の定例MTGはあったのですが、どういったプロダクトが出来上がるのか、といったところで共有しきれていなかったところがあり、もっと上手くできたのではという気がします。
プロダクト開発外のメンバーが気にするポイントを早めに把握しておいて、情報共有の仕組みづくりをしておくのがいいかなと振り返って思います。
ReactのComponentに閉じる形でStyleを定義していたがSCSSなどで切り出しておけば良かった。
デザイナーが１名しかいないこともあって、基本的にエンジニアがStyleの実装をしていたのですが、プロジェクト終盤になってデザインの調整をする際に課題となりました。結果、SCSSに切り出すという作業をしました。Reactが触れるデザイナーの方がいれば問題ないと思うのですが、やはり後からデザインの調整をする際には、Styleだけ切り出されていた方が作業がしやすく、課題感の残る展開となりました。
楽観的な見通しは疑った方がいい。
すでに記載した通り、バックエンド側は「見積もりを聞く→開発する→見積もり誤差を把握する」ということが出来ていたので良かったのですが、フロントエンド側は、そのループが思ったより長くなってしまい、結果的に終盤に結構無理をして間に合わせる展開になりました。
基本的に「Componentが揃ってしまえば後は組み合わせで行けるのでサクッと行ける」という見通しをフロントエンドメンバーとしていたのですが、これが楽観的過ぎました。結果、Componentを揃えてからが勝負、という形で実際に画面を組み始めるのがだいぶ後ろになってしまい、「画面を組み立てるのにどのぐらいかかるんだっけ？」という検証をするのが遅くなり、見通しの甘さに気づくのも遅くなりました。
今から考えれば、見積もり誤差の把握をもっと意識してサンプルケースの収集を早めにやれば良かったと思います。
最後に
関わるメンバー含め同じ環境で同じプロジェクトをやることは２度とないので、そういう意味では、プロジェクトは生ものだと思っているのですが、今回、振り返ってみるとやはりコミュニケーションだったり、QCDの意識だったり、ステークホルダーとの調整だったり、プロジェクトマネジメントの肝となる部分が浮かんできておもしろいなと思いました。
やはり勘所というか定石みたいなものは存在していて、いかにそこを意識できるか、逸脱しないように導けるか、がプロジェクトマネジメントに求められる要素かなと思いました。
少しでもこの記事が誰かの役に立てば幸いです。