you88blog

とあるPMの開発日記

Menu Close

Month: 7月 2019

非エンジニアPMが開発フローを四苦八苦して考えてみた

最近開発フローを一新する機会があり、非エンジニアプロダクトマネージャーながら四苦八苦していろいろ考え、開発フローを作り直していた。2−3ヶ月たち、一通り回ってきたタイミングなのと次のフェーズに移る段階だったので備忘録がてらまとめてみた。ちなみに次どうしようかという課題点もあるし、正直完全理想形態です!みたいな感じでもない。あと僕は非エンジニアで開発組織を作った経験のある人と接点が少なく、こここうしたほうがいいよなど指摘があったらぜひ受けたいし、なんならランチしてもらいたいので気さくな方はご連絡いただけると幸いです。(という募集ポストでもある)

状況

もともと開発責任者(VPoE)を頂点に書くプラットフォームごとにリーダーをたてていた。各チームでスクラムを組み、それを横串で開発責任者中心に各チームの定例を毎週やるという形。すごくオーソドックスかなと思う。人数もまあまあいてすべてを1チームにするには大きくてかといって分けるのもなあみたいな微妙な規模。

この状態で回していたが急遽開発責任者、リーダーがほぼ全員抜けるという自体になり、開発に一番近いという理由で非エンジニアPMが開発フローについて考えることになった。ちなみにコードはある程度書けて趣味でサービスを作れるぐらいではあったが実務でコードを書いた経験はほぼなく、チーム開発もエンジニアとしては参加したことがなかった。20人近くのチーム開発もそこまで経験はなかった。技術力も趣味程度なので大したことはない。

技術力、エンジニア経験がない人間がどうやって開発組織を考えればいいのかから考えた。

なぜそもそもエンジニア経験があったほうがいいか?

やってみて開発を統括する人間はエンジニア経験があったほうがいいなとは思った。ただないとできないというわけでもなかった。しかし、他の開発統括と同じやり方はできない。まず技術的にそれがいけそうなのかをぱっと思いつけば誰にふればいいのかわかるし早い。これは趣味でコード書いてるから自分はまあまあわかる方な気がするが基本非エンジニアだとむずい気がする。

またエンジニア文化の理解も差が出ると思う。めちゃくちゃ感覚的だがそれがイケてるかどうかの感覚はエンジニア文化独特のものがある気がしていてその感覚があうかは重要。そこはゆるくやりたいよね、そこはちゃんと決めようよ、そのフローダサいなどなど。まあでも一番はエンジニアを特別視しすぎないところかもしれない。エンジニアじゃない人間からするとエンジニアがそれ技術的に難しいですとかいうのがようわからんとかなんかなにを話したらいいかわからないなど気が引けちゃってる人もいるんじゃないかなと思う。よくエンジニアは〜みたいな職種で人をかたる人がいるがエンジニアという名前の人はいないわけで変に壁を作らなくなるというのがエンジニア経験あることの一番のメリットな気がする。それは個人で一応コード書いているのと文化尊重をちゃんと意識するようにしている。

受託と自社開発の組織としての違いはなにか?

開発組織を考える上で受託と自社開発で大きく違うと思う。(別にどっちがいいとか悪いとかではないです。もちろん)受託は基本クライアントが作る仕様をどれだけスピードと正確さをもって実現するかが重要であり開発途中で仕様が変わることを前提にしなくていい。(ちなみにここでの受託はクライアントが仕様をきめて渡すウォーターフォールを前提にしているが最近月額制とかも出ているし例外ももちろんあると思います)

対して自社開発は作りながら仕様を検討していきたい。やはり実物を触った際に違うなと思ったら変えたい。また内製でエンジニアを抱える理由としてはエンジニアやデザイナーなど実装者がサービスの文脈を理解して細部の調整をできるところにある。例えば仕様策定者が思いつかない裏のデータの持ち方をエンジニアが文脈を理解し、のちのちに備えDB設計しておくこともできるし、作ってみて動きに違和感を感じてプロダクトマネージャーにアラートを上げたりできる。この実装者の文脈理解が自社開発の開発組織において大きな資産だと思う。

対策

できないことをリストアップしてみた

開発統括者の役割は会社によって結構違うと思う。やる可能性があるものに関して言うと

1.人的マネージメント:人の配置を考える。採用も含め
2.開発フローのマネージメント
3.ディレクション:チームをまたいだ進捗を管理する
4.アーキテクトの設計、仕様策定

3と4は密接に関係しており、設計、仕様策定するものがそのまま工数を計算し、ディレクションしたほうがいい。ここは非エンジニアには無理なので後述するプロジェクトマネージャーを案件ごとにたて権限を移譲した。案件のリリース単位ではディレクションするがサーバーが〇〇のAPIをいつまでに作ってなどの詳細なディレクションはプロジェクトマネージャーに一任した。

プロジェクトマネージャーにほぼほぼ権限を渡す

このプロジェクトマネージャーという制度が今回非エンジニアが開発フローを考えるにあたって大事なところだと思っていて今まで一人が見ていたものを案件ごとに分散させた形になる。あくまで僕は1と2に終始し、3と4は案件ごとに分散させることで開発統括の役割を組織で補おうとした。できないことに関しては完全に移譲し、1個人でカバーするのではなく複数人でカバーするというのが大きな方針でもあった。

