【IT事業本部コラム】~開発の時間配分を見直そう!

IT事業本部アーキテクトの石川です。

システム開発に関わる皆さんは日々、様々な機能を決められたスケジュールのなかで開発しているかと思いますが、今回はその時間配分のお話させていただきます。

開発作業は、主に

  • メインの動きとなる「正常系」処理の作成
  • 入力検証などの「異常系」処理の作成

の二つのステップに分かれ、また作成後には、

  • 目視や簡単なテストケースを用いた「セルフテスト」

を経て完了となるわけですが、皆さんはその時間配分をどのようにしていますか?

社内の幾人かに質問してみたところ、
「正常系2、異常系1、セルフテスト1」
の割合が多いようでした。優秀ですね。ちょっと盛ってる気もしますが…

世の中にはろくにセルフテストを行わないまま完了としてしまう技術者も少なくない中で、回答してくれた方々が1/4もの時間を品質向上のために割いてくれているのはとても素晴らしいことだと感じます。

あくまで私のこれまでの経験からですが
「正常系1、異常系1、セルフテスト2」
くらいが理想だと考えています。

セルフテストの重要性

ややテスト時間が多く感じられるかもしれませんが、実際にやってみると、はじめはこれぐらい時間を確保しないと書き出した項目が消化できません。
特に若い技術者は期限を何よりも優先する傾向が強く、セルフテストが不十分なままテストフェーズに突入しバグを多発させてしまうことがよくあります。ひと度テストフェーズでバグが発生すれば、それが軽微なものだとしてもチケット起票、原因調査、改修、再検証など、作成者以外のメンバーの作業も増えていきます。

プロジェクトが危機的状況に陥る最たる原因が、このような当初のスケジュールにはない作業の積み上がりであり、PMが若い技術者の受け入れに難色を示す理由もまさにこれ。

ですから、期限内に製造を終わらせれば良いのではなく、与えられた期間の1/2で製造を終えてやっとオンスケであると理解してください。
信頼の厚い技術者は与えられた時間の多くを品質向上に充てています。セルフテストにあまり馴染みがなければ、まずはノートに担当機能のテスト項目を記述するとことから始めてみてください。

「URL直接入力」、「二重送信」などや、入力項目ごとに、「必須」「最大50文字」「初期値〇〇」など、実装した仕様を書き並べ、動作確認ができたら〇を付けていきます。ノートに自筆することに拘りはありませんので、何をチェックしたかを手軽に確認でき、新しい観点を思いついたらチェックが抜けていた他の機能にすぐに追記できるやり方があればなんでもOKです。

ちなみに、過去にそうしたセルフテストを義務付けた結果、単体・結合テストフェーズでのバグ発生率は3%未満、検収テストでのバグも1%未満となった事例があります。
このプロジェクトのメンバーはほとんどが若い技術者でした。経験の浅い技術者でも正しく作業を行えば高い品質を達成することができます。

新しい技術の探求も大切ですが、たまにはアプローチを変えてセルフテストのやり方を見直してみるのも良いかもしれませんね。

Text by IT事業本部 アーキテクト 石川