一般の人には、「誰でもできそうな簡単なプログラミング」、あるいは「質の悪いプログラミング」といった意味にとられるかもしれない。

しかし、プログラミングについての文脈で「低レベル」といわれる場合は、通常は「ハードウェアに近い」という意味である。つまり、「低レベルなプログラミング」とは、「ハードウェアが理解する言葉」に近い（たとえばアセンブラのような）言語を使ったプログラミングだとか、直接ハードウェアに命令を送って制御するようなプログラミングのことである。

このハードウェアとの「近さ」は測定できる類のものではないが、プログラマ（あるいはその周辺の業界人）は、なんとなく了解していると思う。このブログの「スキルアップのためにラップを剥がしてみる 」というエントリで「層」と表現したものにも近いだろう。

もともと「レベル」という言葉は「何らかの基準」を意味しているだけである。それが何の基準であるか、ということは文脈によって変わるので、別段ここでの使われ方が特殊であるというわけではないだろう。

しかし、何の説明もなく「低レベル」という言葉を使うと、上記のような了解のない人には、「品質が低い」、「スキルが低い」といった侮蔑的な意味に誤解される可能性があるので、気をつけたい。

また、初心者プログラマの中には、そのような誤解をしてしまう人も多いかもしれない。あるいは「低レベル・プログラミング」と聞いて、「簡単そう」と思ってしまう人もいるかもしれない。しかし、低レベルなプログラミングほど難易度は高レベルだったりもするので、注意が必要である。

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

■関連記事
・普通の言葉
・「￥」について普通の感覚で考えてみる
・スキルアップのためにラップを剥がしてみる
・簡単フレームワーク・プログラミングの罠

CPUの創りかた

posted with amazlet at 09.05.05

渡波 郁
毎日コミュニケーションズ
売り上げランキング: 1745

おすすめ度の平均:

基本的な電子回路でCPUができる
趣味の本だよねぇ
読んでもすぐには理解できませんが、他のＣＰＵ本はもっと理解できません
ノイマン型コンピュータを自作する・・・名著かも
CPUの超基本構造

Amazon.co.jp で詳細を見る

真・コンピュータ用語辞典 (ホームページブックス)

posted with amazlet at 09.05.05

tell‐a‐lie
キルタイムコミュニケーション
売り上げランキング: 377785

Amazon.co.jp で詳細を見る

何らかのデータを変更するプログラムにおいて、保存されているデータを直接書き換えるのではなく、データをコピーしてからそのコピーを変更し、最終的に元のデータに書き戻す、という方法をとることがある。このとき、「コピーの方は変更されているが、元データには反映されていない」という状態を「ダーティである」という。

たとえば、ユーザーが画面でデータを編集するようなソフトでは、既存のデータを編集してそのまま終了しようとすると、「変更されています。保存しますか？」といったメッセージを表示するのが一般的だ。このような、データが「ダーティかどうか」という判定を「ダーティチェック」と呼んだりする。

また、データベースで「ダーティリード」という時の「ダーティ」も同じ意味だろう（「汚い」という英語の意味を考えるとこれが語源かも？）。

「ダーティ」という言葉を使わなくても、「データが変更されたかどうか」と言えば伝わるのだから、あえて使う必要もない、と思うかもしれない。

しかし、開発チームの中で、このような、「使わなくてもやっていけるが、使うと便利」というレベルの言葉がどれだけ共有されているか、ということは、円滑なプロジェクトの進行のための要素のひとつである。

また、言葉を共有することの効果は、コミュニケーション面の向上だけでなく、ものの考え方（システム開発であれば「設計思想」など）の共有にまで及ぶことも多く、侮れないものである。

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

■関連記事
・曖昧言葉

2009-'10年版 [最新] パソコン・IT用語事典

posted with amazlet at 09.03.22

堀本 勝久 大島 邦夫
技術評論社
売り上げランキング: 35830

Amazon.co.jp で詳細を見る

IT英語のナゾ

