こんにちは、エンジニアのさもです。
少し昔の話になりますが、会社の新人研修で行った開発演習と発表会について、一人反省会をします。
こちらの記事にも書きましたが、入社1ヶ月目に開発演習とその成果発表会を行いました。
開発要件は、コーヒーショップの販売webシステムで、商品の販売や、マスタ(コーヒータンク)の管理、販売履歴の確認などを実装します。
スポンサーリンク
開発は4~5人のチームに分かれて行うのですが、私はリーダーでした。
自分自身でリーダーに向いているとは思っていなかったので、研修担当者に「なぜ私がリーダなんですか?」って聞いたところ、「あえてだよ」って言われました(笑)。
2週間の開発演習ですが、あれから2年間ほど開発業務を経験した今、あの当時を振り返って一人反省会を行います。
反省
発表を意識して進めていなかった
機能を全て作って、動くようにして、その上で発表会のスライドやデモの動かし方を考えるというのが、当時の私のスタンスでした。
でも、結果から言えば一番最初に発表のストーリを考えて、発表で見せる機能を優先的に実装し、動くようにすべきでした。
「全部完成することが正義!」と思ってしまっていたのですが、その自己満足より、「細かいところまで作りこまなくていいから、見せる機能を動くところまで作る」というのが大切でした。社会人になると評価っていうのは見えている部分だけですからね。
設計から開発、発表まで2週間という期間で、素人4人が集まって全部きっちり完成させるのは難しいです。今考えると、限られた時間で、最高の評価をもらうにはどうすればいいか、を考えるというのが狙いだったのではないかと思っています。
発表を機能を担当したメンバに任せた
「発表内容は任せるから、大体一人○分くらいで担当した機能の説明をお願いします。」って言っておけば、全員まじめだから大丈夫だろうなと思っていまいた。
実際全員、準備してきてくれたのですが、ログイン機能に時間取りすぎだな~とか、発表するとこかぶったなとか、そういう操作されたら自分のとき困る!とか、はっきり言ってグダグダになっていました。
前日に結合した&データ不整合が起こり、発表本番で落ちた
明日発表というところで、やっと各メンバの作った機能を統合しました。
今ならgitでソース管理するのですが、当時はそんなツールの存在すら知らず、ファイル共有で共有して、フォルダを一つにまとめました。
丁寧に作ってくれていたおかげで、幸いにもほとんど修正することなく、全ての機能が動いてくれました。 これで一安心と思って本番を迎えたわけです。
発表が始まって、一番最初のログイン処理のところで、ログインエラーや、3回失敗のアカウントロックも実演し、ログイン機能はほぼほぼ大丈夫そうでした。
いざ、メイン機能の説明というところで、データ不整合が起こり、スクリーンにでかでかとエラーメッセージが表示されてしまいました。
原因はログイン失敗のデモの部分でログインユーザに値が入らなくなるバグがあり、結合してからあまり動かせなかったため、発表で露見してしまったのです。
意味の無いSQLがたくさん
要件全て満たす機能を作るというスタンスでやっていたのですが、さらに欲張って、こんな機能あればいいんじゃない。みたいな話が設計段階からあり、実装段階でも途中まで実装してもらっていました。
ですが後半になってきてどうも間に合わないと気づき始めてから、間に合っていない部分をみんなで分担しあい、結局大量につくってもらったSQLは使われないまま放置されてしまいました。
「あればいい」は作らない、タスク・進捗管理、など、あのころの私の方針はアンチパターンであふれかえっていました。
もちろんテストコードなど無かったです。
発表に必要な機能だけ優先的に作っていれば時間的にも余裕があったし、ちゃんとテストも出来ていたなと思います
どうすればよかったか
ではあの時どうすればよかったのでしょう。
今ならこうするというのをあげてみます。
ただし、gitを使う、backlogでタスク管理など、当時能力的にできなかったことは省きます
- 設計段階では要件を満たす最小の機能だけ実現するようにする
- 「あればいい」「あれば便利」は作らない
- 実装が始まる前に、発表のストーリー、最低限開発する機能(発表で見せる機能)を考えておく
- 最低限見せる機能とは、ログイン画面で言うと「ログインできること」です
- 3回失敗でアカウントロックは見せないと決めたら、一旦保留(実装しない)にしておきます
- 全ての機能をタスクに分割して、その中でさらに分割する
- 二日に1回ぐらいのペースで進捗報告
- ログイン機能をさらに、画面の実装、ログイン機能、メインページへのリダイレクトなどにあらかじめ分割しておく
- 「どれくらいできているか」をわかりやすくする
- 段階的に結合していく
- たとえば画面の遷移を実装できたときや、コーヒー販売とタンク管理ができたときなど、つどつど結合していく
- 前々日までに発表者を決めておき、その時点で完成している機能でリハーサル・練習をしておいてもらう
- 発表で使う機能がそろったらテストする
- まだ機能が要件どおりでなくても、発表すると決めたところが出来ていればテストして、バグを直し、開発用のフォルダから分離する
- 分離したフォルダでアプリを起動し、それを元に発表の準備を進めてもらう
- もし時間があれば開発をすすめ、同じことをする
- データをバッチで用意する
- 各シーン(一連の動作でない)では都合のいいデータを用意する
- また、直前の機能のデモでデータ不整合にならないようにする
- この二つを満たすために、DB作成バッチを用意しておき、各シーンを説明する前にDBを作り直せばよかった
最後に
当時は、リーダを任せてもらいながら、メンバの力を発揮できないまま中途半端なもをの作ってしまったとすごく後悔しました。
同じような状況・立場の方へ少しでも参考になればと思います。
読者登録をしていただけると、ブログを続ける励みになりますので、よろしくお願いします。