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つだと考えています。


2018-02-10

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

全ての選択には理由がある

どんな些細なことでも、選択肢があればそこに優劣があります。
多くの場合、論理的に優劣の説明ができ、普遍的な選択というものが決まってきます。
そのことを無視して、何も考えずに自分独自の選択をするほど、その仕事の結果はチープになっていくのです。

もちろん、本質的な問題は個々の事情によって異なる場合も意外に多いと言えます。
問題の焦点の当て方によって、解決すべき問題が異なり、同じ選択肢であってもいつも正しい答えが1つとは限らないこともあります。

普遍的で絶対的な答えがあったとしても、それさえも揺るがすような事情が本当にあるかも知れません。そのことを理解していれば、闇雲に他人の書いたコードを尊大に否定することはできないはずです。


しかし、数々の問題を検討した結果ではなく、何も考えずにあなたの個人的な経験だけを全ての世界だと信じ、最初に見たたままの習慣を間違っていてもそのままにしておくことはみっともないばかりか、能力の低いエンジニアであると、密かに、しかし確実に評価されてしまいます。
増して、その理由に自分のセンスだとか、美学だとかを持ち出しようものなら、挽回できないほどに信用は失墜します。

どちらでもいいということは、特にこのICTの世界ではほぼあり得ません。しかし、それを知った上、理解した上で妥協をした方がいいことも多々ありますので、そこは誤解のないように。

事例

C言語系のプログラミングソース、中括弧「{}」の始まりをどこに書きますか。
これは、始まりと終りの括弧を同じインデントカラム位置に書くのが正解です。しかし、中括弧の始まりをその上にあるifだとかwhileだとかと同じ行の一番後ろに書く人が多いですね。これは、昔々、大昔、ソースコード印刷時の行数を減らすための習慣があった頃にできたC言語の教科書の書き方に習っている人が多いことが原因だと思われます。
多くの人が正しさよりも最初に見たすりこみに支配されているのです。

僕自身も、C言語を始めて5年位は、なんとなく疑問に感じながらもそのようなスタイルで書いていました。しかし、ある日ある開発環境でソースコード整形ツールを使ってみると、全て始まりの中括弧はカラム位置を揃えられてしまいました。最初は戸惑いましたが、その書き方の方がつまらないバグやミスを減らせることを実感できたので、以来その描き方を貫いています。(同じ行で中括弧を閉じる場合は別です)

その選択の理由は体験そのものではありません。体験を元にした普遍的な理屈です。
それは・・・

人は図形を素早く感覚的に認識する能力があります。
中括弧の始まりと終りが同じインデントのカラム位置に存在することで、図形的に囲まれていることを直感的に認識することができるのです。そのことで、コードの視認性が格段に高まります。
一般の文章でも、罫線に囲まれていると直感的にそこがまとまっていることを認識しやすいでしょ?(日本人は特に好きなはず)
それと一緒です。

逆に、他の某言語のように begin と end という単語で囲まれているとあまり直感的に見ることができなくなり、視認性が悪くなりますね。
同様に、中括弧の位置がずれていれば、結局その分余計な情報処理が脳で起こってしまうので、始まりと終りの位置を揃えたコードに比べてやや視認性に劣ってしまいます。

せっかくC系の言語は図形的な表現をして視認性を高めるデザインになっているのに、わざわざそのメリットを削ぐことは正しくないと断言できます。

ですが、長年そのスタイルで書いてきたプログラマに文句は言いません。スタイルが統一されていれば、そこまで読み辛いということもありませんし。
でも、一番正しい正解というわけでもありません。
改善する力が残っているならば、よりよい選択をすべきです。


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

明日の自分は他人と思う

プログラマであれば、特にコメントに気を遣いましょう。コメントは後で書くのではなく、コードと同時に書かなければいけません。明日どころか、10分後にはなぜそのようなコードを書いたのか判らなくなることさえあるからです。

しかし、プログラミングでコメントに依存したコードを書くのは完全にNGです。コメントの内容は必ずしも信用できないからです。特に、修正を繰り返したコードは、コメントがメンテナンスされていないことが多々あります。
なので、第一義的にはコメントを読まなくても理解しやすいコードを目指します。
そして、コメントはコード自体では何をしているか判りにくい箇所を捕捉し、コードの可読性を高めることを目的とします。

このようにすることで、多大な複雑系で疲弊し、記憶することを放棄した脳にも優しくなり、明日他人になった自分を取り戻すことができるようになります。

そして、それは本当の他人に対しても優しくなり、保守性、つまりソフトウエア制作における「質」の要素の1つ、を改善することができるのです。


自分を含めた他人に対して優しく作ること、それは善意のあるソフトウエア制作であり、技術者の善意、という最近では忘れられてしまった大切な精神を思い出させる行為でもありますね。

これなくして、技術者は成立しない「何か」の1つなのではないでしょうか。


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

継続的にメンテナンスできないドキュメントは書かない

もしあなたに作成ドキュメントの選択権があるならば、まず第一に新規作成より修正のことを念頭に無駄を排除すべきです。

大きなプロジェクトほど無駄なドキュメントを作成する傾向が感じられます。最初に作成したはいいが、結局それが何の為に存在しているのか誰にも理由がわからず、そして役に立たない。役に立たない一番の原因は、メンテナンスが行き届いていないため、内容をどこまで信用していいのかさえ判らなくなっているからです。

少なくとも、システムの内容に変更が生じたときは、修正すべきところを全て洗い出すことができなくてはなりません。そして、修正すべきであることを直接ドキュメントに印を付けることが重要です。修正後の内容を書き込むのは後でもいいので、とにかくその内容が違ってしまったことがはっきりと判るようにだけはしておきましょう。その際、修正IDを併記しておくと良いでしょう。
そのようにしておけば、もしそのままの状態で放置されてしまったとしても、印の付いていないところはまだ信用できることが判るので、ドキュメント全体が死んでしまうことはなくなります。

同じ内容は1箇所だけに書くようにしろ、という教えもありますが、それは無理があります。もちろん、極力重複は排除すべきですが、概要と詳細に分かれていたり、図面と文章に分けて表現する等、どうしても複数箇所に同一内容が記載されてしまいます。

これらのことを踏まえて、確実にメンテナンスできるドキュメントを作成するように心がけましょう。

とは言え、ドキュメントは必ず書かなければなりません。どうせメンテナンスできないのだから、という理由でドキュメントの作成を放棄するのは大間違いです。
それは、ひょっとするとコンパイルしてバイナリが生成できたら、ソースファイルを廃棄するのと同じかも知れませんよ。