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

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

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

今回は、設計フェーズのお話をしたいと思います。

どのように設計フェーズを進めたのか？

まず、設計の段階でも要件定義と同様、非エンジニアの方（以下、彼）は「システム設計」経験がゼロでした。

彼のスキルは基本的に、
・プログラム（Ruby / PHP）を書いたことがある
・HTML / CSSを書いたことがある

という類で、彼はいわゆる"駆け出しエンジニア"（プログラミングスクール量産型エンジニア）といっても過言ではありませんでした。

従って、設計フェーズにおいては、
・システム設計の考え方（処理フロー、UI設計、I/O、内部処理）
・データベースのスキーマの考え方（ER図 /  テーブル / カラム / インデックス / PK / FK）

を概念的に学んでもらいつつ、要所要所で現場と同じように設計してもらうことにしました。

成功した点

成功した点としては、データベースの概念的なところは朧気ながらも理解できた、というところでしょうか。

特に、
・データベースは、テーブル（Excelのシートみたいなもの）の集合体であるということ。
・テーブル間のリレーション、結合にはキーという紐づけできる材料が必要だということ。
・NULLはExcelのシートの空文字とは異なる、ということ。

といった感じで、普段は考えもしないことを少しずつ覚えてくれたのはよかったと思います。

また、
・プログラミングをする前に、I/Oを意識しないとシステムを作ることが難しい。
・処理の流れを意識しないと、処理の間で不整合が起きてしまう。

といったことも、彼自身が責任を担うプロジェクトの中で身近で経験できたのがよかったと思っています。
（実際にレビューでは、かなり厳しく指摘しています💦）

失敗した点

逆に、失敗した点もいくつかありました。

特に、「納期の関係上、教育サイド側が、彼のアーキテクチャの理解スピードよりもシステムの完成を優先してしまった」という点が大きかったと感じます。

今回のプロジェクトスコープは、業務委託しているスタッフが請求書を申請するための請求書管理システムを自社開発することにあったのですが、

・このカラムはなぜ必要なのか？
（システム的にどのような制御に使われるのか？）
・PKやFKが、データベース的にどのような意味を持つのか？
（なぜユニークである必要があるのか？等）
・中間テーブルとは何か？何のために持つ必要があるのか？
・必要なデータは内部結合で得られるものか？それとも外部結合で得られるものか？

といった感じで、データベースの知識が非常に重要なポイントでした。
しかし、システム開発の軸となるデータベースの知識に関して、理解が非常に浅いことを目をつぶってプロジェクトを進めてしまったのが残念だったと反省しています。

納期が短いと、特に設計への教育がおろそかになりがちだが…

今回のプロジェクトは、本来なら1月末には終わっていなければならない内容でした。ところが、上記のような失敗等により、2月以降も開発する必要が生じています。

社内プロジェクトならよかったものの、これが納期を伴う社外プロジェクトだとすると、非常にリカバリは厳しいものになると思います。

本来なら、設計も要件定義や実装と同様に、納期を伸ばしつつじっくりと教育した方がよかったかもしれません。

ところが、実際の現場では、こんなに教育するだけの余裕があるとは思えません。その点では、

・納期がある中で、彼自身実力をどう発揮するか？
・納期に間に合わせるために、本来彼自身がどのような技術を身に着ける必要だったのか？

といった点も、彼と一緒に振り返った方がよかったと感じました。

そこは、彼自身も自分自身振り返って、実力不足だった点を勉強して挽回してもらいたいなと思っています。

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