郷土博物館とかに置いてあるやつ。
それは古民具や!
家庭用台所洗剤。
それはハミングや!
右手の法則。
それはフレミングや!!
すんません、 元落研なもんで。
…あれって右手と左手とあったけどどっちが何だったかさっぱり忘れたなぁ。

かかりつけの医師に仕事の内容を聞かれ答えたところ、 「 それは競争のための競争になりませんか? 」 と聞き返された。

いままで手作業で行っていた業務にITが導入され、 爆発的に効率が良くなる。
本業に全力投球が可能になる。 本業以外の業務は徹底的に省力化・アウトソーシングが可能になる。
そればかりではない。
ビジネスの時間的な壁はコンピュータの限界まで、 空間的な壁は人間の行けるところまで拡張された。
そして暴走は始まったのだ。

私は以前から歴史の時間に不思議に思っていたことがある。
始めはささいなことである。 暴動だったり、 地方の紛争だったりするものが、 やがて国をあげての戦争になる。
すると戦争は他の地域にも飛び火し、 「 戦争時代 」 が幕を開ける。 日本の戦国時代、 中国の春秋戦国時代、 欧米の百年戦争、 二度の世界大戦など、 数え上げればきりがない。
戦争時代になると、 「 食うか食われるか 」 のレースになる。 そればかりでなく、 時間を追うにつれ、 「 戦争のための戦争 」 の様相を呈しはじめる。 そして、 平和な時代に築いたあらゆる文化を破壊し始める。
そして、 もうにっちもさっちもいかなくなって、 誰もがくたびれてうんざりしはじめる頃に、 英雄が出てきて大統一を成し遂げたり、 停戦協定が結ばれたりする。
すると不思議なことに、 人々は凄まじいエネルギーで復興し、 次の戦争時代に破壊される文化を創造し、 平和を謳歌し始める。
平和が堕落になり、 徐々に蓄積された破壊のエネルギーが堰を切って溢れる時、 また振り出しに戻る。
なぜこんな周期運動になるのだろう。

この現象は戦争だけでなく、 あらゆる分野で見られる。
そして必ず凸凹が繰り返される。
例えば経済を例に挙げれば、 好景気の後には必ず不景気が来る。 当たり前の話だが好景気がずうっと続いたりはしない。
そして、 様々な分野で戦争と同じように加速し、 行き着くところまで行って崩壊する現象が見られる。

そういう予備知識を踏まえて自分の立場を検証してみると、 「 武器商人 」 に例えることができる。

例えば携帯電話を例に挙げると、 メーカーはユーザのニーズに応えるために、 次々と新機種を発表する。
そしてそれが新たなニーズを引き出す。
ユーザの要望に応えるために、 メーカーは短期間での製造・納品を求められる。 そのためITを含め様々な効率化を迫られる。 効率化に失敗すれば、 レースから離脱せざるを得ない。
レースから離脱するまいと、 メーカーは生き残りをかけた設備投資に走る。
まずこれが第一の 「 戦争のための戦争 」 である。
メーカーの厳しい要求に応えるために、 我々は様々なソリューションを提供する。
我々もメーカーの要望に応えられなければCADベンダーの競争から消えていく運命にあるのだ。
これが第二の戦争である。
そしてそれが振り出しに戻ってメーカーのビジネスを加速し、 さらなる加速を促す。 つまるところ鶏と卵の関係になる。

冷静に考えれば分かることなのだが、 これは 「 自分が楽をするために導入したものに振り回されている 」 現象に他ならない。
業務の効率化を目的としてITを導入したのに、 効率が良くなったこと、 あるいは導入により増えてしまった業務ができたことにより以前より就業時間が長くなってしまった人も多いのではないだろうか。
そして、 その諸悪の根元であり、 メーカーの武器である製造ソリューションを提供するのが我々の仕事である。
我々は武器商人だ。 戦争のあるところへのこのこと出かけて行き武器を売りつけ、 戦争が長引くことを祈る。
が、 戦争はいつか終わる。
何でもないことだ。 終わるやいなや店をたたみ、 別の戦争を見つけてそこで店開きをする。

