現役エンジニアが、現場で駆け出しエンジニアを育ててみて思うところあり②

こんにちは、引きこもりのHisashiです。

前回、「現役エンジニアが、現場で駆け出しエンジニアを育ててみて思うところあり①」で、#非エンジニアと要件定義からリリースまでやってしまおうの総括をしました。

今回は、各フェーズごとの振り返る…ってことで、非エンジニアが要件定義と要件定義するとどうなったのか？について、お伝えします。

要件定義フェーズの進め方

まず最初に、要件定義の段階では、非エンジニアの方（以下、彼）は「顧客との折衝」や「顧客との交渉」経験がゼロでした。

そのため、

・要件定義の目的は何か？（要件定義でやるべきことを認識する）
・顧客と何を合意する必要があるか？（要件定義のゴール）
・顧客が求めているものをイメージ（可視化、図視化）する
・機能要件と非機能要件の違いを理解する

といった、SE教育のキホンに取り込むました。

成功した点

要件定義フェーズで大きな収穫だったのが、何のために顧客がシステムを欲しがるのか？を、言語化・図視化して関係者と共有できたことです。

今回は社内プロジェクトでしたが、（自分をふくめ）経営層と彼との間で、「何を成果とするか？」について、お互いに認識させることができました。
特に、業務フローや画面ラフ案をまとめながら「何を作るのか？」を、徐々に主体的に考えられるようになったのは、見ていて楽しかったです。

逆に、自分が顧客の立場に立った時、どのような要求をエンジニアにするべきか？イメージする視点が備わってきたのも、大きい収穫でした。

このようなプロセスは、TECH CAMPをはじめ殆どのプログラミングスクールでは教えてくれないですし、経験できる場もないため、彼にとっても我々経営層にとっても、かなり有意義なプロジェクトになりました。

失敗した点

逆に失敗した点は、「何が正解なのか？を顧客（他の経営層）に聞かずに、自分（最高技術責任者）に聞くスキームになってしまったこと」です。

要件定義フェーズでは、顧客の要求仕様に基づいて予算内でやるべき事・やらなけれなならない事を要件としてまとめます。

そのため、本来は顧客に対してベクトルが向くべきなのですが、本人が自信がなかったのか、自分に逐一お伺いを立てるスキームになってしまったのが失敗だったと思いました（といっても、自分も顧客の一人になるのでやむを得ないのですが…💦）

振り返りをやってみて

上記の点を踏まえ、プロジェクト終了後に彼本人と振り返りを実施しました。その結果、彼の中でも、

・自分の技術に自信がなかったので、逐一確認したくなってしまった
・顧客の求める完成像が最初からイメージできなかった
・実際に要件定義をやっていく中で、顧客に対してどのような提案をすべきなのか、少しずつ分かってきたような気がした

といった反省点や気づきを挙げてくれました。

最初から優秀なエンジニアを確保するのではなく、駆け出しエンジニアや非エンジニアをじっくり育てる、という意味でも、積極的にチャレンジさせて振り返りを行うスキームを作っていくと、時間はかかりますが徐々に戦力化につながると感じました。

次回は、設計フェーズについて振り返ってみようと思います。