2018-12-29

身につけるべきプログラマの習慣 番外編2

番外編の理由は、ICT技術者以前の問題でもあるからです・・・

コミュニケーションの重要性

ビジネスの世界ではコミュニケーション能力の重要性が叫ばれ、多数の書籍が出版されているようです。

一方で、ICTエンジニアは内向的で1人で黙々と作業をしているイメージを持っている世間の人たちも多いかもしれません。そのためなのかは分かりませんが、エンジニア向けのコミュニケーションについて書かれた書籍はなかなか見かけません。

私も長年、基本的には1人で仕事を請け負って自宅で黙々と作業をこなしていました。しかし、お客さんと直接対話をし、漏れなく要求仕様を聞き出さなければシステムの設計もおぼつかないわけで、密度の高いコミュニケーションが求められました。
また、1人で行う作業であっても、プロジェクトの一部を請け負うことも多く、それはつまり実際のところはチーム開発である、ということなのです。

チーム開発では横の繋がりがとても重要です。
残念ながらチームマネージャが技術に疎い人が担当することも多く(技術力が無いからマネージャをやらされる人も多い?)、上からの指示は全く大雑把で、的を射ていることはむしろ希なのです。
そのため、自分たちでなんとかしなければなりません。
自分と相手のどちらが上に立つか、といった低次元かつ下衆な話ではなく、
責任分担、作業分担を相互のコミュニケーションで決める必要があるのです。

責任分他、役割分担はプロジェクトにおいて非常に大切な作業ですが、各自に丸投げにする無責任なマネージャも多いし、コミュニケーション無しに自分勝手に作業を始めてしまうとんでもない人もいます。
実は、この役割分担のコミュニケーションの中で、明確になっていない仕様が表面化することも多く、プロジェクトの成功には欠かせない重要なコミュニケーションの1つであると私は考えています。
本来的、建前的にはマネージャの責任であるとか、そのフェーズ以前の仕事の結果の甘さがこういった重要性を更に引き上げているのですが、実際の現場はそういっただらしなさがむしろ常態化しているものだと考えた方がいいと、今は実感しています。

日本企業の技術力の低さは、もうどうにもならないところまで地に落ちていると感じています。そのうち、大きな破綻が来てしまうことは確実のように思われます。

そういったよろしくない環境であると認識していながらも、自分はコミュ障である?とか人見知り?だとか、生まれ持った自分の特性だ?とか、何がそれを正当化させるのかは知りませんが、極力人とのコミュニケーションを避け、曖昧な仕様を自分勝手に決めて作業を進め、これまた自分勝手に自身の責任の範囲を制限し、それを終えるととっとと休憩していつまでも自分の席に戻ってこない人がいて大変迷惑を被りました。

あなたの周りにも、そんな人はいませんか? 流石にここまで極端な人物は希だと思いますが、こういった人にはこの業界にいて欲しくないというのが本音です。若い人ならまだ更生する可能性はあるでしょうが、そうでもない人にはひたすら去っていただけることを願うばかりです。
また、生まれた国や文化の違いもあり、自分の事(いかに自分の仕事を楽にするか)しか考えられない技術者とも呼べない技術者もこれまで何人も見てきました。

あなたは何の為に技術者になったのですか。金のため? 喰うため? だったら、すぐにこの業界を去った方がいいですよ。この業界は一部の人しか儲かりません。
技術者というのは、良いもの作りをすることが第一義的に意義を感じられる人の事だと、私は信じています。良いものを作り、誰かに、あるいは社会に貢献することです。(自分の独りよがりの良いものでは、当然それは成り立ちません。)

チーム開発で良い結果を残すためにコミュニケーションが重要である、というのは、あえて説明しなくてもその重要性は直感的に理解できる話ではあります。
それでも、そこを軽視する現場のいかに多いことか。

技術者のコミュニケーション手段