我々は何故こんな不毛な繰り返しを営むのだろう。
生態系のバランスを保つために遺伝子の中に埋め込まれたプログラムなのだと言えば簡単なことだが、 競争の行き着くところまで行った果てには何があるのだろう。
まるで冷戦時代の核武装レースを見るようだ。
いずれ軍縮が行われるのだろうか。
その時我々はどこに活路を見出すのだろうか。
レースが行き着くところまで行き着いたら、 みんな考え始めるのだろう。
暴走は始まったばかりだ。 私もまた、 暴走しているレミングの一匹である。
最後まで暴走して全滅するのか、 群れ全体で暴走を止めるのか、 目覚めたものだけが立ち止まるのか、 はたまたレミングであることそのものをやめるのか。
全ては、 終わってみてからでないと分からない。

お前だけ暴走して死んじまえって? その可能性も大だなぁ。

父の遺品の中から1眼レフを発掘した。
ミノルタSR-T101である。
これまでコンパクトカメラしか使っていなかった私が夢中になったのは言うまでもない。
が、 これまでコンパクトカメラしか使っていなかっただけに、 どこを押したらどうなるのかすら分からない。

すると勉強が始まる。
本を買ったり、 カメラ屋で聞いたりする。

プログラミングもそうだけれど、 勉強している時が一番楽しい。
新しい言語や新しい技術を勉強する時も楽しいけれど、 何にも知らない時にゼロから勉強する時が今思えば一番楽しかった。
プログラミングにおいてその時は既に過去のものとなり、 もう二度と訪れない。
だから別のものでゼロから勉強する感動が味わえるのが楽しくて仕方がないのだ。

それにしても暇だ。
一つのプロジェクトが終わった。
これだけ一つのプロジェクトに心身共に入れ込んだのは初めてのことだ。
しばらくコードは見たくない気分だ。
体重も3kg減った。 歩くのさえ辛い。

しばらくはコードすら見たくない気分だが、 どうせまた暫くすると何かしたくなるはずだ。
そう考えて暇なうちにやっておきたいことを挙げると結構な量になる。
COM/ATL、 デザインパターン、 Java…。
一方で製造業に対する知識、 CADに対する知識もまだまだ習得しなければならない。

子供の頃、 大人になったら勉強をしなくてよくなるのだと思っていた。
大人になってみるとそんなことはなかった。
が、 勉強は子供の頃より楽しくなった。
製造業のこと、 プログラミングのこと、 チームで働くということ、 様々なことが雨のように私に降り注いでくる。
それらは乾いた大地に水が吸い込まれるように私の中に入ってくる。

勤勉な日本のサラリーマンに 「 いやぁ、 仕事が楽しくて…。 仕事が趣味なのか、 趣味が仕事なのか分からないくらい。 楽しんでやっていて、 お金は後からついてくる、 って感じかな 」 と言ったら、 「 仕事と趣味を同列に考えているような奴と話すことなど何もない! 」 と言われてしまったことがあります。
言われてもまあ無理もないか、 と思いますが、 仕事なんてその程度に捉えてていいと思いますね。 もちろん業務としてちゃんとこなしての上ですよ。
動物の子は遊んでいるうちに生きていく技術を学びます。
人間も同じでしょう。 人間だけが知能のある優秀な生き物だなんて思うのは変です。
遊びの延長に生存技術の習得があります。 また、 時には生存技術を使って遊んでもいいと思います。
「 業務に関係のあることは何がなんでも業務時間内にやらなければならない 」 なんて言っていたらいい仕事はできないんじゃないかと思います。
ちなみに私はいいロジックは大抵風呂の中で思いつきますが、 業務時間中にやらなければならないとすると会社で風呂に入らなければいけなくなりますね。

とにかく今は、 子供の頃の仮説が否定されたことを祝ってカメラの勉強中である。
今日撮った我が家の紫陽花はきれいに撮れているかなぁ。

お前は勉強するだけ無駄だって? 頭悪いもんなぁ。

紫陽花はまあまあちゃんと撮れていた。
ちょっと白く抜け気味だった。 露出はやはり難しい。
絞りはなるたけ開けるようにしてみた。 絞りを開放するとシャッタースピードを上げられるが、 その代償としてほぼ一点にしか焦点が合わなくなる。
もちろん、 被写体を風景から切り取るように映すためにわざと遠景をぼかす常套手段だが、 一点にしか焦点が合わないというのはそれだけピンぼけ写真になる可能性が高くなるわけで、 被写体と向かう瞬間はさながら一対一の勝負のよう。
「 撮れるもんなら撮ってみろ 」 「 おう、 バッチリ撮ってやるぜ! 」 ってな感じ。
今日は花瓶の百合。 黒の背広をバックに白が生えるように撮った(つもり)。
それにしても花の接写写真ばっかり撮ってるとマクロレンズが欲しくなるなぁ。 50mmだと限界が…。

