JTCでのソフトウェア開発のギャップ
概要
メガベンチャーからJTC (Japanese Traditional Company)に入ってギャップを感じた、ソフトウェア開発プロセスについてまとめる
※ JTCの全てがこういう状況ではないことは百も承知です ※ これから内製化をしていこうというフェーズのJTC(製造・小売業)が題材です
目次
- 異常に多い会議
- 中途半端に関わるプロジェクトが多い
- 1on1の目的がよくわからない
- 承認プロセスが無駄に長い
- 複雑なリリース承認文化
- 圧倒的メール文化
- 情報の不透明さ
- 包括的なドキュメントはある、ただしどれが正しいのかは属人化されている
- コードを書くよりエクセルをいじる時間が長い
- 結局はベンダーがやりやすいような開発プロセス
異常に多い会議
なにしろ会議が多い。開発をしようにも、半日が会議で埋まることもざらにある。 その会議が午後にまとまってるのであればまだ良いが、中途半端に散らかっているので、まとまって開発する時間が取りづらい。 時間を動かそうにも、関係者(本当に関係者なのかはよくわからない人)が多く、調整コストが高いため諦めてしまう
中途半端に関わるプロジェクトが多い
1つめの原因でもあるが、小さいプロジェクトなどがいくつも走ることがあり、どれに集中してるのかよくわからないことが多い。 オブザーバーとして呼ばれたり、テック的な意見を求められて呼ばれることも多く、結局プログラマーがエンジニアリングする時間が取りづらくなってしまう。 また、エンジニア以外の人も色々やっているため、結局どれも中途半端になることが多い
1on1の目的がよくわからない
とりあえず1on1入れますみたいなのが多い。(あくまでも自分だけかも) 1on1やらないのは良くないが、1on1の目的/意義/やり方を知らずして、とりあえず上長だから入れるとか、チームメンバー同士で交流頻度を上げて欲しいから入れるみたいなのが多く、個々人の成長につながる1on1は極めて稀である
承認プロセスが無駄に長い
無駄に階層構造とセクショナリズムが強いため、1つのプロジェクトを進めるにも調整コストが異常に高い。 また、大企業特有のプロセスに対してガバナンスを敷きたがるため、とりあえずいろんな人に説明して承認を得るみたいなことが発生しがちである。
複雑なリリース手順
リリースをするのにも、毎回リリースの手順や切り戻し方法、対応時間を分単位で示したものをエクセルにまとめて共有する必要があり、それを御前会議みたいなところで承認を得る必要がある。 また、ブランチ運用もかなり複雑で、リリースまでに複数のブランチにマージする必要があったり、リリースまでにかなり時間を要することがある。
圧倒的メール文化
SlackやTeamsが導入されてはいるものの、情報伝達は基本的にメールが中心。
情報の不透明さ・包括的なドキュメントはある、ただしどれが正しいのかは属人化されている
どこに何があるのかわからないが、一応ドキュメントはあることにはある。 ただし、エクセルやパワポがそのままファイルサーバーに格納されて、ぱっと見どれが正しいのかよくわからない状態。 ただ、社内に一応どれが正しいのか知ってる人はいるので、その人を探し出せれば情報に辿り着ける。
コードを書くよりエクセルをいじる時間が長い
資料作成の時間が圧倒的に多い。 内製化を目指してるといいつつも、まだまだコードを書く作業はベンダーに投げるものという文化が染み付いており、何をやるにもとりあえずエクセルやパワポで提案資料を作るということが多い。
結局はベンダーがやりやすいような開発プロセス
上記の背景もあり、結局はベンダー依存が強く、エンジニアが入ってプロセスを変えようにも、パワー的にベンダーの方が強く、ベンダーが慣れ親しんだプロセスに固執しがちというのが実態である
まとめ
よくある内製化という言葉が、エンジニアから見た時の内製化と非エンジニアから見た時の内製化は意味が異なる
仮にこれから事業会社で内製化エンジニアを募集してるところに応募する人がいたら、まずは内製化エンジニアのメンバーとベンダーの構成比を確認することはマスト。その中で自分が期待されてる役割を聞いたり、内製化のマイルストーンを丁寧に擦り合わせることをお勧めする。