posted with amazlet at 09.03.22

豊沢 聡 緒方 孝文
カットシステム
売り上げランキング: 261531

おすすめ度の平均:

実務英語に即した本です。
多少勉強になる
もっと収録語数をしぼってくれたほうが、個人的にはよかった。
この著者は語学もコンピュータも詳しい
IT業界人に限らず 中級以上の英語学習者にもお勧め!!

Amazon.co.jp で詳細を見る

これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「本来の意図が伝わっていないな」と思うことは日常茶飯事である。

CodeZine の「コーディングスタイルの常識をぶち壊せ 」という記事のコメントや「はてブ」のコメントを読んでいて、改めて感じた。

この記事の２つ目のサンプルソースについて、「こんな用途に switch は使うべきでない」とか、「配列を使ったほうがよい」などというのは野暮である。「常識」的に考えて、この記事の著者も他の読者もそんなことは分かっているだろう。

ここでは、「同種の記述を繰り返す時は、複数行にせず、桁位置を揃えて書くと見やすい」と言っているだけである（つまり「表」のようなコードにしろと）。サンプルソースでは、その「同種の記述」の単純な例として、たまたま「２つの文字列リテラルの変数への代入文」が書かれているというだけである。もちろん、代入文である必要はなく、数値演算でも関数呼び出しでも、何でもよかったはずだ。

しかし、この何でもいいはずの処理内容（ここでは代入文）に引きずられてしまう読者は意外と多い。プログラマがソースコードを読むということは、普通なら「処理内容を理解する」ということなので、そういう読み方が染みついてしまうのだろう。「ソースはこう読むものだ」という「常識」にとらわれて読み方を変えることができないとも言える。

そういう意味で、「処理内容以外のことを伝える」ためのサンプルソースを作ることは難しい。

このブログでも、「コードの書き方」を論ずるためにサンプルソースを載せることがあるが、文章を書く以上に頭を悩ませる。「書き方」を見せるだけだから「処理内容」は何でもよい、といっても、リアリティがなければ上記のように読者の気が逸れてしまう。実例（職場で見つけたコード）を載せればリアルではあるが、逆に複雑になりすぎて論点がぼやけたり、一部だけ抜き出しても意味不明になったりする。

実は、上記の CodeZine の記事と似た内容の記事も書いたことがある。「あなたにもできること 」がそれだ。配列を使った簡単なサンプルソースを載せているだけだが、実はかなり悩んだ結果である。今読み返すと、あまりに説明が短いため、意図が伝わっていないような気もするので、ついでに補足しておこう。

コーディングの際、同じような処理を繰り返して書くときには、上に書いた行をコピーして下の行を作り、少しだけ改変していくような書き方をすることが多いと思う。が、そこで、改変し忘れるというミスをしたことはないだろうか？　この手のミスを防ぐには、どうすればよいだろうか？

最低限必要なことは、自分で書いたソースコードを読み返してチェックすることである。その時、「修正箇所」の桁位置が揃っていた方が、ガタガタと不揃いであるよりもずっとチェックしやすい。視線を縦に真っ直ぐ流せるからだ。

コードを印刷してチェックする場合は、指でなぞったり、ペンで印もつけやすい。画面でチェックする場合でも、カーソル（キャレット）を同じ桁位置で縦に動かして記述を追えるので確認しやすい。少なくとも私は、何度もそういう経験をしているので、自然とソースコードの桁を揃えるようになった。

このようなソース・チェック時のメリットは、CodeZine の記事で「ケアレスBUGの混入が防げるため、メンテナンス性が上が」ると書かれていることと同じだろう。CodeZine の記事では、「桁位置を揃える」というだけでなく、「複数行にまたがらせない」という点も例示されているという意味では、よい記事だと思う。

