概要
ゆとり教育がスタートしたころに JUnit を導入した昔話です
システム開発の現場改善記シリーズの目的
下記のリンク先を参照ください
前提
以下のエントリの続き。 10 年以上前の話。日本において JUnit の情報が出始めたばかりの頃です。
システム開発の現場改善記 - Template Method パターンでチームの開発工数を 1 / 10 にした話 ※オチ付 - TbpgrBlog
目次
1. 今北産業
以下の前提から話はスタート。
システム開発の現場改善記 - Template Method パターンでチームの開発工数を 1 / 10 にした話 ※オチ付 - TbpgrBlog
要約すると以下の三行。
- SI'er の現場に下請けで参入。
- コードの臭いを嗅ぎ取って改善案を実施。
- 改善により信頼と権限が強まった。
2. プロジェクトのはざま
前回の納品を順調に終えたため、次案件までの間かなり のんびりとした待機期間 に。
基本的には障害対応要員として時間を確保されているものの、障害がおこらないので
かなり多くの自由時間を手に入れました。
（PM に確認したが、障害が発生していなければ自分の判断で業務に関わる好きなことをしていていい
と言われていた。）
そこで、納品したプログラムに JUnit の単体テストを追加してみることにしました。
PM に JUnit 導入について、そのメリットを報告すると すんなり話が通った 。
前回の 信頼貯金の影響 でしょう。
ちなみに、 JUnit は 業務外でサンプルコードを書いたことがあるだけ でした。
3. JUnit 導入
前回の納品した各サービスに JUnit の単体テストを追加した。
テストの作成法について、簡単に Word に情報をまとめ 新人でも実装できるように した。
新人も待機で暇をしていたので、 JUnit について ペアプロで実際のテストを一緒に書きながら内容を教えた 。
4. 結果
無事 JUnit の単体テスト導入完了。
これで 単体レベルの回帰テストのコストを大幅に削減 し、
以後の開発も 単体レベルの品質と保守工数を下げる ことができました。
単価交渉の件( 『Template Method パターンでチームの開発工数を 1 / 10 にした話』参照 )もあり、この現場に長居しなかったので、以下の内容は想像です。
現場内の他の多くプロジェクトでは 自動テストは一切行われていなかった ので
モデルケースとして有用だったのでは？ と想像しています。
ポイント
- 前回、プロジェクトの納品危機回避に貢献したことによる 信頼貯金
- プロジェクトの狭間の 自由時間を有効活用
- JUnit の個人学習を実践投入
- 個人学習駆動
- 実務経験に加えることができる
- JUnit 自体の導入経験としてアピールできる
N 次派遣で現場に派遣されるような業態の場合、派遣された案件が納期を迎え、
実力を認められると継続して契約が続くことになります。
その時に、 次の開発着手までは期間があく ことがあります。
さらに社内政治によりプロジェクトの合間で、暇をもてあましていても
他のプロジェクトの案件を手伝うことが難しいことがあります。
（部門間の予算の関係や一度人材を手放すと、相手のチームに取られたりしてしまうことを危惧しているらしい）
その場合、
気に入った人材を持ち駒として確保しておきたい。 しかし次の案件までやることはない。 結果として、明確な業務を与えずに案件が動き出すまで放置する。
ということが良くあります。
（他の人はどうか分かりませんが、私はよくありました。）
これは、 10 年以上前の話だけではなく、4 ～ 5 年前にいた派遣現場でも同じだったので
今でも似たようなところは多いだろう、と予想しています。
この期間は 業務の時間を使っておおっぴらに自己投資をできるチャンス です。
さらに、期間的にもゆとりがあるので 新規技術の調査・検証・導入 など 普段はできないことをやりやすい です。
今後の業務や自身のキャリアに役だつものを導入できれば一石二鳥です。
結果として、ここで JUnit を導入した経験は
他の複数の現場で JUnit を導入した際にも役だちました。