CAD屋のくせにようやく最近になって機械設計の勉強を始めた。
やらなきゃなぁとずっと思っていたのだけれど、 デスマーチになったのでそれどころではなくなってしまったのだ。
やっと暇になったので勉強する次第だ。

製造業には情報産業にとって見習うべきことがたくさんある。
産業としては大先輩であるから当然といえば当然なのだが、 単に学ぶことが多いだけではない。
製造業のセオリーを通じて、 ソフトを作るという業務はモノ作りの一端であることをまざまざと見せつけられる。
私は言語学系の人間で、 プログラミングをどうしても書き物の延長線上に捉えてしまう。
もちろんプログラミング言語を通じてプログラミングを捉える視点も大切だが、 それだけでは駄目だ。 プログラミングは立派なモノ作りなのだ。

設計手法にしても、 製造業はずっとずっと先を走っている。
我々はプログラミングをする時、 ボトムアップに設計するのが良いと教え込まれている。
もちろん概要設計の段階、 大枠を決める段階まではトップダウンだが、 詳細設計段階でトップダウンに設計したらとんでもないものが出来上がるのは目に見えている。
だからまず最初に数行からなる小さなモジュールを作り、 それを組み合わせて動くモジュールを作り、 という具合で下から組み上げていって巨大なモジュールができあがる。

機械設計でも昔はそうだったそうだ。 熟練工が頭の中で機械を組み上げ、 それからおもむろに図面を引いていたようだ。
が、 機械にデザインが求められ、 3次元CADが出現し、 設計は一気にトップダウンへと変化した。

ご承知のとおり現在の工業製品の殆どはデザインを非常に重視して設計される。
スピードも求められる。
また、じっくり設計を検討してから発注というわけにはいかず、 途中で設計変更が命じられることもある。

そんな厳しい状況においてボトムアップで設計していたらいつまでたっても製品が出来上がらないことになる。
そこで、 部品が組み上がった絵を見ながらトップダウンで設計すればメーカーの厳しい要望にも応えられる、 というのが現在の製造業のパラダイムのようだ。
要約してしまうと、 昔の熟練工が頭の中でやっていたことをCADがやってくれるようになってしまったのだ。

が、 プログラミングにもまさに今同じパラダイムシフトが求められているのは賢明な読者諸氏ならお見通しだろう。
特にボトムアップ設計のできないプログラマの増加は深刻だ。
何としてでも製造業を見習わねばならない。

ちなみに製造業において設計することをモデリングと言うが、 我々の業界でもデザインパターンやUMLなどの設計手法関連の用語としてモデリングという単語が定着してきたのは偶然の一致ではないだろう。
モデリングツールも徐々に出てきたようだが、 まだまだ実用レベルとは思えない。 かたや製造業ではトップダウンアプローチが徐々に浸透しつつある。
やはり製造業は大先輩である。 学ぶべきことは多い。

と、 勉強していたら新しい仕事を言い付かった。
貧乏暇なしってこのことか?

暇でも貧乏なくせにって? そうだけどさ。

先週の百合は絞りを開けすぎてピンぼけ気味だった。 百合の花って花びらの先端から根元までが長いから、 おしべのあたりに焦点を合わせると花びらの先端はぼけてしまう。 ぬかった。
今日の被写体は紫がかったピンクのトルコ桔梗。 開きかけの花びらのねじれ具合が美しい。

皆さん選挙行かれました? 元落研の私としては 「 無所属の会 」 に座布団一枚、 かな。 「 クレタ島人のパラドックス 」 みたいで(爆)。 あっ、 選挙は真面目に投票しましたよ。

先日、 東京ビッグサイトで 「 設計・製造ソリューション展 」 が開催されました。
私は行けなかったのですが、 行った人の話をいろいろと耳にしました。
製造業向けに限らず、 この手のフェアを見るといつも 「 それは本当にユーザの問題をきちんと解決しているのだろうか? 」 と疑問に思ってしまいます。 もしかしてベンダーの自己満足に終わっていないだろうか、 と。

