#90 システム開発をまるごと理解できる人は育てられるのか？～前編～（2024/05/28）
こんにちは。ITベンチャーエンジニアのこへいです。
プロジェクトをリードできる人ってなかなかいないよね。という社内の会話から、プロジェクトをリードできる人は育てられるのかということを考えました。
エンジニアとして10年以上システム開発をし、プロジェクトをリードする経験も沢山させていただく中で、最低限必要であるシステム開発をまるごと理解しているということについて考えます。
◯まるごと理解するとはどういうこと？
このような基本的なフローを把握し、各フローでのアクションや次のフローへ進むための条件、そのフローで最低限達成すべきことや次のフローでリカバリーが出来るかどうか、各フローでの成果物の作成なとなど、抽象レベルから具体レベルまで体験を通して理解していること、といえます。
例えば、要件定義においては「この課題を解決したい」といった要求から期間や費用などの制約を満たす要件に落とし込むという抽象的な概念を理解しているだけでは不十分です。
ステークホルダーによって優先事項が異なる中でのコミュニケーションの設計、大量の要求同士の整合性を保ちながら制約に合わせて要求や要件を調整すること、各タスクの依存関係を認識し、あるタスクが遅延した際に影響のあるタスク毎に打ち手を考えることなど、どのような課題が発生するかの認知やそれらの課題に対する具体的な解決策を持っていないと要件定義をうまく対応することは出来ません。
全てのフローでどのようなイベントが起きるのか、どのような対応が必要かを具体的に解像度高く認識できていることが、まるごと理解するということです。
具体的な打ち手までを、全て一人でひねり出せる必要はありませんが、課題を認識して解結するための方向性を示せる必要があります。
◯まるごと理解するに至った実例紹介
私はエンジニアであるため要件定義・設計・開発を得意としつつ、システム開発についてまるごと理解はしているつもりです。
どのように理解していったかというと、プロジェクトに自主的にコミットして、結果成功を積み重ねるなかで体得していきました。
具体的に説明します。
新卒で入社し研修後に、ある顧客にシステムを提供しているチームに配属されました。そこでの私の最初の仕事は運用保守でした。顧客からの問い合わせやバグ修正、小さな改善要望への対応をしながら提供しているシステムの理解を深めました。
ただ単に振られる仕事をこなすだけでなく、運用保守の改善や、顧客との定例のファシリテーションを務めるなど、一つ一つの仕事を自らリードし、失敗も重ねながら様々な経験を積みました。
先輩のエンジニアや営業の方だけでなく、顧客の担当者の方から様々なことを学ばせていただき、その後、新機能の開発、要件定義、設計なども経験し、大きなプロジェクトをリードする役目を担うようになりました。
私が入社した12年前はまだ会社も30人規模で、新卒未経験エンジニアの私にも責任のある仕事が回ってくるありがたい環境でした。
また、会社として受けるプロジェクトも段々と大きくなっていく状況だったため、常に会社と一緒にジャンプアップが求められる中で任されるという経験を積むことが出来ました。
ITベンチャーが成長しやすい環境であることはこちらの記事でも紹介しています。
◯まるごと理解出来る人が増えない理由
会社や事業が大きくなるにつれて一つのプロジェクトが大きくなると、失敗しながら試行錯誤を繰り返して経験を積むことが難しくなります。
失敗のリスクや失敗によるダメージが大きくなるため、チャレンジングなプロジェクトはベテランにしか回ってこず、ベテランがどんどん成長する一方で経験の浅いメンバーは成長の機会に恵まれない状況になりやすいです。
この辺の話は、ゲーム作りの文脈ではありますが、とてもわかりやすく説明されている記事がありましたので紹介します。
というとで、今回はまるごと理解することについて整理するところまでで時間切れです。
最後までお読みいただきありがとうございます。
後半では、まるごと理解できる人を育てる方法について掘り下げていきます。
2024年6月7日に後編を公開しました。