うちの会社でも
春の情報処理試験を受ける方が
数多くいます。

会社としては、特に褒賞的なところも、
強制的なところもないのですが
個々の方のモチベーションの高さに
本当に勇気付けられます。

私も、会社としてそれにこたえられるよう
また個人としても日々の勉強を続けていけるよう
がんばります。

ちょっと話は変わってしまいますが。

最近、ＷＥＢのニュースで
イギリスで数億円の宝くじを当てた男性が
仲間がすきだからという理由で
マクドナルドに店員として再就職した
という記事を見ました。

仕事をする理由はお金以外でも、
人間関係の中にあると言うことだと思います。

モチベーションを高めるといっても
一人ぼっちでは、長い間それを保つことは本当に難しいと思います。
でも、刺激を与えてくれる人が近くにいると
結構、影響を受けて元気が沸いてきたりするものです。

お互いが良い人間関係を築きながらも刺激し合い、
個々が自己研鑽をし続けられるような雰囲気を
会社の中につくっていけたら、
と思っています。

家の直ぐ目の前が小学校のグラウンドで
桜の木がぐるっと周りに植えられているのですが
花が咲き始めました。
まだ１、２分咲き程度ですが
青い空に薄いピンクの花が本当にきれいです。

最近（というか今年にはいってから）、小さな失敗を数多く繰り返して
ちょっとヘコむところもあったのですが、
ちょっと癒されて勇気づけられました。

自分自身の中の恐れとか欲とかに打ち勝てるよう、
言い換えれば「強く」なれるようがんばろう、
と前向きな気持ちにさせてくれるきれいな桜でした。

今まで備忘録の中ではプログラミングのことを中心に書いていましたが、
これからしばらくは、今度はＳＥ的なところで書いてみます。

以前にブログで書いたプログラミングの話の中で
器のシミュレーションのことを述べましたが、
器をプログラム内の変数からテーブルのカラム、テーブル、ファイル、
その他の「データを格納する何か」に適用を広めると、
ＳＥの必要とされるシステム内部デザイン能力は言い尽くせるように思います。
（またしても極論であることは否めませんが。）

つまるところ、システム外部デザインが固まってしまえば
（現実実務の中では、そうそううまくは行きませんが。）
業務系システムの果たせる役割というのは、ほとんどが、絵が出て、紙が出るだけでしょう。
他のシステムに何らかの方法でデータのやり取りが発生したとしても、
他のシステムの動きをみると最終的にはそれだけの話です。
現実世界を動かしているのは最終的には人間であり、
人間に理解できるかたちでＯＵＴＰＵＴしなければ
業務系システム自体に何の意味もないことを考えると至極単純な話です。
※制御系のシステムではあてはまりませんが、その点はご容赦下さい。

従ってシステムの内部のデザインを決めることは
ＩＮＰＵＴされたデータを何らかの形で溜めておき、
必要に応じて引き出すことだと極論できます。
それ以外では必要に応じてデータ自体に何らかの加工をする程度が関の山です。

だからこそ器を違うものに応用して考えてみると、
必要とされるシステム内部をシミュレーションする能力において
ＳＥはプログラマの延長線上にあると思います。

最近、数年ぶりにテニススクールに通っています。
体力ＵＰのためにもがんばっているのですが、
本当にすぐに息が上がってしまいます。

そういえばテニスを始めたころの最初のウィンブルドン決勝が
１９８０年のボルグとマッケンローの死闘でした。
でも、今やそれ以降に生まれた人と一緒に働いているような状況です。

なので、
まあ、
息が直ぐにあがってもしょうがないかなぁ、
とも感じるこのごろです。

でも横浜の工藤投手のような人もいるので
ちょっと勇気づけられます。

がんばれ工藤、がんばれ桑田、野茂。

他の業界の他の職能では、出来るひととあまり芳しくない人の格差は、
数字として十数倍程度が限度ではないでしょうか。
しかしながらプログラマの世界では平気で百倍以上は違います。

コードの生産性だけをとっても一人月（一人が一ヶ月働く工数）の目安に使われる数値は、
一千数百ステップ～二、三千数百ステップ程度だと思います。
「あまり芳しくない人などは三ヶ月かかっても五百ステップのプログラムも完成できなかったが、
逆に出来るひとは１ヶ月で二万ステップ以上のプログラムをくみ上げた。」
などは普通に良く聞く話です。
これだけでも百倍程度は十分に違うわけです。

私が実際に見た中で最も多くのコードを生産できるプログラマの生産性は、
一人月で五万ステップ分のＣ言語のプログラムを組み上げるものでした。
当然ながら正常動作を確認する作業も必要なため、
一日辺りのコーディング量に直すと五千ステップ程度はコードを書けないと到達できない数字です。

それでいてバグの数は片手もないほどでした。

スピードを上げれば、精度が犠牲になるわけではありません。
それどころか、経験的には必ずスピードと精度は比例するように思います。
個人のスキルにほぼ全てが依存していることを考えると至極当然のことです。

