詰将棋のようにTDDでC#を学ぶ実験 | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/8347
で、プログラムを練習する訳だが、実際の詰将棋のように「この問題は3分で解けると5級」みたいなのがあるといいと思う…というか、そういう作りをしている。
試験じゃないので(仕事ベースでやるので)、ググろうが問題文からコピペしようが構わない。実際、チェック上仕方がなかったので、問題のテストコードに解答が書いてあったりする。だいたい、1問(1つのテストメソッド)に対して、15分以内にコードが通るようになれば十分だろう。だいたい、人の集中力は10~15分程度なので、それを超えると効率がガタンと落ちる。訓練で、この時間は2時間ぐらいまで伸ばせるけど(時間制限のある不具合の修正のときに使う)疲れるので、お勧めはしない。
パーソナルソフトウェアプロセスを使う
パーソナルソフトウェアプロセス入門 / Watts S.Humphrey 著 PSPネットワーク 訳 | 共立出版
http://www.kyoritsu-pub.co.jp/bookdetail/9784320120136
パーソナルソフトウェアプロセス技法の補助教材
http://www.kyoritsu-pub.co.jp/service/psp/dse_index.html
絶版になってしまったが、この手の時間を気にしたプログラミングの手法として「パーソナルソフトウェアプロセス」がある。もともと、情報工学の授業で使われていたもので、講義用のスライドや演習用のシートが用意されている。
これが、実際の仕事としてのプログラミングに応用できるかというと、経験上、そうでもありそうでもない、という状態と言える。検索すると、いくつか仕事に利用する例があるが、まあ、プログラマな仕事をしているときには使わない。何故か?端的に「疲れる」からだ。なので、社内研修などで PSP(パーソナル・ソフトウェア・プロセス)を使うのは時間制約内で効率的なんだけど、実際の仕事の場合には疲れすぎて役に立たなかったりする。
ただし、自分のプログラミング速度を測定する(私は「巡航速度」と呼んでいる)ためにはよい。
PSP の利用法に2種類あって、「最大戦速」と「巡航速度」がある。
「最大戦速」は、まさしく船のボイラーが悲鳴を上げるぐらい速度を上げるので、人間の体力的にもキツイ速度だ。できて、3時間から半日ぐらいが限界だろう。いわゆる、「この不具合を明日の朝のリリース前までに直してくれ」と言われたときのスピードだと思っても良い。これをやると、息も浅くなるし、モノも食べず飲み物も飲まない(口に何か入れるとリラックスしてしまって、遅くなるからだ)。なので、あまりやりたくない。
「巡航速度」のほうは、いわゆる毎日続けられる時間になる。継続できるプログラミング体制というのは、XP で言うところの 40時間/週 勤務であったり、8時間/日のうちに Google の 20% ルールが入っていたりする勤務体系になる。匍匐前進とかはやらない。その位の、ペースが毎日続けらる(プロジェクトが続いている間だから、2,3か月は大丈夫とか)パターンになる。アジャイル開発のスクラムよりも遅いペースでよい。
そういう巡航速度で過ごせる、プログラミング速度を自分で知っておくのは必要で、問題を解くときに、
- 問題に対し予想時間を決める
- 開始時刻を記録する
- 問題を解く
- 終了時刻を記録する
- 予想と実績の時間を比較する
- 次回の予想時間を調節する
という具合に、予想を常に調節する(ドライビングする)ことになる。そうやって、何度も繰り返していくと、設計などを見たときに直感的に作業時間が見積もれるという「勘」が養われる。「勘」というとまるでマジックのような気がするか、モノづくりをするときに「勘」は必要だ。大工にも勘所があるし、税理士にだって不正のあるところが「勘」でわかる。そういう、プロフェッショナル「勘」を養うために、こういう問題を何度も疑似的に解いてみるというのが目的である。
ちなみに Humphrey 氏は、(悪名高い)CMMI の提唱者らしいので、その先のことは沿わなくてよい。CMMI とか ITSS は測定のための測定(端的にいえば、外部から「資格」を与えるものなので、自己言及がない)ので、測定の「道具」として使うにとどめるとよい。なので、プログラマな現場としては、自己鍛錬のひとつとして PSP を使うとよいだろう。
[amazonjs asin=”4320120132″ locale=”JP” title=”パーソナルソフトウェアプロセス入門”]