プログラマーを目指す君に！の最近のブログ記事

　現在、行っている案件でWebのリソースを測定する試験を行う為、自社製品であるWebシステム高負荷試験ツール 「SADEE 2（サディー ツー）」を利用して試験を行いました。

　リソース測定試験とは、想定される複数のユーザがWebにアクセスした時に、どれくらいCPUやメモリなどのリソースを使用しているかを測定し、例えば、メモリなどの消費が適切かどうかを測定する試験です。

　プログラムでメモリを使用した場合に、適切にメモリを開放しているかまたは無駄に使用していないかが重要になってきます。Javaでは、ガベージコレクション（GC）によって、プログラマやユーザ側からは正確に制御できませんが、例えば、変数などを局所化または最適化することで、無駄なメモリの発生を抑制出来る為、、変数などを局所化または最適化する必要があるかが確認できます。

　「SADEE 2」は、「詳細モード」と「高負荷モード」の2種類が用意されていますが、JavaのJ2SE 5.0以降ならJConsoleを利用することにより、簡単にメモリやガベージコレクションの動きを測定する事が可能です。JConsoleについては、別記事で！

「SADEE 2」の操作は、SADEE 2をインストールして、ブラウザでシナリオ作成する。後は、実行するだけと簡単です。一部、開発者である社長に操作を教えて頂きましたが、問題なくリソース測定試験を行えました。マニュアルを読むのも大事ですが、時間を買うという意味でも、聞いてしまった方が良い場合がありますしね。

「SADEE 2」の目的は、負荷試験をメインに置いていますが、JConsoleなどのツールを利用することにより、メモリやガベージコレクションの測定にも応用できます。負荷試験をメインにしていますので、複数のユーザを想定したり、複数回実行するのに、最適なため、楽にリソース測定が行えました。

　達人プログラマーを読んでいて、参考になる事は、たくさんあるのですが、今日読んでいて特に気になった事や考えさせられた事を紹介します。

各項目の最後には、演習問題があるのですが、その中で以下の問題がありました。

「
6. Javaにおいて、(a + 1) <= a となる。
」

答えは、真となることはないのでしょうか。考え方は、Javaのプログラミング言語以外も同じだと思います。他にも問題がありますが、一番シンプルで一番分かりやすいので、紹介しました。

 

　ここで、私もシンプルな問題を一つ。言語は、Javaを例にしていますが、C++で考えても考え方は、変わりません。次のソースサンプルを見て下さい。

インタフェースで「hoge」メソッドが以下のように定義されていたとします。

void hoge() throws Exception;

以下のプログラムを実行したとします。

try {
    obj.hoge();
} catch (Exception e) {
    e.printStackTrace();
}

「hoge」メソッド内で、例外が発生した場合、「e.printStackTrace();」が実行されない場合があるか？。

通常例外が、発生した場合は、呼び出し元に例外を返すように処理している場合が多いでしょう。今回の場合も、「hoge」メソッドで例外が発生した場合に、例外をスローしていれば、「Exception」がキャッチされ、「e.printStackTrace();」が実行されます。ただ、「hoge」メソッドで、「Exception」をキャッチして、例外をスローしなければ、「e.printStackTrace();」が実行されません。

私が作成した問題は、わざとインタフェースでメソッドの定義を紹介しています。その為に、「Exception」がスローされるものだと思いこむと間違えてしまいます。

よって、答えは、実行されない場合もあるです。「hoge」メソッド内で例外をスローしない場合は、「e.printStackTrace();」が実行されません。

 

今回紹介した2つの問題は、SJC-P試験の問題に出てきてもおかしくない問題だと思います。

　金曜日も、毎度お世話になっている客先へ行きました。納期の話もちらほらと出来てきました。私がメインで行う案件なので、納期も今まで以上に意識を感じています。メールのやり取りも頻繁に行われるようになり、社内外を含めて、400件近くになりました。頻繁になってきたこともあり、リーダーの確認は気になる時にだけ確認して頂いています。

　約二か月弱でメールのやり取りが約400件と言うと、多いように感じるかもしれませんが、ソフトウェア系の会社では、普通かむしろ少ないかも知れません。前回の案件では、私はお手伝いという事もあり、メインのメンバーと直接話す事が多かったですが、それでも、約三か月で300件は優に超えています。今回の案件では、リーダーとの毎朝の打ち合わせや客先にも最低一週間に一回は打ち合わせをしてのメールの件数です。

お客さんとの頻繁な調整やメールを主でやり取りする会社であれば、一つの案件で休日も含めて一日平均10回×2（送信と受信分です）とすると、一か月、600件は超えると思います。

　又、打ち合わせがあった場合でも、確認の為や議事録などを送る為にメールをしたりもします。それから、複数の仕事を掛け持ちをしていたり、客先などのように、電話だと時間を拘束していまう為、非同期のメリットを利用して、メールでやり取りをしています。以下も参考になると思うので、良ければどうぞ。