しかし、「メリット」の説明がこれだけでは不足だ。「そんなことは誰もが承知している」という前提で書かれているのだろう。つまり、プログラマの「常識」だと。しかし、ソースを読み返さないプログラマは、意外と多い（記述ミスは動作確認でも見つけられるので）。常識と思っていることも、本当は常識ではないのかもしれない。そういう意味でも、「常識をぶち壊す」ということは難しいものである。

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

■関連記事
・あなたにもできること
・誰のためのコード？
・まずは丁寧なプログラミングを
・プログラムは二度書け
・読者指向プログラミング

プログラマの完全常識 開発者が知っておくべきプロの知恵

posted with amazlet at 08.11.25

矢沢 久雄
技術評論社
売り上げランキング: 175375

おすすめ度の平均:

コンピューターを舞台裏から見よう
ソフトウェア業界で働く事を考えている人は読んでおいた方が良い。情報処理技術者試験対策としても。
プログラマ入門用本です。
プログラマの完全常識

Amazon.co.jp で詳細を見る

Code Reading―オープンソースから学ぶソフトウェア開発技法

posted with amazlet at 08.11.25

トップスタジオ まつもと ゆきひろ 平林 俊一 鵜飼 文敏
毎日コミュニケーションズ
売り上げランキング: 14938

おすすめ度の平均:

コードリーディングのイロハ＆必要な知識・技術の全装備
Code completeと併せて読むとよい
着眼点は良いと思う
意外なほどに教科書的な内容
ホップ・ステップ・ジャンプ

Amazon.co.jp で詳細を見る

・理論的にできる／できない
・技術的にできる／できない
・時間的にできる／できない
・費用的にできる／できない
・感情的にできる／できない

など。

ソフトウェア開発者の中には、理論的・技術的な可能性にしか注目しない人がいる。例えば、「既存のシステムにこんな機能を追加したいが、可能か？」という質問があったとする。それが、システムの仕様として矛盾がなく、実装方法が頭に浮かぶようなら、「できます」と答えてしまう。

しかし、ほとんどの仕事には「いつまでに（納期）」「いくらで（予算）」など、他の条件があるはずだ。質問者と回答者の間で、そうしたことが全く話題にならなかったとしたら、誤解が生じている可能性がある。回答者は多忙で寝る時間もない状態なのに、質問者は「頼んだらすぐやってくれるのだろう」と思ってしまうかもしれない。

ついでに書いておくと、「できるか？」という質問の答えは「はい」か「いいえ」である。上記のように「条件」によって答えが変わる場合があっても、結局は「はい」か「いいえ」だ。

ところが、「できるか？」と聞かれて「がんばります」と答える人がいる。それは、できるの、できないの？　がんばったらできるの？　できないけどがんばるの？

いずれにせよ、できない可能性があるということなので、リスクを考えると、「がんばります」＝「できない」と見なすしかない。

しかし、これを「できる」とみなす人もいて、困ってしまう。できる前提でスケジュールを立てて、結局は遅れてしまう。

その仕事の成果として最低限必要な部分を 100％ とすると、「できるか？」という質問に対しては、その 100％ の仕事ができるかできないかを明確に答えるべきである。「がんばる」という言葉を使うとしたら、更にそれ以上の成果、110％、120％ を目指す場合にしか使うべきでない。

プロジェクトでスケジュールを立てる場合、どの仕事を誰がどの期間で行うのか、ということを組み合わせていく。リーダーから各作業者に「できるか？」という質問がなされる場合も多いだろう。この際、各人の「見積能力」が重要なことは言うまでもないのだが、コミュニケーションについても注意が必要、という話である。

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

■関連記事
・どうして仕事を断らないのだろうか
・意気込みは分かったから...
・話が通じない話
・感情の行き違い

本当に使える見積もり技術―ソフトウエア開発を成功に導く

posted with amazlet at 08.10.26

初田 賢司
日経BP社
売り上げランキング: 20625

おすすめ度の平均:

FP法を詳説した良書
ズバリ良書だと思います
見積りの全体構造
ファンクションポイント法の使いこなし方

Amazon.co.jp で詳細を見る

速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS)