人が苦手で人見知りでも、文章は書けるはず。メールであるとか、それに似たコミュニケーション手段もいくつもあります。足りなければ、我々自身が開発すればいい。
会話をして議事録を取るのもいいですが、最初から文章を使ったコミュニケーションは一挙両得かも知れません。
その場に合った、合理的な手段の選択肢を柔軟に取り入れられる現場には活気があります。逆に、その方法を伝統に沿うなどと耳に心地の良い言葉で頑なに変えない、変化を好まない老化した現場には未来もないし、良い結果など残せるはずがありません。そんな死んだ現場、干物のような現場、いや、ミイラ化した現場はさっさと辞めた(抜けた)方が無難です。

常駐している外注人員にメールさえ使わせない、恐ろしく風化した(ミイラさえ風化して形が分からなくなっているほど酷い?)現場もあるのだから、これはもう日本の未来を愁いたほうがいいのかも知れません。

ところで、ICT技術者のコミュニケーションには対人だけではなく、もちろんコンピュータそのものに対するものも含まれると考えています。
プログラミングは最もディープなコンピュータとのコミュニケーションではないでしょうか。もちろん、これは同時に明日の自分を含めた他人とのコミュニケーションでもあります。
動けばいいだけなら、ある意味汚いソースコードを書いても構わないのですが、明日の自分、未来の自分を含めた他人に対する重要なドキュメントでもあるので、分かりやすい書き方が求められます。

どうすれば分かりやすいのか、それはその場の事情によっても異なってきますから、これしかない! と、ここで決め打ちすることは危険です。毎回工夫する必要がある、という点だけは強調しておきたいと思います。それを考えつくようでなければ、プログラミングという創造作業ができるはずはないのでは? と思います。

そのドキュメントはなぜ必要なのか、毎回その必要性、必然性を考えなければなりません。あらゆる選択肢から選ぶ理由を論理的に説明できなければ、それは素人の技術者です。理由を説明することも出来ないのに、その選択を押しつけるような人物は、この世界で最も嫌われます。無能な権力者だからです。

まとめ

まとめられません。
コミュニケーションの重要性は、ICTエンジニアにとって命であるとさえ思いますが、むしろ軽視されている現場の多さに愕然とします。この非常識極まりない世界が、早く終わることを願ってやみません。
人手不足が解消されれば、そういった方々が淘汰され、業界を去って頂く事が出来るのではないかと・・・ いやいや、言い過ぎでしょうか。
体力の無い自分が、一番最初に淘汰されてしまうかも知れません。


2018-12-28

身につけるべきプログラマの習慣 番外編1

なぜ番外編なのか? それ以前の人間形成にさえ係わる基本的な問題を扱おうとしているからです。

普通の良識を持った人は、どうぞ読み飛ばしていただいて結構です。しかし、あなたの身近にそんな人がいたらどうすべきか、考えてみようという方は一読しておくといいかも知れません。

相手を疑う前に、自身の潔白を証明する

様々な人が係わって構築したシステムの場合、障害が発生すると独特の緊張が走ります。誰の責任なのか? まずは自分自身の作ったプログラムにバグがないか机上デバッグを始めるのが通常の行動であり、最低限のマナーであり、ルールでもあります。

しかし、中にはまずは自分以外の部分、他社が作った部分に問題があるはずと疑い、すぐにその相手におまえらのせいで困っている、調査しろ、と依頼する企業や人がいます。そして、逆に相手のバグではないこことを証明され、突きつけられてやっと重い腰を上げて自分たちの問題の調査を始めるのです。

最近の経験ですが、調査というほどのこともなく、単にテキストエディタで開いてみるだけで問題の無いことがすぐに判るようなことなのに、それすらもせず、まずはこちらを疑ってせめて立てるようなメールをよこした他社の人がいました。そのために無駄な調査の工数で時間を奪われました。全く余裕がないプロジェクトなので、大変迷惑なのです。
事実が判明すると謝罪の言葉はありましたが、反省はしていなかったようです。再度、同じようなことが起こりました。

これは、技術者として非常に未熟であるばかりでなく、それ以前の人間形成だとか、会社での社員教育などが全くなっていないということなのかな?と思うのです。