スピードを上げるために必要なことは三つあると思います。

一つは俗に言われる「だんどり」といわれるものです。
言い換えれば、自分自身の作業をシミュレーションする能力です。
これはプログラミングに限らずどのような作業でも同じだと思います。

もう一つは、単純に集中力です。
だからこそ以前のブログで述べたように、この仕事に好きな部分を見出せるかどうかが重要なのです。
どんな優れたプログラマであっても、覇気なく、集中力が足りていなければスピードも遅く、
精度の悪いものを作り込んでしまうでしょう。
根本的にはモチベーションの問題です。

最後の一つは、決断する時間を短くすることです。
業務システム開発においては、仕事に費やされる時間の半分以上の時間は、「まよっている時間」です。
決して考えている時間ではありません。
「そんなことはないですよ、一日中コーディング（または機能仕様作成、またはテスト、、、）していますよ。」
という方はよく思い返して仕事中の自分自身を観察みて下さい。
きっと言っている意味が解るはずです。
どんなレベルの作業でもそれはおこります。
まよっていることをきちんと自覚してそれぞれの決断スピードを高めることは、
より複雑な作業を行う良い訓練になるでしょう。
ここで断っておかなくてはならないことは、
早く決断しようとすると二十パーセント程度は間違ってしまうということを覚悟することです。
どんなに習熟しても、過去に経験したことのない新たな決断の場合は、
逆に八十パーセントを間違ってしまうかもしれません。
どうか決断することを恐れないで下さい。
それよりもアイドリングしてしまうことのほうがもったいないのですから。

私の経験からいうと、「スピードが速く、精度の高い人」は、
最初は「スピードが速く、制度の悪い人」になるように思います。
「スピードが遅く、精度の高い人」を目指そうとしてはいけません。
そんな人は、実際にはいないように思います。
あとは「スピードが遅く、精度の悪い人」がいるだけです。

以上、明確な理由は述べられず、あくまで個人の経験からくる私見ですが。。。

フォーエスラボ（Fores　Labs）
↓
http://www.fores.jp/labs/index.html

で作った作品をマイコミジャーナル様でとりあげてもらいました
↓
「AIRで作ったシンプルIM「ForesMessenger」を公開 - フォーエス」
http://journal.mycom.co.jp/news/2008/03/08/007/index.html

これも、うちの技術者がタイトなスケジュールの中、
がんばってくれたおかげです。
ありがとうございました。

以降もちょっとづつでもこの辺りを掘り下げて行ければ。。。
と思っています。

完璧なコード、堅いコード、ソリッドなコード。
そもそも「完璧な」というものが現実世界にあるとは思えませんが、
それを求めるのはプロフェッショナルなプログラマのプロフェッショナルたる所以だと思います。

仕事としてプログラミングする中では、ほぼまちがいなく不可能だと思いますが、
より完璧に近いコードを書く方法を知っています。
それは一度コードを書き上げた後に、全てを最初からやり直すことです。

「やり直す」これほどプログラマにとって苦痛なものはありません。
言葉だけだと単純なことですが、
数日から数ヶ月かけて作り上げたものを捨てて一から書き直すわけですから
精神的にも体力的にも、苦痛以外のなにものでもないでしょう。
しかしながら、もし仮にそれに耐えることができ、
（こちらのほうが問題ですが）仕事の時間的制約がそれをゆるせば、
その出来栄えはその時点でのそのプログラマの最高到達地点であるといえるでしょう。

我々は実務者なので架空の話はやめて、現実的な話に戻しましょう。
本当にやり直すことは不可能ですが、頭の中で組みなおすことは可能です。
しかも実際にやり直すとしたら、モジュールの構成を変え、データの扱いを変え、
実際に一つのミスもなく修正を施すことは容易ではないですが、
頭の中だけであれば通勤電車の中でも一瞬で出来上がります。
「あぁっ、あそこのモジュール構成をこんな風に分割して、呼び出し方法はこんな感じにしよう。」
なんて感じです。
単純な方法ですが経験的にはプログラミングスキルを高める最も効果的な方法の一つだと思います。

しかもこれを何度か繰り返すとほかにも訓練されることがあります。
それはコードを丸ごと頭に入れる能力です。
慣れない間は三百ステップ程度のコードですら大変ですが、
一時的には（そのプログラム作成中の間だけという意味です。次のプロジェクトに入ってしまえば、
仕様を思い出すことすら困難でしょう。）五千ステップ程度までなら特殊な能力なしに
訓練次第で可能なのではないでしょうか。
（ここで訓練とは、以前に述べたコーディングスタイルの確立と単純さの追求を指します。）

昨日で４３歳になりました。
家でバースディケーキを前に歌を歌ってもらいました。

今年は厄年を抜けたから、という訳でもないのですが、
いろんなことに挑戦していくつもりです。

たったこれだけ、でした。