flint>flint blog
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »

グラフィカルなお仕事

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

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

ID X Y Z Time Voltage
107556 253 44 111 4190 -0.217001
107557 254 44 111 4190 -0.199018
107558 255 44 111 4190 -0.000210
107559 0 45 111 4190 0.043779
107560 1 45 111 4190 0.155322
107561 2 45 111 4190 0.154002
107562 3 45 111 4190 0.003454

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

The 6th Anniversary

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

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

UI設計という職能

ノートPCとスマートフォン

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

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

The 5th Anniversary

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

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

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

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

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

エンジニアと疑似科学 (後編)

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

何故、エンジニア (技術者) だけを殊更に問題視するのか? エンジニアであろうと一般人 (非技術者) であろうと、自分が真実であると思うもの (たとえそれが疑似科学とされるものであっても) を信じる権利は等しく保障されるべきではないのか?

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

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

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

エンジニアと疑似科学 (前編)

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

皆さん、血液型は何型ですか?

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

  • 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
};

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

生トマトドリンク

7月も残すところあと少し。甲府は最高気温33~34℃という灼熱の日が続いていますが、皆様におかれましては如何お過ごしでしょうか。 連日こうも暑いと、調理をするのはおろか、食事を摂ることそのものすら億劫になってきますね。 私自身そうした傾向が顕著なので、「夏を乗り切る」料理のレパートリー拡充は重要な課題だったり。

そんなわけで、今回は一般的なトマトジュースとは一味違う、トマトを使った特製飲料の作り方を紹介したいと思います。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

The 4th Anniversary

月日の過ぎるのは本当に早いもので、独立してから4年が経ちました。 未だ法人化もできてはいませんが、それでも縁故もなかったこの山梨で事業を継続できているのは、ひとえに周囲の皆様の力添えによるものでしょう。

さて、これまでの仕事であちこちの現場に入らせて頂いていますが、その在り方は本当に多様です。 規則・規約でアウトプットの内容と形式を厳格に制限し、技術者を「部品として扱う」ことが徹底されているところもあれば、「技術者に (しかも外部委託先である私) にここまでの裁量を与えて大丈夫なのだろうか」とこちらが心配になるほど奔放な会社も。 また、内部の雰囲気についても然りで、従業員間で公私共に良い関係が築かれている職場もあれば、互いのプライバシーには極力干渉しないといったスタイルもありで、一概にどれが良い・正しいと言えるものではありませんが、そうした違いを観察できるのは、個人事業主ならではの醍醐味かも知れません。

そんなわけで、このエントリでは、そうした多様な現場を渡り歩いた経験から、特定の企業・団体に限らず、IT業界全体 (といっても私の観測範囲など多寡が知れていますが) について私が感じていることを述べてみることにします。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

引数のデザイン

私が受ける仕事には、新規のプログラムを開発するのではなく、既存のプログラムの動作を変更したり、新しい機能を追加したりする「改修案件」が多く含まれています。 この改修案件では、新規開発と比べて、書かなければならないコードの量はずっと少なくなるのですが、その前段階にある「他人が書いたコードを読み解く作業」がなかなかのクセモノ。 つい先日も、JavaScript を使用したウェブページ上のアニメーションの改修作業を行ったのですが、まず既存コードがどのような動きをするのかを調べるのに大変な苦労をしました。

そのコードの動作を追うのが難しい理由は色々ありますが、最も大きな要因は、プログラム内で定義されている各関数の使い方が分かりづらいこと。 関数とは処理のシーケンスの中から関連する部分を分離して名前を与えたものであり、プログラムを読み解くための重要な手掛かりとなります。 しかしそれ故に、関数の設計が適切になされていないプログラムの読解は非常に厄介なものになってしまいます。

通常、プログラムを書くときは、処理をただ順番に書き下すのではなく、いくつかの「関数」に分割します。 これによって各ステップの処理が部品化され、再利用が可能になるわけですが、関数分けの効用はそれだけに留まりません。 たとえ、たった一度しか実行されない処理でも、これらを上手く関数化し、本体から分離することで、プログラムの可読性・保守性を向上させることができます。

flint blog: 関数分けの効用
>> 続きを読む
成田
このエントリーをはてなブックマークに追加
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »