第25話 思考回路のメンテナンス

ワークスタイル

» 2011/04/08

　最近は暖かくなり、出かけるにも良い季節になりましたね。首都圏の方では電力問題も一段落したようですが、これから夏に向かってまた問題になりそうです。私の方は毎年恒例の花粉症です。去年は涙が止まらなくて苦労しましたが、今年は喉が痛いです。薬で何とか収まっていますが、鼻の方はあきらめてマスクしてます。

　さて、人間40年以上生きていると考え方がある程度固定化されてしまいます。ようするにあまり今の風潮に合わないのです。だからこそ「俺たちの若い頃は」とか「今時の若い者の考えは良くわからん」とか言ってしまいます。今、10代、20代前半の若い人もいずれ40代を過ぎた時に大半の人は分かると思います。私もそうでしたから。

　そういうことの比喩的表現として「頭が硬くなる」とよく言います。自分なりの価値観ができてしまうために、なかなか他の考え方が受け入れられなくなるんですが、特に仕事に関して普通はある程度経験してきた自負もプライドもあるため、気が付いたら部下や後輩に頭ごなしに押し付けてしまうこともしばしばあります。これが上手にできると「リーダーシップがある」と周りは評価しますし、下手だと「いばりくさって」と言われてしまいます。

　私も40歳を過ぎ、エンジニア歴も20年を超えています。「プログラマ35歳定年説」ではないのですが、私の同期でも仕事でプログラムを作る連中はあまりいません。せいぜい修正したりツールを作る程度でしょうか。管理職になった連中も多いのでもうそういう歳になったのだと実感します。

　そうは言っても、日進月歩の激しいこの業界、立場は別にしてそれなりに新しいことにもチャレンジして果敢に「攻める」ことをしないとおいて行かれるのは年齢や立場に関係ありません。おっさん年齢の人は意識しないとダメですし、若い人もぼーっとしているとすぐに40代になってしまいます。「光陰矢のごとし」とは良く言ったものです。

　そのためには時々自分の「思考回路」をメンテナンスする必要があると私は考えています。年齢が上がれば上がるほど意識してやる必要があるので、最近あんまり考えていない（惰性で行動している、という意味で）と思われる方はたまにはどうでしょうか？ 参考になるかはわかりませんが、少し私の例を紹介します。あまり真面目に考えずに、少し気楽に考えるのがコツだと思っています。

■好奇心

　私の場合ですが、年々衰えていくことがなんとなく実感できるのが好奇心と視力です。私はこの仕事が長いですが、視力はずっと1.5とかなり良い方でした。でも、最近はさすがに「老眼」気味です。電車とかで携帯をいじってふっと外の景色に目をやってもなかなか焦点が合いません。細かい字もちょっと離さないと厳しくなってきました。

　好奇心は新しいことになかなかときめかなくなったというか、何となく気乗りしなくなってきているのを実感します。一言で言えば「面倒」になっているんでしょうね。そういう人も少なからずいると思います。

　ですから、新しいものが出たら（出そうになったら）一通りどんなものかだけなるべくチェックするようにしています。

　ちょっと前ですが、「ニンテンドー3DS」が発売されました。やっぱり裸眼で3Dってどんなもんやろ？みたいな想像から食指が動いたのですが、取りあえず購入してしまいました（嫁さんに内緒で）でも、先ほど書いた視力の衰えも相まって、3Dゲームがかなり目の負担になる感じがしました。結局、3Dスイッチをオフにしていることが多いという、ちょっとトホホな結果となってしまいました。でも、設定画面を3Dにしているとなんだか新しいユーザーインターフェイスみたいでこっちは非常にお気に入りです（笑）。

　ちなみに後日、嫁さんに見つかってしっかりお説教されました。

■物事の見方

　よく、年寄りは「頑固」だ、と言われます。本人にその意識があるかは分かりませんが、これって知らず知らずのうちに自分もそうなっているのでは？ と感じることがあります。ですから私はどんな物事でもなるべく一方からだけではなく、両方の立場から考えるようにしています。