私が個人で直接お客さんから受注している場合であれば、作業途中であっても契約をキャンセルし、引き上げるかも知れません。
私は少なくとも、今後係わることは絶対に避けるつもりでいます。


2018-08-09

量子論と霊の世界

「霊の世界を信じますか?」


うさんくささが先に立つこの問いは、実際とても曖昧でいろんな意味を含んでいるし、霊感商法といった闇の世界から、宗教や死者への尊厳の問題まで広く及ぶので、簡単に答えなど出せるはずはないだろう。

理化学系に属する人たちの中には、即座に非科学的であることを理由に否定する人がいる。
科学で解明できないことは全て否定するといった低次元な理由が大半だろうが、中にはあと何年もすれば人間が存在する理由も全て科学的に証明できると豪語するどこぞの大学の教授のような人物もいる。火の玉をプラズマで再現して見せて、調子に乗ってしまったのだろうか?(テレビのバラエティ番組内での発言を真に受けることもないとは思うが)

ヒッグス粒子の存在が証明された頃、それをきっかけに素人向けの量子論や量子力学の本を何冊か読んでみた。とても楽しかった。
それまでも、光が波の性質と粒子の性質を併せ持っているだとか、アインシュタインが量子論に反発するも、相対性理論の次に、それを度台にして発展した物理学なのだろう、ということは何となく知っていた。

素人向けの量子力学の説明では数学を使うことができない。そのため、比喩に頼る傾向があり、そしてそれが必ずしも適切でない場合も多々あるようだ。しかし、数学を使わず、僕のような素人にもその本質を伝えようとする本もあった。
そんな本に助けられて、量子論のおもしろいところだけをかいつまんで楽しませてもらったと思う。

そんな浅い理解でも、自分なりに考え、気が付くこともある。

たとえば、有名な「シュレーディンガーの猫」という思考実験があるが、僕はこの思考実験の本質とは別に、観測が観測対象に及ぼす影響について思い当たった。
通常、物理の実験では観測そのものが対象(結果)に影響を及ぼさないといった前提がある。
ニュートン物理学までの実験では、厳密には影響を及ぼしたとしても、それが無視できる程小さいので問題はなかった。
しかし、相手が量子になると、影響の度合いが100%、あるいはそれを超えてしまう。なので、非破壊検査はできないと言っていい。
(見る為に光を当てれば、対象がその光により変化してしまうといったようなこと)

つまり、観測を行うことそのものが、実はもっと本質的な「何か」なのではないか、という考えに行き着いたのだ。飛んでいる蚊を観測するためには、必ず叩き潰さなければならない世界なのだと。

これは、観測=対象に変化を加える、ということ。「シュレーディンガーの猫」も、猫の入った箱を開けたときに死んでいる、あるいは生きているの2択なのだが、開けない限りは死んでいるとも生きているとも言えない、という状況なのだ。いや、実際には死んでいる、とか、実際には生きているがその情報が伝わっていないだけだ、というのとは違う。箱を開けた瞬間に決定するという思考実験だ。つまり、箱を開けるまでは、猫は死んだ状態でもあり、生きた状態でもある、ということらしい。
しかし、実はこの話には何の矛盾もなく、箱を開けることによって猫に影響を与える、ということが本質なのではないか、と考える。観測が対象に影響を与える、ということを理論に取り入れるべきではないのか、ということだ。実際、どのような観測方法をとったとしても、素粒子を対象とした場合、それに影響を与えてしまうことは、おそらく数学を使って証明できることなのではないか、と思うからだ。

非常に観念的で現実味の無い話に思えるかも知れないが、物の最小単位である素粒子はそんな世界なのだ。

この、観測が対象に与える影響という点については、まだまだ考慮すべき点があると思う。ただ、思考実験のように観測自体が無影響であるという前提自体が無意味ではないのかな、ということが言いたいのだ。
もしかすると物理学者はこんなことは当然すぎて問題にしていない可能性の方が高いとも思うが。

