退職の経緯と選んだ理由

転職して半年近く経ったので感想を書く。

前職を退職した理由は以下の5つ。

未経験からプログラマとして丸３年働いてコンフォートゾーンに留まっている感覚があったのでそこから抜け出す必要があると感じていた。
別の会社の仕事の進め方を見てみたかった。
一人で作っても限界があると感じた。チームで働くという経験を身につけたかった。
年齢的にリーダーやマネジメントの経験が無いとこれから厳しそう。
給料を上げたかった。

転職先の感想

　転職先は主に受託開発を中心に一部SESで客先に派遣される人もいたりする50~100人規模の開発会社。チームがいくつかあり各チームごとに案件を担当しているような感じ。
　1つ目のプロジェクトは一人で開発したが、2つ目のプロジェクトは孫請け受託案件プロジェクトのバックエンドチームのチームリーダ的なことをすることになった。
　マネジメント的なことは経験してみたかったのでよかったが、チームの人たちが自社の人ではなくBP(Business Partner)と呼ばれる他社の人たちとで構成されたチームで、自分1人（一応、プロパー）と4人（BP）のチームでいきなり難易度が高かった。
　一応要件定義書とER図はある状態で始まったものの、お客さんが要件定義と違うことを平気で言ったり重要な仕様が全然決まらなかったりMTGの度に仕様追加されたりと、ここらへんはどのプロジェクトでも変わらないんだなと思った。

チーム開発は難しい

自分でも何を作るのかよくわかっていないものを他の人に依頼するのって難しいなと思った。前職では一人で作業していたので、「こういうことがやりたい」というざっくりした要望とワイヤーフレームを見ながら、簡易的に設計をしてプロトタイプをお客さんに見せて確認→修正をするという作り方をしていたが、複数人でチーム開発するとなるとこのやり方が通用しないんだなと気づいた。
　基本的にコードレベルまで落とし込んだレベルの詳細設計書と画面デザインはマストで、それを作らなかったため今割とやばいことになっている。スケジュールがきついしどうせ仕様なんて決まらないからと簡易的な画面設計書を作成しただけで進めてしまったが、そもそもシステム開発でスケジュールに余裕があることなんてほぼないし仕様が細部まで決まることなんてないので、こつこつと基本設計書と詳細設計書、画面デザインを作成するべきだった・・・。
　ただしそもそもBPの人たちが仕様もよくわかっていないのに設計書を作ることが出来たのかは怪しい部分で、ここらへんは特定の人がガーッと作るべきものであると言いたいが、設計書を作成している間はBPの人たちが待機状態になってしまうので、そもそもその時間を設けてもらうべきだった気がする。
　しかし開発経験2～3年目の人たちの寄せ集めのチームで仕様もよくわかってない状態でうまく設計書を作成してもらう方法なんてあるんでしょうか・・・。

設計書を作るスキル

誰が見ても（実装経験が浅い人でも）目的のものを作れるような設計書を作成するスキルが求められていて、これが出来ないともっと大きなプロジェクトの規模になると破綻するなと感じる。そのスキルが有れば後の工程は他の人に回せるので、その間に他の作業ができるのでスケールすることができるとも思う。実際、自分で作るより人に作ってもらうほうが何倍も難しい。

これは、子供たちにプログラミングを教える上でも大変効果的な方法✨。面白いし、結果を見てどんな改善が必要なのか考えるのでアルゴリズムの基礎が学べる。pic.twitter.com/JoCJcINg9u
— Sangmin @ChoimiraiSchool (@gijigae) 2021年7月6日

これを繰り返すのはしんどい

もはやすでに転職も考えてしまっていて、土日も仕事して余裕がなくなっているということもあるし、これからもこんな感じのプロジェクトを繰り返していくのか～みたいに思うと結構しんどいなと感じる。他のプロジェクトの話を聞いても結構やばそうだなみたいな案件しか聞かないので、他の会社が請けたがらない案件の終着点なのでは？みたいな疑心暗鬼に陥っている（笑）。

最近よく見てるチャンネル。結構面白いからおすすめ。 www.youtube.com www.youtube.com www.youtube.com