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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくプログラマ同士の議論の対象になるものにコーディングスタイルがあります。
（私自身も自己のスタイルを確立するために悩んだように、
またその途中で愚かにも他人を論破しようと
どこにも行き着かない無駄な論争をしたように思います。）

コーディングの記載スタイルについては、
二人のプログラマがいれば二つの異なったスタイルが存在し、
百人のプログラマがいれば百の異なったスタイルが存在するはずです。

（もちろんここでは、ＣＰＵおよびメモリ上での動作、
可読性などにも考慮されたコーディングスタイルだけを対象とし、
単に長年書きなれただけのスタイルを
コーディングスタイルとは認めません。）

その意見が合致することは稀なことであり、
また議論してもどこにもいきつかずあまりにも不毛なので
ここでは具体例については何も述べないことにします。

但し、記載スタイルの確立が不要だという意味ではありません。

それどころか括弧・カンマ一つ、
空白・インデント一つ
についてまでも記載方法が決まっていることは
優れたプログラマにとっては当たり前のことであり、

理由を求められれば
理路整然と答えられなければならないものだと思います。

記載レベルではなくプログラムの指し示すもの全体でのスタイルを確立しようとすると、
「データの保持方法と扱い方」を交通整理する必要がでてくると思います。

つまり、データをどういうものだと捕らえるか、

また仮にそうだとすればどのように扱うべきなのか？

ちょっと焦点がずれてしまいましたが、
ここで話ておきたいことはたった一つで、
「美意識を満たすように書きましょう」ということだけです。

他人にいちいち喋る必要はありませんが、
自分で納得できるものでなくてはなりません。

「より良いものを」
ここがおざなりで実際に良いものができる訳がありません。

自分を卑下しないためにも
譲れないものの一つのように思います。

またそのことによりプロフェッショナルとしての
「誇り」の一部を得ることが出来るでしょう。
この話には「但し」があって、
仕事の中でプロフェッショナルとしてやる以上
次の三点には気を付けなくてはなりません。

その一つは、
現場で求められるスタイルの制約がある場合は、
（良くあるコーディング規約というめんどうくさいローカルルールです。）
これに従うことです。
同一の言語でもスタイルが異なると、
一見別のプログラミング言語に見えるようなことは、
ままあります。
コードの書き方が統一されていることは、
後日メンテナンスする人にとってどれだけ助けになるか解りません。

もう一つは、
話が少しかぶってしまいますが、他人の目を意識することです。
メンテナンスする人は初心者かもしれません。
特殊な賢いが解りづらい方法でコードを書いてはいけません。
一見陳腐な単純なコードに見えるほうが優れているのです、
というか一人よがりの「おまえらに解ってたまるか」的なコードはアマチュアの仕事です。
難しい問題領域を一見陳腐な単純なコードで書けるとしたら、
それ以上のプロフェッショナルなコードはないでしょう。

最後の一つは、
状況によっては逆にスタイルに縛られないことです。
納期を十分守れるほど短期で出来上がらない場合は、
柔軟にショートカットできることも、
本当にプロフェッショナルなことのように思います。

私は２５才で情報処理業界に入り、
コンピュータによる業務システム開発だけを行い、
今年で１８年目となります。

サラリーマンを５年、
フリーとして３年、
その後今の会社を独立起業してまる１０年を超えます。

起業すると一人で全てを行わざろう得ないため人事採用も私自身が行います。
（人事採用が社長業として一番大事な仕事のように思います。）

ここで苦労して得たことは、
「本当に大事なのは技術的なスキルではない」ということなのですが、
そのこと自体を書き始めると焦点がずれてしまうので
ここでは、次に大事なロジカルな思考能力、コミュニケーション能力など
システム開発の現場で必要となる能力に絞って話しをさせてもらいます。

面接のなかで
システム開発の基盤として必要とされるプログラミング能力を
見抜くほど難しいことはありません。

一応１０数年この業界で働いてきているので
現場で一緒に作業をしながら技術的な質問を２、３交わせば
直ぐに大体の力量は判断できるのですが、
未経験の方だと本当に確信を持って判断できたためしがありません。

数学、物理の成績はもちろんのこと、
ＩＱテスト的な適性テスト、
コンピュータ自体の好き嫌いなどでもさっぱり解りません。
（ちなみに私も仕事自体は好きなのですが、
コンピュータ自体はいまだにそれほど好きではありません。）

面接では無理なのですが、
試しにちょっとプログラミングをやってみて、
当人自身の好き嫌いを教えてもらうほうがよっぽど正確だと思います。

これを読む方は、きっとプログラミングの経験が多少はあることでしょう。

あなたが多少はプログラミングに面白さを感じていることを願っています。

もしそうであれば、あなたはこの仕事に向いていると思って間違いありません。

自信をもって仕事を楽しんで下さい。

起業した後も現場に居座り続け、
つい最近まで現場でシステム開発に携わっていたのですが、
その中で痛切に感じるのは人材の大切さです。

例えば製造業とかであれば優秀な企業経営者は生産ラインの現場視察をする中から
カイゼンなりをできるのでしょうが、

システム開発の業界のなかでは生産ライン自体が人の頭の中にあります。

解らない人にとっては生産ラインの実態をおぼろげながらでも見ることすらできないでしょう。

個人に大きく依存する業界であるにも関わらず、
例えば陶器、刀剣のような職人の世界よりも眼に見えないだけ
たちが悪いと思います。

この業界は、ひどく矛盾をはらんだ解りにくいところがあります。

理不尽なビジネス慣習、現実に即さないルールなど
システム開発の現場に携わったことがあればきっといくつかは挙げられることでしょう。

ほんの少しでも問題解決の糸口になれば、
もしくは一から考えるアイデアのもととなればと思い
（現場の感覚を忘れないうちに、）
この文章を書き溜めてみます。

稚拙な構成、文章についてはどうぞお許し下さい。