チームごとの管理もそうで各プラットフォームの定例、スクラムも各チームに移譲した。

全体MTGの復活

とはいえプロジェクトリーダーもそれ専任ではないのでチームをまたいだコミュニケーションは漏れる可能性もある。そこで全員を集めたスクラムMTGを2週ごとにするのを復活させた。ここでissue単位で進捗を共有し、ぬけもれと他チームとの連携を行った。意外と共有したらこれはほかチームに影響あるなとかサーバーで実装したら大変そうだったけどクライアントに処理持ってったら楽かもなどもここで拾う。

技術的な可否の検討

これはまだ悩ましいところで正直非エンジニアPMに技術検討は難しい。ここは文殊の知恵じゃないがエンジニア全員の知恵をどう出させるかにかかっており、slackでのコミュニケーションをどう活発化させるかにかかっていると思っていてチャンネルの目的など運用を試行錯誤しているが完全な解は見つかっていないような気がする。本当はめちゃくちゃ技術力のある人間がCTOとかの役職でバンバン決めれるといいのかもだけどただアプリ開発は複数プラットフォーム絡むのでどんな案件も全プラットフォーム網羅して技術可否を考えたりとか設計できる人間っていない気がするし、どちらにせよ文殊の知恵は必要な気がする。

エンジニアとのコミュニケーション方法は実物をもって

実装内容について議論することは非エンジニアPMには難しいので実装物をもとにコミュニケーションを取れる組織を目指した。具体的には毎週実装物を一緒に触る会を設けてそこで途中でもいいので触りながら実物を媒介にコミュニケーションする。それが一番確実だし、細部の認識を合わせるのにも役立っている。

わからんことは一任して疑わないようにする

今回1人でできないことを組織でカバーする方針でいったので複数人ですすめ一個人で管理、観測できなところも正直出てくる。その際気をつけないといけないのがわからんのになんか不安だから大丈夫か〜?って聞くことだと思っている。課題感を相談する際に具体的に話せて対策を出せない場合、ただ不信感を伝えるだけでなにも意味ない。具体的に話せ、対策まで持っていけないならもう任せてからは疑ってはいけないと思う。正直不安になることもあるがその不安感は不信感ともとれるのでそれを組織を束ねる人間が出すとただ共有コストだけあがって話が進まない。大丈夫か〜と聞かれたらエンジニアもある程度ちゃんと説明せざる負えないが他職種に実装内容を伝えるのは高コスト。任せたら疑わず、助けを求められたときに対応できるような組織にすることにリソースを割く。

人材配置において経験、知識の重要度はどんどん低くなる

今の会社に入り、大きく組織で変えていったのは広告運用(媒体として)やSEOのインハウス化だと思う。ツール郡が発達し、運用コストが低くなる上で社内に運用をできるだけ巻取り、ノウハウの蓄積をはかった。もちろんすべてをインハウスするわけではなく外部コンサルも必要になる場合がある。イメージとしては外部コンサルから専門知識、外部での事例を収集し、それを独自に活用するためにインハウスで担当者を用意するという形。外部コンサルをいくらいい人に頼んでもそれを独自化できないと意味がない。両方必要なのである。

ちょい話がそれたけど上記の体制を構築するため社内の人材配置を変えてきた。ちなみにもともと広告運用やSEOの経験者が社内にいなかったため0から知識をつけてもらった。よく他社の人にその話をするとなぜ経験者を採用しなかったのかなど未経験者に1からやってもらうことに関して驚く声が多い。こういう話を聞くと人材配置において世の中では経験が重要視されすぎている気がする。正直個人的には経験とか2-3ヶ月もすれば身につくし、もっと重要な事があると思っているのでさほど気にしていない。

適正の職種は経験ではなく人間性で決まる

適正職種は

人間性との相性×経験値×モチベ

で決まると考えています。人間性との相性というのは例えば分析計の職種ではちゃんと客観的にものを考えられるかなどです。人間にはそれぞれ思考の癖や仕事の仕方などがあります。その人間性と職種の相性が悪いと成長できない。しかし、この人間性は正直先天的なものが大きく、あとから変えるのは相当難しい。対して経験値は基本後天的に身につけられるものです。ある意味どうとでもなる。またモチベも目標のもたせ方などでコントロール可能な分野です。

経験の差は後天的にどうとでもできる

採用のときにもいえるけど世間では経験を重要視し過ぎな気がする。前述したように経験は後天的にどうとでもできるが人間性はどうしようもない。確かに経験値があり、なおかつある程度結果も出している人は人間性の相性も証明できている場合が多いのでうまくいく可能性は高くなる。ただやはり結果にはいろいろな要因が重なるので人間性の適性の見極めはどちらにしろ必要だと思う。

相対的に専門知識の経験値は価値が低くなり、学習能力の価値が高まっている

また、昔より知識の価値は下がっている。と思う。特にIT業界では変化が目まぐるしいので3ヶ月前の知識がもういらなくなったりする。専門知識自体の賞味期限が短くなっており、本質的なもの以外は相対的に価値が低くなっている。

© 2019 you88blog. All rights reserved.

Theme by Anders Norén.