posted with amazlet at 08.10.26

田中 淳子
日経BP社
売り上げランキング: 17930

おすすめ度の平均:

もっと早く、この本のことを知っていれば・・・
コミュニケーションの大切さを実感！
SE以外の人にもお勧め！
速効性は高いですが…
図解・企業論文の書き方の著者の読後感想

Amazon.co.jp で詳細を見る

そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。

アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想である。これには、開発期間の不足や業務面・技術面でのスキル不足など、多くの問題があるが、最もやっかいなのは、多くのプログラマがコピー・プログラミングを好むということである。

あるプロジェクトで共通機能（基底クラス）を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。これには「プログラマの管理がうまくいっていない」という指摘もできる。しかし、それ以前に、プログラマに「コピー・プログラミングへの抵抗感がない」ということが問題なのである。

実際、多くの職業プログラマを自由にしておくと、むしろ好んでコピー・プログラミングを行うようである。みんなコピー・プログラミングが大好きなのだ。

たしかに、チーム開発で共通化をしようと思うと、他のメンバーと相談して仕様を決めたり、あるいは他のメンバーの作った複数のソースを変更したりと面倒なことは多い。そういう役割の人（「共通チーム」などと呼ばれる）ならともかく、単なる「一機能の担当者」であるプログラマが、共通化のためにそこまでの労力を払うことは、まずないだろう。

コピー・プログラミングなら、誰にも気兼ねすることなく、自分の担当機能を作ることができる。多くの職業プログラマにとっての最優先課題は「自分の担当機能を動くものに仕上げること」であって、「ソースコードが美しいかどうか」などは二の次なのである。

私はこれまでコピー・プログラムには何度も痛い目にあってきたので、自分のプロジェクトでは、いかにして共通化を徹底するか（コピーさせないか）、ということに頭を悩ませてきた。しかし、多くのプログラマがコピーが大好きなのだとすれば、それを前提とした開発方法を考えるのも一興である。たとえば、以下のようなことだ。

あらかじめ完成度の高い「コピー元」を用意する

「コピーされたもの」が分かるようにする

コピーしたコードは可能な限り変更しない

あるいは、開発ツールの助けにより、コピー・プログラミングの品質向上が見込めるかもしれない。既存のツールでも、例えば、Visual Studio 等の統合開発環境で、アプリケーションの雛形を作ってくれる「ウィザード」や、「よくあるコード」を挿入してくれる「コードスニペット」は、「コピー指向」であると言ってもいいだろう。ソースコードを現在のようなテキスト形式のみで保存することに拘らなければ、他にも色々な対策はできそうだ。例えば、どのコードがどこへコピーされたか、ということをエディタが記録してくれれば、後から追跡することが容易になるだろう。

私も「同じことを何度も書くべきではない」という考え方を変える気はない。しかし、同じプログラマといっても、プログラミングについて誰もが同じように考えているわけではない。むしろ自分のようなプログラマは少数派なのかもしれない。そう考えると、日々の「悪態」も少なくなってくるのである。

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

■関連記事
・簡単コピー・プログラミングの罠
・簡単フレームワーク・プログラミングの罠
・スキルアップのためにラップを剥がしてみる

アスペクト指向入門 -Java ・ オブジェクト指向から AspectJプログラミングへ

posted with amazlet at 08.09.26

千葉 滋
技術評論社
売り上げランキング: 158663

おすすめ度の平均:

入門書として良く出来てます

Amazon.co.jp で詳細を見る

初めてでもカンタン コピーするだけですぐに使えるJavaScript

posted with amazlet at 08.09.26

立山 秀利
ローカス
売り上げランキング: 115209

おすすめ度の平均:

「とにかく今すぐ使いたい」と言う人向きです。

Amazon.co.jp で詳細を見る

