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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「シンプル　イズ　ザ　ベスト」とは良く言われる表現ですが、
プログラミングの世界では何を指すのでしょうか？

私は、まず最初に意識しなければならないのは、
器自体のシンプルさだと思います。
つまり、
「単一の目的の器を、必要最小限の数だけ、必要最短期間だけ保持する。」
ということを意識しなければなりません。

「単一の目的の器を」ということは、
一つの器に二つのものを入れないというだけの話です。

例えば、処理区分（０：未処理または処理不要、１：未処理、２：処理済）のような器は
一つの器に二つのものを入れたものであり、
処理要フラグ（０：処理不要、１：処理要）と
処理済フラグ（０：未処理、１：処理済）に分割して
一つの器には単一のものだけを入れるようにすべき場合が多いです。

「必要最小限の数だけ」ということは、その言葉通りの意味です。
初心者が陥る最たるものは不必要なデータの複製です。

データの複製は「コール　バイ　バリュー」のメソッド呼び出し等、
言語レベルで強要される場合以外では不要です、
と言っても言いすぎではないでしょう。

また、初心者でなくとも単純に同じ内容を複製する場合には気づき易いのですが、
同一の意味合いのデータを違う形で複製する場合には非常に認識しづらくなります。
（そのためにも「単一の目的の器を」ということがキーになるのですが。）

「必要最短期間だけ保持する」ということは、
オブジェクト指向言語であれ、非オブジェクト指向言語であれ、
器の色を明確に分類するということです。
オブジェクト指向が強要するように手続きと器をきちんと紐付けた上で、
必要最小限度の期間だけ器を生成して保持（そして消滅）すべきです。

器の次に意識すべきは手続きですが、
方法論としてはアルゴリズム辞典、デザインパターン集、問題領域の考察など
関連資料が多く書店にならんでいるのでそちらを見て下さい。
（私の稚拙な話よりは、論理だった話が聞けることは間違いありません。）

ただ、器をきちんと意識してプログラミングできるようになるとアルゴリズム
（と言うか業務システムの九十数パーセントまでは、単に処理手続きといったほうが妥当かもしれませんが。）
は自然と単純化されると思います。

「頭の中に数個から十数個のデータを入れる器をイメージし、
その中身が移り変わる様、またはその器自体が消滅、生成されていく様を
正確にシミュレーションすること」
プログラミングのイメージは極論するとそういうことのように思えます。

キーとなる部分は、
けっして手順、手続き主導の考え方の中には
無いのではないでしょうか。

プログラミングの習得し始めは文法、開発環境への慣れ等、
自分自身の基礎スキルアップのために神経を使わされます。
誰でも動かない原因が
全角空白が入っていたため、
ソースとオブジェクトとの同期ミス、
などという馬鹿げた目にあっているのではないでしょうか？

その後に、今度は仕様把握、
つまり機能理解のために惑わされるでしょう。
当初は設計レベルでのスキル不足からくる
仕様書行間の読み違え、読み漏れがほとんどですが、
実はこれはこれでやっかいで
仕様書自体のバグと一緒になるとバカげたトラブルに巻き込まれます。

そのまた後に、前述のコーディングスタイルのように、
自己のスタイルを確立するために悩んだように思います。
記載レベルではなくプログラムの指し示すもの全体でのスタイルを確立しようとすると、
「アセンブラ言語レベルでの動作イメージを把握すること」の他にも
「データの保持方法と扱い方」を注意深く整理する必要がでてきます。

つまり、データをどういうものだと捕らえて扱うか、
また仮にそうだとすればどのように扱うべきなのか？
つまるところ問題領域において、
何を１つの対象物と捕らえるかということです。
大事なのは、１つのデータを１つの器に、
ということだけだと思うのですが、
これが、なかなかそう簡単ではありません。

説明するまでもありませんが、
先ほどのプログラミングのイメージの中でいう器とは、
プログラミングの上では変数により具現化されるものです。

器の中身を確かめること、または器の中身を書き換えること、
または器自体を生成、消滅させることがアルゴリズムです。

