ジュニアメンバーに伝えていること
最近は立場上、内定式や入社式で数分話す機会をもらうことがあります。
そういった機会で話していることを紹介したいと思います。
1. 制限のある中でパフォーマンスを出していくことが求められる
チーム開発をしているとリソース、期限、開発言語・フレームワークなど様々な制約が出てきます。特にエンジニアが気にしている技術的負債は作った瞬間から発生しています。
このような状況で既存のやり方を否定して俺の考えたベストプラクティスを考えることは簡単です。しかし、代案を提案をしてみるという姿勢が大事です。
なぜならアサインする側としたらスキルが同じエンジニアであれば、そういった課題解決の方法を提案して実行部分まで引き受けてくれるエンジニアの方がアサインしやすいです。
また、課題に向き合ってやりきって解決できた場合はスキルの向上や周りからの評価も大きく違ってくるからです。
何より自分ごととして仕事に向き合うことができた経験ができるのは大きいと思います。
2. 社会人として時間がない中で効率的なインプットが求められる
例え話でよく「日本史のテストでいい点取ろうと思ったら縄文時代から勉強せずに近代史や戦国時代の勉強重点的にするよね？」と伝えてます。
例えば、エンジニアであれば開発ロードマップは埋めるように逆算してインプットしていくことが適切だと思いますが、
実際実務で使う知識・技術は限られていることも多く、手段が目的化してしまう可能性もあるので全員にとって開発ロードマップは埋めるようインプットを進めることはベストプラクティスではないと思います。
直面している課題を解決するためのインプット・アウトプットを重ねていき、その延長線上で課題解決したという小さな成功体験を積み重ねることが自信や評価に繋がっていくと考えています。
3. サービスの品質はプロセスと成果から構成されている
１の話と関連しますが制約が多いという観点で他社のシステム・アプリを開発することは一番難しいと考えています。
DX推進部署の担当者と伴走してプロジェクトを進めることが多いですが、以下のような課題があります。
既存事業の売り上げアップ、コストカットのどちらにしても大きな期待を背負っている。
稟議が通るまで長い、サードパーティーのシステムを使うためにハードルがある。
社内でシステム・アプリを導入したことがなく知見がない。
関係各所の様々な意見を聞かないと適切に評価できないことが多い。
既存インフラ・システムとの連携を考慮する必要がある。
エンジニアだと成果品質の部分にコミットすることが多いですが、最終的に相手であるお客様がいるので作り上げていく過程でのプロセス品質も重要になります。（上記の資料でも指摘されていますが）
我々の扱っているプロジェクトの場合、クライアントの担当者とエンジニアが近い位置で接することもできるため、質問への回答や技術的な提案が求められる場面もあります。
そういう状況でプロセス品質を高めていくことも意識して開発プロジェクトを進めていくことが好ましいです。
この記事が気に入ったらサポートをしてみませんか？