エンジニアの学びに「自分プロジェクト」が最適な理由
エンジニアの好きな言葉「成長」を加速する最適な方法は 自分プロジェクト であるとここで断言します。 成長という言葉、私はあまり好きではないことも付け加えておきます。
実務での役割分担
業務としてソフトウェアを開発する際のフェーズを表にまとめました。 最近はアジャイル開発もありますが、顧客にとって予算感がつかみやすいウォータフォール開発モデルはまだまだ現役です。
| No. | フェーズ | 実施者 | 技術レベル |
|---|---|---|---|
| 1 | 要件定義 | ベンダー | ★★★ |
| 2 | 設計 | ベンダー | ★★★ |
| 3 | 製造 | ベンダー | ★★ |
| 4 | 評価 | ベンダー | ★ |
| 5 | 受入れ | 顧客 | － |
一般的にテスターやコーダーは技術レベルが高くない、下積みの方々が やらされる 作業、設計ができて一人前、要件定義ができて上級エンジニアと見なされます。 私はこの考え方は好きではありませんが、業務アプリを開発するベンダーの多くはこんな感じです。
つまり、要件定義や設計は若手が任されることが少なく、受入れに至ってはベンダーが行うことはありません。
自分PJは学びに最適
つまり、要件定義や設計は若手が任されることが少なく、受入れに至ってはベンダーが行うことはありません。
自分1人でソフトウェアを作り上げる 自分プロジェクト では、上級エンジニアや顧客が行っていた作業すらも自分で行います。 そう、一人前になる前に要件定義ができるのです！
自分プロジェクトを行っている人には考えられないことですが、ソフトウェアのゼロ→イチを作れない人って実は少なくないです。 また、受け入れる顧客の気持ちになって考えることができるエンジニアというのもまた貴重な存在です。
最新の技術トレンドを追いかけるよりもプロとして求められる 顧客目線 を養うのに最適なのが自分プロジェクトというわけです。
成長
プログラミング言語やフレームワークを覚えて「学び」「成長」「技術力」なんて言っちゃう人が多いです。 趣味でなくプロを名乗るのであれば、これは間違っています。
我々はお客様からお金をいただいてお客様の課題を解決する専門家です。 どんなプログラミング言語を使うかはお客様からの評価には関係ないのです。
それよりも「どんな課題なのか」「どのように解決するか」「直感的に使えるのか」のほうがはるかに重要です。
【追記】成長に関する記事を書きました。
- 謝辞
- 画像は pixabay 様より使わせていただきました。
Explore more like this
プログラミングの文化的側面
綺麗ではないコードを目にしたとき、厳しく指摘することに意味がない気がしてきました。
Rubyの行く末を見守っている
年収の高いプログラミング言語ランキングなど、毎年ネットを騒がせています。 長い目で何が良いかを見極めるのは難しいですが、ワタシはRubyの方向性を最も興味深く見守っています。