我々はソフト屋です。
だからどうしてもユーザが抱えている問題を、 ソフトを作ったり、 システムを導入したりすることによって解決しようとしがちです。
しかし、 本当のソリューションとはそんなものではないはずです。

例えば、 紙ベースで業務を行っているところで何か問題があったとします。
本来なら、 その会社の業務を洗い出して、 紙ベースの運用形態にちょっと手を入れて解決する方法、 ちょっとした道具を導入することで解決する方法、 業務形態を抜本的に見直してシステム導入する方法、 など様々なソリューション形態があると思うのですが、 ソフト屋さんはシステムを導入しないとお金にならないのでどうしてもシステム導入の方へ話を持っていってしまいます。
でも、 それはソリューションでもコンサルティングでも何でもなくて、 ただのシステム導入です。

ちょっと話が横道に逸れますが、 特定ERPパッケージ系のSIベンダーなんかで、 システム導入スタッフのことを 「 コンサルタント 」 と称していますが、 彼らはそのパッケージを導入するアドバイスしかしないわけで、 果たしてコンサルタントと呼んでいいのだろうかと思っているのは私だけでしょうかね。 ま、 こんなのは言葉の定義の問題ですけど。

極端な話 「 凄まじいスピードで事務処理をしてくれる事務員 」 を派遣する方が安く解決するのであれば、 無理にシステムを導入する必要なんかないわけで、 どうしても人手では間に合わないからソフト屋さんがソフトを作るわけです。
そこのところを履き違えて、 ソフトを作って売ることが目的になってしまうと、 ユーザは少しも欲しくない機能満載のソフトをつかまされることになります。

これまでのソフトハウスというのはかなり技術的なところで勝負できていたと思います。 もちろん販売戦略などもありますが、 それは会社である以上必要な技術ですからこの際置いておきます。
ところがこれからは 「 ウチのソフトは凄いですよ 」 だけでは済まない。
「 ウチのコンサルタントは凄いですよ 」 になる。
が、 プログラミングの教科書は星の数ほどあるのに (それでもソフトウェア工学の本などはプログラミング言語の本に比べて非常に少ないと思いませんか)、 コンサルティングの教科書は殆ど見当たらない。
日本においてまともなプログラミング技術の書籍が少ないのは、 プログラミング技術が現場で軽視されてきたことが大きいと思う。
コンサルティング技術についての書籍が少ないのも、 やはり現場で、 目に見えない技術が軽視されていることによるものではなかろうか。
今後コンサルティング技術の有無がソフトハウスの生死を決める可能性は高い。 ソフトハウスの経営者たちはどのようにお考えなのだろうか。

経営者の心配よりてめえの心配しろって? 心配しようにも首の皮一枚が切れるか切れないかだけの話だし(爆)。

人に写真を見せたら 「 何を撮りたいのか分からん 」 と言われた。 しくしく。 今週の百合で挽回しよう。

プログラマといえど会社に勤務する限りは会社員である。
日々会社員として会社を見つめているが、 会社というのは難しい。
営利団体であるからには金を稼がなければいけない。
その一方で顧客の信頼を勝ち取らねばならない。

この二つの命題は互いに相反するものである。
矛盾する二つの命題の解を求めねばならない。
そしてこの命題には絶対の解がない。
最適解をどこに求めるかでその会社が決まる。

営利を追求しすぎると金の亡者になりさがる。
信頼を追求しすぎるとボランティアになってしまう。
どちらか一方にあまりにも偏ってしまえばそれはもう会社ではない。

個人企業を営んでいた父の血が流れているからだろう。
今の私はどちらでもあり、 どちらでもない。
会社という生き物のあり方について、 経営者の言葉を聞くたびに、 顧客の声を聞くたびに、 最適解を求めて日々苦悩する。

誰かが選挙の時に言っていた。
二兎は追わねばならない。
それは会社にもいえることだろう。
ただ同時に二兎を追えば一兎も得ない。
その時その時、 軸足をかえながら波乗りをするゲームである。
バランスを崩せば海に転落する。
さて目の前に迫る波はビッグウェンズデーか津波か。

お前はとっとと海に落ちろって? その前にサーフボードに乗れないんだよ。

