最近開発フローを一新する機会があり、非エンジニアプロダクトマネージャーながら四苦八苦していろいろ考え、開発フローを作り直していた。２−３ヶ月たち、一通り回ってきたタイミングなのと次のフェーズに移る段階だったので備忘録がてらまとめてみた。ちなみに次どうしようかという課題点もあるし、正直完全理想形態です！みたいな感じでもない。あと僕は非エンジニアで開発組織を作った経験のある人と接点が少なく、こここうしたほうがいいよなど指摘があったらぜひ受けたいし、なんならランチしてもらいたいので気さくな方はご連絡いただけると幸いです。（という募集ポストでもある）
状況
もともと開発責任者(VPoE)を頂点に書くプラットフォームごとにリーダーをたてていた。各チームでスクラムを組み、それを横串で開発責任者中心に各チームの定例を毎週やるという形。すごくオーソドックスかなと思う。人数もまあまあいてすべてを１チームにするには大きくてかといって分けるのもなあみたいな微妙な規模。
この状態で回していたが急遽開発責任者、リーダーがほぼ全員抜けるという自体になり、開発に一番近いという理由で非エンジニアPMが開発フローについて考えることになった。ちなみにコードはある程度書けて趣味でサービスを作れるぐらいではあったが実務でコードを書いた経験はほぼなく、チーム開発もエンジニアとしては参加したことがなかった。20人近くのチーム開発もそこまで経験はなかった。技術力も趣味程度なので大したことはない。
技術力、エンジニア経験がない人間がどうやって開発組織を考えればいいのかから考えた。
なぜそもそもエンジニア経験があったほうがいいか？
やってみて開発を統括する人間はエンジニア経験があったほうがいいなとは思った。ただないとできないというわけでもなかった。しかし、他の開発統括と同じやり方はできない。まず技術的にそれがいけそうなのかをぱっと思いつけば誰にふればいいのかわかるし早い。これは趣味でコード書いてるから自分はまあまあわかる方な気がするが基本非エンジニアだとむずい気がする。
またエンジニア文化の理解も差が出ると思う。めちゃくちゃ感覚的だがそれがイケてるかどうかの感覚はエンジニア文化独特のものがある気がしていてその感覚があうかは重要。そこはゆるくやりたいよね、そこはちゃんと決めようよ、そのフローダサいなどなど。まあでも一番はエンジニアを特別視しすぎないところかもしれない。エンジニアじゃない人間からするとエンジニアがそれ技術的に難しいですとかいうのがようわからんとかなんかなにを話したらいいかわからないなど気が引けちゃってる人もいるんじゃないかなと思う。よくエンジニアは〜みたいな職種で人をかたる人がいるがエンジニアという名前の人はいないわけで変に壁を作らなくなるというのがエンジニア経験あることの一番のメリットな気がする。それは個人で一応コード書いているのと文化尊重をちゃんと意識するようにしている。
受託と自社開発の組織としての違いはなにか？
開発組織を考える上で受託と自社開発で大きく違うと思う。（別にどっちがいいとか悪いとかではないです。もちろん）受託は基本クライアントが作る仕様をどれだけスピードと正確さをもって実現するかが重要であり開発途中で仕様が変わることを前提にしなくていい。（ちなみにここでの受託はクライアントが仕様をきめて渡すウォーターフォールを前提にしているが最近月額制とかも出ているし例外ももちろんあると思います）
対して自社開発は作りながら仕様を検討していきたい。やはり実物を触った際に違うなと思ったら変えたい。また内製でエンジニアを抱える理由としてはエンジニアやデザイナーなど実装者がサービスの文脈を理解して細部の調整をできるところにある。例えば仕様策定者が思いつかない裏のデータの持ち方をエンジニアが文脈を理解し、のちのちに備えDB設計しておくこともできるし、作ってみて動きに違和感を感じてプロダクトマネージャーにアラートを上げたりできる。この実装者の文脈理解が自社開発の開発組織において大きな資産だと思う。
対策
できないことをリストアップしてみた
開発統括者の役割は会社によって結構違うと思う。やる可能性があるものに関して言うと
1.人的マネージメント：人の配置を考える。採用も含め
2.開発フローのマネージメント
3.ディレクション：チームをまたいだ進捗を管理する
4.アーキテクトの設計、仕様策定
3と4は密接に関係しており、設計、仕様策定するものがそのまま工数を計算し、ディレクションしたほうがいい。ここは非エンジニアには無理なので後述するプロジェクトマネージャーを案件ごとにたて権限を移譲した。案件のリリース単位ではディレクションするがサーバーが〇〇のAPIをいつまでに作ってなどの詳細なディレクションはプロジェクトマネージャーに一任した。
プロジェクトマネージャーにほぼほぼ権限を渡す
このプロジェクトマネージャーという制度が今回非エンジニアが開発フローを考えるにあたって大事なところだと思っていて今まで一人が見ていたものを案件ごとに分散させた形になる。あくまで僕は1と2に終始し、3と4は案件ごとに分散させることで開発統括の役割を組織で補おうとした。できないことに関しては完全に移譲し、1個人でカバーするのではなく複数人でカバーするというのが大きな方針でもあった。
チームごとの管理もそうで各プラットフォームの定例、スクラムも各チームに移譲した。
全体MTGの復活
とはいえプロジェクトリーダーもそれ専任ではないのでチームをまたいだコミュニケーションは漏れる可能性もある。そこで全員を集めたスクラムMTGを２週ごとにするのを復活させた。ここでissue単位で進捗を共有し、ぬけもれと他チームとの連携を行った。意外と共有したらこれはほかチームに影響あるなとかサーバーで実装したら大変そうだったけどクライアントに処理持ってったら楽かもなどもここで拾う。
技術的な可否の検討
これはまだ悩ましいところで正直非エンジニアPMに技術検討は難しい。ここは文殊の知恵じゃないがエンジニア全員の知恵をどう出させるかにかかっており、slackでのコミュニケーションをどう活発化させるかにかかっていると思っていてチャンネルの目的など運用を試行錯誤しているが完全な解は見つかっていないような気がする。本当はめちゃくちゃ技術力のある人間がCTOとかの役職でバンバン決めれるといいのかもだけどただアプリ開発は複数プラットフォーム絡むのでどんな案件も全プラットフォーム網羅して技術可否を考えたりとか設計できる人間っていない気がするし、どちらにせよ文殊の知恵は必要な気がする。
エンジニアとのコミュニケーション方法は実物をもって
実装内容について議論することは非エンジニアPMには難しいので実装物をもとにコミュニケーションを取れる組織を目指した。具体的には毎週実装物を一緒に触る会を設けてそこで途中でもいいので触りながら実物を媒介にコミュニケーションする。それが一番確実だし、細部の認識を合わせるのにも役立っている。
わからんことは一任して疑わないようにする
今回１人でできないことを組織でカバーする方針でいったので複数人ですすめ一個人で管理、観測できなところも正直出てくる。その際気をつけないといけないのがわからんのになんか不安だから大丈夫か〜？って聞くことだと思っている。課題感を相談する際に具体的に話せて対策を出せない場合、ただ不信感を伝えるだけでなにも意味ない。具体的に話せ、対策まで持っていけないならもう任せてからは疑ってはいけないと思う。正直不安になることもあるがその不安感は不信感ともとれるのでそれを組織を束ねる人間が出すとただ共有コストだけあがって話が進まない。大丈夫か〜と聞かれたらエンジニアもある程度ちゃんと説明せざる負えないが他職種に実装内容を伝えるのは高コスト。任せたら疑わず、助けを求められたときに対応できるような組織にすることにリソースを割く。