そして、もっと抽象的で漠然とした考えにも行き着いた。今の量子力学、量子論はまだ完成していない、発展途上であることは誰もが認めるところではあるが、現時点でこの理論は非常に複雑、いや、必要以上に複雑すぎるという点だ。まるで、天動説を元にして天体の動きを説明しているかのようだ、と感じたのだ。あまりに、例外が多すぎる気がする。一本筋の通った、美しい理論とはほど遠い。
天動説では複雑怪奇だった天体の動きは、地動説の発見でとてもシンプルになった。

量子論は、まだ天動説でしか説明できていないように思えるのだ。ひょっとすると、数ある理論の中には、地動説に限りなく接近しているものもあるのかも知れないが、まだそこには至っていないというのが現実であろう。

天動説から地動説への革命的変化のようなことが、量子論にも起こらなければ、現在謎とされている事の全てを説明できる日は来ないかも知れない。しかし、ひょっとするとそれは人間には永遠に解けない問題かも知れないが。


そんな謎が解明されれば、ひょっとすると宇宙の存在理由も判るのかも知れない。そしてその頃になれば、霊であるとか、魂の存在であるとか、自ずと解明されている可能性もある。

そんな考えの1つのきっかけは、「量子のもつれ」という現象だ。説明は省くが、この現象では情報が光の速度を超える。距離には関係なく、瞬時に伝わるというものだ。現象は知られていても、理屈は解明されていない。

たとえば、これは無いとは思うのだが、人間などの脳がこの現象を利用して情報伝達が可能だったとすれば、テレパシーが従来の電磁波などによるものと想定した観測方法で感知できなくても当然なのだ。まぁ、これはいかにも素人が考えつきそうな話ではある。

しかし、目に見えるものしか信じようとしない現実論者が見ているものは、いったい何なのだろうか、という考えに飛躍した。彼らは量子論を知らないし、知ったとしても宗教のように単なる絵空事のようにしか感じ取ることしかできないのかも知れない。
しかし、この世界の大元は、そのような人間にとって観念的でさえある物理世界によって成り立っているのは、現実なのだ。

そうした物理的な世界において、宇宙の存在理由でさえまだ何も判っていないのに、増して、人間の存在の、その奇跡の度合いは計り知れないものがあるということなのだ。つまり、我々が見ている現実は、奇跡の中の奇跡なのだ。人間が存在するのだから、霊の存在が現実的だとか、非現実的だといった議論はほぼ無意味に思えるのだ。
何の意思もなく、自然に、勝手に人間が存在することなど、僕には全く考えられない。
人間はそれを神と呼ぶのだろうが、それは量子論をはじめとする物理学の延長にあるものののはずだ。

その宗教ではない神が、人に隠し事をしていて、しかしそれが隠しきれない何か、それが霊的な現象として認知されているのかも知れないと思う。

霊的な体験


奇跡と偶然は相反することではない。

たとえば、ある夜に急に亡くなった人が、昼間現れた虹を見舞客と一緒に見た。その虹を見て、「親類の葬儀の帰途にも虹が出て、あれを渡っていったのね」、という話をし合った事を思い出し、見舞客にその事を伝えていた。

この昼間の虹は、単なる偶然だろうか。あるいは、奇跡なのだろうか。

虹を見た夜に亡くなった人の事を知らなければ、偶然ですらない。知っていたとしても、見舞客なら奇跡だと感慨をもつだろうし、他人の感情に寄り添えない立場ならただの偶然で片付ける。見方の違いだ。

仮に、昼間の虹を見せたのが霊的な人間以外の意思だったとする。であれば、その「意思」は偶然を装い、数学的に、物理的に矛盾がないようにうまく装って虹を発生させるに違いない。

だから、偶然と奇跡は見方によって違うだけだ。光が、粒子の性質と波の性質という、相反する性質を併せ持っているのと少し似ている。


実は、上記の虹を見た夜に亡くなったのは僕の母であり、見舞客は僕と母の友人だった。

亡くなった後も、母の事で親類で集まりがあったとき、天気はずっと雨だったのに、みんなが目的地で車を降りる頃には雨が止み、建物の中にいるときは雨になり、また車に戻る時間になったらまた止んだ。雨はけっこう激しかったから、傘を差さずに済んだのは助かった。
母は医大に検体をしていて、3年を過ぎて火葬になった日も、その前後はずっとずっと雨続きだったのに、その日だけ晴れた。その日ももちろん親類や友人など母の縁者が集まった。

この天候に関しては、僕には単なる偶然には思えない。


夢の話もある。昔、世話になっていたクラシックギターの先生の夢を、ある日唐突に見た。何のきっかけもなかったし、最後にお会いしてから30年は経っていて、とても気になってしまい、ネットでいろいろ探してみたが情報は得られなかった。1年位して、またその先生の夢を見て、またネットで検索すると、最初に夢を見た一週間前くらいに亡くなっていたことが判明した。49日が過ぎるまでは亡くなったことは公表されていなかったらしい。このことは日記を付けていたので、はっきりとしている。

他にも、親戚が亡くなって、やはり一週間以内くらいにその人の夢を見たこともあった。

天候などとは違い、夢という曖昧ではあるが、その人個人だけに係わる現象だから、あちらの意思が伝える手段としては簡単なのかも知れない。

宗教


偶然は、見る人や立場によって奇跡になる。同じように、人間にとって不可解であったり、科学的に説明できない現象も奇跡だったり、神の御業だとか、祟りだとか解釈される。
宗教の多くは、その解釈を人間の想像力で膨らませたものだと言っていいと思う。信じる人にとって、それは事実と同じなのかも知れない。

しかし、過剰な解釈は人間の都合や欲に利用される。人々をコントロールしたり、金儲けだったり。
だから、僕は大方の宗教に深く加担しないように気をつけている。

しかし、一方では、多くの人が何かを一心に信じることで、「何か」に影響を与える可能性を否定できないでいる。本当かどうかは僕は疑わしいと感じているが、量子の原理を使ったランダム数発生装置が、大勢の人の活動によって確率が偏った、という実験があるようだ。この実験の前提となる環境は客観性に乏しく、甚だ疑わしい部分もあると感じてはいるが、事実だとすれば非常に興味深い。
いずれにしても、人の精神的な活動が物理的な影響を生む可能性は否定できないと考えている。それが、宗教活動の一部において、リアリティーを持たせている可能性があるのではないか、と考え、僕は真面目に神社でお参りするようになった。
以前は、神道に対して胡散臭い占いと同レベルでしか向き合っていなかったように思うが。



まだまだ、漠然とした結びつけしかできてはいないが、量子論と霊は、案外近しい存在なのかも知れない、と考えている。


2018-03-18

PCが売れなくなった本当の理由

「開発環境」カテゴリーを追加し、最初の投稿です。

主な問題

PCが売れなくなったと聞きます。スマホにその役割の多くを奪われた結果と思われます。
しかし、PCそのものにもその一因があるようにも思えるのです。

今、個人的にWindowsのノートPCが欲しいと思っています。ノートPCは比較的高額で、昔から必要に迫られない限り買う事はありませんでした。普段は主に自作のデスクトップを使用しています。

それがいいのか悪いのか、あるいは先取りなのか、2in1という新たに発現したPCがあります。Windows 10の機能を最も活かすハードウェア、というか、Windows 10の為に作られたPCと言ってもいいのかも知れません。

残念ながら、僕自身は2in1PCを直接的に必要とはしていません。しかし、アプリケーションを作成するためには、全ての機能が使える環境を手元に置いて、実際に使い続ける必要があります。つまり、アプリケーションのターゲットとしての意味があるのです。

Appleは現時点で2in1PCを遠くから静観しているだけのように見えます。また、iOSとmacOSを統合することも実現できていません。