ここに対照的な二つの企業がある。
一夜にして顧客の信頼を勝ち得た者と、 一夜にして顧客の信頼を失った者。
「 真実は小説より奇なり 」 とは詩人バイロンの言葉だが、 ニセ娘に言わせれば、 「 真実は小説より小説らしい 」 とでもなるだろうか。

何でもそうだが、 「 創造 」 には不断の努力と永い永い年月を要する。
にもかかわらず 「 破壊 」 は非常に短い時間で実行できる。
相手があればなおさらのことだ。
個人間でさえ、 確固たる信頼関係を築くには時間が必要だ。
企業と顧客の関係は、 一見1:Nのように見えて、 実はN:Nの関係にある。
N:Nであるということは信頼関係の構築には個人間よりはるかに永い年月を要するということだ。
にもかかわらず崩壊は一瞬だ。
たった一人の社員が顧客の信頼を失うことは、 社員全体が顧客の信頼を失うことを意味する。
企業と顧客の信頼関係は、 そんな、 まるでトランプカードのピラミッドのようなものなのだ。

昔から、 企業は永い時間をかけて顧客の信頼を勝ち得てきた。
が、 このところ様々な企業が叫ぶ 「 ナントカビジネス 」 だとか、 「 ナントカ革命 」 だとかを見ていると、 企業というものはとにかく儲ければよい、 利潤が出なくなれば倒産するなり事業から撤退するなりすればよいのだ、 という考え方が強いように思われる。
合理的であることは良いことだ。
だが非合理的なものと一緒に顧客の信頼まで捨ててしまってはいけない。
儲からないと分かれば明日にでも撤退するかもしれない企業を、 信じるわけにはいかない。
こちらもビジネスと割り切る覚悟が必要だ。
確かに今後、 顧客にもリスクマネジメントは必要とされるだろう。
が、 商売の基本は地道に顧客との信頼関係を築くことである。
それを忘れて流行のビジネスモデルに飛びつき、 一時期利潤をあげても、 長期的な結果として顧客の信頼を失うようなことになれば、 企業は金では買えぬものを失ったことになるのではなかろうか。

お前が一番信用ならないって? 口だけで生きてるしねぇ。

土曜日に遊びすぎたせいか、 日曜日久々にごろ寝をした。
実家に帰るといろいろ命じられるので一日中寝ているわけにもいかないが、 一人暮らしの時には次の週来ていく服を洗濯して、 後は食事の時だけ起きてきて食べたら寝るという凄まじいことをしていたことがある。
夜寝て、 昼もちゃんとした昼寝をして、 なおかつまた夜ちゃんと寝られるほど疲れるなんて一年のうちに何度もあることではないが、 しかも歳を取るごとに長時間睡眠に耐えられなくなるものだが、 でもやはり生きているとそんな日もめぐってくるのである。
というわけで久々に自分でも驚くほどよく寝た。
なんでこんなくだらないことを延々と書いているかというと、 今週はネタらしいネタがない(笑) 。
あることはあるのだけれど、 コラムにまとめられるほど煮詰まってなくて、 なおかつごろ寝をしてしまったのでまともなコラムに出来なかったのだ。
ということで今日は 「 休むこと 」 をテーマに、 普段よりさらに輪をかけてまとまりのないコラムをお送りしよう。

この仕事は時期によって稼働率にかなりむらがあるのは既にご承知のとおり。
時間的な点で朝何時に出社して何時に退社するかが不定なのはもちろんなのだが、 本人のモチベーションも時期によってかなりむらがある。
どんな仕事でもそうだが、 プロジェクトの真っ最中にはやる気満々、 残業も休日出勤も平気である。
ところが一旦プロジェクトが終わってしまうとホワイトアウトしてしまって、 ぼけーっとして時間を過ごす時期が来る。
もちろん勉強するとか、 次の仕事に向けていろいろとやることはあるけれど、 一旦炉の火が落ちてしまうと次に火が入るまでは無理に燃やさない性質なので、 私は気が済むまでぼやーんとすることにしている。

ぐうたらな、 と思われるかもしれないが (実際ぐうたらなのだが)、 全力を出しきってしまった後というのは暫くコードを見る気にもなれない。
夢中で働いた後は夢中で休むのがいいよ、 などと勝手に決め込んでいる。
気分がのっていないのに無理に 「 勉強しなくちゃ 」 なんて思うとかえって逆効果だ。
「 勉強するふりをする時間 」 だけが過ぎていって、 何も残らない。
ということで暫くはプログラミングのことなんて忘れて、 「 製造業とは 」 とか、 「 ソリューションとは 」 といったぼやーんとしたテーマについて考えるともなく考えていた。

でもそれもぼんやり考えるだけで、 具体的に 「 こんなシステムがあればいいのでは 」 とか、 「 実際にプロトタイプを作ってみよう 」 というところにはいかない。
自分が容易に思いつくことは他人も容易に思いつくことであり、 それを具体化したところで既に世の中にあるというのがオチである。
本当に画期的なソリューションを提供したいのであれば、 誰もが見落としているところにまずスポットを当てなければいけないのではないか?
そんなことを、 ぼんやりと考えていたのである。

しかし悲しいかな私には製造業の知識が皆無である。
それで製図から勉強を開始した。
まともなアイデアが出てくるのは更に後になるだろう。
アイデアというのは勉強したらそれに比例して質の良いものが閃くとか、 たくさん出てくるという性質のものではない。
時にはあせらず寝て待つことも必要なのだ。
さあ、 夜になったのでまた寝よう(爆)。
目が覚めたら、 何か思いつくかもしれない。

起きてこなくていいって? 畳の上で死ねるほど善人じゃないと思うなぁ。

ずーっと前、 まんだらけに行こうとして、 店員がコスプレしているという噂を聞いて断念したことが…。

21日はお休みにして4連休にしてしまいました。 でもなぜかプライベート充実しまくりで、 読もうと思っていた本が全然片付いていない(汗)。
本といえば私はなぜか本が好きで、 ちょっといいなと思った本はほいと買ってしまう性質です。
家の本棚はもちろん、 会社の本棚にまでプログラミング・設計・プロジェクト管理などの本が増殖しています。
お陰で会社の自席は 「 図書館 」 なるあだ名を頂戴する始末です。

そんなに本を買ってちゃんと読んでいるのかという鋭いツッコミが予想されますが、 答えは見事に 「 ノー 」 です。
読み物系の本であれば通読しますが、 専門書は必要な時に必要なところを拾い読みする程度で、 通読する本は殆どありません。
で拾い読みした後の本を本棚に置いておくと誰かが借りに来て私の知らないところを読んでいたりします。
折角買った本ですから、 みんなの役に立てば元が取れるかなぁなどと、 楽観していたりします。

私が本を自腹で買うようになったのは前の会社で転職を意識し始めた頃でした。
折角会社に本を買ってもらっても、 転職してしまったらその本は読めません。
また、 その本が運良く転職先にあるとは限りません。
というわけで、 私は本は商売道具として、 自腹で買うことにしました。
Win32APIリファレンスなんかを買ってるあたりは良かったのですが、 買う本の間口も奥行きも広くなって、 上司から 「 これという本は大概揃ってるなぁ 」 とまで言われる図書館にまで成長してしまいました。

会社に持っていく本はリファレンスとして見たい時に引っ張り出す必要のある本と、 あれば他の人にも便利だろうというものを選んでいます。 また、 リクエストがあれば自宅から持ってきます。
で、 「 Ada72さーん、 こんな本ないっすか〜 」 と言われると速攻貸してあげて、 「 この本、 いいっすね〜 」 などと言われようものなら得意になっていたり(笑)。

なんでそんなことをするのかと言うと、 サラリーマンプログラマというのは会社が何でもお膳立てしてくれるのに慣れてしまっていて、 商売道具であるところの本ですら会社に買ってもらう癖がついてしまっています。
会社にとって必要な本は会社で買って皆で共有すべきですが、 自腹で商売道具を買うということも大切なことではないかと思うのです。
プログラミング書籍というのは結構高くて購入をためらってしまいますが、 一生これで食っていくのだと思えば安い投資です。 折角高いお金を払って買った書籍の内容が一年後には古くなっているのが痛いですが(笑)。

