会津に住んでいた頃、私の住むアパートで水道管が凍結し、すべての部屋で水が使えなくなってしまったことがありました。 それから半日ほど経ったところで、管理会社が手配した業者がやってきましたが、そこに現れたのはどう見ても60歳を優に超えていると思しき男性3人。 彼らは雪が吹きつける屋外であれこれと調査を行い、乗ってきた車から機材を担ぎ出し、かれこれ4時間ほどの作業で水道を復旧させて帰っていきました。

私はその様子を見ながら、「なかなかの力仕事なのに若者を連れてこないのか」「彼らの会社に若手はいないのだろうか」などということをぼんやりと考えていました。 たとえ会社に若い衆がいたとしても、こうして現場に出て経験を積むことがなければ、いつまでたっても彼ら年配者がこなしているような仕事をできるようになる道理もなし、と思いを巡らせたところで、ある不安に行き当ります。 「5年後とか10年後とかにまた水道管がトラブったとき、直しに来てくれる人はいるんだろうか?」

現在、IT業界に限らず、「ものづくり」の現場では、空前の技術者不足が起きています。 多分に主観が入りますが、私の見るところでは、モノを作るために必要な知識や技術をきちんと身につけているのは、50歳よりも上の人たちまで。 これよりも若い世代になると、少数のエキスパートが散在してはいるものの、層の厚さ・広さといった点では及ぶべくもない、と感じています。 そして、これまで社会の基盤を支えてきた彼らのような技術者はあと数年で退職し、一線から姿を消してしまうでしょう。 そうなったとき、私たちの世代は果たして、その技術を受け継ぎ・発展させてくことができるのでしょうか?

技術と魔法のギャップ

それから8年が経過した現在、とりあえず水道については問題なく使用できていますが、その一方で、私が身を置くIT業界ではこれに類する問題が起きつつあります。

ここ甲府は梅雨が明けたと同時に温度・気温の湿度が急上昇、早くも熱帯気候の様相を呈してきており、一日のうちに二度三度とシャワーを浴びることもあるようになってきておりますが、皆様におかれましては如何お過ごしでしょうか。

当方はフリーランス (個人事業主) としてなってから7年が経過しましたが、おかげさまで受注とそれに伴う収入は独立当時と比較してだいぶ安定してきました。 その一方で、世間の動向に目を向けてみると、つい先日「働き方改革」を掲げる政府・与党の主導によって成立した「高度プロフェッショナル制度 (高プロ)」に関連して、裁量労働制や割増賃金 (時間外手当) の不払い問題などが方々で議論されているようです。

高度プロフェッショナル制度は、高度な専門知識を有し一定水準以上の年収を得る労働者について、労働時間規制の対象から除外する仕組みである。

労働時間と賃金との関係を切断するもので、対象とされた労働者は、時間外労働・休日労働・深夜労働に対する割増賃金の支払いを受けないが、他方自由な時間で働くことを使用者から認められる、とされる。

高度プロフェッショナル制度 - Wikipedia

主に「雇用者 (経営者)」と「被雇用者 (労働者)」の間の利害対立を焦点として語られることの多いこの話題について、私のようなフリーランスは蚊帳の外に置かれている感はありますが、今回はこれについて個人的に思うところを述べてみたいと思います。

ソフトウェア開発の分野では、やってはいけない (やらない方がよい) 設計や実装の類型は「アンチパターン (anti-patterns)」として共有・認知されています。 個人的な観測の範囲でも、方々の現場で頻繁に目にするものとしては以下のようなものが挙げられるでしょうか:

魔法のボタン (英語版)

抽象化を行わず、インタフェースコードの中でロジックを実装してしまうこと

円-楕円問題 (英語版)

変更できない型から変更可能な派生型を作成する際の問題

定数インターフェイス (英語版)

インターフェイスを定数の定義に用いること

特殊事項によるコーディング (英語版)

特殊なケースが認識される度に、それに対応するコードを追加する

書き直しプログラミング（英語版）/偶然にもとづくプログラミング

コードを徐々に修正しながら動くかどうかを確認することで、問題を解決しようとする

アンチパターン - Wikipedia

Java で書かれたシステムにおいて、定義されているほぼすべてのクラスが "Constants" という (あるいは "SystemSettings" のような) 名前のインターフェイスを実装している、という「定数インターフェイス」などはもはや見慣れた風景。 「試験 (テスト) 工程の充実」をコンセプトとして掲げる開発現場の実態が、実は単なる「書き直しプログラミング」の連続でしかない、などといったケースも珍しいものではありません。

コード全体が非常に「雑」に書かれており、ブラックボックステストによってかろうじて動作が保証されているシステムというのは頻繁に眼にするところ。

内製のススメ

データベース設計についても、こうしたアンチパターンは存在しており、関係データベースにおける配列の表現 で取り上げたような「カラムの反復定義」や「カンマ区切り」で配列を表現する手法などがそれに該当します。 こうした「べからず集」はいずれも経験に裏打ちされた実効性のあるものなのですが、その中に「これはアンチパターンに含めるべきではないのでは?」と思わざるを得ないものがひとつ。 それが、このエントリのテーマである "Naive Tree (素朴な木)" です。

普段はもっぱらウェブアプリケーションの開発ばかりやっているのですが、縁あって年に1～2度の頻度で研究・教育系のグラフィカルなシステムの制作も行っています。

コンピュータが取り扱う「データ」とはつまるところ「数値の羅列」ですが、並べられた大量の数字、たとえば以下のような表を眺めていても、そのデータにどのような性質・特徴があるのかといったことは見えてこないでしょう。

数十万から数百万レコードにも及ぶ大量のデータをそのまま把握することは不可能なので、適切な可視化を行う必要があります。 しかし、これらのデータは時間的な変化を含めて4～6 (ときにはそれ以上) の次元・自由度を持つため、単純なグラフ化はもとより、単純な3次元空間へのプロットでは充分な表現を得ることは望めません。

そのため、データの特徴とその意味を考慮しながら適切な可視化手法を考案･実装する必要が生じてきます。 今回紹介するのは、そうした特殊な可視化を行うためのプログラムですが、詳細についての説明はあまりにも入り組んでいるため割愛。 皆様には風変わりなスクリーンショットを眺めて楽しんでいただければ幸いです。

事業の5年目にあたる前期は、皆様のご支援により独立以来最高の売上を記録することができました。 その分、今期の市県民税や各種保険料が跳ね上がり、今月は通帳からゴソッと大金が消えてやや気分が落ち込んだりもしておりますが、これは「嬉しい悲鳴」の範疇でしょうか。 それだけに今年以降もこの業績を伸ばしていく手段を考えていかなければ、ジリ貧に陥り、当面の目標である法人化も遠のいてしまうため、現状に満足してしまうことなく一層精進していく所存です。

ところで、事業を「法人化」するということは「雇用」を行うということでもあり、それは即ち「給与」の支払いという義務を負うこと。 給与を含め、人件費は事業にかかる費用の中でも特に大きな割合を占めるもののひとつであり、世の経営者たちはこれを削減する方法の模索に余念がありません。 そのための道具を作り・売ることで成り立っているIT業界に身を置く私自身、あちらこちらのオフィスで日々営まれている各種の業務を効率化 (あるいは自動化) する方法はないものかということに常に頭をめぐらせているわけですが、そんな立ち位置から眺めていると、自動化・合理化による削減以前のレベルで、本質的にまったく不要な人件費を垂れ流しているプロジェクトを頻繁に目にすることに。

前期より業務内容に「開発コンサルティング」を加えたこともあるので、今回のエントリではそうしたプロジェクトにおける無駄について、思うところを述べてみたいと思います。

昨月、4年と9ヶ月に及ぶ使用を経てソフト・ハード両面において限界を超えつつあったスマートフォン (Xperia Acro) を新しい機種 (Xperia X Performance) へと買い換えてきました。 更にノートPCが仕事で必要になったため、こちらも新しいものを購入。 私はもともとガジェットの類にあまり強い関心を持たない人間であるため、買い替えとなると技術的な世代のギャップを渡ることになるのが常。 今回は Androd のバージョンは 2.3.4 から 6.0.1、Windows は 7 から 10 というロングジャンプをすることに。

ここまで足長の移行を遂げると、モノの良し悪しはさておき、まずユーザインターフェイスの様変わりに面食らうことになるわけですが、その変化の中には、何を考えてそのようにしたのか理解に苦しむものが少なからず見受けられます。 もちろん、技術の進歩によって、それまでは「使い物にならない」とみなされてきた設計が「理に適ったカタチ」として受け入れられてきた例も数多くあるわけですが、それを考慮に入れてもなお、とても及第点を与えられないようなデザインが蔓延してはいないでしょうか。