しかし、AppleとMicrosoftでは前提となる環境に違いがあります。AppleはモバイルOSとしてiOSは大成功を収めていますが、Microsoftは完敗状態でした。完敗したOSを捨てることに躊躇う必要は無かったはずです。そこで、主流であるWindowsにモバイルOSとしての機能をくっつけてしまったわけです。
対して、AppleはPC用もモバイル用も成功していますから、無理にくっつける必要はないのかも知れません。

Microsoftは世界で一番普及しているOSをモバイル対応とすることでスマートフォンなどの巻き返しを考えたのかも知れません。
しかし、MicrosoftはWindows 8で一度失敗しています。しかも、失敗をよく反省もせず、MicrosoftはWindows 10を世の中に押しつけてきました。特に、デスクトップPCを使っている人にとって何のメリットも無い、むしろ害悪となる非常に視認性の悪いデザインは今でも大変不評です。

では、2in1PCのように、タッチパネルを使ったPCでWindows 10は本領を発揮するのでしょうか。僕はまだ店で少し触っただけですが、とても水を得た魚というような印象を持つことはできませんでした。もちろん、タブレットモードも試してみました。
最も当てはまる言葉は「どっちつかず」、あるいは「中途半端」です。

そして、あらためて思うのは、タッチパネルに無縁な環境なのに、それがまるでタッチパネルのためのような見た目ののっぺらぼうで平面的なデザイン。そして、それは決してタッチパネルを通して使ってみても使いやすいわけでは無いという事実です。
Windows XP時代には1つのウインドウにいくつものカラーやサイズを設定できる項目がありました。Windows 7はそれがずいぶんと減りましたが、それでも完成度の高いデザインでほとんど不満はありませんでした。視認性が高く、凝ったデザインなのに湯水のごとく当たり前にストレス無く使うことができました。
それまで培ってきたデザインの集大成、研究の成果が盛り込まれた素晴らしいものだったと感じています。

しかし、Windows 8、10でMicrosoftはその長年の成果のほとんどを捨て去りました。画面を見ているだけで目が疲れます。特に、ファイルエクスプローラーはほとんど全体的に白っぽく見えるため、非常に大きなストレスを感じてしまいます。
非アクティブのウインドウのタイトルの背景が白に固定されているため、これも非常に鬱陶しく感じます。

Microsoftは頭がおかしくなったのでしょうか。いえ、頭を失ったのですね。しかも、失った頭自体は寄付という自己満足の偽善道楽に興じていて、胴体を顧みることはもう永遠にないのでしょう。
この企業は相変わらず巨大ですが、過去の信用という遺産を無駄遣いし、破壊しながら生き恥をさらしている衰退途上企業と言っていいのではないでしょうか。

このMicrosoftの体たらくでPCが以前より売れるようになるはずなど、あり得ないと思います。
スマホにユーザを取られたことを除き、PCが売れなくなった最も大きな原因は、Microsoftの体たらくにあると思うのです。

もう1つの大きな問題

そして、Microsoftの体たらくに同調するかのように、各社PCメーカーの体たらくもあるのです。
PCなのになぜか不便な方に向かっています。拡張性も放棄したようです。この点ではAppleも同罪ですね。
しかし、ハードウエアメーカーとしてのMicrosoftやApple以外のメーカーの最も共通する具体的な問題は、ノートPCの画面を概ね16:9に揃えてしまったことです。特に、13インチ台の小型PCを16:9にすると、縦のサイズがごく僅かとなってしまい、文章などの編集に非常に大きなストレスを感じてしまうのです。
そもそも、16:9はどこから来たのでしょうか。動画のハイビジョンサイズしか考えられませんが、これはPCのワークエリアとして全く適性がありません。
16:9のパネルは安く生産されるため、弱小のメーカーではこれを仕方なく使って安く上げて利益を確保している、と思っていました。しかし、実際にはわざわざ16:9にしているという情報を得ることがありました。だとしたら、なんと愚かなことでしょうか。

