闘え! プログラマ

　いきなりだが、ニュートンの粘性法則に従う流体をニュートン流体という。学生時代に流体工学で 学んだがもう忘れていたのでちょっと調べて見た(^^;。それは次式で表される。

Ｘy ＝ η・∂u／∂y

　ただし、Ｘy : y軸に直角な面にはたらく応力のx成分、u : 速度、η: 粘性、流れの方向がx 。 だそうだ。
　私が液体といってスグ思いつくのが「水」なんだが、水はニュートン流体だ。力を加えると 変形する(流れる)。力と変形は比例関係にある。通常我々が液体といって連想するものは 大方このニュートン流体になるであろう。
　一方、このニュートンの粘性法則に従わない流体を「非ニュートン流体」という。 非ニュートン流体には力を加えたときの挙動によっていくつかの種類に分けられている。 そのひとつとして「ダイラタント流体(dilatant fluid)」がある。 この流体は力(せん断応力)のかけ始めは液体だが、力が大きくなるほど(硬くなってきて)流れにくくなる。 イメージがわきにくいかもしれないが..
　車の流れを流体とみなすと、交通渋滞なんかも定性的には上記流体のように感じてしまう。 空いてるときは「スースー」で走れるが、3車線がいきなり1車線になったりすると 極端にのろのろ運転になってしまう。
　実は情報伝達も流体とみなすとダイラタント流体のように振舞うと私は思っている。 昔のような情報伝達手段であればサクサク情報は流れて、その受け手も常にアクセタブルな状態 で居られるであろう。ところが、膨大な情報量を個々が瞬時に伝達できるような昨今、 受け手の状態は然に非ず。更に情報量が増すと一向に受け手の頭には流れなくなってしまう。。 で、渋滞待ちなんてことになってしまうのだ。

　ソフトウェアの開発においても思うところがある。 プログラマが晒される環境は、その流体の流れる方向に自分が居るのだ。我らプログラマ は潜在意識としてこの感覚は持っている。ならば手立てを考えておけばよいのだ。
　そして如何なる流体が来ようともそれをそれを留まらせることなく、 事前対処を取っておく必要がある。いつ、どこから、どんな量の情報が舞い込んで来るか 予想がつかないからだ。流体を通すパスが狭ければ事前にバイパスを作るなり、そのパス の抵抗値を下げたり、はたまた強制ポンプを具備したりと.. 。

　我ら崇高なプログラマは多忙な時こそ「次回多忙時に楽ができる事前処置を 閑暇に行うよう書き留め」ておかなくてはならない。

# 書き留めておいた事を閑暇に実行するかどうかが大きな分かれ目だ(笑)

　インターネットがまだ普及してなくて、パソコン通信が盛んだったころ Nifty-serve の会議室ログをダウンロードして、所定のルールに従って テキストを切り出したりマージしたりといったツールは非常に便利で手放せなかった。 この手のツールはいろいろあったが、やはり led は草分け的存在だった。
　led を使いこなすには少しばかり設定スクリプトを書く必要があったが一旦書いて しまえばログ整理は自動化できた。
　Nifty-serveのログ(テキストファイル)はフォーマットが決まっており、それを 字句解析してパースするってのが基本的な仕掛けなんだろう。もちろん内容まで 汲み取ってセマンティック・エラーを出すことなどはできない。AIを積んでも 難しかろう。だからこそ、意味論まで含めて検討する場合は人間が必要となる。

　さて、どこの業界でも自動化の波は押しよせてきているが、一方では 先のような人間の存在を求めれるシーンも多々ある。
が、中にはそこを求められて仕事を託されながら、アウトプットはログカッター並という 人間もいるのだ。
　自分ひとりでやる分には構わないがタッグなりチームを組んで、 他の人間の依存タスクとしてそれをやられたらかなわない。協調どころか 破壊行為に近い。

　そんな輩にはどんなに要求事項を説明しても ログカッターの出力しか望めないのだ。なぜならその輩はログカッターに等値変換されるからだ。

　我ら崇高なるプログラマはログカッターを作ったり使ったりすることはあっても、 決してログカッターになってはならない。

　プロジェクトの大小に関わらずプログラムのテスト段階においては バグトラッキングシステムは必須だ。
　GNATS や Bugzilla などの定評のあるものもあるし、独自に作成されている 方々もいらっしゃる。sourceforgeも然り。別に大袈裟なシステムが必要と 言っているんじゃない。バグを追跡できる機能が実現できればいいんだ。

　しかし、その必要性とは裏腹に現場で導入されていないところも少なからず 存在するのではないだろうか。もし理由なくバグトラッキングシステムを 運用していないとすればそれは勉強不足と言っていいだろう。「知らない」のなら 導入できるわけがないんだから。でも問題なのはそれじゃなくて、バグトラッキングの 必要性を感じていないということなんだ。もし必要性を感じたら作るなり調べるなりするはずだ。 一次的なその兆候としてはバグの一覧を作ることだ。(こういう時に利用されるのが オイラのキライなスプレッドシートなんだなぁ。まぁいいけど。。) 作る暇などなければ調査すればいい。ご時世、ちょいと検索するだけでたくさん情報が 得られる。

　とここまでは前振りで、それらしくバグトラッキングシステム(もどきでも..)を運用し始めると、 何を勘違いしたかじゃんじゃん書き込むヤツがいる。それがバグなら歓迎なのだが、 感想だとか気づきだとかを書くヤツがいる。「伝言板」と間違えてるんだ。 勘違いにも程がある。 　挙句の果てには肝心のプログラマへではなく「テスタだけに向けて」発信したりもする(-_-;
かと言って「テスタへ..」なんて明示してるわけでもなく.. まさか痴呆の兆候でもあるのかと 疑ってしまう。
　バグトラッキングシステムの目的すら理解していないと、こんなお粗末なことになるのだ。

　バグトラッキングシステムの効果は言うに及ばないが、それを理解してないと 逆に邪魔で足手まといのムダなシステムになってしまうことを、我らプログラマは 認識しておく必要がある。だからといってバグトラッキングシステムの運用を否定 してはいけない。要は挫けてはいけないということだ。

　G.Polyaの有名な書籍でもあるが、最近は問題の解き方がなってない技術者も 増えてきているように思い憂慮している。
　我らプログラマは要求分析もするし、仕様が与えられればそれに従ってプログラム を作る。そういう習性が資質として備わっているのだ。 もちろんプログラムにはバグがつきものでデバッグにて大方のそれを取り除く。 大方だ。大方。。
　プログラムを実行させると意図した結果にならないとか、挙動がおかしい.. とう症状はよくある話で、プログラムが完全無欠の前提があるならば 疑いは晴れるのだがそんなこともあるわけもなく、とかくプログラムは疑いをかけれる 恰好の対象となる。

　さてここからが動作を実行した人間の裁量が問われる。つまり「いかにして 問題を解くか」だ。様々な必要な要素があるが、まずはプログラムの仕様を把握して おくことだ。もし、ここのスタート地点で満足できないようならその人は失格だ。 当たりまえだ。例えば橋梁の応力解析に有限要素法のプログラムを作らせておいて、 自分は有限要素法は知らないとか。。 解が予想値から外れるとその計算方法や入力値を確認せず(知らず)に まず「プログラムが変だ! バグだ!」と叫ぶ輩は問題外として扱うべきだ。
そんなヤツはあまりいないと思うが、いたらある種障害をお持ちと考えて優しく接っして あげることが大切だ。

　専門技術の事前知識を持っていると仮定しよう。この場合、予想外の結果が出たとき の問題解決アプローチは前者から少し発展する。「環境の違いはないか?」「以前のバージョン では動いたか?」等様々な推測をし、一つずつ確認していくことだろう。
　私もきっとそうする。そしてその一つ一つの確認事項を一つの命題ととらえて、 推論にて原因を導出することだろう。つまり命題論理やちょっと潜って述語論理を 持ってして解決にあたるのだ。 隠喩としてユークリッドが構築した「公理系(*)」を頭の片隅にでも置くと理解しやすく なると思う。

　いわば公理系にて不具合原因を導出するわけだ。しかしながら、現場でプログラムを動かす人間 の脳が公理系に収まっているかどうかは知らない。分かりやすく言うと、 ある命題の真偽を正しく判定できない人もいるということだ。推論の根底から足をすくわれるような ことだが現場ではよくあることだ。推論が妥当でない公理系ということになる。
　こんな人はもちろん技術者とは呼べないだろうし逆に迷惑な存在となるであろう。 もちろん、問題など解ける人間でもありえない。

　我らプログラマはプログラムに疑いをかける人に対して、まずその人の思考プロセスが 公理系からみて妥当か否かを判断する必要があるこを忘れてはならない。

# もちろん、自分が自信をもってリリースしたプログラムでなければこうは行かない;-P

(*)公理系: 命題(=公理)から出発して論理的な推論のみを用いて新たな命題(=定理)を導出する系

　ソフト開発に限った話ではないが、企業内で開発してきて得たノウハウや設計文書を 残すべきなのは当然だが、全てにおいてそれを実施するのはなかなか難しい。 (私も言えたガラではないのだが..)
　こうして中途半端なまま放置された大切な知識・ノウハウは共有資産としては残らない ことを意味する。時が経ち、改修やら不具合修正のときにまた開発初期と同じ程度の 投資が必要となる。既に一度投資したにもかかわらずだ。
　これを回避する方法はいくつかあるが、現場で最も多く採用されているのは 初期開発の経験者をその作業にあてることだ。ノウハウや設計文書を残さなかった当事者 である。
　そして、あろうことかその当事者は「私しか出来ない業務... 私は選ばれた技術者..」 なんて甚だしい勘違いを抱くことになる。更にまずいことはそれをもてはやしたり する周囲だ。
　もっと情けないことには「○○○のことはあの人に聞け..」とかいう群衆の認知がなされて いくことだ。

　周囲の人は騙されていることに気が付いていない。共有資産として残さなかった当事者 を批判するどころか重宝しているのだ。揃いも揃って騙されているのだ。 「裸の王様」ならぬ「裸の群衆」である。
　共有資産として残さなかった当事者は浅はかな人間であり、自分のことを「女王様」 とでも思っているのである。また裸の群衆も「女王様」と呼ぶのである。

P.S. これは、過去在籍した企業で私が出会った女性に関する実話でもある。。。　あー怖い、ブルブル..

　使いものにならない代名詞と私は思っている。
ソフト業界で生きていこうと思うからこそ「ソフトハウス」に いるわけで、そんな渦中のソフトハウスに雇われ激動する環境に左右されず単なる職業としてしか 労をなさない職業プログラマの前途は明らかに暗い。 だから私は表題の3条件をすべて満足するプログラマを憐憫に思う。 もちろん皮肉だ。
　時代背景が好況であればそれは表に現われないかもしれないが、 世の中そんなに元気ではない。実は私もバブルがはじけた時代、青二才ながら自分に危機感を抱いた ことがある。「今、職がなくなっても食べていけるか?」、「 転職できるのか?」と。 ある会社のある業務をうまくこなしていたとしても、それが多くの 企業や職場でも通用するとは限らない。むしろ通用しない場合が多いだろう。 そんな人間を企業は好き好んで採用したりするわけがない。 ましてや、歳を取っているという理由だけで高給を要求しようとしたらどこも 相手にさえしてくれない。
　使い物にならない例として、「自分が職務上得た知識の上でしか議論できない人間」だ。 限られた知識ユニットしか持ちえておらず、それらの単純な組み合わせで複雑な技術等 を説明しようとする傾向があるからだ。
文法しかり、プログラムの設計しかり。 それに勘違いした「年取っていることの自負心」がいたずらに加速させるわけだ。 そこに巻き込まれた前途あるプログラマの方々は災難だ。
　こういったヤツは家に帰っても本棚すら ないんだろうなぁと思う。定年がゴールと思って、そこまで頑張れば..と思うヤツが この業界に居たら改心させる必要がある。

「年老いたソフトハウスの職業プログラマ」においては「老兵は死す」だ。

　向上心や好奇心がある限りこのような心配はない。つまり3条件のANDは偽に なるからだ。

　世の中にはプログラマをキーパンチャーに近い存在と思っている人間も多いので ないかろうか? SEと名乗る人間が出現して以来、本来はプログラマの職域である部分を SE が分業したに過ぎないと私は思っている。
　持論だが、プログラマは脳をフル稼働させる職業であると思っている。 ものには限度がつきものだが、 XPではそれを8時間/日と言っている。集中した8時間はかなりの疲労を伴うものだ。 疲労はその日のうちに回復させ、翌日にまた万全の体勢で臨むのが定石だが、 なかなか思い通りにならないのが人間の身体というものだ。 とかく疲労を残した翌日には図らずも脳の働きが悪い(笑)
そんな鈍った脳で仕事をすると、通常の8時間のアウトプットを8時間で出せるものではない。 スポーツ選手が疲労を蓄積したまま試合に臨むのと同じようなものだと。スポーツ選手の 場合だとすぐにパフォーマンスに表れるので察しやすいが、プログラマの場合はそう 簡単には察することは難しい(居眠りする人は論外)。8時間でこなせないから＋1時間..なんて ことをすると悪循環に陥ることは明らか。こうならないように我らプログラマは 日々コンディションに気を配る必要がある。
　ちょっと思い出した。「マズローの欲求5段階説」をご存知だろうか。 人はさまざまな欲求をもっていて、それぞれに優先順位がつけられ段階的にそれらを 望むというものだ。その欲求が5段階あるというのだが以下がそれだ。

1. 生理的欲求 (physiological)
2. 安全欲求 (safety)
3. 愛情欲求 (love)
4. 尊厳欲求 (esteem)
5. 自己実現欲求 (self-actualization)

生理的欲求とは生きていくために必要な欲求で例えば食欲や睡眠である。 これが満たされると第2段階の安全欲求を満たそうとするらしい。 感覚的にうなずける説だと思う。
　プログラマが集中して1日8時間を闘うには 第1段階の欲求がはたらくようでは失格だ。よく食べて、よく睡眠をとることは 何をおいてもまず実践しなければならない。

　ソフトウェアはよかれと思っていてもバグの発見によりその信頼性は失われることがある。 徐々にではなく、瞬く間にだ。この様子はまるで脆性材料の破壊過程のように呆気ない。
　そこで脆性破壊理論とソフトウェア開発の関連性を探究してみた。
　脆性破壊理論にはいくつもあるようだが、その中でも有名なのが1920年のGriffithの提案だ。 「Griffithクラック理論」と呼ばれるそれは
　　「初めから存在する小さいクラックによって脆性材料の強度が支配される」
というものだ。ソフトウェア開発用に翻訳すると..
　　「初めかから存在する小さい破壊因子によってソフトウェアの信頼性が支配される」
となるであろう。小さいクラックでもそれほどの影響力があるのだからちょっとでも大きな クラックならその脆弱性は増すばかりだろう。
　脆性材料のクラックは除去することはできない(インマージョンならOKか?..)が、 ソフトウェア開発におけるそれは除去可能である。ソフトウェア開発者はこの可能性を追究するべきである。

　PCの世界で言えば、Windows95が登場してしばらくアプリケーション の流通が細くなった時代があった。多くのDOSプログラマが、OSと協調しながら 動くWindowsプログラムへのパラダイムシフトに時間がかかったからだ。
　その穴を埋めてくれたのがRADツールの存在だ。熱狂的なTurbo Pascalファンを 喚起させたDelphi。数々の制約がありながらもVisual Basicも一役かった。
　その結果産まれてきたのがダイアログ嵐のようなアプリケーションだ。 何をするにしてもダイアログを開いて片づけることになる。確かに便利だが 肝は使いようだ。RADの功績は確かに大きいが、その性質上、精緻に練られた スマートなインターフェイスとパフォーマンスを備えるのは簡単ではない。
　RADはRADが要求されるときに使うものだと私は思う。万能ではない。 最近は考える絶対量が少なくてもそれなりのソフトウェアが作成できるようになった。 だが、そんなものばかり使う人は、そんなものでしか作れないダイアログ嵐のようなものしか 作れなくなってしまうのではと心配だ。
　そこにきて最近、この事態に喝をいれるような書籍が出版された。
　Webでもおなじみの「猫でもわかるWindowsプログラミング」 の書籍版だ。また、PC UNIXの普及で往年のUNIX関連書籍も息を吹き返して出版されている。 なんかうれしく思うのは私だけだろうか..

　上役同士のコミュニケーションがままならないことはよくある。原因は 沢山あるだろう。「嫌い」「プライド」「見栄」とか...。　どんな会社でも 組織のトップに近いほどこの傾向が強いように思う。どんなに小さな会社でもだ。
　だからといって、部下を伝書鳩や間駒に遣ってはならんだろうよ。
挙げ句の果てには策略の尖兵として派兵させれるようでは仕事も出来んよ、全く。 下っ端でありながらも我らプログラマは日々の業務に追われているのである。 些細なことで仕事の邪魔はしないでもらいたいものだ。
　業績悪化に伴い、この傾向は顕著になる。そして淘汰が始まる。
　淘汰とは、肩たたきの契機を狙っている上役もいれば、肩たたかれそうなことも 知らずに日向ぼっこしてる上役もおり、前者が自分に影響のない部下を遣って 後者を舞台から引きずり降ろすことを指す。 　そんな部下となるような変な役回りが来たら、なかなか避けられないものだ。 やれば次も来るだろうし、その次も。。。

　我らプログラマは決して上役の狡知に加担してはならない。

　ソフトウェア業界に限らないと思うが入社して、1年や2年ではなかなか一人前として扱ってもらえない ことが多い。仕方ない側面は確かにある。
　そういうプログラマが例えば1ヶ月労働しても、実績は「1人月」もなく、とかく 「0.5人月」とか「0.7人月」と見られてしまう。現実もその場合が多い。その分、 お給金も少ないのでつい納得しがちである。確かに、そうなのであるが、 それは法定労働時間内での話だ。進捗が悪い、生産性が 悪いので「アイツには1.5倍やってもらえ」とか言う上司がいたら、その会社は 早急に退職した方がよい。いつかツブされてしまう。ま、時間外手当や休日出勤手当を 正当に支払ってくれる会社ならある程度在籍しててもよいのではないかと思うが..。
　とかくそんな会社は払わないか、もしくは払っても最小限で済む工作準備が敷かれているものだ。
　生産性が悪いので労働時間を増やして帳尻を合わせるやり方は、その効果は 全く正反対に作用する　ことを認識して欲しい。
　知的労働にそんな安易な計算で事が済むなら皆億万長者だ。もしくは犯罪者だ。 労働基準法を犯した犯罪者である。
　私が経営者ならば「0.5人月」しか実績の出せないプログラマが居たら、 労働時間の何割かを、教育に当てる。長期的な戦略上の教育だ。スキルがない者に、 過負荷なまでに業務を詰め込んでも、スキルアップなど望めはしない。
　本当にスキルアップが必要なプログラマを抱えていたら、現在は「0.3人月」でもいい。 「将来の1.5人月」に期待する教育をすべきだ。採用した以上は必要十分な教育を施す義務がある のではなかろうか？

　目前の利益にしか目がいかない経営者に限って技術者を育てもしないで使い捨てるんだ。 離職率が高いことも気にしない。寄せては逃げる波とでも思っているのであろうか。
　よいか我ら誇り高きプログラマよ！ 上記のような経営者がもし存在してたら即刻転職する か自立しようではないか。だって我々はソフトウェア工場の単純作業ロボットではないのだから..

日付：2002/03/18
Ｎ〇Ｃ、管理職の職務や報酬を社内で公開

「..管理職の自覚を高める狙いだ。」

だそうだ。本質的か？これが。
薄汚れた虚栄心でも期待しているのだろうか？
それとも偏狭な競争心でも煽るつもりだろうか？

いずれにしても管理職の在るべき姿に近づける策には思えない。
公開すること自体には異論はないが、そのモチーフが全くトンチンカンだ。 私ならこの策には「0点」をつける。

そもそも管理職は何の為に管理するのだろうか。管理そのものに焦点を当てて 考えてみると、答えは簡単だ。単純に企業利益を出すために部下を管理するだけ だ。管理する手法やノウハウは当然ご立派な理論が思想があるだろうがそんなこ とよりも、もっと根幹をなす*何か*が欠けているだけだと思う。
それを補うなり、刺激するなりしなければ何の解決にはならないと思う。
その*何か*とは、自らの利益だ。お金でもいいだろうし、モノでもいい。 とにかく、管理した結果に直結したリターンがなければ、本気で管理なんかしな いだろう。少なくとも私はそうだ。ただの職種＝管理職なら、年季を積んだ人間 でなくとも、それこそ若手で十分だ。
業績直結型でなければ、建設的な改善にはならないと思うが、いかがだろうか。 己の懐を管理する気位があって、始めて管理できるのではないかと思う。
# 調達部品を値切るだけじゃ、アキマセンデェ

　ヒトゲノム解析がどんなに難解なのかさえ私には分かりかねる。
キーワード「バイオインフォマティクス」をYahoo Japan で検索かけたら4500件くらいヒットするほど世の中には認知されているようだ。
　なにやら「生物学」と「情報科学」の融合みないたことをするようだ。 生物学屋さんにはゲノム解析や配列(シークエンス)解析に必要となる道具(ツール)を いくらかは使うことが出来てもそれを構築することはできないので、そこを 情報科学屋さんが、データベースや各種アプリケーションでシステムを構築して、 両者の協力のもとゲノム解析に寄与するらしい。
　だが、正直笑ってしまいそうになった。そんな造語まで作って自分達の畑まで 他人の手を借りる必要があるのだろうか？化学屋さんなら自分で分子構造解析の プログラムくらい作ったことがあるはずだ。機械屋さんや土木・建設屋さんなら 有限要素法や線形計画法などのプログラムも作ったことがあるだろう。
　そこにはあからさまに他人の手を借りて、自分の専門分野ながら不透明な部分を 残す代償を払ってまでも、自らの研究負荷を軽減しようとする甘えた考えは 存在しない。
　情報科学の発展の一因は、そうした自分達に課せられた難題をなんとかして 解決しようとしたその*精神*にあるんじゃないかと思う。
　Perl を作り出した Larry Wall氏も「楽をするための努力なら惜しまない..」 とも言っている。
　努力との引き替えに楽を得る代償はあまりにも大き過ぎる。これは生物学屋及び 情報科学屋双方が負うものである。
# DBメーカーさん、SIベンダさんッ、喉から手が見えてますヨ(笑)

　「15パズル」をご存知だろうか？　私は昔、お祭りの夜店で買った記憶がある。 最近では携帯電話のJavaアプリ等で見かけることもでる。
　15パズルとは、4×4のマス目に15枚のコマを置いて、1つだけ空けて1枚ずつスライド させて遊ぶゲームだ。1から15までの番号が振られてて、一旦好き勝手に移動 させた後に、もとの整列した並びに戻すものだ。
　この15パズル指向を、思いがけず身近に感じてしまった。
　ソフトウェアの開発プロジェクトの要員調整だ。小規模なソフトハウスでは、 業務規模と従業員(プログラマ)と納期がいつも理想的な状況にない傾向が強いと 思う。小人数にパンパンの負荷をかけてやらせる分には会社は文句など言わない。 が、「現在担当なし」を一人でも且つ、一時期でも作ることには異常なまでに 過敏に反応する。その結果、負荷の多いプロジェクトに日雇い労務者のように アサインされることになるのだ。得てして、そんな仕事は身につかないことが多い。
　「出来る・出来ない」は二の次で、まず工数に対する人数合わせの虚勢として 安易な異動を行うことがある。数ヶ月単位ならまだしも、数週間単位で 複数人がそれぞれバラバラに、異動することさえある。現に私もその境遇にあった 時代がある(怒)。
　ま、管理できてない。虚弱体質なと正しい理由はいくつもあるが、やっている ことはまさに「15パズル」そのものだ。
　もともと意識はしていなかったがこれは何か経験したことがあると思った。デジャブだ。
普通に行う15パズル(最初に1〜15まで整列させてからシャッフルして行う) については時間はどうであれ、必ず解ける。数学でも証明されているらしい。
　が、例えば最初の整列時点で「14と15が入れ替わって」いたら、絶対にとけない ことも証明されているらしい。この絶対にとけない15パズルを「14-15パズル」 と言うそうだ。
　小規模ソフトハウスの恐ろしいところは、この「14-15パズル」を解こうと することがあるということだ。
# 空中で入れ替えたらダメよ。

　ソフトウェア開発に携わる人口の何%がコンピュータ・サイエンスを修得して いるのか大きな疑問だ。
　「そんなモン、必要ない」言い分もあろう。だが、我ら崇高なプログラマは 決してソフトウェア開発の本質であり礎でもあるコンピュータ・サイエンスを 欠いてはならない!
　ちょっと思い出して欲しい。C言語をかじり始めたとき「再帰」キーワードを使って翻弄する輩が周りに いなかっただろうか。そんなもん、変な説明するより「漸化式」の一言で終わりだ。
　果たして「オートマトン理論」一つとっても、理解して説明できるソフト ウェア技術者がどれほどいようか、1%も居ないであろう。
Steve McConnellもコンピュータ・サイエンスを修めた技術者の比率が低いことを うったえているし、我が敬愛するP.J.Plaugerもオートマトン理論の必要性を説いている。 　MFCのクラス覚えたり、そのメソッドや属性覚えてサンプルコードのカット& ペーストするのがプログラマじゃねーぞ。大きな間違いだ。
　基本的な「集合と写像」さえおさえてないヤツがどうして満足な論理演算が出来ようものか。 アセンブリ言語から入るプログラマは減ったにしろ、ビット演算もままならない なんてプログラマとは言えないぞ。
　最近見た情けないモノは、とあるメーカーのSDKのヘルプだ。
ほとんどコンピュータ・サイエンスを修めてない人間が集まって作ってるのは 分かってるんだが、国語もできないんだなぁこれが(苦笑)。 かく言う私も国語は苦手なんだが。 とにかく的を射た言葉で表現できてないんだ。だから造語を載せることになる。 読んでる私の方が恥ずかしくなってくる。全く。
　必要な勉強は遡上してでもやらなければならない。

　文系出身だからと言ってプログラミング能力が劣ると思ってはいない。概して。
コンピューターの歴史を紐解けば、そこは科学技術計算や幾多アルゴリズムの実践で プログラムが芽生えてきたことは確かであろう。その時代なら文系プログラマは皆無に 等しいのではなかろうか。
　だが現在のソフトウェアを見渡すと、難解な数学や工学の知識が無くてもできるものが 多い。「論理の組み立て」と、GUIならば「見栄えのための決め事を覚える」ことさえおさえて おけば文系だろうが理系だろうが全然関係ない。だから文系プログラマも大いに活躍 できるのだ。もし「文系だから..」と言って些細なことにコンプレックスを抱いておられる 方がいらっしゃればそれは払拭すべきことだ。
　さて、ちなみに私は理系出身だがプログラマをやっている。職業としては SEだが根は誇り高き(笑)プログラマだ。
　次は理系出身のプログラマに関して言及する。上記に述べたように文系プログラマでは 手におえない分野が存在する。そう、工学分野だ。「フーリエ変換」「プロセス制御」 「ラプラス変換」「有限要素法」「偏微分方程式」「特性方程式」等ちょっと思いつくキーワードを 並べただけでもこれらを工学知識のないプログラマに投げるのは酷である。というか無理だ。 そこを我らは理解しなくてはならない。
　元来プログラミングの本道はこの分野にあるのであろうが、昨今の氾濫で混同しているのでは ないだろうか。だから、大手電気メーカーはこぞってリストラ代替としてIT技術者への 職種転換を行わせるんだ。間違っている。。。と言いたいが、ターゲットが データベースやらWeb関連ならば(やれば)できるだろうから(笑)、言えない。
　最小限の住み分けは必要だ。これが言いたかった。

　自分を少しでも立派に見せたい... 人間の見栄、いや本能だろう。誰にでも少なからず存在するハズだ。
だーが、モノには限度がある。これに関してIT業界でよく聞く常套文句について考察してみた。おそらく、周りに いるんでないかい。以下のようなことをのたまうヤツは。
　「私は３５歳ではもうプログラムは作っていなかった」
何を自慢したいのか感の鈍い私は計りかねた(笑)。どうやら、プログラマからSEに早々に転身したことを自慢したかった らしい。泥臭いプログラマなんぞ卒業して、より上流工程の業務を任された。オレはすごいんだ。。。
以下の文句と同様だ。 　「私はプログラマは短かった」
　でもオイラに言わせると、そいつらはろくなプログラムを作れなかったんだと思ってしまう。優秀なプログラマは お粗末なプログラマの10倍程の生産性があると言われる。そんな「打ち出の小槌」をなんで早々に転向させるものかと 私は思う。
　さて、そんなやつらに限って少し歳を召されて役職が付き、部下を管理するようになって言う常套文句がある。 それは部下に対してではなく、同僚や上司に対する意見として部下にのたまうのである。周囲のレベルを下げて 相対的に自分を上げる論法だ。
　「あの人は作ったことがないから」
　どうやら、これはオレ様はプログラマからのたたき上げでここまで来ていて、末端の作業まで全部熟知しているん だ。だから、下積み生活が少ないあいつらよりは遥かにオレ様の方が優れている。と、言いたいのである。
　上記、2文句をのたまう同一人物が居たらその人は、自己矛盾に陥いて強烈なジレンマに煩悶するか、もしくは 何も考えない野放図なただのおめでたいサラリーマンだ。
　私は後者しか見たことが無い。
　我ら崇高なプログラマは上記のようなことを言う輩を相手にしてはいけない。

　いかん、鬱憤が溜まっているようだ。。。
IT業界で「派遣」と「請負い」の違いはよく話しにでる。〇〇試験とかでもよくでる 題材だけにその区別はしっかりと認識しておく必要がある。内容を知りたければその手の 専門書や試験の対策本などに書かれていることなのでそちらを参照していただきたい。
　私がここで言いたいのは、現場サイドの両者の違いだ！。こんなことは書籍などでは 勉強できない(笑)
　まず、派遣からだ。派遣は、技術者の職務経歴を客先に提出し、スキルを確認した上で、 面接等で決定する。言わば、実績のある仕事しか行わないことを意味する。業務リスクは少ない し、当事者の技術者も助かることであろう。その分、自分の得意分野の守備範囲が 今後のお給金に直接影響する。また、派遣ならまず時間外労働は手当てが支給されるであろう。
　一方、請負って自社に持ち帰って行う業務に関しては、営業段階から大きなリスクを 実ははらんでいる。そのリスクとは当然、現場で働く我々にとってのリスクだ。
　業務請負いの場合は、派遣の場合ほど当事者たちの職務経歴に敏感ではない。むしろ、 そのソフトハウスの業務内容と営業の手腕で受注することがよくある。これが 大きな問題だ。単刀直入に言うと、出来るか出来ないかハッキリしない業務でも取ってくる んだ。それを、社内であまってる技術者に振るんだ(笑)。
　だから週40時間労働で成功するわけがない。仕方なく時間外労働するんだが大方そんな会社は、 裁量労働制という超便利なきまりを適用して内部留保を積むんだ。
　「請負い」に固執する会社は多かれ少なかれ、根底にこのような権謀術数を持っている。そして そんな会社のバランスシートを見ると当然健全な経営と映るのである。
騙されるなよ！我らプログラマ！

　純粋な疑問を抱くときがあるはずだ。例えば今流行のデータベース屋(以下、DB屋)が あるとする。オラ〇ル・マスターだのゴールドだのプラチナだの何人居るかを自慢がてらに 商談に参入するソフトハウスも多かろう。だって、その為の(ベンダーが企図した)ベンダー資格だ。 　ちょっとここで考えて欲しい。例えば、DB屋の会社なら自社の様々なデータ管理はどうやってるの。 自分ところで解決してるんでしょうか。まさか、M$のスプレッドシートなんかでやってたりして。
　自社のソリューションもままならぬ会社がお客のソリューションに貢献できるわけがない。 ERPやる会社が、自社のERPは大手メーカーのERPを導入してたりしたらそれこそ大笑いだ。 どうも、お客の業務で実践して自社のスキルアップを計ろうとする不束なソフトハウスが 多すぎると思う。
　ま、いずれ淘汰されるであろうが。

　特に中途採用者が被ることが多いが、最近ではそうでもなさそうだ。
　入社時に被雇用者が持ち得ていない業務遂行に必要な知識や技術は会社が 教育すべきた(向上心があって自ら勉強する人も当然いるが..)と思う。「履歴書」も 提出し、中途採用者ならば「職務経歴書」も提出して試験に臨む。その時の 持ちうるスキルを公表しているのだ。
　それを認めて採用するのであるから、変な約束(「会社は教えないけど、 自分で全部勉強できるなら採用する」など)をしない限りは社員のスキルは会社の実施した教育 が、入社時以降の積み重ね分となる。そんなこと、当たりまえだ。
　教育には時間もかかるし、費用もかかる。会社としてはどれも大切な要素だ。 だがIT産業にとって教育は、製造業の設備投資に値すると私は思うくらい必要かつ 不可欠である。ケチって教育もしない会社に限って「ウチの社員はアレしかできない」、 とか「もっといろんなこと出来るようにしろ」とか言うのである。
　IT業界の変遷も激しい。それに追従したり先回りして勉強するのは、一般企業の 社員教育よりももっと難しいと思う。そのような必要なるであろう分野への教育方針や 計画も策定できぬ会社に限って先のつぶやきが聞こえてくのだ。
　なんか愚痴そのままだが、本意は、会社の教育などアテにせず自分で勉強する。 会社を利用してスキルアップし、その会社に 魅力や在籍意義がなくなれば転職するなり、自立するなりするべきだと私は思う。

　意欲を失墜させる業務受注はどこにでもあるものだ。責任と権限のバランスが全くとれて ない会社であればそれは大きな悲劇を生むことになる。
　請負いソウトハウスでは客先から仕事を受注しようと必死である。客先企業 側は相見積もりも当然するだろう。例えば、工数4人月の仕事を受注しようと 請負い側は自社基準の4人月工数をそのまま見積書として提出したら、競合他社に 奪われてしまうことを危惧し、例えば3人月で見積もりを出すこともある。 　だーが、それは営業上の問題で「工数は工数として4人月要する事実」が 変更されたわけではない！
　それをそのまま3人月でプロジェクト完遂の予定を立てさせる会社が存在する。 3人月以上の工数を使えば、赤字プロジェクトの烙印を 押され、虐げられる。
　こんな不条理な話は、よくあるのである。 解決策はいくつかあるが、多くは「サービス残業」で賄う負け組みとなるのが、 日本人社会であろう。
　これこそ失敗への始まりである。