システムの要件定義（要求分析）は依頼者（顧客）と開発者が共同で行うものであり、漏れがあったとしても、どちらが悪いとも言い難い場合も多い。例えば、開発者の考慮不足とも言えるが、顧客側の情報提供が不足とも言えるというようなことだ。しかし、顧客は「金を払って依頼している」という意識が強いためか、開発会社の責任で修正させようすることも多い。

開発会社もある程度は折り込み済で、「手戻り」の時間を確保しているものだ。しかし、なにしろリリースまでの時間が残り少ない時のことである。「手戻り」の規模によっては間に合わないケースも多く、顧客との関係が悪化することもある。

開発者が「しかし、当初のお話では・・・」などと反論しようものなら、「こっちは客だぞてめえ」ぐらいのことは平気で言う人も。ビジネスの世界では金を払う人が偉いのである。

いわゆる「Ｖモデル 」に従って進めているとされるプロジェクトでは、こうしたトラブルがよくある。Ｖモデルの図をよく見ていると分かるのだが、開発の終盤に「当初のお話」が間違っていることに気がつくというのは、自然なことである。

Ｖ字の後半の右上がりの部分は、テスト工程を表している。この部分は、意地の悪い言い方をすれば、「先にプログラムの細かい枝葉を確認し、システムの拠り所である要件が正しいかどうかは最後に確認しましょう」ということになっているのである。最後に要件上の問題が見つかるのは当然である。しかも、顧客が要件を出したのは遙か昔のことなので、今更「当初のお話」をしたところで、「そんなこと言いましたっけ？」となるのも当然である。

もちろん、ここでのテストとは、あくまでも動作確認（動的テスト）の話である。要件定義自体のチェック（静的テスト）は、Ｖ字の「書き出し」に定義した時点で行われているはずであり 100% 問題ない、という前提（というか建前）で進んできているわけである。基本設計（外部設計）以降も同様だ。

しかし、この静的テストは、主に要件定義書や設計書などを作って「机上」で行われる。開発の当初、まだ影も形もない新しいシステムを 100% イメージできる人がいるだろうか？　もちろん、システムだけでなく、それを使った業務全体の運用イメージも必要なのだ。しかも、誰か１人が分かっていればよいというわけではない。そのイメージは、システムの素人である顧客と、業務の素人である開発者の間で、完全に共有しなければならない（出会って間がないにもかかわらず）。

実際のところ、そんなことはできないのである。結局、システム要件というものは、結局は開発期間の最初から最後までかけて、ああでもない、こうでもないと言いながら決めていくことになる。

いや、開発が終わってもそれは続く。完成した後で「ここはこうした方が良かった」と思わないようなシステムは、まずないだろう。ソフトウェアに限らず、実際に使ってみて初めて気がつくことがあるというのは、当然のことだ。

このように、仕様変更があるというのは自然なことであり、開発プロジェクトでは、変更があったときにどうするか、ということをあらかじめ決めておくということも重要である。

とはいえ、Ｖモデル（ウォーターフォール）での開発では、後半に発生する変更を少なくすることが最重要課題である。開発が終盤に近づくほど、残り期間が少なくなるし、同じ変更であっても手戻りの作業量も難易度も大きいからだ（既に作っている部分を直すため）。

このため、一番最初の要件定義の段階でいかにして精度の高い「完成図」をイメージするか、ということが非常に重要なのである。これは、開発側の視点でいえば、顧客に「どこまで本気で考えてもらえるか」ということにかかっている。

プロジェクトも始まったばかりのこの頃、顧客はのんきに構えているのが普通である。そして困ったことに、開発者にもそんな人は多い。会議を開いても、結論も出さずにあいまいな状態で終わったり、雑談ばかりしていたりする。「時間があるのだから、今考えなくてもいいでしょう？」などと思っているようだが、実はこの時が最も重要なのだ。Ｖモデルでは、最初はバリバリ、最後は淡々と仕事すべきなのである。

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

■関連記事
・怖いこと
・情報求む
・捨てるべきときには潔く
・簡単に見える時ほど注意せよ
・ちょっとしたプログラム

はじめての上流工程をやり抜くための本 (エンジニア道場)