SEって、パソコン越しの会話ばっかだよね？

　IT事業部では各チームで目標年度に向けて事業計画を立てその中で技術者の幸せが問われました。

　毎週月曜日に各チームごとの報告（進捗？）会があるのですが、その後に目標年度に向けての事業計画を決めました。その中でも議論になったのが「技術者の幸せ」に付いてです。当然といえば当然ですが、会社の経営方針に符合します。ただ、私の意見も含めてよりITに近い意見も出てきました。それはエンドユーザーにも喜ばれるという事です。特に私はまだ顧客やエンドユーザーに会って仕事するわけではなく、上司、先輩又は仕様からなぜそれが必要なのかを推測するしかありません。最終的に使用するのはエンドユーザーでありその方が便利になった事などに役立てるのに私は幸せを感じます。

補足すると、顧客とはどこを意味するかという事です。ITの場合「顧客=エンドユーザー」とは必ずしも一致しません。接客業などとは違う事からもよりITに近い意見と書きました。

　ここからはより個人的な「技術者の幸せ」を述べていきます。私はロボットなどのハードも好きなのですが、それは目に見える為です。WEB-DBが目に見ないかと言えばそうではないのですが、より動きが解る動作です。又、既にあるものよりも普段は手作業でやっていた作業（特に私が体験した作業）が自動化されると幸せや満足感を感じます。例えば、メールなどはもう当たり前や既に存在していたという感じなので、あまり幸せや魅力を感じませんが、例えば、今までソースを手で整理していたのが、Eclipseなどのツールを利用することで自動化できるなどです。特にEclipseのツールはソースの動きも見えますし、クリーンアップなら違いも直に分かります。さらにVBAもその一つからも知れません。VBAにつきましては「私がVBAにはまった理由」（仮）などで紹介することとして、続けます。

　自動化はSE又はプログラマーが好きな人も多いことでしょう。参考する記事としては次を読むと共感やSE及びプログラマーの生態が解るかもしれません。
・Dr.きたみりゅうじの"IT業界の勘違い"クリニック
　SEって、ムダに手間ヒマかけるフシギ人だよね？
　

　社内プログラマーや受託専門の会社でも必ずないとはいない常駐があります。プログラマーを目指す人なら必ず常駐の事も考えて損はありません。今回は明日に控えた常駐最終日についてです。

　今回のテーマとねらいです。
●テーマ
　私が体験した常駐
●ねらい
　私が体験した常駐での体験を知ってもらう。

 

　現在の常駐が3ヶ月経ちます。6月からになるので会社での仕事よりも長いです。4，5月はチーム全体のプロジェクトの作業というよりかは社内アプリや調査で本格的な仕事は現在の常駐が最初と言えると思います。私も含め常駐先では増員が行われチームとしては、当社の部の人数よりも多いです。また、チームとして一つのプロジェクトに向かって作業を行う仕事もはじめてです。常駐先では大変にぎやかでいい体験をさせてもらえました。引き続きお世話になりたいチームの人たちだと感じています。

　明日が常駐の最終日になるのですが、新たな増員の方の歓迎会も含めて飲み会があります。前回は、6月の歓迎会でお互いにまだ能力も性格もわからない状況での飲み会です。仕事としても常駐としてもいい体験でしたので明日は楽しんできます。

　私が現在常駐している先のお盆の期間を語らせていただきます。プログラマーを目指す方は、一例ですが、ご参考に！

今回のテーマとねらいです。

●テーマ
　常駐先でお盆の期間の様子

●ねらい
　一例ですが、プログラマーのお盆の期間を知ってもらう。

　プログラマーを目指している人は気にしている人も多いと思う夏休み・お盆についてです。結論から言うと常駐先では、夏休みまたはお盆による休みをしている方は全体の15%から20%ぐらいです。

　私の素直な感想としては、夏休みまたはお盆による休みをしている方は少ないという印象です。私自身はどうかというと今回は休日や祝日などの通常の休みだけです。

　私の場合、今回夏休みまたはお盆による休みを取らない理由が2つあります。

1つ目は、当社が通常の夏休みとは別の形を取っていることです。別の形とは、有給休暇です（その分の有給休暇数を与えられています）。よって、夏休みやお盆による休みを取れば、有給休暇に反映されます。その分の有給休暇が与えられるか、会社側で夏休みが決まられているかはその時の状況によると思います。私は、有給休暇に反映された方が良いと考えています。結局夏休み中に忙しければ、出社しないといけませんし（自分が引き受けた仕事だから当然です）、一般的な夏休み以外でまとめて取ることも可能だからです。

