書かずに伝える

この季節、新入社員の書いた報告書を読む機会が多い。そんな中で特に気になることがある・・・と以前にも書いたが、他にも気になることがある。

報告書に長い文を書いてしまう人が多いのだ。例えば、こんな具合だ。

今日は、○○機能の一覧画面と編集画面の設計を行いました。一覧画面は設計を終わらせてレビューまで完了しましたが、編集画面は設計途中で完成していません。

まぁ、言いたいことは分かる。

しかし、こうした文章を読んで理解するためには、多かれ少なかれ時間と労力が必要である。そして報告を受ける側の人間は、往々にして多忙なものである。

同じ内容を報告するなら、こんな風に書いてほしい。

本日の作業
　　○○機能
　　　　・一覧画面・・・設計、レビュー完
　　　　・編集画面・・・設計中

これなら、下手な文章を解読しなくても済む（※）。

★
長い文章をだらだらと書けば、「てにをは」を間違えたり、誤読の原因ともなる。なるべく文章を使わずに情報を伝えるテクニックを身に付けたいものだ。

例えば、適切な見出しをつけたり、箇条書きにしたり、といったことである。要するに、必要十分な言葉を紙面上にどう並べるかということを考えればよいのである。書く側にとっても、「文章」を考えるよりも楽なはずだ。

もちろん、文章でなければ表現できないような内容もある。しかし、そのような場合でも、なるべく文を短くし、見出しをつけるなどの工夫をすべきだろう。

※進捗報告としては、本当はもっと書くべきことがあるとは思うが。。。

報告書作成法―技術者必携!読み手をうならせる

posted with amazlet on 06.06.24

野村俊夫
日刊工業新聞社 (1999/01)
売り上げランキング: 19,660

おすすめ度の平均:

もっと早く買えばよかった

技術者必読！

Amazon.co.jp で詳細を見る

あしたをつかめ平成若者仕事図鑑
プログラマー誰でも使えるシステムを作れ

posted with amazlet on 06.06.24

NHKエンタープライズ (2006/06/23)

Amazon.co.jp で詳細を見る

切捨て御注意

プログラミングをしていて、簡単な数値の計算が予想外の結果になってしまって、驚いたことはないだろうか？

★
5 を 2 で割ったらいくつになるか？

もちろん、2.5 であるが、これは実数での計算だ。Ｃ言語で int と表現されるような「整数型」の計算では、小数点以下は扱えない。そこで、少数点以下は切り捨てて計算される。例えば、5 ÷ 2 なら、2 になるのである（※１）。

ここまではよいだろう。では、-5 ÷ 2 ではどうなるか？

-2.5 の小数点以下が切り捨てられて -2 になる？　しかし、切り捨てたら値は小さくなるはずなので、-3 になる、という考え方もある。

★
整数の割り算は、いわゆる「商と余り」を求めることでもある。身近な（？）２つの電卓プログラムで、-5 を 2 で割った「余り」を計算させ、切捨て方法の違いを体験してみた。

まず、Windows XP 付属の電卓で "-5" → [Mod] → "2" とやってみた。-1 が返ってきた。

　　-5 ÷ 2 = -2 … -1 （商 = -2、余り = -1）

ということである。

次に、「Google 電卓機能」で、「-5 % 2」を求めると、答えは 1 だという。

　　-5 ÷ 2 = -3 … 1 （商 = -3、余り = 1）

ということだろう。

★
プログラマとして認識しておきたいのは、このような基本的な計算ですら、処理系（プログラミング言語など）によって動作が違うことがある、ということである（※２）

初めて使う言語は、コードの書き方の違い、ライブラリの違いなどは大いに気にすると思う。しかし、こうした、演算仕様の違いなどには、意外と気が及ばないものだ。

ちょっとしたプログラムを書いて動かしてみれば確認できることなので、今使っている言語ではどうなのか、調べてみるといいだろう。

※１
詳しく調べていないが、切り捨てないで、例えば四捨五入のような「丸め込み」をする言語（処理系）もあるかもしれない。

また、型に厳密でない言語では、整数同士で割り算をしても、「答えの型」が勝手に実数になってしまうことも多い。このような場合、例えば、(5 / 2) * 2 + (5 % 2) が 5 にならないというように、意図しないことが起こる場合があるので注意。

※２
ちょっと手元で試しただけでも、Java では -5 / 2 は -2 だが、Ruby では -3 だった。-5 % 2 については、Java は -1、Ruby は 1 を返した。同じ処理系内では、商と余りの関係に一貫性があるようだ。ただし、Ruby では、(-5/2) が -3 である一方、(-2.5).to_int が -2 となった。

■関連記事
・五捨五入
・ゼロ除算についてあらためて考える

Excelで学ぶやさしい数学―三角関数から微積分まで

posted with amazlet on 06.04.03

高橋幸久渡辺八一
オーム社 (2004/01)
売り上げランキング: 141,472

Amazon.co.jp で詳細を見る

プログラマの数学

posted with amazlet on 06.04.03

結城浩結城浩
ソフトバンククリエイティブ (2005/03/24)
売り上げランキング: 4,427