posted with amazlet at 08.08.18

三輪 一郎
翔泳社
売り上げランキング: 6219

おすすめ度の平均:

上流経験者にもぜひ
濃い本です

Amazon.co.jp で詳細を見る

成功する要求仕様 失敗する要求仕様

posted with amazlet at 08.08.18

アラン・M・デービス
日経BP社
売り上げランキング: 16586

おすすめ度の平均:

要求マネジメントの良書

Amazon.co.jp で詳細を見る

この業界では「ひもつく」という言葉がよく使われる。個人的には「ひもづく」と言う方が多いのだが、同じものだろう。データ構造に関する文脈などで、「繋がっている」、「関連している」といった意味でよく使う。たとえば、「従業員のデータは部門コードで部署マスターにひもづいている」という具合である。

しかし、この言葉、メールに書こうとすると漢字変換できない。辞書で調べても出てこない。実は、最近生まれたいわゆる「オトナ語」なのである。仕方がないので「繋がっている」とか「リンクしている」などに置き換えてみるが、文脈によってはしっくりこないこともあり、ちょっと困る。

まぁ、どのみち受託システムに関する文章は専門用語のオンパレードである。関係者が読んで理解できる言葉であれば、メールで使うくらいは構わないだろう。とはいえ、平仮名では格好が付かないので、「紐付く」と表記することにした。

逆に、きちんと定義された「正しい」言葉であっても、それを読む人が理解できないものを使うのはよくない。先日も、あるシステムの画面に、

　20バイト以内で入力してください。

というエラーメッセージが出てきて、エンドユーザーが「意味が分からない」と言っていた。システムを作る側は、「バイト」という単位にあまりに馴染んでしまっているので、思わず使ってしまったのだろう。しかし、一般には、「バイト」といえば「アルバイト」の略である。

ここは、ユーザー層を考えて「バイト数」ではなく、「文字数」で表現すべきところだった（細かいことをいえば、文字数とバイト数との関係は文字コードセットによって違うので、単にバイト数を示すだけでは、いずれにせよ不十分である）。

バイトといえば、「バイト敬語」が日本語の乱れとして問題視されている。「１万円からでよろしかったでしょうか？」のような、コンビニやファミレスの店員などが話す独特の言葉である。

私もこうした「乱れた」とされる言葉には違和感を感じる方である。しかし、言葉が本来「変化する」という特徴を持っていることを思い出すと、あまりこだわることもないか、と思い直す。何を基準に「乱れている」というべきか分からないからだ。

特に、そう思わせるのが「全然」の誤用問題である。私はずっと「全然」という言葉がその後に否定的な意味を伴わずに使用されるのは誤用だと信じていた。つまり、「全然良くない」は正しいが、「全然良い」のような肯定的な表現は最近の「日本語の乱れ」だと思っていた。しかし、調べてみると実はそうでもない。「全然」の肯定的な表現は昔からあり、漱石や鴎外も使っているというのである。

結局、言葉が「正しい」かどうかというのは、それを使う人同士が持っている「基準」に合っているかどうか、という程度でしかないのだろう。つまり、うまくコミュニケーションするには、「相手が正しいと思う言葉を使え」ということである。相手によっては、自分より「基準」が厳しい場合だってあるだろう。そう考えると、「ひもつく」などという辞書にない言葉に違和感を感じる人もいるかもしれない。とりあえず、設計書などの正式な文書には、「紐付く」などと書かないようにしようと思う。

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

■関連記事
・普通の言葉
・曖昧言葉
・えいやぁと眉を引く話
・エンドユーザーとは

問題な日本語―どこがおかしい?何がおかしい?

posted with amazlet at 08.07.06

北原 保雄
大修館書店
売り上げランキング: 56754

おすすめ度の平均:

文法的な解析や過去の吟味とあわせて、現在の生きた用法をしっかりと見据える事が大事
「問題な日本語」は問題ではないでしょうか？
ってゆ0か、わたし的にはおもしろい、ってかんじ？
柔軟な思想
言葉は生きている！

