Web アプリ開発の「見えない時間」とは？

Web アプリ開発の「見えない時間」とは？

仕事として、Web アプリを開発する場合、納期は重要です。 納期までに仕事が終わらないと発注元にも迷惑をかけてしまうので、予定をしっかり立てて納期に間に合うように開発を進める事が求められます。

仕事を受ける場合、基本的には「自分に出来ると思う」仕事を受けるのが普通なので、大まかにはどれくらいでプログラムが書けるかは感覚的に分かる場合が多いと思います。

ところが、納期や品質はトラブルが多い部分でもあります。大きな理由は「見えない時間」が存在するからです。

見えない時間の正体

見えない時間とは、予め計画されていない時間の事です。Web アプリの仕事の場合、プログラムの作成にかかる時間は見落とされる事はほぼありません。誰でも、考える時間だからです。しかし、テスト（検証）とデバッグの時間は見落とされたり、予想以上に時間がかかる場合があります。それが原因で、納期が遅れたり、納品した Web アプリがきちんと動作しないというトラブルに繋がる事がよく起きます。

テスト（検証）は軽視されがち！

特にテスト（検証）は、実際のプログラムを各作業（コーディング）に比べると軽視されがちな傾向があります。これは、テストをしないという意味ではなく、テストを行う「ケース」が限られている事が原因になる場合が多くなります。

Web アプリに限らず、プログラムを開発する場合、思った通りに動作するかをチェックすることは誰でも重要だと認識しています。したがって、殆どの場合、テストがされないという事はほとんどありません。仕事で開発したプログラムでなくてもテストはされています。

問題は、テストを行う「パターン」が少ないという所にあります。

実は、Web アプリに限らず、基本的な動作は少なくてもプログラムを書く人が想定する一連の動作はチェックするのは普通です。それで、思ったように動作すると、プログラムを書いた人は「このプログラムは大丈夫」と思ってしまう場合が多くなります。 逆にうまく動かないと何が悪いのか、中々解らない場合が多く、デバッグに時間がかかるケースが多くなります。

問題はどこにあるのか？

これは、プログラムに限った事ではありませんが、「想定内」の事は大抵は上手く行くというのが多くの事で当てはまるということです。設計者が想定している動作は、その流れを基にプログラムが書かれているので多くの場合、想定通りに動作します。

上手く動かないという場合は、想定外の事が起きているからというケースがほとんどです。

最初の動作確認で上手く動作しないという場合は、その時点で設計者が想定していない事が起きているというのがほとんどです。当然想定していないので、原因を探すのも簡単ではありません。

最初の動作確認で上手く動作したとしても、それはあくまで想定内なので、自然に考えれば動作するのは普通です。しかし、何か別の設計者が想定していない要素が入ると動かない場合がかなりあります。

基本動作は、簡単に想定が出来るのでテスト（検証）も簡単です。しかし、利用者の誤った操作などは、実際に起こり得るケースでもテストされない場合がかなりあります。そうした部分がプログラムのバグとして存在するというのが「問題」です。

想定外と言ってもイメージしにくいと思いますので、例を挙げてみます。

例えば、ある Web アプリでは、ファイルを読み込んで画面に表示する機能があるとします。通常の処理では、ファイルを読み込んでその中身を表示するというシンプルなものです。

しかし、例えば、ファイルの読み込みをキャンセルしたりした場合はどうでしょう？あるいは、ファイルを２回読み込んだ場合はどうなるでしょう？

この両方のケースを想定してプログラムが書かれていれば、多くの場合通常に動きます。しかし、こうしたケースが考慮されていなくて、きちんと対応するような処理がされない場合は、問題が起こる場合があります。例えば、ファイルを２回読み込んだ場合、前のファイルのデータが残っているような場合もあり得るわけです。

対策は？

では、対策はどうすれば良いのかという事になりますよね？ 実は、対策は、テスト（検証）をする事を意識して予め計画に盛り込むことがとても重要です。

＊　何をテストするか考える

＊　どうやってテストするか考える

＊　普通の操作・動作と異常な操作・動作を分けて考える

「作る」ために考えることは、殆どの人が言われなくてもやっているので問題ではありません。しかし、どうやってテストするかは考えないケースが多いので、まずは、どうテストをするか考える事を計画に入れて実行する事で大きな違いが生まれます。

どやってテストするかを意識すると、そのケースでも「動くように」作るのは自然な流れです。また、テストがやり易いような仕組みを設計に組み込んだりもできます。そうすることで、テストもスムーズに実行できますし、万が一上手く動作しない場合でも、必要な情報がすぐに得られるようにできます。

つまり、納品前により多くのテスト（検証）を行うことで、Web アプリの品質は上がりますし、予めテスト（検証）を予定することで、テストのための時間が「見える」ようになります。

まとめ

多くの場合、問題は「見えない所」で起きます。 したがって、問題を減らすには「見える」ようにすれば良いことになります。 実際に、Web アプリを開発する場合、慣れない人の場合は作ることばかりに目が行って、テスト（検証）は疎かになりがちです。予め、テストする項目として考えられていない事は見落としも多く、実際にその条件になった場合、予想通りの動作をしない場合も多くなります。

こうした問題は後で発覚したり、仮に納品前でも見つかると解決までに時間がかかる事が多くなります。予め、テストする内容や項目を考えて、開発の中に取り込むことで、いろいろな見えないものが見えてきます。

Web アプリの開発では、見えない部分を少なくして見えるように工夫することで、隠れた時間、つまり見えない時間を大きく減らす事が可能になります。

「見えない」のは「意識していないから」が大きな理由で、意識すると見えるようになるものです。不思議ですが、ちょっと視点や見方を変えるとプログラムに限らず問題を減らすことに繋がります。