現役エンジニアが、現場で駆け出しエンジニアを育ててみて思うところあり②
こんにちは、引きこもりのHisashiです。
前回、「現役エンジニアが、現場で駆け出しエンジニアを育ててみて思うところあり①」で、#非エンジニアと要件定義からリリースまでやってしまおうの総括をしました。
今回は、各フェーズごとの振り返る…ってことで、非エンジニアが要件定義と要件定義するとどうなったのか?について、お伝えします。
要件定義フェーズの進め方
まず最初に、要件定義の段階では、非エンジニアの方(以下、彼)は「顧客との折衝」や「顧客との交渉」経験がゼロでした。
そのため、
・要件定義の目的は何か?(要件定義でやるべきことを認識する)
・顧客と何を合意する必要があるか?(要件定義のゴール)
・顧客が求めているものをイメージ(可視化、図視化)する
・機能要件と非機能要件の違いを理解する
といった、SE教育のキホンに取り込むました。
成功した点
要件定義フェーズで大きな収穫だったのが、何のために顧客がシステムを欲しがるのか?を、言語化・図視化して関係者と共有できたことです。
今回は社内プロジェクトでしたが、(自分をふくめ)経営層と彼との間で、「何を成果とするか?」について、お互いに認識させることができました。
特に、業務フローや画面ラフ案をまとめながら「何を作るのか?」を、徐々に主体的に考えられるようになったのは、見ていて楽しかったです。
逆に、自分が顧客の立場に立った時、どのような要求をエンジニアにするべきか?イメージする視点が備わってきたのも、大きい収穫でした。
このようなプロセスは、TECH CAMPをはじめ殆どのプログラミングスクールでは教えてくれないですし、経験できる場もないため、彼にとっても我々経営層にとっても、かなり有意義なプロジェクトになりました。
失敗した点
逆に失敗した点は、「何が正解なのか?を顧客(他の経営層)に聞かずに、自分(最高技術責任者)に聞くスキームになってしまったこと」です。
要件定義フェーズでは、顧客の要求仕様に基づいて予算内でやるべき事・やらなけれなならない事を要件としてまとめます。
そのため、本来は顧客に対してベクトルが向くべきなのですが、本人が自信がなかったのか、自分に逐一お伺いを立てるスキームになってしまったのが失敗だったと思いました(といっても、自分も顧客の一人になるのでやむを得ないのですが…💦)
振り返りをやってみて
上記の点を踏まえ、プロジェクト終了後に彼本人と振り返りを実施しました。その結果、彼の中でも、
・自分の技術に自信がなかったので、逐一確認したくなってしまった
・顧客の求める完成像が最初からイメージできなかった
・実際に要件定義をやっていく中で、顧客に対してどのような提案をすべきなのか、少しずつ分かってきたような気がした
といった反省点や気づきを挙げてくれました。
最初から優秀なエンジニアを確保するのではなく、駆け出しエンジニアや非エンジニアをじっくり育てる、という意味でも、積極的にチャレンジさせて振り返りを行うスキームを作っていくと、時間はかかりますが徐々に戦力化につながると感じました。
次回は、設計フェーズについて振り返ってみようと思います。
この記事が気に入ったらサポートをしてみませんか?