Amazon.co.jp で詳細を見る

問題だ!そのバイト語―その言葉は耳障り!直すべし、その言い方!

posted with amazlet at 08.07.06

浦野 啓子
東洋経済新報社
売り上げランキング: 72839

おすすめ度の平均:

普段何気なく使っているけど

Amazon.co.jp で詳細を見る

上司から ToDoリストを作るように言われ、数日の間、「今日のタスクは ToDo リストを作ることであります」などと言っていたが、結局できなかったという人もいた。やるべきことが発生したら追加するというだけのもののはずなのに、このように気合いを入れて作ろうとするのもおかしな話である（最初に作る時は、抱えているタスクを列挙するのに時間が必要かもしれないが、それでも何日もかからないだろう・・・）。

ToDo リストを作るといっても、色々な方法がある。この業界では、PC や携帯端末など電子的なツールを使う人も多いかもしれないが、私の場合は「紙とペン」である（しかも、今のお気に入りはルーズリーフと万年筆という懐かしい組み合わせだ）。

基本的には普通に「やるべきタスク」を書いては潰していくだけなのだが、ちょっとした工夫をしている。優先が高いいくつかのタスクについては、以前紹介した フリクションボール（最近はビジネスモデル もある）を使って、赤いラインを入れるのである。フリクションボールのように消せるペンであれば、終わったタスクのラインを消すことができる。このため、常に「次にやるべきタスク」だけが赤くなっているというわけだ。

また、タスクの進行状況等のコメントを、他の色のフリクションボールで記入することもある。「次のアクション」は青、「お客様回答待ち」は緑など。やはり、状況が変わったら消して書き直すことができるので便利だ。もちろん、元のタスク自体は、普通の消えないペンで書くので、「行」を上から大胆に擦っても大丈夫である。

プログラマならではの ToDo 管理としては、「ToDo コメント」がある。

プログラミング中、細かい処理まで逐一実装しながら進めていると、思考の流れが止まってしまいそうなことがある。そのような場合、枝葉末節は後回しにして、主要な処理だけ先に書いてしまいたい、と思うだろう。

あるいは、一部の処理の仕様が確定しないまま、プログラミングを進めることもある。そういう場合は、そこだけ「仮」の実装にしておいて、他の部分を先に書いていくことになるだろう。

いずれも、後から一部の処理を書かなければならないのだが、ともすれば忘れてしまいがちである。そういう場合は、ソースコードの該当箇所に「ToDo コメント」を書くとよい。

後から実装すべき部分に、例えば「TODO:」という文字列を付けたコメントを書いておき、これを定期的に検索するのである。当然、実装が終わったらこのコメントは削除する。最終的に検索結果がゼロにならなければ、プログラムは完成しないというわけだ（「もっとコメント論　～その４～　システムの開発や保守のために 」も参照）。

やるべきことを忘れないこと、というのは、スケジュール管理（遅れないでやる）以前の問題である。仕事をする上での最低限の条件と言ってもいいだろう。忘れないためには、忘れる前に記録すること、そしてそれを常に参照することである。方法自体は難しくない。習慣化できるかどうかが鍵だろう。

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

■関連記事
・書き込まれる資料作り
・もっとコメント論　～その４～　システムの開発や保守のために

開発の現場 vol.006

posted with amazlet at 08.06.09

翔泳社
売り上げランキング: 64211

Amazon.co.jp で詳細を見る

パイロット フリクションボールビズ 0.5mm 黒インク【ブラックボディ】 LFB-150EF-B

posted with amazlet at 08.06.09

パイロット
売り上げランキング: 19109

Amazon.co.jp で詳細を見る

ポインティング・スティックがその機能性の割に普及しないのはなぜか。製造コストの問題もあるが、それよりも「とっつきにくい」ということのほうが重大なように思う。トラックポイントの開発担当者は「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 で詳細を見る