私が自分に対して時々行うチェックポイントとして、 「 自分はこの会社の企業内企業か 」 というのがあります。
「 独立できるか 」 という質問に置き換えてもいいと思います。
つまり自分の会社に 「 Ada72株式会社代表取締役社長 」 として取り引きに来ているんだと思って、 ウチの会社はこの仕事内容でちゃんと自分と取り引きしてくれるだろうか? という質問を自分にしてみるのです。
その時、 「 この点については取り引きに応じてくれないだろう 」 と思う点があれば補わなければなりません。
ところが自分は社長ですから、 自分の能力を高めるための投資も、 自分で行わなければいけません。
そこで、 本に限らず自腹で投資する覚悟を決めるのです。
逆にいうと、 足りないところが多すぎるから図書館になったのでしょう(爆)。

どのみち投資効果ゼロなんだからいい加減諦めたらどうかって? 「 Ada72漬物店 」 は大繁盛だからいいのだ!

生まれてはじめて 「 ひとりでおつかい 」 をしました。
いや、 何のことはない、 初めて一人で車を運転して買い物に出かけただけなんですけれど。
これまでずっと運転経験のある人に同乗してもらっていたのですが、 今日やっと一人で乗ったのでした。
しかも仏間に生ける花を買いに行くというおつかい。
なんか情けないなぁ(笑)。

誰でも一度ぐらいは 「 自分はこの仕事に向いていないのではないか 」 と思ったことがあるだろう。
一度も思ったことがないならばそれは天職だろう。
私も時々自信をなくして落ち込んでしまうのだが、 そんな時は大学時代の恩師の言葉を思い出すことにしている。
彼はその分野では第一人者といっていい研究者なのだが、 「 俺はこの研究には向いていないんじゃないか 」 と思うこともあれば、 天職だと思うこともあるという。
その道の第一人者でさえ私と同じことを悩んでいるのだから、 第一人者どころか糞プログラマの私が悩んでも当然なのだ!
ということでつまらないことで悩むのはやめました(笑)。

プログラミング全体について向き不向きを悩んでも仕方がないし悩むのはやめたのですが、 個々の技能に関しては 「 これはどうも苦手だなぁ 」 というのはあります。
実は他人のプログラムのデバッグが非常に苦手なのです。
まぁこれが得意だと胸を張って言えたら凄いですけどね。
元々の性格がお人好しというか、 性善説というか、 他人の言動を 「 へぇ〜そうなんですかー 」 で流してしまうというか、 そんなのらりくらりとしたところがたたって、 他人のソースを見ても 「 んっ、 これは変ではないのか!? 」 と思いつつも 「 でも動いてるしなぁ…なんでこんな変なロジックなんだろう… 」 と通り過ぎてしまうことがあります。
結局散々デバッグして最初に変だと思ったところが元凶だったりすると、 「 私はデバッグには向いていないのだろうか 」 などと思ってしまうのです。
#言い訳じみてるけど、 普通のロジックで変なのはまあともかく、 ウィンドウメッセージが複雑に絡んでくるとタイミングによっては再現しないバグになったりして結構厄介だったりするのです(涙)。

これには思い当たる理由があります。
社会人になってからゼロからコードを書き起こすプロジェクトにばかり突っ込まれていたため、 他人のコードをデバッグした経験が3年もの間にわたってなかったのです。
しかし物事は悪い面ばかりでもなく、 新規プロジェクト、 それも少しデスマーチの気配のあるプロジェクトが得意だったりして。
なんのことはない、 デスマーチが嫌で飛び出したのに、 どんなに窮屈でもゆりかごが恋しいようだ(爆)。

向き不向きというのは誰にでもあって、 数値演算をやらせたら右に出る者はない代わりにOSまわりはからっきしとか、 ネットワーク系は凄いけれどその他はそれほどでもとか。
様々な得意分野を持つ人が寄り集まっているのだから、 一人一人はスーパーマンでなくても、 全体として良いものが作れればいい。

集まって仕事をすることには意味がある。
一匹狼のスーパープログラマがいて凄いソフトを作ればそれでいいじゃないかと思う向きもあるかもしれないが、 一人で出来ることなんて、 それがたとえスーパーマンのなせる技であってもたかが知れている。
大勢のプログラマ、 設計者、 テスター、 カスタマサポート、 営業などのスタッフが集まってソフトハウスは動く。
その時、 スタッフの全てがスーパーマンであることなどありえない。
スーパーマンを集める努力、 各々がスーパーマンになる努力をしつつも、 お互いの足りない部分をどのように補うか。
それが集団の善し悪しを決める。