今回は、私が新規に購入したふたつのデバイスを例として、近年のトレンドとなっているUIデザインの問題について論じてみようと思います。

甲府では猛暑の日々が続いておりますが、皆様におかれましては如何お過ごしでしょうか。 独立のためにこちらへ引っ越してきたときは、同じ盆地でありながら会津より一段格上の暑さに驚いたものですが、そんなことも今は昔。 五年目ともなれば、さすがにこちらの気候にも慣れ、炎天と熱帯夜を凌ぐための心得と工夫ができるようになってきました。

仕事においても、当初こそは営業回りや他社様のオフィスに入って仕事をさせて頂くことに戸惑うことも多々ありましたが、近年ではそれらの見通しや段取りをある程度は付けることができるようになり、時間・体力の過剰な消耗を避けることができるようになってきたところ。 ただし、こうした「慣れ」はともすれば「慢心」や「油断」につながる危険を多分に含んでいるため、今後も初心を忘れることのないようにせねば、と気持ちを新たにしております。

独立4周年まとめとして昨年公開したエントリでは、ソフトウェア開発における「組織」が果たす役割とその必要性について私が経験した範囲で思ったことを幾つか述べました。

ある程度の規模以上のソフトウェア開発には、設計や実装以外にも多くの職能を持つ人間が携わります。 その際、個人で賄うことが特に難しいのが、全体の調整と金銭まわりの処理、そして顧客 (発注者) との遣り取り。 例えば、各機能をどの順で、それぞれいつまでに作るかというスケジュールは技術的な要因だけでなく、他部門のスタッフやレビューの実施計画によって応じて決める必要があります。 また、開発中に仕様変更などがあった場合には、スケジュール変更や予算の調整なども必要になるでしょう。 スタッフの雇用契約に関する処理も適切に行わなければならず、そのためには各種の法律に関する知識やある程度の実務経験が欠かせません。 また、仕入れに関して発注者からの前払いが受けられない場合は、その分を立て替えなければなりませんが、個人事業主のレベルでは不可能なほど大きな金額になることもしばしばです。

そして何より、そうした大規模なプロジェクトの業務は個人の事情で遅滞させることは許されず、誰かが職務を遂行できなくなった場合に代替の人員を充てる (場合によっては新たに雇用する) ことが必要となるわけですが、そうしたバックアップ体制は組織にしか持ち得ないもの。 そうした「確実性」「信頼性」の有無こそが、個人と組織の達成しうる成果を分ける要因であり、また、趣味的なソフトウェア開発とビジネスにおけるそれの違いでもあるわけです。 会社あるいは担当者によって、そのこなし方の上手い/下手の差はありますが、いずれにせよ、20年前であればいざ知らず、現代のソフトウェア開発はそうした「組織の力」なしには成立しません。

The 4th Anniversary

しかしながら、そこには「組織」であるが故に生じる問題もあり、良いことづくめというわけではありません。 今回はそうした問題が発生する要因と、それらへの対策について思うところを述べてみたいと思います。

エンジニアと疑似科学 (前編) では幾つかの疑似科学とそれを受け入れてしまったエンジニアの事例を紹介しました。 私たちが暮らすこの社会の科学リテラシーの低下は、実に嘆かわしい......かどうかはさておき、読者諸兄の中には、次のような疑問を持っている方もいらっしゃるかも知れません。

確かに、エンジニアであろうとも、何を信じるかは個人の自由。 それによって法的に罰されることはありませんし、また、そんなことがあってはいけません。 しかしその一方で、科学・工学の知見と合致しないものをその対象として選ぶということは、エンジニアとしての資質を決定的決に欠くことの証左でもあります。

コンピュータ技術者は例外的に免許制度のない分野ですが、医師や各種技師をはじめとする技術職は、その職務を遂行するにあたって国家ないしそれに準ずる機関による認可が必要であることが一般的。 これは、エンジニアとは程度の差こそあれ、人間の生命・財産に関わる作業・操作を行う職業であるため、当座の業務遂行のための知識・技術のみならず、その技術と社会の関わりについての認識、マニュアル化しきれない瑣末な事案や突発的な事象に対応するための考え方を身に付けることが求められるからです。