2つ目は、8月までが契約期間だからです。予定通りに進んでいないわけではなく、むしろ他の方の手伝いもしているのですが、私の場合は8月末で9月からは自社での作業になるからです。よって、8月中に休みを取らなくても9月以降に休むことができるからです（1つ目の理由の通り、夏休みなどの休みを取らなければその分の有給休暇が余り別の休みに使えます）。

　さて、別の方ですが、常駐先では、夏休みを取っている方はさらに少なくほとんどの方が、お盆中の休みです。全体としては、新入社員の方と家庭を持っている方が中心です。プログラマー自体が他の職業に比べ年齢が低いですが、常駐先でも同じです。その為、休みを取らない方は、一人暮らしが多く、結婚している方も少ないため、あえて休みを取る必要がないように感じました。又、8月末までに納期を納めないといかない物も多くあるためと思われます。

　先輩や上司の方は今回、お盆による休みより夏休みの方が多かったように思えます（常駐先のため詳しくは知りませんが）。

　先輩や上司の方は去年のアルバイトの時より夏休みが少なかったように感じます。話や様子を見ると、当社や常駐先の会社などは他の年に比べて夏休みを取る方が少ないように感じます。プログラマーイコール忙しいというイメージがあると思いますが、少なくともたまたま今年が休みを取る方が少なかっただけで、決して休みが取れないわけではないことを知ってもらいたいと思います。私も今回は先ほど2つの理由のために、取らなかっただけです。

　資格は仕事に役立つのか　その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はまさにコンピュータの利用を中心にした仕事をしているのですから、普段からフレームワークを利用するプログラマーも多いと思いますが、普段から利用しているからこそ、他にも応用が効かないか考えてみるのも仕事の効率や品質だけではなくプライベートを充実する為にも良いかもしれません。

　プログラマを目指す学生であれば、何らかの資格取得を目指して勉強していると思います。資格を取得して勉強している時や友達との会話にもあるかもしれませんが、「資格は役立つのだろうか」という疑問です。「就職には有利になりそうだけど実際の仕事では役に立つのか」という疑問は、私も学生時代から勉強中に考えていたことです。そこで、私が仕事をしている中で、これは資格取得で役立った点を紹介していきます。また、資格は抽象的に説明されることが多いので参考書よりは偏ってしまうかもしれませんが、私が経験した範囲の実態で書こうと思っています。

 

　その1は、単体テストに付いてです。はじめに紹介するのが「単体テスト」と思われるかもしれませんが、アルバイトやはじめの仕事に単体テストを任されることもありますし、プログラミングには慣れていても単体テストはやったことがなかったりすると思います。私自身は、基本情報を勉強中に単体テストが実際にどのように行うのが分からなかった一つでもあります。

単体テストは、プログラマの仕事の範囲なので、資格では、「基本情報技術者試験」や「ソフトウェア開発技術者」などが、該当するでしょう。単体テストをするには、何をテストするかを記入するために、マトリックスを使用することが多いようです。マトリックスは、設計やテストに関係なく情報整理にも使われているため、「初級システムアドミニストレータ」でもテスト範囲です。はじめに言っておくと単体テストに限定しても「基本情報技術者試験」、「ソフトウェア開発技術者」や「初級システムアドミニストレータ」は仕事の役に立っていると私自身は感じています。

　単体テストの説明を少ししておきましょう。単体テストは、ウォータフォールモデルのプログラミングに該当します。テスト対象範囲は、自分が作成したモジュールのテストです。プログラミングが完了するとおおよそのテスト数を決め、チェックリスト（テスト内容）を作成しチェックリストに基づいてテストを行います。私自身は、プロジェクトにかかわった件数は少ないですが、テストを実施する場合は、チェックリストに基づいて証拠を取ることが多いということを聞きました。証拠の話は、参考書に記述さていないので参考になると思います。

テスト数を決めるのは、基本情報やソフ開で勉強したのがそのまま役立ちます。ただ、資格の場合、特に情報処理技術者試験は抽象的、学術的な事が問われるので、単体テストの経験が無いとより難しく考えてしまう説明が多いように感じます。ソフ開では、「ファンクションポイント」や「COCOMO」が中心となって出題されますが、それ以外にも「ハルステッドモデル」や「SLIM」などの説明が記述されていることから難しく考えてしまう点かもしれません。

私が経験したのが、ステップ法のNCLOC法です。LOC法は、ソースプログラムの行数からステップ数を決める方法で、1万行あれば、1万ステップ（10K）です。LOC法は、ただ単純なソースプログラムの行数ですが、NCLOC法ではコメント行を抜いた行数からステップ数を決めます。NCLOC法で10Kならどれくらいテスト数をこなせば良いかですが、独学などで勉強するのであれば、1割の1,000個を目標にテストを作成すると実態に近くなってくると思います。

　次回は、ブラックボックスに付いてです。