プログラマは、機能としてやりたいことを
たったこれだけのことだけで成り立つようにプログラム言語で言いなおす、
と言う一種の翻訳者だと言えるのではないでしょうか。

今日も良い天気で、気持ちが良いです。

長期間の統計を取った話では
株価は、晴れの方が上昇する確率が高いそうです。

そんなロジカルに思える世界ですら
無意識のうちに天候に左右された人の気分の
影響を受けてしまうんですね。

私は学生時代、テニス部に入っていて
テニスに熱中していました。

雨が降ると、コートでボールを打つことができず、
構内で筋トレなので、
朝起きて雨が降ってると憂鬱になるクセがつきました。

今もそのクセが完全には抜けてないんでしょうが
晴れるとウキウキして、雨だとドンヨリしてしまう
傾向があります。

もう４２歳なのに１０代のころのクセも無いんですが。。。
雨があまり好きでは無い
って話でした。

仕事であれ何であれ、
スキルアップを望んだときに
努力することが大事なのは、
言うまでもないですが、

それを継続し続けることがさらに重要です。

三日坊主では何事もできないのは
誰でも知っていることです。

継続していく上で
私が役に立った、良いヒントだと思うことを
２つ紹介します。

一つは、根を詰めすぎないことです。

ジョギングを例にとると
「朝、ジョギングをしよう！」と決めて走りだした人の中で
雨が降って気乗りしない日がきたときに

その日は休んで晴れた日にまた走る人と
雨の日にも休まずにカッパを着て走りに行く人、

数ヶ月とかではなく何年も続く人は
雨が降ったときは休んで、晴れた日だけ走る人のほうが多い
という話を聞いたことがあります。

短距離走、中距離走ではなく、
仕事も人生も超長距離走です。
数ヶ月だけ続いても、その後やめてしまうのであれば
あまり意味がありません。

何年も、何年も続ける必要があるので
根を詰めすぎないことです。

疲れたら休めば良いんです。
乗り気がしなければ、違うことをすれば良いんです。

大事なのは、晴れた日にまた走り始めることです。

もう一つは、どこまで行っても慢心しないことです。

昔のことわざ、偉人の訓話とかの通りで
未熟だと感じているからこそ努力するのであって
現状に満足すれば、
成長のスピードが緩むのは
誰が考えても間違いのないところでしょう。

還暦を過ぎても自分のことが
「全くもって未熟だ」と言えるような
おじいちゃんでいれたらと思います。

今日は朝からカゼのせいか頭痛がひどいです。
（きっと、昨日、子供たちと一緒に雪だるまを作ったせいです。）

今日から新人さんの勉強会が始まるというのに。。。

でも、さっき風邪薬を飲んだので
これから気合で治します。

週はじめなので、元気だして行きましょう。
ファイト！
オー！！

さて、新人さんの勉強会ですが、

今、上ちゃんが先生役で
コンピュータの概要を教えてくれてます。

最初なので
当然ながらみんな緊張ぎみで
ういういしい感じです。

はやくなれて
騒々しくなってくれれば
良いのですが。

これからが楽しみです。

今日、仕事の打ち合わせの中で
私が最初にソフトウェア開発の業界に入ったときのことを
ちょっと思い出しました。

私の場合は、
正直に言って、
まったくもって

「コンピュータって何？」

って言うゼロの状態から
始めたのですが。。。

最初に就職したソフトハウスさんでは
簡単な講習を１週間程度受けて
「後は体で覚えていって」
みたいな体育会系みたいなところがあって、

私の小心者な性格も相まって
最初の1ヶ月ぐらいは
本当に緊張して過ごしたのを

思い出しました。

実は来週から未経験の方に

Javaのプログラミングの講習会を
行っていくのですが

これからの若い人のために

はやく緊張がとけて
熱中できるような環境、雰囲気を
作っていけたら

と思っています。

とはいっても
関係者のみんなの協力を頂けないと
絶対に無理な話ですが。。。

今も関わってくれているみんなが
義務感とか損得とかではなく
善意とか良心的なところからだと思うのですが、

本当にがんばってくれているので
私自身が本当に勇気付けられています。

みんな
ありがとう。

よ～～し。

私もまけずに
がんばろう！！

と思った１日でした。