疑似科学やオカルトの理論は、科学・工学の知見とは決して相容れない性質のもの。 何故ならば、科学的に証明されていないことを証明したと主張するのが疑似科学の疑似科学たる所以であり、科学的に不可能であるとされることをやってのけると主張するのがオカルトのオカルトたる所以だからです。 これを受け入れているということは、少なくとも両者が説くところが食い違う部分では、科学の知見の方を否定しているということに他なりません。 そのうちのどれか一つ、殊に科学・工学の基礎となっているような根本的な知見を否定する者はいずれ、そこから論理的に繋がる知見の連なり・積み重ねから成り立っている科学という枠組みへの信頼を全面的に放棄せざるを得なくなる、というのは当然の帰結です。

前編で紹介した血液型性格判断やモーツァルト効果、ガイア理論といった疑似科学・オカルトは、それを信じてしまっても差し迫った問題を招くことのないものでした。 しかし、それらを受け入れることは懐疑的な思考を鈍らせ、より危険な理論への抵抗力を失わせるでしょう。 この後編では、科学に背を向けたエンジニアが如何に危険な存在であるか、それによって支えられる社会がどれほど脆いものかということについて考えてみたいと思います。

やや昔のことになりますが、私を含め数人のソフトウェア技術者 (プログラマ, システムエンジニア) で「上司や他の部署からの無茶な追加作業要求から如何にして自分のスケジュールを守るか」という話をしていたときのこと。 ひとりの参加者から、次のような質問が飛び出しました。

一体何を言い出すのかと面食らいつつも黙って彼の話を聞いてみるに、曰く

• O型の人は、頼まれ事を断るのが苦手である。
• 特に、相手がB型の場合は押し切られてしまいやすい。

要するに、血液型性格分類をベースとした「考察」の一形態です。

血液型性格分類は「コテコテの」と形容したくなるほど典型的な疑似科学ですが、日本では世間的に広く浸透しており、少なくない割合の人によって信じられている (とまではいかずとも、幾許かの「事実」を含むものと見なされている) 説であることはご存知の通り。 身近な人の口からこれを聞いたところで、今更驚くには当たらないのかもしれません。 しかしながら私は、それがエンジニア、即ち、物事の有り様を客観的に捉え、これを科学的な知見と手法によって制御し役立てることを職能とする人間の言葉として発されたことに強い衝撃を、もっと言えば、失望と危惧を覚えました。

疑似科学やオカルトの類から最も遠い場所に立つべきエンジニアが、意外にもそれらを受け入れてしまうのは何故なのか。 このエントリでは、具体的な疑似科学の例を挙げながら、その背景と問題点について論じてみたいと思います。

システムで扱われるデータの設計をしていると、「細部は異なるけれども、共通する部分を持つ」一連のバリエーションと呼べるものが出てくることが多々あります。 例えば、ある物販システムが扱う商品に、「食品」「衣料」「書籍」という区分があったとして、それぞれが次のようなデータ構造を持つとしましょう。

食品

商品ID, 名称, 取扱業者ID, 価格, 内容量, 消費期限, 品切れフラグ

衣料

商品ID, 名称, 取扱業者ID, 価格, サイズ下限, サイズ上限, 品切れフラグ

書籍

商品ID, 名称, 著者名, ISBN, 取扱業者ID, 価格, 品切れフラグ

こうしたデータ型をオブジェクト指向プログラミング言語で扱う場合、まず共通する属性をまとめて「商品」を表す抽象クラスとして定義し、これを継承して「食品」「衣料」「書籍」を表す具象クラスを定義するのが一般的なやり方です。

//商品
class Product {
    UINT    uID;      //ID
    String  name;     //名称
    UINT    uDealer;  //取扱業者ID
    int     nPrice;   //価格 (単位: 円)
    bool    bSoldOut; //品切れフラグ
};

//食品
class Food : Product {
    int     nNet;       //内容量 (単位: g)
    Date    dateExpire; //消費期限
};

//衣料
class Cloth : Product {
    int nHeightMin; //サイズ下限 (身長 / 単位: cm)
    int nHeightMax; //サイズ上限 (身長 / 単位: cm)
};

//書籍
class Book : Product {
    String  author; //著者名
    String  isbn;   //ISBN
};

こうした設計手法は業界的にも概ね「常識」として定着しているようで、ここまでのところであまり問題のある開発現場に遭遇することはありません。 ところが、このデータ構造を関係データベース上で表現する段になると、途端におかしな設計が目に付くようになります。