通のツール

私がパソコンを使う際には、マウスではなくポインティング・スティック（トラックポイント）を愛用している。会社のデスクトップ・パソコンにも、それが付属したキーボードを個人的に購入して繋いでいるくらいである。しかし、ポインティングスティックを搭載したノート・パソコンは種類が少なく、残念な限りである。

ポインティング・スティックがその機能性の割に普及しないのはなぜか。製造コストの問題もあるが、それよりも「とっつきにくい」ということのほうが重大なように思う。トラックポイントの開発担当者は「10分も使えばなれる」と言うが、店頭で10分も触る人がいるとは思えない。ThinkPad を購入した（あるいは支給された）としても、タッチパッドも付いているし、マウスも繋げる。それらに慣れたユーザーが10分間もトラックポイントを使い続ける機会はほとんどないだろう。

★

このように、便利な道具の中には、ある程度の慣れが必要なものも多いが、多くの人が触れる機会を持たないためにメジャーになりきれないというものがある。

もう十数年前の話だが、私の所属していた大学の研究室に「筋金入りのマック・ユーザー」というのがいて、いつも MS-DOS のコマンドラインによる操作方法を「呪文」と称して皮肉っていた（当時、GUI は Macintosh の十八番だった）。しかし、そんな彼が、ある研究の一環で UNIX 系の OS に触れるようになってからは、CUI の利点に気づかされたという話をしてくれた。GUI は「とっつきやすい」が、必ずしも CUI より便利というわけではない（詳細は「コマンドラインのすすめ」を参照）。

★

プログラミング言語についても同じことが言える。もう６年ほど前だろうか、常駐先で会った人に Ruby を薦められた。といっても、当時の Ruby は企業の開発プロジェクトで使うようなメジャーな言語ではなかった。自分で使う「ちょんプロ」を作るための言語としてである。しかし、当時の私は Perl を覚えたばかりだったし、それ以上の必要性も感じなかったので、結局使わなかった。近年の Ruby の評判を見るにつけ、あの時から使っておけばよかったな、と思うのである。

★

先に「道具」と書いたのだが、「書類の書き方」でも同じようなことがある。この仕事をしていると、顧客から見慣れない書式の図や表を見せられることがある。顧客側は「これが一番分かりやすい資料だ」というのだが、何が書いてあるのかさっぱり分からない。その資料はとりあえず無視して業務分析をしてみると、後になって「なるほど、確かに分かりやすい資料だ」と思えてくることがある。はじめからその資料を理解した方が早かっただろう。

★

「通」が使うような難しい道具に見えるものであっても、試してみれば意外と簡単に使えることもある。誰かが便利だというものは、積極的に試してみたいものである。

応援のクリックお願いします →

ぷらっとホーム Mini Keyboard III 日本語版 HMB633PJP

posted with amazlet at 08.05.07

ぷらっとホーム
売り上げランキング: 86676

おすすめ度の平均:

打鍵感のある省スペースキーボード

Amazon.co.jp で詳細を見る

Rubyスクリプティングテクニック ―テスト駆動による日常業務処理術

posted with amazlet at 08.05.07

Brian Marick
オライリー・ジャパン
売り上げランキング: 78287

おすすめ度の平均:

ツールを書くのにRubyを使うという本

Amazon.co.jp で詳細を見る

感情の行き違い

技術者同士でシステムの設計方針などについて話していると、白熱してしまうことがある。お互い、声も大きくなってしまっているのだろう。傍から見ていると、喧嘩でもしているかのように見えるらしい。後から「あの人とやりあってましたね」などと言われるが、なんのことか分からない。本人たちは議論を楽しんでいるくらいなのだ。

★

会議の議事録でも、そういう誤解が起こりやすい。終始和やかな雰囲気の会議だったはずなのに、後から議事録を読むと、言い争いをしていたかのような印象を受けることがある。会議中、相手に気を使って、わざわざ婉曲な表現で話したのに、断定的な文章になって残されてしまったりする。

会議に出席している人が読むだけなら、大きな問題はないのだが、出席していない人に誤解され、いらぬ心配をさせたりすることもある。

議事録を書く人の力量にもよるが、ビジネス文書の形で、会議の雰囲気まで伝えることは容易ではない。

★

もっと危険なのはメールである。やりとりをしている当人同士が相手の感情を誤解してしまうこともあるからだ。「怒っているのだろうか？」と思うようなメールが届いたので、相手に電話してみると全くそんなことはなく、笑って話をしたというような経験はないだろうか？

そうやって電話をすればいいのだが、怒っているように見えるメールに対して、こちらもムキになって対抗するようなメールを返すと、険悪なやりとりになる可能性もある。

