IT業界で気づいたことをこっそり書くブログ

くすぶってる系アプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業(仮))

受託新規開発と、内製継続開発の体制の差

観測数が少ないんですが、私の見た限りこういうのが多かった。というものと、その課題について。少し考えたこと。

 

受託・新規開発

だいたいこんなだと思います。

 

f:id:otihateten3510:20180308214000p:plain

 

受託・新規開発で社会人デビューしたので、こちらが一般的だと信じ込んでいました。

PM、あるいはPMとディレクターがPO(プロダクトオーナー、つまりお客さん)との間に入って調整してくれます。

 

内製・継続開発

内製・継続開発的な会社に入った時、下図のような感じで割りと面食らいました。

 

f:id:otihateten3510:20180308214107p:plain

 

案件はチケット単位で走ります。1チケットは軽いものだと1日で、重いものだと2ヶ月くらいです。
重くても新規開発の1プロジェクトの大きさには満たないので、エンジニアが割りと全面に出ることを求められます。
結果的に「エンジニア=ディレクター+PG」的な動きとなります。

 

PO側も非常に奇妙に感じました。お客さんに相当する人は部門であることが多いです。例えばQA、企画、広報、法務部など。いろんなところからいろんな要望が出て、それに対応するのがメイン業務となります(6割位?)

もちろんサービス自体の改善もあります。それが残りの業務です。

 

この体制の問題点

図を見ればわかると思いますが、情報の導線がカオスです。
これがどういう問題の顕在化に繋がるかというと。

  • 全体を把握しづらい、戦略的に動きづらい
  • 一貫した方針でプロダクトを作りづらくなる
  • 質の担保がエンジニアの感覚値になる
  • 無限に仕事が発生する
  • 無限に複雑度が上がる
  • エンジニア負担が大きい
  • ディレクションまでできるエンジニアが必要
  • 誰の認識している仕様が正しいのか迷子に成りがち

もっとある気がしますが、こんな感じでしょうか。

「よくわからない」状態になります。

 

もっと良い体制はないものか?

プログラムの設計に似ています。
誰に何を担わせるのか、どことどこを分けるのか。

 

まだ考え中ですが、こんな体制だとどうでしょう。

 

 

f:id:otihateten3510:20180308214900p:plain

 

結局一般的なスクラム体制なんですが。やはりPMとSMをどう設計するか次第で良し悪しが決まりそうです。
正直物量を考えると、この中間層が2人でいいか自体疑問です。
3、4人はほしくないですか?

数値を計測する人、情報の流れを管理する人も欲しいです。

 

またそのうち書きます。