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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最近、いろいろと考えさせられることがあって、
わが身を振り返ると
私の周りにはフェアな人が多く、
人に恵まれていると感じることがありました。

社会人になると、
ましてや経営者になると当然ですが
直接的に教えてもらえる相手は
なくなります。
（まあ、言うまでも無いことですね。）

その道のプロとして報酬を頂いているからには
できて当たり前、のことばかりですが、
個人として考えた場合、
そんな完璧な人は存在しないですし、
正直なところ、私は本当に至らないところが多々あります。

至らないところがあれば、
お叱りを頂ければ幸せで
ほとんどの場合は、
ただ単に、次からの機会を失うだけです。

だからこそ
怒ってお叱りを頂ける相手は得がたいですし、
さらにつっこんで意見してもらえる人は、
本当に替え難い存在だと思います。

以前に、松下幸之助様の本で、
「
怒られることを感謝する相手でなければ
怒る価値もない。
君は怒られることを感謝しているか。
感謝しているようであれば、怒ってあげる。
」
と言った意味の訓話を読んだことがありますが、
本当に最近になってその意味を
少し解ったような気がします。

フェアな信念から意見してくれる周りの人々によって
支えられているんだなぁ。。。

と感じるこのごろ、と言う話でした。

鍛冶屋の槌を振るう利き手は、
その反対側の手に比べて見違えるほど太いはずです。
利き手は、毎日毎日重い槌を振るっているからです。

それにくらべて反対側の手は鋼を押さえるだけで、
利き手に比べたらはるかに貧弱になってしまいます。

仕事をしていると反対側の手になりたがる人が
多くいることに誰しも気がついていることでしょう。

誰しも「出来たらスキルは得たい」と思っているでしょうが、
その希望とは裏腹に、実際にやっていることは、
反対側の手のようなことが多いことにがっかりします。

同じような話で、
中高校生のころは誰も「パシリ」には、なりたがらないのに、
仕事についたとたんに「パシリ」になりたがります。

何かしらのリーダ経験をした人なら誰でも、
「私はそんな指示は聞いていません。」
「それは私の作業ではありません。」
といった部下の言葉を聞いたことがあるはずです。

他人に自分の仕事自体を委ね過ぎている人が多く
本当にがっかりした経験があるはずです。

なにかの本の受け売りですが、
何かに依存すると
その人は弱くなります。
ここで依存すると、と言うのは、
「自分自身以外に自分の行動の責任を置くと」
「何か自分以外のものに過度の期待をすると」
と言った意味です。

会社に頼り過ぎている人は、当初は居心地が良くとも
そのうちにだんだんと、会社に「ノー」と言えなくなっていくでしょう。
親に頼り過ぎている人は、親がいなくなってからのことを考えると、
強い不安に襲われるでしょう。
彼女、彼氏に頼りすぎている人は、フェアなケンカなんてできないに違いありませんし、
また、妻、夫にに頼りすぎている人も同様でしょう。

もちろん何も他人に感謝せずに生きていける訳はなく
そういった事を言っている訳ではありません。

単に、何かに依存しすぎて
反対側の手のように弱弱しくならないように注意しましょう、
という話でした。

「バグ」
いやな言葉ですが、これをなんとかしないと話しになりません。

プログラミングの領域に絞って考えてみると品質の作りこみは、
つまるところコードを書いている最中に行うのがもっとも効率的です。
大工さんのいう「二回計って一回で切る」のように
最初から完成形に近いものを作りこむことが一番効率的なのは間違いないでしょう。

その次に来るのがコードを書いたプログラマ自身による動作確認です。

さらにそれ以降に行われる「第三者によるテスト」「統合されたまたはシステム全体でのテスト」などは、
優れた方法論が多く存在しますのでそちらを参照して下さい。
ただ、あくまでこれらは最初の二つの方法による作りこみが出来た上での補助的なテストにすぎませんので、
品質の作りこみの九十数パーセントは、プログラマ自身の手によって行われることは間違いないでしょう。

コードを書いている最中に品質の作りこみを行う。
実際にこれを行うためには出来ないといけないことが二つあります。

その一つは、書いたコードの動作シミュレーションを頭の中で行うことです。
「このデータ取得で１が３件取得できたとすると、このループを２回まわり、ここでこのフラグが立って、、、」
というような感じです。
（これ自体は、必ずしも先に述べた器のシミュレーションが出来なくとも出来ます。）

もう一つは、例外を想像することです。

それは、（性格が悪くなるかもしれませんが）全てを疑ってかかることによって磨かれます。
コードの中で疑わなくて良いのは、
キャストの発生しないスレッドセーフなプリミティブな変数間の代入文ぐらいです。
それ以外のコードでは全てを疑ってかかった方が良いように思います。

「１、２、３のいずれかしら入らない区分に９が入っていたら。」
「絶対対応がとれているデータの対応がとれていなかったら。」
実際にコードで何らかしらの対処をすべきかどうかは別にして、
全てについて一度は考えてみる必要はあります。
（一旦、コーディングスタイルが確立されれば一々最初から考える必要はなくなるのですが。）

例に挙げたような単純な場合は、言うまでもないですが、
いかにこのような例外ケースを考えつくことができるかが一つの能力だと思います。

これに慣れると機能仕様自体の矛盾点を検出できるようになります。
間違った機能仕様のもとでコードを書くことは、
間違った地図をもとに目的地へたどり着こうとしているようなものです。
優れたプログラマは例外なく優れたシステムの内部設計者である所以は、
ここにあると思います。

コードを書いた本人による動作確認は、俗に言われる単体テストとは違います。
優れたプログラマは、全てのケースの網羅を最小テストケースで行うことができます。
ここで言う全てのケースとは全機能仕様分という意味ではありません。
プログラムロジックから考えて全てのケースと言う意味です。
プログラムロジックが全て頭に入っている本人だからこそ短時間で精度の高いテストを実施できるのです。

それを実施した後は、単にロジック全てを忘れて第三者になったつもりで再度テストを行えば、
思い違いによるミスを出来る限り取り除くことができるでしょう。

繰り返しになりますが、あくまでコードを書いている最中に品質の作り込みが出来てはじめて
動作確認の意味があります。
不毛な論争の中で述べたようにコーディングスタイルを確立する必要がある理由の一つは
ここにあると思います。

睡眠時間が不規則なのは、
学生時代からずっとそうなのですが、
みなさんはどうなんでしょうか？

システム開発作業に従事していたころは
徹夜なんかもあったりして
不規則なことも多く、
平日はタフに働いて、土日に寝だめする
ということが多くありました。

でも、歳をとってくると長期的な無理は
きかなくなってきて
なるべく就寝時刻と起床時間を一定に
しようと思っているのですが
なかなかうまくいきません。

就寝時刻はともかく起床時間だけでも
一定にしようと思っているのですが、
土日の朝が遅くなってしまい、これがなかなか．．．

ワタミの渡辺さんは、
起業してからずっと４時間ちょっとの睡眠時間らしいです。

そこまでは無理でも
朝早くに起きて一仕事こなすような
朝方の生活にしていこう、
と思うこのごろでした。