口だけの男

懐かしい。10年ちょっとくらい前のすこし昔話をする。
https://togetter.com/li/1361053

僕が新人の頃にやったのは、1チーム5人、全チーム同じ要件定義書と機能仕様書で1か月で実装、の研修だった。
指示に従えば、余った時間で自由に機能を足してもよい。
最後にできたシステムの評価を投票でランキングにする。
他は上記リンク先とだいたい似たような条件。
全員同じだから、実装等見て監督者がフォローできる。

当時、僕は技術リーダーに任命されたが、ほぼコードは書かなかった。
この研修で僕が書いてもあまり意味がない。
課題の内容なんて簡単にできそうだし、やっても自分は成長しない、と思ったから。
java&J2EEのWebシステムで商品の管理システムを作る。
他のチームは、実装が遅いメンバーの遅れを技術リーダーが驚異の実装スピードでフォローしていた。
僕は、顧客役である教官のところへ行き、「今どきこんな古臭い見た目と機能いりませんよね、こんな感じでさっぱり分かりやすくしましょう」と提案し、無駄な画面操作や表示機能を省き、コンパクトで見やすいように変える合意をした。*1
テキストにはコンパクトになった仕様書やデザインはもちろん載っていないので、図示したりペアプロなどひたすらメンバーのフォローを実施。
僕は一切コードを書かなかった≒他のチームよりもよくできる実装者が1人足りなかった、が期間内に品質の良いものができた。
自由に機能を足すというお題目に対し、機能を削ってコンパクトに使いやすくしたのが良かった。
投票の結果、10チーム中２位だったのを覚えている。
1位は同期一番の凄腕プログラマーが、長時間労働＆ハイペースで作ったものだった。

当時の教官に、
同期の中で2人は抜きんでている。だが今までの教えた生徒の中でもお前は異質、口だけの男、悪い意味じゃないんだがそうとしか言いようがない。
と言われたことを印象深く覚えている。

*1:テキストに書いてあった画面仕様は、Webシステムのノウハウがまだ弱い、各個人に役割を分けやすさを考慮してか、無駄な機能や画面遷移が多かった。 例：更新機能の場合、 （テキスト）機能選択=>更新機能を選ぶ=>更新したい商品のID入力=>更新入力画面＝＞更新処理。 （変更案）検索＆検索結果画面＝＞ヒットした商品に更新のリンク=>更新入力画面＝＞更新処理。 今の感覚だったら常識だが、当時はまだこんな画面遷移の考え方が残っていた。