議事録の例と同じように、ビジネス上のメールは、固い文章になりがちだ。特に、否定的な内容を書く時には怒っているように取られがちなので、意識して柔らかく表現する方がよい。単に丁寧な言葉にするだけでは逆に慇懃無礼に感じられることもある。断定的な表現を避けるとか、口語を交えるといった方法がよいのではないだろうか（例えば「です」を「ですよね？」とするなど）。相手によっては、顔文字を使うのも悪くないと思う（これは、賛否両論あるかもしれないが）。

もちろん、やりすぎると、ふざけているように見えたり、失礼に当たることもあるので、難しいところではある。

★

事務的に仕事をしていると、人の「感情」などは情報として不要であるかのように扱われることもある。しかし、関係者の感情面がうまくいかなければ、仕事もうまくいかない。なるべく誤解や行き違いがないようなコミュニケーションを心がけたいものである。

応援のクリックお願いします →

最初の3秒で心をつかむビジネス文章術

posted with amazlet at 08.04.14

堀内伸浩
日本実業出版社
売り上げランキング: 2512

おすすめ度の平均:

タイトルにひかれて買いました

埋もれてしまいかねないメールを救う本

ほんのちょっとの心遣い

Amazon.co.jp で詳細を見る

成功する!「ビジネスメール」入門 (主婦の友ベストBOOKS)

posted with amazlet at 08.04.14

主婦の友社
売り上げランキング: 36740

おすすめ度の平均:

知っておきたいビジネスメールのあれこれ

Amazon.co.jp で詳細を見る

ドキュメント内のリテラルにも注意

アプリケーション開発では、「なんとか区分」とか「なんとかステータス」などといったデータを扱うことがよくある。例えば、

承認ステータス: 0=申請中, 1=承認済, 2=差戻し

というように、決まった値を持つようなもの（名義尺度や順序尺度）である。

プログラミングでこうした値を扱う場合は、数値やコード値をそのまま（リテラル）では記述せず、定数を定義して、それを使う。あるいは、「列挙型」を扱える言語であれば、そちらを使う。

ソースコードが読みやすくなるのはもちろん、数字と「意味」の対応が変わった時に、定義だけを変えれば対応できるからだ。例えば、途中に新しいステータスが挿入されて後ろの数字がずれたとしても、既存のソースコードには影響しない（もちろん、挿入したステータスを使う必要がある箇所は別だし、新しいステータスの追加により「意味」が微妙に変わったりすると、修正が必要にはなるが）。

これはプログラマにとっては基本的なテクニックであり、初心者の書いたコードでもそうなっていることがほとんどだろう。

★

しかし、どういうわけか、設計書等のドキュメントでは、数字がそのまま書いてあるようなものをよく見かける。

承認ステータスが 2 のデータを検索する

といった具合である。これではどんなデータを検索しているのか、直感的に分からない。別途、ステータスの意味が冒頭のように定義されているのなら、

承認ステータスが「差戻し」のデータを検索する

でよいだろう。何らかの理由で数字を直接書くというルール（文化）だったとしても、

承認ステータスが 2（差戻し）のデータを検索する

という具合に、補足的に「意味」を書いた方がよい。

★

ドキュメントに数字を直接書くと、後から値の意味が変わった場合に、修正箇所が非常に大きくなる。しかも、可読性が悪いため、修正ミスに繋がりやすい。そのあたりの事情はソースコードと全く同じである。

通常、こうした数字の変更は、単純に置換すればよい、というわけにはいかない（そもそも、数字だと、関係ない色々な箇所がマッチするので、検索しにくいという問題もある）。例えば、上記の定義が、

承認ステータス: 0=申請中, 1=課長承認済, 2=部長承認済, 3=差戻し

に変更になったとしよう。

この場合、「2」を「3」に変更するという他に、「1」を「2」に変更するケースもあるだろう。これを無計画に数字だけを見てやっていると、変更途中のある時点での「2」が、元々「2」だったのか、元は「1」だったものが「2」に修正された結果なのか分からなくなる。つまり、元々「1」だったものを誤って「3」にしてしまう危険性が出てくる。実際には、「1」については、「2」にするという変更以外にも、「1」のまま修正しない、「1 または 2」にする、「1 かつ 2」にするなど、複数の修正パターンが発生するため、混乱しやすい。

・・・と、この文章も既に何を書いているのか分からなくなってきている。これ自体、数字による表記がいかに分かりにくいか、ということを示している。