仕方なく13.3インチの16:9サイズのノートPCをしばらく使っていました。しかし、流石にメインで使うことはできませんでした。ネットサーフィンでさえ我慢を強いられます。
16:9の画面でPCを作るなど、非常に愚かなことだと感じていますが、バカがバカの真似をしてAppleとMicrosoft以外のほとんどのノートPCは16:9なのです。昔のように4:3にしろとは言いいませんが、13インチ台ならせめて3:2、15インチ台なら最悪でも16:10ではないでしょうか。

こんな不真面目なPCを真面目に使う気になれないのは、至極当然のことなのです。こんなクソPCを生産して売れなくなったと嘆いているバカどもに、本質に立ち返れと言いたいのです。

2018-02-14

身につけるべきプログラマの習慣 その7

本当の問題を探る

人は最初に入ってきた情報を優先しがちです。先入観もそういったことの1つです。
だから、何か問題が起こったとき、それを見たまま聞いたまま受け取ってしまいます。
更に悪いことに、問題の本質にたどり着けないまま我先にと夢中になって解決策を考案してしまうのです。

日常茶飯事の光景ではないでしょうか?

本当の問題は何か、一度咀嚼して考えなければなりません。
まずは、それが誰にとっての問題であるか、という点が大きなヒントになります。立場を変えれば、それは問題ではないかも知れません。誰かにとって問題でも、それが誰かにとってはメリットかも知れないのです。

そして、問題の本質を探るときに大切なことは、客観的視点です。問題の渦中にいる感覚でいるうちは、本質的な解決策を見出すことはできません。

そして、候補に挙げた解決策が、どの問題をどのように解決するのかを予測します。1つの問題を解決することで、別の新たな問題を発生させてしまうことにも注意を払います。
そのような副作用の問題を含め、一気に解決できることが理想かも知れません。そのような理想的な解決には、発想力、創造力、想像力が欠かせません。

創造力が大切

矛盾する要素を1つ高い次元で解決して融和させることは、創造的脳活動の本質だと考えています。
脳のこの能力を引き出させるためには、記憶依存の思考を行っていてはいけません。また、スケジュールなどに追われ、尻を叩かれながらの作業でも決して行えません。

精神的なゆとりや前向きの気持ちをもつことが大切ですが、それにはそういった環境が必須になります。
残念ながら、日本の企業の会社勤めではそういった環境はほとんど望むことはできません。日本人は記憶に頼る教育しか受けていないからかも知れません。

僕自身は長年在宅で、自分の体調と向き合いながらその能力を自分なりに引き出してきました。そのことで、大技、小技を繰り出してきました。もし、部屋に監視カメラが取り付けてあれば、そんな技を繰り出す前は、まるでサボっているように見えることでしょう。

発想力を必要としない、コツコツとした非創造的な作業においては、とにかく手を動かしなさい、という製造業的なやり方でも世界に通用していたかも知れませんが、ソフトウエア開発というのは、言わば創造的思考の連続でもあります。少なくとも、そういった作業フェーズの時だけは在宅での作業を認めるなど、創造性を引き出す環境作りに真剣に取り組まなければ、ますます日本の技術力は地に落ちていく一方になると思います。


2018-02-13

身につけるべきプログラマの習慣 その6

試験でのバグ出しは誉れ

バグ出しでたくさん発見されると成績を下げるという評価があります。これは最低です。
また、バグ出しなのに、自分のコードにバグが見つかるといちいちがっかりして落ち込む人を見かけますが、それもおかしいですね。

バグというのは、人間なのだから必ず入り込むものです。その率は人によって異なりますが、多かれ少なかれ必ず入り込むのです。

最終的にバグを取り去れば良くて、途中でのバグの件数自体は問題ではありません。

試験の局面においては極力バグを洗い出すことが重要で、次の行程に問題を残さないようにしなければならなりません。
だから、既にできたコードに対しては、極力バグを残さないようにできる限り多く発見することが誉れであって、恥ではないのです。


もちろん、バグにも質があります。単純なミスが原因なものもありますし、ロジックをよく理解しないまま当てずっぽうに書いたコードが動かない、という最低レベルのものまであります。
後者の場合、プログラマの資質にまで問題の範囲が及ぶことになります。動くはず、という確証のないままコーディング行程を終了させたのは深刻な問題かも知れませんね。
また、単純なミスであっても、あまり多発するようではデバッグを含め、余分に工数を要してしまうことにはなります。