おすすめ度の平均:

文系の方向けの良書

文系プログラマにはよい

「情報工学をかじったことのないプログラマ」向けの本

Amazon.co.jp で詳細を見る

アイコンの色を塗る時

プログラマという仕事をしていると、アイコンやツールバーのような、いわゆる「ドット絵」を描かなければならないことがある。

パッケージソフトでは、デザイナーに作ってもらうところだろう。しかし、特定の会社の中だけで使うような業務アプリでは、そこまでしないのが普通である。そこで、開発者が適当なものを用意するわけである。

最近では、ネットでフリーの素材が入手できるので、自分で描かなければならないという状況も少なくなった。とはいえ、機能に合った絵柄が見つからないような場合には、自作したり、既存のものを改造したりしなければならないこともある。

私も専門家ではないが、ドット絵を作る時に気をつけていることがあるので、書いておこうと思う。ただし、正しいかどうかは別である。

★
昔のパソコンは、表示できる色数が少なく、アイコンには、既定パレットの16色しか使わないというのが決まりだった。実行環境を選ばないという意味では、今でもそのほうがいいだろう。また、数が少ない方が素人にとっては描きやすいと思う。

■	■	■	■	■	■	■	□
■	■	■	■	■	■	■	■

ただ、この16色の中にある「明るい色」（上段の黒と白を除いた色）を使うと、どうしても、安っぽい印象になってしまう気がするのだ。

もちろん、個人的な趣味の問題かもしれない。

しかし、伝統的な Microsoft 製品のツールバー等を見ても、「暗い色」が主体に使われているのがわかる。一方で、フリーソフト等では「明るい色」を多用しているものをよく見かける。色彩の問題だけではないとは思うが、やはり、Microsoft 製品に比べると、見劣りしないだろうか？

そんなわけで、私は、16色の中でも、なるべく暗い色を使うようにしている。明るい色は特に強調したい所だけに使うのである。

★
実際に描いてみるとこんな感じである。

「見易さ」という点では、上段の明るい絵の方が良いのかもしれない。しかし、「ツールバー」として貼り付けられたところを想像すると、下段の方がそれっぽいような気がするのだが、どうだろうか？

※もっと本気でドット絵に取り組みたい方には、以下サイトがおすすめ。
　小道具展示室＞みにこんてんつ＞ソフトウェアのためのアイコン作り

意気込みは分かったから...

この季節、新入社員の書いた報告書を読む機会が多い。そんな中で特に気になることがある。ミスを報告するときのことである。

報告の結びとして、「今後は気をつけます」とか「慎重に作業を行います」といった、抽象的な表現で終わっている場合が多いのだ。あるいは、「努力します」とか「頑張ります」といった、「意気込み」のようなものしか書かれていないこともある。

もちろん、そうした報告書からは、「彼が心から反省している」とか「彼には改善への意欲がある」といったことは伝わってくる。しかし、そんなことは人として当たり前のことなのである。当たり前のことしか書かれていない情報は必要ない。

本当に求められているのは、ミスを起こさないようにするための具体的な対策である。また、対策が見つからなかったにしても、彼がその問題をどのように分析したのか、ということなのである。

■関連記事
・書かずに伝える

失敗学のすすめ

posted with amazlet on 06.06.24

畑村洋太郎
講談社 (2005/04)
売り上げランキング: 7,905

おすすめ度の平均:

失敗を繰り返さないために

文系人間ほど、営業マンほど役に立つ本

とてもよかったです

Amazon.co.jp で詳細を見る

誠意が伝わる詫び状・始末書の書き方

posted with amazlet on 06.06.24

紫倉轍
日本文芸社 (2003/01)
売り上げランキング: 77,756

Amazon.co.jp で詳細を見る

あなたにもできること

私はいつも「読みやすいコードを書け」と言っている。そのためにできることは、決して難しいことばかりではない。

例えば、次のようなソースコードをみると、いつも思うのだ。

private static final String DATA[][][] = {
　　{"ringo","gorira","rajio","ondanka","kaimenjoushou"},
　　{"5","5","4","7","12"},
　　{"K100","J1","U200","X203","W9800"}
 };

どうして、こんな風に揃えて書かないのだろうか？

private static final String DATA[][][] = {
　　{"ringo", "gorira", "rajio", "ondanka", "kaimenjoushou"},
　　{"5"    , "5"     , "4"    , "7"      , "12"           },
　　{"K100" , "J1"    , "U200" , "X203"   , "W9800"        }
 };

特に、難しいことではないはずだ。

桁を揃えるためにいくつもスペースを打つことは面倒かもしれない（※１）。しかし、自分でコードを読み返してチェックする習慣がある人なら、こうしないと後でもっと面倒なことになるということを知っているだろう（※２）。

もちろん、読みやすさ、読みにくさを決めるのは、こうした桁位置の問題だけではない。しかし、ここでこれ以上の例を挙げる必要もないだろう。

大切なのは、読む人の立場になって考えるということだ。それは、設計書や報告書のような「日本語」を書くときでも同じことだろう。