このような変更が発生した場合、数字ではなく「意味」で記述している場合も、修正が全く不要になるわけではない。しかし、少なくとも「差戻し」については変更不要である（※）。「承認済」についても、「課長」や「部長」の文字がなければ、未修正であることが一目瞭然なので、修正が漏れにくい（ソースコードで、定数名の定義を変更してコンパイルエラーを発生させるのと同様である）。

数字と「意味」を併記する方法では、修正箇所が少なくなるわけではないが、数字だけの場合に比べると、やはり修正箇所を見つけやすい。また、修正漏れがあっても、定義と一致しない記述が残ることになるので、後から見たときに発見しやすいというメリットもある。

★

仕様変更に対する対応が大変なのは、ソースコードもドキュメントも同じである。むしろ、ソースコードの方が、開発ツール等が充実している分、簡単かつ安全に修正できるのではないだろうか。ドキュメントを記述する際には、プログラミング以上に、将来の修正に対する配慮があってもよいだろう。

応援のクリックお願いします →

※「承認済」という表現を「課長承認済かつ部長承認済」と再定義してしまうことで、修正範囲をもう少し減らせる可能性はある。ただし、その場合は、「承認済」という記述が残っていれば「未修正箇所」である、という短絡的な判断ができなくなるため、得策ではないかもしれない。

SEの文章術 [技評SE新書] (技評SE新書 10)

posted with amazlet on 08.03.09

克元亮
技術評論社 (2007/05/03)
売り上げランキング: 14515

おすすめ度の平均:

文章力に不安のあるSEの方は必読です。

SEであるか否かを問わず自分のドキュメントを最適化していく為に好適な良書

Amazon.co.jp で詳細を見る

90分で学べるSEの文書技術 (ITプロフェッショナルの基礎知識)

posted with amazlet on 08.03.09

高橋慈子
日経BP社 (2005/06/02)
売り上げランキング: 61805

おすすめ度の平均:

自分の文章を見直すきっかけになるかも

ラブソン歌ってる

日頃の仕事のシーンに役立つ一冊！

Amazon.co.jp で詳細を見る

車輪を発明しようとする前に

プログラミングをしていて、何か機能が必要になったとき、「こういう機能は既に誰かが作っているのではないか」と考えてみることは重要である。そういう発想がないと「車輪の再発明」をしてしまう。何でも自作しないと気がすまない人もいるが、既に安定して動くコードやライブラリがあるのなら、それを流用した方が効率がよいことは言うまでもない（プログラミング自体の勉強が目的なら別だが）。

★

もちろん、事前に、既存のコードやライブラリを探す場合と自作する場合とで、どちらが時間が掛かりそうかを判断する必要がある。

そのためには、自分のプログラミング能力と、調査能力を把握しておかなければならない。調査能力については、ネットの「検索力」も重要だが、周囲の人や掲示板等への「質問力」なども影響する。

そして、もっと重要なのは、探そうとしている処理のニーズ（一般性と言ってもいい）を見極めることだ。多くの人が必要としそうな処理ならすぐに見つかるが、限られた人しか必要としないようなものは見つからない。当り前のことだが、その境界がうまく見極められない人もいる。

自分で判断がつかない時は、制限時間を決めて探してみて、時間内に見つからなければ自作する、という方法を取ることもできる。

★

次に、品質の判断が必要である。見つけたプログラムが信頼できるかどうか、ということである。ソースコードの記述内容の確認や動作を確認するのはもちろんだが、他の人がどの程度利用しているか、その評価はどうか、といった利用実績に関する情報は大きな判断材料となる。

また、配布元の Web サイトにメンテナンス情報やサポート掲示板などがあれば、その情報が参考になる。そういったものがなくても、作者が技術的な内容の文章を公開しているようなら、（たとえそれが必要としているプログラムとは関係のない情報であっても）その内容から、ある程度、技術レベルの判断ができるだろう。

★

「車輪の再発明」は、新しいプログラミング言語を使う場面でも起こりうる。最近は、言語の標準機能が充実しすぎて、その全てを把握することが困難になってきているからだ。「こういう機能ぐらい、標準で付いてるだろう」といった見当をつけることができなければ、標準の機能まで自作してしまいかねないのである。

この問題については、事前にその言語のリファレンス等にざっと目を通しておくと、かなり改善する。詳細な仕様まで覚える必要はなく、「そういえば、こういう機能は標準で用意されていたような・・・」という程度に思い出せれば十分だ。詳細は、本当に必要になった時に調べればよい。

インターネットやオンラインヘルプは必要な情報をピンポイントで調べるには向いている。しかし、どんな機能があるのかという観点で全体を眺めておきたいような場合には、本の形の方が向いている。新しい言語を学ぶ場合には、標準ライブラリ等の機能を網羅したリファレンス系の書籍が一冊あるといいだろう。

