原理は単純を、構造は複雑を極め、人は最も人らしく。

twitterでも呟いてるけど、好きな言葉（名言・格言）の一つ。
プログラムやシステムに限らず、何かを作る人ならば何となく分かると思う（思いたいｗ）。
　
自分の場合、客の依頼で小さな業務用ツールを作ることも多い。企業内の業務システムへデータを流し込む前段階用のツールとか。
決して大きくないプログラムの場合が多いが、実業務に近い場所で日常的に使われる道具的なプログラムこそ、柔軟性が必要になってくる。そういう場合こそ、多少手間がかかっても動作や各種設定（エクセルで言えばセル座標とか）を最低限の手間で変更できる様な構造にするようにしてる。プログラムの中にパラメータを書き込まず、必ず別に設定リストを用意し、分かりやすい言葉で各パラメータに名前を付けたり、コメント・設定例を付けたり。
　
さすがに根本的な動作が変更になると追従できないが、扱う項目が１つ増える、リストの項目順が入れ替わる、といった些細な（しかし実業務においては、往々にして上司の好みや業務改革等で変わることが多かったりする）設定は、パラメータの書換だけで対応可能な作りが望ましい。
もちろんその作り込みの分だけ構造は複雑になり、内部に動的な配列を持ってパラメータを取り込んだり、設定を呼び出す関数を作る事になったりするが、こういうモノは他のプロジェクトにも流用可能な部品だし、実は見た目ほど高度な事はやってない。考え方は単純で、単に複雑（面倒）なだけ。
　
こういう、表面はシンプルに扱いやすくして内部はそれを支えるために複雑化・高度化する、という考え方は昔から自分の中の志向（嗜好？）としてあった。それがタイトルにある某コミックでの格言を見て脳内で具体化し、実際の業務でも「そうしておいて良かった」と思える場面をよく経験している。それは、「こんなこともあろうかと」的な、エンジニアとしてちょっと鼻が高くなる一瞬だったりする。
　
　
それから、他人が使うツールの場合は取扱説明書に力を入れると喜ばれる事が多い。何も知らない人に見せて一緒に２〜３回操作しながら教える場面を想定しながら作ると、特に。
噛み砕くと関係者には多少クドいと思われる様な説明書になってしまうが、異動等がよくある部署の客の場合などは、やたら詳細で分厚い仕様書を渡すよりも喜ばれる。この取扱説明書を渡しておくか否かで、その後のサポート・アフターケアも随分変わってくる。
以前に他人が作って納品したシステムのメンテをいくつか引き継いでいるが、当時の当事者達同士で納得していた画面設計や仕様やマニュアルに悩まされている現場を何度も見てきた。都度分かりやすく書き直した手順書をメール等で送ったりしているが、やはり未だ「オペレーターが恐る恐る扱うシステム」になっているようだ。使うのが怖いツールなんて（アウトプットが見事であっても）、それはダメなツールなんだと思う。
　
　
システムの画面設計や内部構造を考える時って、データやソースコードや難解な専門用語ばかりではなく、実は人間の思考や行動を意識することも多いから面白い。操作しやすい様に、メンテしやすい様に、そして前任者が後任者に説明しやすい様に、といった事を考えるうち、逆に動作仕様を変更するような場面もある。
　
システムを通して人を見る。
最近になって少しずつ、面白い仕事だと思える様になってきた。