　携帯やスマートフォンを含めて最近はネットを利用する人がかなり多いからか、報道メディアもネットを意識しています。そのため、情報発信の仕方によっては世論がかなり一方的になることが多々あります。

　ブログなどの炎上や今回の震災、政局など。個人的には「そこまで書かんでも」という事柄が結構あるのですが、選挙の結果など見ると情報発信側の事情としてはそうもいかないんでしょうね、きっと。

　メールの返信も遅いと催促されることがありますが、世の中総じて「短気」になっているように感じます。物事にはすぐに結果が出ることとそれなりに積み重ねてから結果が出ることの2つがあります。何でもかんでも前者のように捉えてしまうのは個人的には不幸だと感じます。仕事でもそうですが、すぐに「OK」「NG」では何も解決しないように思います。

　人間は自分が基準であり中心です。それだけにこだわると「自己中」なんて言われますが、お客様だって開発メンバーだってそれぞれの立場と考え方があります。自分の考えと経験だけを押し付けてしまい、それに合わないと「ダメ」ではあまりに了見が狭すぎます。どんなことでも相手の意見を聞いて、相手の立場に立った上で自分なりにどうすれば一番良いかを考えることが「柔軟な思考」の第一歩だと思っています。

　それでも対立する時はお互い言いたいことを言うことも時には必要です。人間、言いたいことを言い尽くすとそれで少しスッキリしますから。でも、遺恨が残らない程度で……。

■想定外

　今回の震災でよく使われたフレーズですね。原発事故に関してはそれそこよく聞きました。でもこの言葉、ソフトウェア開発をしているとよく聞きませんか？ 私は良く聞きます（笑）。

　社内システムやSIではあまりないかもしれませんが、自社開発でパッケージソフトを作っているとそう思うことがままあります。基本的に不特定多数に向けて販売するので、サポートへの質問などでそれを実感します。ようするに実装した機能が自分たちの意図したことと違う方法で使われていてそれに対しての質問だったりすると「へぇ、こういう使い方もできるんだ」と自分が設計したことも忘れて関心してしまいます。実害のない？ 想定外ですね。

　私の経験上、よくあるのがサーバの負荷についてでしょうか。時々ヘルプで別のシステムを見たりするのですが、構築前に「期待通りのレスポンスをするには数台に分けた方が良いですよ」とアドバイスしてもたいていは1台で構築して四苦八苦していることが多いです。不況だからでしょうか、ねぇ。でも、使い物にならないシステムならそれこそ「無駄金」になると思うのですが。

　この場合、想定外なのは当事者たちだけで、私から言わせれば想定内です。データベースなどでも何も考えず操作しているようなケースも良く見かけますが、そうなると本当に人災だと感じます。

　設計する側も実装する側ももう少し「意図」を考えてやらないと炎上するプロジェクトだけが増えて行く気がします。そのためには構築するシステムの勉強は最低限、必要だと思うのですが。小規模ならともかく、ある程度の規模以上で好き勝手にSQLを記述しているのを見ると本当に倒れそうになります。

　私から見ると、構築するシステムの知識が乏しい人がやっていることが想定外です。

■美しいソースコード

　私はパソコンのBASIC（VBじゃない方）でプログラミングを始め、アセンブラで自分のスタイルを確立してしまいました。この頃はまだCPUレベルで掛け算や割り算はできませんでした。ハードウェアコントロールも単純でしたし。

　会社に入ってハードウェア設計からソフトウェア開発要員になってから初めて世に言う「情報処理の基礎」を教育されました（高校ではちょびっとやりましたが）言語もほとんどCOBOLでC言語が申し訳程度だったと記憶しています。COBOLはそれ以来経験ないですけど。

　仕事ではシステムに近いソフトウェアが多いこともあり、仕事でよく使うのはUnixのC言語かWindowsのVC++です。JavaやPHP、.Net（ASP.Net）なども少しは使いますが、今でも多いのはVC++です。