応援のクリックお願いします →

・頭を使って探せ
・ソースコードの盗み方
・簡単コピー・プログラミングの罠
・プログラミングの入門書は何が良いか？

Boost C++Librariesプログラミング第2版

posted with amazlet on 08.02.02

稲葉一浩
秀和システム (2007/07)
売り上げランキング: 22671

おすすめ度の平均:

boostを初めて使う方、既に使用している方どちらも持っていて損はありません

Amazon.co.jp で詳細を見る

Jakarta Commons クックブック―Javaプロジェクト必須のレシピ集

posted with amazlet on 08.02.02

ティモシー・M. オブライエン Timothy M. O’Brien 長瀬嘉秀テクノロジックアート
オライリージャパン (2005/08)
売り上げランキング: 140918

おすすめ度の平均:

分かりやすい

まずは目次を見てから

「ツチブタ」本として、広く読まれてほしい一冊です

Amazon.co.jp で詳細を見る

スキルアップのためにラップを剥がしてみる

仕事で会計関連のバッチ処理を設計しているところなのだが、機能のほとんどが数値を操作するだけのいわゆる業務ロジック（ビジネスロジック）なので、ちっとも面白くない。そういえば、WEB+DB PRESS Vol.38 の特集に、「"業務ロジックしか書きたくない人" のための書かない技術」というタイトルを見て、違和感を感じた記憶がある。

もちろん、このタイトルの意味は理解している。「業務ロジック」というのは、ユーザーの業務に特化した処理である。そのため、それぞれのシステムによって処理内容が違い、その都度新しく処理を「書く」必要がある。一方、業務ロジック以外の部分は、どのシステムでも似たようなものになりがちなので、ある程度は汎用的な仕組みでの対応が可能だ。システム開発の効率化を考えるとき、業務ロジック以外の部分の汎用性を高めて「書く量」を減らすというのは重要なことである。そういう意味で、「業務ロジックしか書きたくない」というのは自然な話である。

しかし、純粋な意味で「書きたいか、書きたくないか」と問われれば、私は業務ロジックをあまり書きたいとは思わない。ほとんどの場合、顧客の業務内容に興味は沸かないのである（もちろん例外はあるが）。むしろ、業務ロジック以外の部分を書くほうが面白い。例えば、そのシステム専用のアプリケーション・フレームワークや共通ライブラリを作ったりするようなことである。開発プロジェクトの中で、そういう仕事をするメンバーを「共通チーム」と呼んだりするが、そういったチームとして働く時の方が楽しい。

★

ある程度大きな規模のシステム開発では、「共通チーム」が専用のフレームワークを作り（あるいは既存のものを拡張し）、他のメンバーはその仕組みの中で動作する業務ロジックを書いていく、という形をとることが多いだろう。

つまり、多くのプログラマにとって、フレームワークは使うもの（使われるもの？）であり、作るものではない。以前、「簡単フレームワーク・プログラミングの罠」にも書いたが、このことは、プロジェクトの効率化という意味では好ましくとも、プログラマのスキルアップという意味では好ましくない。

業務ロジックだけを書いていたのでは、多くのシステムで必要なはずの基礎的な技術が身につかないからだ。例えば、データベースへの接続方法が分からないとか、適切な文字コードの変換方法が分からないといったことが起こる。ずっと業務ロジックだけを書いて生きていければいいのかもしれないが、現場ではそれ以上のことが求められることも多く、あわてて勉強するような人もいる。

★

コンピュータの世界は、問題を簡単にするための仕組みが積み重なって層を成しているように見える。ある「層」は、下の層にある複雑な問題を隠蔽する（プログラマ流に言えば「ラップ（Wrap）」する）ことで、機能を簡単に利用できるようにしている。業務ロジックだけを書く人が、フレームワークの中身を知る必要がないのと同じように、フレームワークを書く人も、言語の処理系（コンパイラやインタプリタ、VM など）の実装内容まで知る必要はない。こうした階層構造は、アプリケーションから OS、ハードウェアの領域に至るまで、幾重にも積み重なっている。技術者が効率的に分業できる仕組みになっているというわけである。

複雑化した現在のコンピュータについて、一人の人間が全ての階層について理解するのは難しい。しかし、自分のスキルを今以上に伸ばそうと思うなら、自分が今立っている「層」のひとつ下ぐらいは覗いてみることも必要だろう。端的に言えば、自分がいつも呼び出している「共通関数」のソースコードを読んでみることである。

それを面白いと感じないなら、なかなかできないことではあるが。

応援のクリックお願いします →