プログラミング時にいかにバグを入れないようにするか、それもソフトウエア工学の1つです。そういったことをちゃんと守った上で発生するバグは、通常さほど深刻なものにはならないはずです。

もし、バグを恥じるのであれば、納品後に発生すること、あるいは、バグの量ではなく、悪質なバグに対してなのではないでしょうか。

笑い話?

30年位前の、大手企業での実話です。
バグの発生率は統計的に決まっているという点に着目し、ある人の出したバグがその範囲に収まっていない場合、試験を通過させないというものでした。
これはバグが多発した場合もそうですが、バグが少なすぎても試験をパスさせないのです。
そこで、あるグループのリーダーは、バグが少なすぎるプログラマに対して、わざとバグを入れ込めという命令を下しました。

プログラミングの本質を理解していない、あるいは、その内容を理解しないまま評価しようとすると、こういう馬鹿げたことになるのでしょうね。無能な管理者が前提の方法論なのです。

2018-02-11

身につけるべきプログラマの習慣 その5

表と裏を区別する

もしもこれが人間性の話だとしたら、もちろん裏表はない方がいいですよね?
でも、プログラミングにおいては、いつも表と裏をはっきりと区別しなければなりません。外面と、内面を意識すると言い換えてもいいです。

外面、それはインタフェースの部分に相当します。
アプリケーションの外面ならユーザインタフェースであったり、公開API等の仕様であったりしますね。これはしっかりと仕様を決めなければ話にならない部分でもあります。

ライブラリプログラムだった場合はどうでしょうか。
C言語のような関数だけでできているライブラリもあれば、C++のクラスライブラリのようなものもあります。
通常、こういったプログラムはインタフェース仕様書を書いてライブラリのユーザに提供する機能や動作、使用方法や手順をしっかりと定義します。
同じ機能を提供するのであれば、よりシンプルなインタフェースが求められます。

ところが、仲の良い同一プロジェクトチーム内でプログラムを分担するような場合、ついついそれを使う側も作る側も同じチームだから、内々で済ませてしまえるという甘えが出てしまいがちです。
インタフェース仕様をきっちり決めずに作り始めてしまったり、決めても作る時の身勝手な都合でそれを守らずにどんどん崩してしまうのです。
その結果、インタフェースの内側と外側の区別がなくなってしまい、ぐだぐだになってしまうのですね。これはプログラムの品質が格段に落ちることを意味しています。とても深刻な事態なのです。

もし、ぐだぐだになってしまっても誰にも見せない内々の話なんだから構わないだろう、と考えたあなたはかなりやばいです。

ライブラリに限らず、プログラムには使う側と作る側があります(一番外側のプログラムは使う側の立場のみとも言えますが、たとえばmain()関数はOSから使われると考えることもできます)。そこをしっかりと区別しましょう、ということですね。これはむしろ本能的な感覚として身につけておくべき基本的な習慣だと、僕は感じています。

プログラムを関数やクラスといった単位、あるいはもっと小さな単位かも知れませんが、そのまとまりごとに内側と外側を意識して作ることが大切です。

オブジェクト指向プログラムの醍醐味

オブジェクト指向プログラミングで、クラスのユーザ側から見える仕様を設計することはとても楽しいことです。単なる関数と違って、設計方法を工夫することで非常にスマートでセンスの良いクラスインタフェースを実現できるからです。言わば、外面を格好よくできるのですね。

1人の担当者がそのユーザにもなるし、制作者にもなることは普通のことですが、他の章でも書いたように、明日の自分は他人ですから、その他人に向けてよいプログラムを作る、という意識を持つことができるわけです。
そして、実際に明日そのプログラムを使ってみたときに感じる快感は、ある意味独りよがりなのかも知れませんが、それもプログラミングにおける醍醐味の1つだと考えています。