先日、ICレコーダーを買ってきて、何か試せないかと思い以前書きました効率 その1 Java アクセサ の 作成を音声による説明をテスト代わりにしてみました。テストということもあり、言い間違えがありますが、そのまま投稿します。
ブログもそうなんですが、私自身完璧にやろうとはせず（例えば、ブログなら毎日投稿など）はじめは地道に進めます。これから私が作成したプログラムぐらいは音声付きの解説ができればよいと考えています。音声を投稿するのははじめてなので、初心ということで投稿して後々の変化がわかればと考えています。もちろん、解説がうまくなることを願ってです。
今回は、編集も何もしていないので、効率 その1 Java アクセサ の 作成に追加せず、ここに投稿しました。
音声ファイルです。
約7分間収録されています。記事なら3分ぐらいで読めてしまう内容なのでいかにコンパクトにまとめ、要点を押さえられるかが課題です。営業道のように、はじめはこんなものだと思ってがんばります。はじめの踏み出す一歩が大事ということで。
ICレコーダーの事や今回使用したICレコーダーの説明は後々投稿します。
資格は仕事に役立つのか その1 単体テスト編2では、ブラックボックスについて書きました。今回は、ホワイトボックスと網羅についてです。
単体テストの一つである構造テストは、テストの範囲をプログラムコードから分析しコード全てが網羅しているかどうかを調べます。プログラムコードから分析することにより本来起こらない条件もテスト出来ることからホワイトボックスなテスト（中身が見える）と言えます。
試験では、「命令網羅」、「判定条件網羅」、「条件網羅」、「判定条件／条件網羅」や「複数条件網羅」が出題されますが、通常はカバレッジツールを利用して、テストを行うのでチェックリストの作成段階では意識する事はありません。
カバレッジツールを利用していれば、カバレッジモニタで網羅の基準となる「C0」、「C1」、「S0」、「S1」が表示されるので簡単に状況を知ることができます。通常は100%になるようにテストします。チェックリストですべて100%になるようなテストを作成できれば一番好ましいのですが、チェックリストをすべて行っても網羅が100%にならない場合は追加テストなので補完します。
通常起こらないテストとは、例外処理が中心となるでしょう。例えば、JavaならDBに障害が起きてアクセスできない事を想定して、例外をわざとスローさせます。例外がキャッチできて適切にプログラムコードが想定した動作をするのかなどをチェックします。私はまだ通常時にIOExceptionが発生した事はないのですが、当然ここもわざと例外をスローさせて対応をみます。
プログラム作成から当然例外処理を意識して作成しているので、特に大変なの事はないですが、構造テストでしっかりとログを見ることが大事です。ログも当然単体テストの為、エビデンスを残すのですが、それだけではなく構造テストはすべてのパターンのログが出力されることになります。出力されたログで本当に内容がわかるのもチェックすると後々のテスト時の後戻りがなくなります。
ログの出力はすでに設計時にばっちりと決められていることが多いですが、ログ時に出力するメッセージやバグ用に出力する内容は変更できることもあります。変更できる時には、自分の能力を発揮するチャンスでもあります。単体テスト以降に続くテストは当然ですが、運用時に問題が起こった時にもログが重要だからです。
カバレッジ(coverage)とは、コードの網羅度のことでステップ法に続いてテストの品質を決める要素でもあります。テスト数はテストを行う目標値として扱われるので最初に作成したテスト数の数をこなせば単体テストが終了するというわけではなく、ガバレッジが100%にならないと単体テストが終了と認めらないことのほうが多いでしょう。
ガバレッジと網羅の言い方は、私が経験した中では人それぞれなのでどちらでも言いように感じます。
資格は仕事に役立つのか その1 単体テスト編1では、テスト数を決めるステップ法について書きましたが、今回の単体テスト編2は、ブラックボックスに付いてです。
単体テストには、大きく分けて機能テストと構造テストに分ける事ができます。機能テストは、ブラックボックス技法を使い、構造テストは、ホワイトボックス技法を使います。
機能テストとは、テストの範囲を機能からテストすることにより仕様書通りに動作するかどうかを調べます。コードを意識しないことからブラックボックスなテスト（中が見えない）と言えます。ブラックボックスは、資格同様に「同値分割法」、「限界値分析法」がメインなのは、実際も同じと考えて良いでしょう。
私が苦労した点といえば、画面系のテストです。画面では、入力させない文字や最大入力桁のテストなどを行い項目が6以上になるとテスト数が増え大変でした。項目1つに大体15個で5項目なら組み合わせのテストで80ぐらいの数になっていました。プログラミングしながらテストをする為、15程度なら大したことはないのですが、単体テスト編1にも書きましたエビデンス（証拠）を残さないといけません。中には入力不可の文字テストなどのエビデンスが撮れない場合があり、その場合には「目視」と単体テスト書に記述する事もあります。
画面項目はテスト項目に応じてですが、DBがかかわってくると、テスト項目１個に対して3個ぐらい証拠の過程が必要でした。例えば、追加なら、登録する内容を示した画面、実際に処理が行われているコード（ビーンやポーターなどに適切に値が入っているか）、結果のメッセージ、DBのテーブルの中身、ログ（SQL文など）などです。画面で適切なテストが行われていれば、「同値分割法」、「限界値分析法」を行わなくても前提条件が終了している為、テスト数は低減できますが、当然追加の場合には主キーが既に行われているなどのテストがあります。1つテストを作成すれば（例えばDB関連のテスト）自ずとそれに従うテスト項目が浮かんでくるでしょう。
次回は、ホワイトボックスに付いてです。
現在常駐先では、あるシステムで有名なフレームワークを利用してスタンドアロンのプログラムを作成しているのですが、Webのプログラムを担当している方に「Webでも何か(独自の)フレームワークを利用しているのですか。」と聞いてみました。その方が担当している部分だけは独自のフレームワークを利用していないとの事でしたが、Javaで一般的なStrutsを利用しているそうです。ただ今回のような（オフィスの1フローが埋まるぐらいのプログラマーがおり、数年規模の作業）プロジェクトでは、Strutsではまだ応用範囲が多いことから一般的にはその間にもプログラムの品質を統一する独自又は一般的に使用されているフレームワークを使用するそうです。プロジェクトが大規模になればなるほどプログラマーも増え、関わる会社も多くなりますからより中間的なフレームワークが必要ということだと思います。
Struts自体がフレームワークであることや他の言語（例えばCなど）と比較すると色々と制約が多いと考えていましたが、確かにStrutsでもコーディング規約をより明確にしないとプログラマーの差でコードの品質が一定に保つのは難しいそうです。アルバイトや小規模な社内システムしか作成した事が無い私としては、大変参考になりました。
私向きの資格発見！！で番組を紹介しましたが、放送の中で会社ごとに整理するルール（特に、場所）を徹底することによって道具を探す手間を省き生産性を向上させる（目からウロコの整理術）という内容があったのですが、これはまさしく、プログラミングで言うフレームワークに相当するのではないでしょうか。ただ、プログラミングではフレームワークを当たり前のように利用していますが、私が感じるのは、仕事は出来ていてもプライベートに反映されていない事です。例えば、システムの設計でプロジェクト進捗を管理する事は出来ますが、自分のプライベートの事になると計画が一切されていない事などです。私は、仕事の技をプライベートなどの生活で利用したり、プライベートで行っていることや仕事とは関係なく勉強したことを他の人よりは仕事でも生かしていると思っています。例えば、一般的な整理術をプログラミングにも応用するというようにです。又、それは今までコンピュータが導入されていなかった所にコンピュータを導入することと同じでもあると思いませんか。仕事で依頼者（お客）の問題を解決すること自体が出来ると言うことは、プログラミング（一般的にはシステム設計）と他の部分（例えば、勤怠管理などの管理や整理）が共通していることだと思います。おなたは、ちゃんと生かし切れていますか。
LifeHackが叫ばれていますが、プログラマーやSEはまさにコンピュータの利用を中心にした仕事をしているのですから、普段からフレームワークを利用するプログラマーも多いと思いますが、普段から利用しているからこそ、他にも応用が効かないか考えてみるのも仕事の効率や品質だけではなくプライベートを充実する為にも良いかもしれません。
先週NHKの番組「めざせ！会社の星」で、目からウロコの整理術が放送されていました。整理できる方が「ファイリング・デザイナー検定」という資格を持っていることを知り、以前からLifeHackに興味があった私としては、早速「ファイリング・デザイナー検定」の事をいろいろと調べてみました。ファイリング・デザイナー検定は、書類に関する検定のようなのですが、電子化ファイリング検定という資格もあり、電子化ファイリング検定は電子データに関する事のようなのでファイリング・デザイナー検定と合わせて面白そうだなと興味を持ちました。
Web先で過去最優秀合格者をみると「ファイリング・デザイナー検定」や「電子化ファイリング検定」の合格者にソフトウェア系の会社も多く含まれているので、早速資料を請求してみました。資料は、まだ届いていなのですが、今から楽しみです。
私は、会社に入社して3ヶ月半になるのですが、途中から常駐先での作業になったこともあり、会社にある私の机はほとんど空です。常駐先では少しずつファイルが溜まってきたりはしていますが、机に余裕があるうちにファイリングの知識を養おうと考えています。私自身プログラマーですから、ファイリングの知識をプログラムに応用できるよう今から燃えています。
プログラマを目指す学生であれば、何らかの資格取得を目指して勉強していると思います。資格を取得して勉強している時や友達との会話にもあるかもしれませんが、「資格は役立つのだろうか」という疑問です。「就職には有利になりそうだけど実際の仕事では役に立つのか」という疑問は、私も学生時代から勉強中に考えていたことです。そこで、私が仕事をしている中で、これは資格取得で役立った点を紹介していきます。また、資格は抽象的に説明されることが多いので参考書よりは偏ってしまうかもしれませんが、私が経験した範囲の実態で書こうと思っています。
その1は、単体テストに付いてです。はじめに紹介するのが「単体テスト」と思われるかもしれませんが、アルバイトやはじめの仕事に単体テストを任されることもありますし、プログラミングには慣れていても単体テストはやったことがなかったりすると思います。私自身は、基本情報を勉強中に単体テストが実際にどのように行うのが分からなかった一つでもあります。
単体テストは、プログラマの仕事の範囲なので、資格では、「基本情報技術者試験」や「ソフトウェア開発技術者」などが、該当するでしょう。単体テストをするには、何をテストするかを記入するために、マトリックスを使用することが多いようです。マトリックスは、設計やテストに関係なく情報整理にも使われているため、「初級システムアドミニストレータ」でもテスト範囲です。はじめに言っておくと単体テストに限定しても「基本情報技術者試験」、「ソフトウェア開発技術者」や「初級システムアドミニストレータ」は仕事の役に立っていると私自身は感じています。
単体テストの説明を少ししておきましょう。単体テストは、ウォータフォールモデルのプログラミングに該当します。テスト対象範囲は、自分が作成したモジュールのテストです。プログラミングが完了するとおおよそのテスト数を決め、チェックリスト（テスト内容）を作成しチェックリストに基づいてテストを行います。私自身は、プロジェクトにかかわった件数は少ないですが、テストを実施する場合は、チェックリストに基づいて証拠を取ることが多いということを聞きました。証拠の話は、参考書に記述さていないので参考になると思います。
テスト数を決めるのは、基本情報やソフ開で勉強したのがそのまま役立ちます。ただ、資格の場合、特に情報処理技術者試験は抽象的、学術的な事が問われるので、単体テストの経験が無いとより難しく考えてしまう説明が多いように感じます。ソフ開では、「ファンクションポイント」や「COCOMO」が中心となって出題されますが、それ以外にも「ハルステッドモデル」や「SLIM」などの説明が記述されていることから難しく考えてしまう点かもしれません。
私が経験したのが、ステップ法のNCLOC法です。LOC法は、ソースプログラムの行数からステップ数を決める方法で、1万行あれば、1万ステップ（10K）です。LOC法は、ただ単純なソースプログラムの行数ですが、NCLOC法ではコメント行を抜いた行数からステップ数を決めます。NCLOC法で10Kならどれくらいテスト数をこなせば良いかですが、独学などで勉強するのであれば、1割の1,000個を目標にテストを作成すると実態に近くなってくると思います。
次回は、ブラックボックスに付いてです。
自分なりの贅沢は何ですか？突然質問しましたが、エンジニアに限らず体調管理は、大事ですよね。私も自分なりの体調管理を実施しています。体調管理にやる気や集中力がありますが、やる気や集中力を高める上で行っている一つが自分なりの贅沢です。贅沢を自分で与えることによりやる気や集中力を高めます。
先日、常駐先でお昼などの代金を手帳に書き写しているのを隣の方に見られてしまいました。私の場合は、日頃は出費を抑えて一週間に一回、小さな贅沢ですがその為にお金を管理しています。一日に使う目標金額を決め、目標金額に到達しないお金をポイントとして貯めていきます。例えば、一日のポイント金額が100円なら一週間で500円です。
一週間で500円貯めれば何ができるかですが、私の場合は帰りの電車を特急に変えて利用しています。500円であれば、ほとんどの人は特急に乗れるのでしょうないでしょうか？エンジニアの方は、業種を問わず夜遅くなることが多いと思います。私の場合は夜遅くなることはまだありませんが、時間帯によっては帰りでも朝と同様満員電車です。その中を特急で帰ることが私の小さな贅沢です。
たった一週間に一回ですが、その日だけでも仕事中はやる気や集中力が高まりますし、特急の中では、雑誌や本を読んだり睡眠ができます。睡眠では勿体無いと思うかもしれませんが、満員電車で苦しい思いもする事無く、席に座れない事も無いので、その日だけは自宅に着いて直に自分のやりたいことができます。
考え方は、いろいろだと思います。私の場合は一週間に一回でしたが、私とは違って一週間に一回贅沢をするよりも毎日に少しずつ贅沢をする人もいるかもしれません。プログラマーを目指す人は、ただプログラミングや設計の勉強だけではなく、体調管理も大事な仕事の一つなので、今回のテーマのように、学生の時代から心がけてはいかかですか？