　今更ですが、C/C++はコンパイラ言語です。プログラムをコンパイルして出来たアセンブラをアセンブルし、最後にリンクします（ようするにビルドですね）そのため、昔からあまりソースファイルにはこだわりがありませんでした。今でこそシステムリソースが豊富にありますが、昔はメモリも少なく、フロッピーもまだまだ活躍していました。お世辞にもいいとは言えない環境で動かすため、コンパイルして出来たアセンブラを見てソースコードを修正したりもしました。ようするに見易さよりも実用性重視です。

　そのため、ソースコードはその手段でしかないので私の中では設計書と同じ「ドキュメント」の扱いで、コメントもそれなりに書き込んであります。昔のコンパイラには怪しいものもあり、ソースコード通りコンパイルしていないものもありました。それもあって私的には「ソースコード」がそのままイメージ通りのソフトウェアになること自体疑っているのかもしれません。

　で、ある日後輩に

　「にゃん太郎さんのソースコードって美しくないですね」

　と言われてしまいました。初めは耳を疑いました。「間違っている」でも「見にくい」でもなく「美しくない」って、何？ と。そして、コメントの書き方、if文の条件式の書き方、制御文の使い分けの仕方……など、御丁寧にダメ出しをしてくれました。

　if文なんかは私の場合、頭の中でどうやってコンパイルされるかを考えることが多かったので、見やすいとか分かりやすいっていうのは確かに二の次になっていることは多いです。少しでもメモリ使用量を減らし、少しでも高速なものを突き詰めることが多いので、すでに発想の原点が異なります。

　こういうのって言われないと分かりませんね。さすがに美しいコードまでは考えませんが、最近は見やすいコードを心がけるようにはなりました。

　PMが自分の作ったコードをレビューして後輩にダメ出しされると結構凹みますが、それが逆に「まだまだ若い者に負けんわ！」という意欲にはなります。立場上、それなりに勉強しておかないと「何言っているの？」と言われてしまうので、ある意味必死だったりします。

　あ、そこまでこだわるならC/C++じゃなくて、アセンブラの方が早いんじゃない？ と言うのはナシでお願いします。

■開発ポリシー

　オブジェクト指向がメジャーになる前からこの仕事をしているので、今日までいろいろな開発手法が出てきてそれを勉強しました。言語もいろいろ出てくるのでそっちもそれなりに勉強してメジャーなものぐらいならほぼ経験しました。

　ただ、個人的にはあまり手法や言語にこだわりがありません。極論すれば「オブジェクト指向？ アジャイル？ そんなものクソくらえだ！」というぐらいの考えはあります。誤解されるといけないのできちんと補足しておきますが、オブジェクト指向やアジャイル開発が「ダメ」なんじゃなくて、最終的に要求されるものが完成するならどんな方法も構わない、ということです。もっともオブジェクト指向やアジャイル開発の方が効率も良いので、結局そういう方向にはなってますけどね（そうならざるを得ない、と言った方が正しいかも）。

　ただ、「何が何でもオブジェクト指向だ！」とか言われてしまうと個人的には辟易してしまいます。「そうかも知れないけれど、そこまでこだわらなくても……」と思い切り引いてしまいます。

　方法論、と言ってしまえばそれまでですが、そこに「だけ」こだわってしまうと道を外れてしまい本末転倒になりかねません。いろいろな勉強をしつつ、良い所は積極的に取り入れてそこは常に試行錯誤するぐらいの感覚も必要かも知れないと考えています。結局、できたソフトウェアを使うのは自分じゃない訳ですし、商売も考えると人、時間、効率は常に追求しないと生き残れないと思いますから。

　基本的には「いいとこ取り」がポリシーなんですが（失敗も多々あり……）。

■昔取った杵柄

　今でも初めてJavaやOracleなどデータベースを触った時のことを思い出しますが……。