私は 「 割れ鍋に閉じ蓋 」 という言葉が大変好きだ。
集団をうまく動かすことは、 割れ鍋さんに閉じ蓋さんを見つけてあげることでもあろう。
ちなみに上司に 「 理想の配偶者は割れ鍋に閉じ蓋みたいな人なんですよ 」 と言ったら、 「 君は縁がもっと複雑に欠けているから、 ピッタリ合う人はなかなかいないだろうねぇ 」 と言われた…。

粉々に割れてしまえって? 安物の陶器は欠けやすいが割れにくい。

仕事の能力というのは評価が難しい。
TOEIC何点だから英語ができますね、 というのとはわけが違う。

私がこの世界に足を踏み入れた時、 「 最初は機械が使えることを面白いと思うでしょう。 でも徐々に人が使えることが面白いと思うようになるでしょう 」 というようなことを言われたように記憶しています。
その時は聞いてもピンと来なかったのですが、 さすがに社会人5年目にしてじわーっと胸に刺さってきました。
まだまだ使われる立場を続けるだろうし、 人を使えるほどの度量もないのだけれど、 いずれは人と渡り合って仕事をしてみたい。 なんてね。

昔は一匹狼みたいなのに憧れていたんですよね。
人付き合いが非常に苦手だったためにこの仕事を選んだ節もあって、 人付き合いはサッパリなんだけどプログラミングは凄い、 みたいな人になろうと思っていました。
しかし5年も経つうちに少しずつ考え方が変わってきたのは事実です。
もちろん、 今でも生涯スーパープログラマというのも憧れていますが。

話を元に戻すと、 人を使うことが上手いことと、 プログラミングが上手いことは別次元の能力です。
しかし日本のソフトハウスではなぜかプログラマよりSEの方が能力が高いと思われているようです。
確かにプログラマとして非常に優れている人がSEになるケースは多いですが、 そうではないケース、 つまりプログラマとしては使えない、 あるいはプログラミングより折衝の能力の方が高いからSEになるケースも多いのも事実です。
前者は明らかに高い評価を得られるでしょうが、 後者は必ずしもプログラマより優れているということにはならないと思うんですね。

そもそもSEとプログラマを比較することが変なのです。
SEとプログラマはそれぞれ別の別の能力を備える専門職であり、 SEはSE同志、 プログラマはプログラマ同志で能力の比較をすることは出来ますが、 SEとプログラマは専門が違うのだから能力の比較はできないはずなのです。
なぜSEとプログラマという専門を異にする技術者を比較してしまうのかを考えてみると、 日本の会社の体制が影を落としているのではないかと思われます。
平社員を何年かやったら主任、 主任を何年かやったら主査、 主査を何年かやったら…という流れをそのままソフトウェア開発プロジェクトに持ってきてしまったのです。
ところがソフトウェア開発プロジェクトというのはそんな単純なピラミッド構造にはならなくて、 本来様々な専門分野を持った専門家の集合体として機能するものなのです。
これをピラミッド構造の中に押し込むと、 「 くっそーあのSE、 コード一行も書けないくせに偉そうに。 しかも無茶苦茶な仕様起こしてくるよなー。 必ず一回はリジェクトされるんだから俺が書いた方が早いよ。 なのにあいつの方が評価高いってどういうことだい 」 「 得意先にこの仕様では難しいですよ、 なんて俺が謝りに行ってやってるからメシが食えてるってのにあいつらよく俺の仕様にケチつけるよな。 SEがプログラマより偉いわけじゃないって、 ふざけるな 」 なんてことに。

どっちのシステムが優れているというわけではありませんが、 会社のシステムを考える方には、 業種が違えばシステムが違って当たり前、 他の業種と同じでなくてもいいじゃない、 ぐらいに思ってもらえればいいなぁ、 などと思うのです。

話が二点三転するのですが、 再度私のエピソードに戻ると、 見事に日本的会社システムの中でうまいように騙されてしまっていることが見て取れます(笑)。
これもいろいろと悩んだ結果で、 日々 「 プログラマのくせに! 」 とSEから言われつづけて少々卑屈になった時期もあったりして。
これをいい傾向と取るのか、 悪い傾向と取るのかは読者の皆さんにお任せします。

他のプログラマとも比較にならないんだからお呼びでないって? それもそうだ。