見出し画像

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

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

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

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

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

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

そのため、

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

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

成功した点

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

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

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

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

失敗した点

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

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

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

振り返りをやってみて

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

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

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

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

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

この記事が気に入ったらサポートをしてみませんか?