　先ほど書いた通り私はWindowsでの開発が長いため、ほとんど使用言語（開発環境）は「VC++/MFC」です。バージョンはVC++4の頃からなので結構長いお付き合いです。今でもVC++2008を仕事で使っています。

　さて、何を思い出したかと言うと、「null」と「true/false」です。今時こんなこと言うと「はぁ？」って言われそうですが、私は当時まで「null = 0」「true =1」「false = 0」と本気で思っていました。初めてJavaを使った時も当然、この考え方が頭にあってえらい目に合いました。おかげでその区別がきちんとつくようになりましたが。

　VC++って当たり前ですが、Microsoft仕様なので厳密な言語仕様とは異なります。そんなことは分かっていても普段は意識しないのでついつい「標準仕様」と勘違いしてしまいます。ようするに、習慣なので「これが普通」と考えてしまうんですよね。

　MFCですと標準で「NULL」やBOOL型の「TRUE」「FALSE」（すべて大文字）を使うことが多いと思います。そしてそれは#defineなどで以下のように定義されています。

　#define NULL 0
　#define TRUE 1
　#define FALSE 0
　typedef int BOOL

　nullはご存じのようにゼロではありませんし、true/falseもしかりです。当然、Javaやデータベースもそうなのですが、VC++/MFCばかりだとついつい混同してしまいます。そう思って実際にプログラムを組むとtrue/falseはコーディングの時にエラーになるので良いのですが、nullはミスが連発しました。

　長年やっているとついつい惰性になってしまうのは仕方ないとは思いますが、基本をおろそかにしているんだとこの時は猛反省しました。

■ググらないススメ

　私は昔から技術書が好きで結構買っていたのですが、最近はお小遣いが少ないのと置き場所がなくなってきたためにあまり買わなくなりました。古い本から少しずつ「自炊」しているので最近は少し余裕も出来ましたが、何より本を買わなくなった一番の理由は、

　「ググれば安くて早い」

　からです。これは最近のエンジニアでは普通だと思います（ネット環境があればですが）とにかく自分がつまずいたところはたいてい他の誰かもつまずくことが多いので、探せば疑問点はほとんど見つかります。英語圏まで広げれば何でもあるんじゃないかと思うぐらい。しかもソース付きで。

　でも、個人的にはプログラムを組む時にはあまり使わない方が良いと考えています。欲しい物を探したり、一番安いお店を探したり、旅行先の情報を見たりなどガイドブックや百科事典（辞書）的な使い方は良いと思います（仕事中はほどほどに）。でも、同じ感覚でソースコードをコピペするのは多分マズいです。あえて利点を探すなら効率的、でしょうか。

　この間、久しぶりに技術書がたくさんある本屋に行きました。少し見ない間に面白そうな本もたくさんあっていろいろナナメ読みして楽しんできました。でもそういう本って高いのが悩みなのですが、それでもやっぱり仕事でエンジニアをやっている以上は本から情報を仕入れる方が良いと感じました。

　Google検索はいわば「回答」が見つかります。テストのカンニングと同じでその場は何とかなりますが、結局自分で理解していないと後からそこが問題になることもあります。それに対して本は「How to」と「ヒント」が見つかります。つまり、自分がやりたいことがそのままの情報ではなく、それに近いことを手順を追って説明することが多いのです。そして自分で入力しながら（CD-ROMなどに入っている場合もありますが）確認するために「勉強」にもなります。何より「投資」も必要になるので、ある程度は真面目に読むでしょう。

　ググるなとは言いませんが、やっぱり自分で理解するようにしないとネット環境がないところで開発作業をすることになってから慌てるのは、結局自分です。

　Google依存はほどほどに。

■「考える」癖を身につける

　年齢が上がってくると言われるよりもいうことの方が多くなります。立場によってはかなり影響力もあるでしょう。でも、条件反射的ではなくて自分なりに考えて行動することは、逆に年齢が上がれば上がるほど必要になると思います。

　私は時々そういうことも思い出しながら、仕事をするように心がけています。