大学院の有志チームで参加していたRICOH & Java developer challenge2011でRICOH賞をいただきました。
アプリケーション機能は非常にシンプルでしたが、顔認識技術とビジネスモデルとの組み合わせ、アプリケーションとしての完成度が評価されたのではと思います。また、水着の三愛がリコーの傘下といこともあり、画像解析 × ファッションレポート のアプリケーションが受け入れられたのもあるようです。
グランプリの北陸先端技術大学院さんも顔画像技術を使用されており、エンタープライズアプリケーションにおいてもこれらの技術は注目されているのだと感じました。
また、他チームのアイデアや実装は素晴らしく、若い方々の発想力に驚きました。もう少しブラッシュアップすればRICOHからアプリケーションとして出ても良いのではと思われるアプリケーションもあり良い刺激をもらえました。
約8ヶ月ほど、チームで活動をしてきましたが、最後に良い結果が出て良かったです。チームの皆さんありがとうございました。
大学院の有志メンバと参加しているRICOH & Java Developer Challenge 2011の最終選考に提出できました。
9月末に１次選考（Emulator編）を無事通過し、最終選考へ向けて実機上でMFPアプリケーションを開発してきました。
5月にチームを発足してから半年以上と長期に渡って活動してきましたが、ようやくシンプルながらも面白いモノが完成しました。
このプログラミングコンテストからは技術的な部分のみでなく、チーム活動の進め方という点に関しても多くの得る事あった為、参加して良かったと思います。
最終選考は2012/1/12（木）です。あと、Ustreamでも放送があるそうです。
自身の開発プロセス改善を目的として7回に渡りシナリオ仕様毎に、
計画立案 → 設計 → 設計レビュー → コーディング → コードレビュー → コンパイル → テスト → 事後分析
を繰り返し行いましたので、最後に結果を分析しました。
・ プログラムごとの見積規模と実績規模を比較し、見積の正確性を検証する。
【プログラム毎の見積規模と実績規模】
| Program No. | 見積規模(LOC) | 実績規模/KLOC |
| 1 | – | 60 |
| 2 | 150 | 79 |
| 3 | 164 | 124 |
| 4 | 124 | 104 |
| 5 | 144 | 96 |
| 6 | 137 | 152 |
| 7 | 248 | 189 |
全体的に見積規模と実績規模はある程度の近似値で見積が出来ていた。
通常最も避ける必要がある点は、見積規模に対して実績規模が大きく上まるケース（受注金額に対して、予定工数が上まってしまう為）であるが、そのような例は見受けられなかった。
仕様が複雑化していった後半のプログラムにおいても、大きな差異は無かった理由としては設計フェーズで仕様を完全に把握出来たことが功を奏したと推測される。
・ プログラムごとの見積時間と実績時間を比較し、見積の正確性を検証する。
【プログラム毎の見積時間と実績時間】
| Program No. | 見積時間(min) | 実績時間(min) |
| 1 | – | 300 |
| 2 | 120 | 470 |
| 3 | 250 | 297 |
| 4 | 315 | 369 |
| 5 | 385 | 565 |
| 6 | 224 | 451 |
| 7 | 168 | 381 |
時間に関しては、規模と対照的な結果であった。実績時間が見積時間を大きく上まっているケースが多く、終盤においてもこの現象が見られる。まだ見積時に使用する自分のデータが安定していない事と仕様の複雑さや難易度が見積時間に反映出来ていないことが影響していると推測出来る。対応方法としては、見積時間に対してある程度の時間を上乗せすると実績時間と見積時間が合致する。
・ フェーズ毎の実績時間を相関し、フェーズ間の関連を確認する。
【プログラム毎の実績時間】
| プログラム | 計画立案 | 設計 | 設計レビュー | コーディング | コードレビュー | コンパイル | テスト | 事後分析 |
| 1 | 10 | 45 | – | 120 | – | 0 | 65 | 60 |
| 2 | 20 | 30 | – | 183 | – | 5 | 192 | 40 |
| 3 | 20 | 60 | – | 94 | – | 3 | 90 | 30 |
| 4 | 60 | 105 | – | 80 | – | 1 | 63 | 60 |
| 5 | 60 | 65 | 20 | 190 | 15 | 5 | 140 | 70 |
| 6 | 40 | 65 | 15 | 137 | 20 | 1 | 113 | 60 |
| 7 | 70 | 50 | 10 | 100 | 20 | 1 | 70 | 60 |
| 合計 | 280 | 420 | 45 | 904 | 55 | 16 | 733 | 380 |
コーディング（水色）とテスト（緑色）の関係をみると、コーディング時間が長くなると連動してテスト時間も大きくなっている事が確認出来る。また、ほぼ一定の距離感で連動する事が確認出来る。これにより、直感的な単純な見積を行う場合に、開発時間の3/4程度がテスト時間であると定義出来そうである。
・ 設計、コーディングで作り込まれた欠陥を型ごとに分類し、グラフにより型による欠陥数の傾向を図示する。
※ 型番号に関しては、PSPの手順書を参照のこと。
| 作り込み欠陥 | |||||||||||
| 型 | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100 | 合計 |
| 設計 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| コード | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 23 | 0 | 0 | 24 |
欠陥の殆どが80:機能に集中している。
この結果から考察すると、単純なミスというよりもまだプログラムの機能として仕様が満たされていないケースがあると思われる。プログラム3以降は設計フェーズで仕様を確実に把握してから、コーディングに移っていた事を考慮すると、テストやコンパイル前に行うコーディングレビューが不十分である可能性が高い。よって、コーディングレビューの精度を高める事で欠陥数は押さえることが出来そうである。
また、今回はEclipseを使用した為、コンパイル時の欠陥は1件であったが、自分の欠陥傾向を掴む為には統合開発環境を使用せずに計測したほうが良かったかもしれない。
・各プロセスで発見した欠陥数/KLOCを一覧化し、傾向を分析する。
| 発見欠陥数 | 発見欠陥数/KLOC | |
| 設計レビュー | 0 | 0 |
| コードレビュー | 0 | 0 |
| コンパイル | 1 | 1.2 |
| テスト | 23 | 28.6 |
| 合計 | 24 | 29.9 |
| Program No. | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 欠陥数 | 5 | 4 | 3 | 3 | 4 | 3 | 2 |
| 欠陥数/KLOC | 83.3 | 50.6 | 24.2 | 28.4 | 41.7 | 19.7 | 10.6 |
若干ムラはあるものの演習を行う事で、欠陥数は減少傾向である。特にプログラム3以降で欠陥が大きく下がっているのは、このプログラム以降は計画・設計フェーズを重視し、仕様を完全に把握してからコーディングを行うようにしたからと考えられる。また、プログラム5, 6,7は前回のプログラムを再利用・追加していく仕様である為、前プログラムで欠陥を押さえることが出来ていれば、必然的に当該プログラムでも欠陥が減少することが確認できた。これにより、プログラムやクラスを再利用する時は、当然ではあるが、欠陥が無い状態で利用可能とすべきことを再認識できた。
・各プロセスで除去した欠陥数/KLOCを一覧化し、プロセス別の除去欠陥能力を示す。
| 除去欠陥数 | 除去欠陥数/KLOC | 除去欠陥率 | |
| 設計レビュー | 0 | 0 | 0.0% |
| コードレビュー | 0 | 0 | 0.0% |
| コンパイル | 0 | 0 | 0.0% |
| テスト | 24 | 29.9 | 100.0% |
| 合計 | 24 | 29.9 | 100.0% |
欠陥は全てテストフェーズにて確認し、除去を行った。テストフェーズは最終段階であり、後フェーズで発見するほど対応コストが高くなる為、より前フェーズである設計レビューやコードレビューで欠陥を発見する必要がある。前段で確認した欠陥タイプの分析では、80:機能 の欠陥が大半を占めたようにコードレビューでより欠陥を除去出来た可能性がある。よって、今後はレビューにより時間を割くように意識していく。
・設計レビュー、コードレビュー時の時間当たりのレビューLOC数に対する欠陥除去率を一覧化し、傾向を分析する。
| 時間 | LOC数 | 欠陥除去数 | 欠陥除去率 | |
| 設計レビュー | 45 | 437 | 0 | 0.0% |
| コードレビュー | 55 | 0 | 0.0% |
コードレビュー、設計レビューにおいて、1件も欠陥を発見・除去出来ていないのは問題である。まだ実施時間が1時間以下である為、今後のレビュー活動に注視する。設計に関しては、仕様を完全に把握してから進めるようにしていた為、発見出来なかったのも納得出来ているが、コードレビューでは数件は発見・除去できたはずである。
・ 欠陥の修正時間を確認する。
【テストフェーズにおける欠陥修正時間と平均修正時間】
| プログラム | 欠陥数 | 修正時間 | 平均修正時間 |
| 1 | 5 | 50 | 10 |
| 2 | 4 | 197 | 49.25 |
| 3 | 3 | 73 | 24.3 |
| 4 | 3 | 45 | 15 |
| 5 | 4 | 116 | 29 |
| 6 | 3 | 80 | 26.7 |
| 7 | 2 | 50 | 25 |
| 合計 | 24 | 611 | 25.5 |
突出して欠陥修正時間が伸びているプログラム2の際は、設計が非常に甘かったと言える。この演習で非常に時間が掛かってしまった為、プログラム3以降は設計フェーズで仕様を正確に捉えるようにシフトすることができた。また、設計レビューやコーディングレビューで事前に欠陥を発見・修正することで、テストフェーズにおける欠陥数、大きな欠陥による修正時間の増加を押さえることが出来ると考えた。
【最も優先すべき点】
統一した計測方法で作業ログを残し、改善点を見つける為の振り返りを行う。
【理由】
現在の個人データは不十分 且つ、データ量が少ない為、正確な見積値として使用する事が出来ない。これを改善する為に、日々の業務や個人開発おいて、統一した計測方法で作業ログを残し、後日、改善点や傾向を把握する為の振り返りを行い、パーソナルプロセス改善を行う。
【現在の作業能力】
規模見積に関して、今までは仕様に対する規模推測を大きく見積過ぎていた。演習を行うことで似たような仕様（過去に経験した仕様）であれば、ある程度正確な規模が見積もれるようになっている。過去の実績時間を使用することで、全体を見通した時間が見積もれるようになったが、まだ若干のブレがある。
また、計画や設計フェーズの重要性を自分のデータを通して、実感出来ている。例えば、仕様は確実に理解することで、コーディング時間や欠陥数、欠陥に対する対応時間の短縮等の効果が大きい事を理解できている。
【将来あるべき作業能力】
まず最初に持たなければならない能力としては、時間見積の正確性である。規模見積が行えたとしても、時間見積が全く異なっていれば、見積が出来ているとは言えないからである。その為に必要なアクションとしては、今後の作業ログを確実に残していき、自分の見積時の基データを収集することである。次に必要な能力としては、レビュー能力と考えた。演習では欠陥検出は出来なかったが、欠陥傾向としてコーディングレビューが有効と判断した為、本能力を向上させることにより欠陥をある程度減少させることが可能である。
最終的なゴールとしては、自分が作業を行う為の見積ではなく、一般的な技術者が作業を行う場合の適性値を見積ることである。この為には、自分の能力と一般的な技術者の能力差を把握する必要がある。
PSP演習を実施するにつれて、設計の重要性が再認識出来たのは非常に良い結果であった。また、いつも見積を行う際にドンブリ勘定を行なっていたが、より精度の高い見積を行うことの重要性と手法を学べた事が良かった。今後は自分の基データを収集すると共に継続的にプロセス改善を行なっていき、機会があればチームに対してTSPを適用していきたい。これにより、トラブルプロジェクト（欠陥や期間、金額など）を減少させる１要素になると感じた。
ということで、PSPの演習自体の仕様としては業務にあまり活かせない可能性はありますが、
個々のプロセスを振り返る事で自身の開発プロセスを改善する第１歩となるという点では間違いありません。
以上です。
よく複数のプログラミングパラダイムを理解することは非常に良いことだと言われますが、
今回は関数型言語であるErlangでCollatz問題を実装してみました。
Erlangをさわるのは今回が初めてになります。実装に際しては、評判の良かった戦闘機本
を読みました。
普段使用している言語であれば、あっさり実装出来そうな（完全解決出来ていない問題なので、プログラム上の意味）仕様でさえも、かなりの時間が掛かってしまいました。
新しいパラダイムを理解するのは非常に大変だと実感できました。また、並行処理を実装する・理解するまではもっと訓練が必要そうです。
● 仕様
Nが1以上256未満の整数のとき、Nに対して関数fを有限回繰り返し適用すると１になることを示す。
【Collatz問題とは】
問題の概要は、「任意の0でない自然数 n をとり、
n が偶数の場合、n を 2 で割る
n が奇数の場合、n に 3 をかけて 1 を足す
という操作を繰り返すと、有限回で 1 に到達する」という主張である（1 に到達すると、1→4→2→1 を繰り返す）。
-module(hoge).
-export([f/1]).
f(X) when is_integer(X), (X >= 1), (X < 256) -> collatz(X);
f(_X) -> io:format("This function can use Integer and under 256.n").
collatz(1) -> 1;
collatz(X) when (X rem 2 == 0) -> collatzEn(X);
collatz(X) when (X rem 2 == 1) -> collatzOn(X).
collatzEn(X) ->
io:format("~p~n", [X]),
collatz(X div 2).
collatzOn(X) ->
io:format("~p~n", [X]),
collatz(X * 3 + 1).
● 実行方法・結果
OS: CentOS5.6
Ver: Erlang R12B-5.12
Emu: Erlang emulator Ver5.6.5
$erlcによってコンパイルすると、hoge.beamが生成されます。
その後、erlコマンドでEmulatorを起動し、実装したCollatz関数を呼び出すと、最終的に1となります。
[shmachid@hoge work]$ erlc hoge.erl [shmachid@hoge work]$ erl Erlang (BEAM) emulator version 5.6.5 [64-bit] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.5 (abort with ^G) 1> hoge:f(13). 13 40 20 10 5 16 8 4 2 1 2>