面白いプログラムを作ろう

私の職場では、社員採用時の入社前研修として、Ｃ言語を教えている。講師をしている後輩社員によると、プログラミング初心者の生徒から「ポインタの仕組みは理解できましたが、何のためにあるのか分かりません」というような相談があったそうだ。

その疑問に対して、一般的な例を示してやることはできるだろう。例えば、関数の引数をポインタにすれば、それが示す値を関数内で変更して返すことができるし、処理速度的にもメモリ消費量的にも効率的である。この生徒もポインタの原理が理解できているのなら、そのメリットを頭では理解できるだろう。

しかし、彼にとって本当に必要なのは、そのような言葉による説明ではない。自らがそれを経験することである。彼自身がポインタの「必要性」を感じてみなければ、本当の意味で理解したとはいえないだろう。

もちろん、それはポインタの問題だけではない。「プログラミングは体で覚えろ」にも書いたように、実際に何度もプログラミングをしてみなければ、プログラミングの技術は身につかない。

★

自らプログラミングをしようとすれば、原動力となる明確な「目的」、「動機」が必要である。ただ漠然と「プログラミングをしたい」と思うだけでは、何をしたらいいのかわからないだろう。プログラミング言語の文法やライブラリの使い方のような「技術的知識」を詰め込んだとしても同じだ。とにかく、「こんなプログラムを作りたい」といった動機がなければ、プログラムは書けないのである。

ブログを書くことを考えてみよう。ブログのサービスに登録し、「文字装飾の方法」や「リンクの仕方」を勉強しても、それだけでは記事は書けない。何かを「誰かに伝えたい」とか、「記録として残しておきたい」といった、書くための動機がなければ、何も書けはしない。

むしろ、何か書きたいことを書いているうちに技術力は後からついてくる。「この言葉を強調したい」と思うからこそ、文字を太字にする方法を学ぶのだし、「紹介したサイトを見てほしい」と思うからこそ、リンクの仕方を覚えるのである。ブロガーにとって、「ブログの書き方を学ぶ」ことは目的ではない。ブログを書くための手段にすぎないのだ。

プログラミングでも同じだ。「こんなプログラムが欲しい」、「こんなプログラムを作りたい」といった気持ちこそが、プログラミング技術を上達させるのである。

★

初心者プログラマには、とにかく「実際に使える」プログラムを作ってみて欲しいと思う。ゲームやジョークソフトでもいい。斬新なものである必要はない。大切なのは、自分が「面白い」とか「便利だ」と思う題材を選ぶということである。

「動機」は、誰かが与えてくれるものではない。そういう意味では、誰かに課題として与えられた題材よりも、自分で考えた題材のほうがいいだろう（もちろん、与えられた課題を面白いと感じればそれでもいいのだが）。プログラミングを仕事にすれば、顧客からの「要件」だとか設計者からの「仕様」という形で、（自分にとっては）つまらない題材が与えられることになる。せめて、今のうちに自分が面白いと思うものを作ってみようではないか。

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

C言語ポインタ完全制覇

posted with amazlet on 06.10.16

前橋和弥
技術評論社
売り上げランキング: 7,246

おすすめ度の平均:

やっと見つけたマトモな本

理解があやふやな方へ

本当のプログラムを意識するようになる。

Amazon.co.jp で詳細を見る

熱狂する社員
企業競争力を決定するモチベーションの3要素

posted with amazlet on 06.10.17

デビッド・シロタスカイライトコンサルティング
英治出版

Amazon.co.jp で詳細を見る

ドキュメントへの「朱筆」について考える

SE の仕事では多くのドキュメントを作成する。その過程では、印刷したものを顧客や有識者にレビューしてもらったり、自分自身でチェックするようなことも多いだろう。そこで、修正すべきことがあれば、該当箇所に「朱筆」を入れる（もちろん、色は赤とは限らないが）。実際の電子ファイルは、後でその紙を見ながら修正することになる。

私の場合、開発チーム内ではレビュアーとなる機会も多いのだが、時々、この「朱筆」が漏れなく電子文書に反映されるかどうか、不安になることがある。

例えば、文書の枚数が多く、しかも修正すべきページがいくつもあるときだ。修正箇所がページの中に埋もれて忘れられてしまうのではないかと思う。該当のページに付箋を貼ればいいのだが、レビューに付箋を持参しない人も多い。余計なお世話かもしれないが、気になる場合には、私が自分の付箋を付けてやることもある。

★

また、１つのページ内に多くの修正が入ったり、修正には関係なく「覚え書き」のようなものを沢山書き込んだりして、ごちゃごちゃと読みにくくなってしまった場合も心配である。情報を書き込むこと自体は構わないのだが、後から見て、修正箇所が明確に分かるような工夫は必要だろう。

私自身が好んでやる方法は、修正箇所に「チェックボックス」を置くことである。といっても、目立つように四角形 "□" を手書きするだけだ。実際に電子ファイルを修正した時には、そこを１つずつチェックする（「レ点」を入れる）ことで、修正漏れはなくなる（※１）。

ドキュメントの修正作業は退屈なものだが、"□" にチェックを入れるという行為は、少し楽しい。まぁ、少しだけだが。

また、こうしておけば、「覚え書き」などの「ノイズ」が混じっていても、修正箇所を見つけやすい特定しやすいというメリットもある。"□" に注目して資料を眺めれば、修正が必要な箇所を見つけやすいのだ（※２）。

★

普段、資料への書き込みなどは何気なくやっているが、改めて考えれば、まだまだ工夫の余地はありそうだ。例えば、メモ用の領域を確保するために、余白を大きく取って印刷するというだけでも、かなり違うだろう（※３）。

また、レビュー時などでは「修正漏れを無くす」というだけでなく、「なるべく速く書く」という条件も必要だ。例えば、標準的な「校正記号」を覚えれば、もっと効率よく記入できるかもしれない。

いわゆる「ノート術」の一種になるのだろうが、ドキュメント作成の機会が多い SE には、こうした工夫をしていくことも重要かもしれない。

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

※１
最後にまとめてチェックすると意味がないので注意が必要だ。

※２
知覚心理学で「ポップアウト」という現象だ。私はチェックボックスに見立てて "□" を使っているが、"☆" や "◎" のような、もっと目立つ記号の方がいいのかもしれない。また、ペンの色を変えたり、スタンプのようなものを使うのもよさそうだが、持ち変える手間が増えるのがデメリットか。

※３
FinePrint

のような印刷ツールを使えば、自分用の資料だけ余白を広げるようなことも簡単に出来る。

図解百戦百勝のメモ術・ノート術
―仕事、年収、昇格…人生は「書きグセ」で決まる!

posted with amazlet on 06.10.09

本田尚也
三笠書房
売り上げランキング: 30,785

おすすめ度の平均:

積極的にメモを取りましょう

メモることの効用

メモを使って能力アップ

Amazon.co.jp で詳細を見る

校正記号の使い方―タテ組・ヨコ組・欧文組

posted with amazlet on 06.10.08

日本エディタースクール
日本エディタースクール出版部
売り上げランキング: 7,871

おすすめ度の平均:

中学校で校正記号を教えたら

素人でも分かりやすい。

Amazon.co.jp で詳細を見る

すぐ傍にあって気がつかないこと

「いっぱい」の「い」を「お」に換えたらどうなるか？　なんていう言葉遊びがある。子供の遊びのようなものだが、邪念がある大人のほうが間違えてしまうかも。

次は Java のクイズ。

 String s = "いっぱい";

 s.replaceAll("^い", "お");

 System.out.println(s);

これで何が出力されるだろうか？

String の replaceAll() メソッドは、第１引数にマッチした全ての箇所を第２引数に置換する。しかし、第１引数をよく見ると、文字列の先頭を意味する正規表現の「^」がついている。つまり、先頭の「お」だけが置換される。

というわけで、答えは「おっぱい」・・・ではない。

s.replaceAll() は、s 自身が示す文字列は置換せず、置換した結果を戻り値として返すのだ。ここでは戻り値が受け取られていないから、出力されるのは最初に s に代入された「いっぱい」である（※）。

★

正規表現は便利だが、複雑になれば読みにくくなる。このため、プログラマは、正規表現を使った処理が思うように動かない場合、まず正規表現の書き方を疑うものだ。うまくいくまで何度も書き方を見直しては動作確認を繰り返すだろう。

たしかに、正規表現が間違っているという可能性は大きいのかもしれない。しかし、原因が全く別である可能性もある。もしそうなら、正規表現をいくら見直しても解決しない。そして、それに気がつかないなら、長時間無駄に悩んでしまうことになる。

私も上記の例のように replaceAll() の戻り値を捨ててしまうという過ちに気がつかず、無駄に悩んだことがある。また、他の人が同じ原因で悩んでいるところも目撃したことがある。

後から考えれば単純なミスなのだが、そのときは先入観のために全く気がつかないのだ。

★

このように、プログラミングをしていると、先入観のためにバグの原因が見つからないということが時々ある。すぐ近くに単純な原因が見えているのに、それに気がつかないのだ。ちょっと視野を広くして見ればいいだけの話なのだが、人間、それが難しい。

ある程度悩んで解決しない場合には、環境を変え、気分をリフレッシュしてから再度取り組むようにするといいだろう。例えば、休憩を取ったり、他の作業をするなどして、時間を置いてから考え直してみると、原因に気がつくことがある。翌日に持ち越す余裕があれば、よく寝てから翌朝考えるのもいい。あるいは、ソースコードを印刷して紙の上で読むことで、見つかるようなこともある。

もちろん、他の人に相談するのも有効である。上記のような初歩的なミスを他人に指摘されるのは恥ずかしいかもしれない。しかし、そんなのは誰にでもあること。笑い話にすればよい。悩んで無駄な時間を過ごすよりはずっといいだろう。

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

※Java の String は文字列定数を示すクラスなので、自分の示す値自体を変更するメソッド（Ruby流に言えば「破壊的メソッド」）を持たない。これは、Java の基礎的な知識だ。しかし、他のプログラミング言語では、この種のメソッドは破壊的になっている場合も多く、ケアレスミスに繋がりやすい（→ 「新しいプログラミング言語を学ぶということ」）。

■関連記事
・真夜中のコード
・怖いこと

詳説正規表現第2版

posted with amazlet on 06.09.30

Jeffrey E.F. Friedl 田和勝
オライリー・ジャパン
売り上げランキング: 19,679

おすすめ度の平均:

正規表現を学びたい人が買う第一冊目に最適

著者の努力に脱帽

Amazon.co.jp で詳細を見る

ヒューマンエラー

posted with amazlet on 06.09.30

小松原明哲
丸善
売り上げランキング: 22,009

おすすめ度の平均:

入門的な本

Amazon.co.jp で詳細を見る

メモをさせない方法

仕事柄、SE やプログラマに作業内容等の説明をする機会が多い。そんなとき、相手の様子を見ていると、全くメモをとらない人と、常にメモをし続ける人がいる。

話している相手が全くメモを取っていないと、内容を忘れはしないかと心配になる。そして、案の定、そういう人は後になってから質問に来たりする。

一方で、メモばかりしている人を見ると、本当に内容を理解しながら聞いているのかと心配になる。また、相手が下を向いてペンを動かしていると、話を続ける気にはならないので、書き終わるのを待つことになる。時間の無駄だ。

そして、いずれの場合も、メモすべきような重要なこととそうでないことの判断が出来ていないのだろうか、と不安になる。

★

説明する相手の人数が多い場合なら、メモしなくても済むように、事前に要点をまとめた資料を用意しておけばいいだろう。しかし、１人や２人に説明するだけの場合にわざわざ資料を作成するのは効率的ではない。

そういう場合、説明をしながら、相手の目の前で手書きの資料を書いていくことにしている。「出来た資料は最後に渡すので、メモを取る必要はない」と言っておけば、相手が無駄なメモをとることはなくなる。また、話の進行に合わせて、書いていけば、相手も内容を理解しやすいだろう。

もちろん、それは特別なことではない。学校の先生が黒板を使ってやっているのと同じである（※１）。オフィスでは、ホワイトボードが使われることが多いが、相手が１人か２人なら、紙のほうが便利だ。

★

といっても、これが意外と難しいのだ。相手がメモする時間を待つことはなくなるのだが、自分が書くことに手間を取られてしまい、話のテンポが悪くなってしまうのである。特に、手書きで文字を書くのは意外と時間が掛かる。なるべく図や記号を取り入れて、手早く情報を示せるようにしたいものだ。

そうした場合、我々の仕事では、UML（Unified Modeling Language）が役に立つ。UML と言えば、設計書の書式のように考えている人もいるが、個人的には、このように、コミュニケーションのために使うことのほうが多い。また、設計の過程で自分の考えをまとめるために、ちょこっと書いてみることもある。Martin Fowler 氏のいうところの「スケッチとしてのUML 」である（※２）。

自分のためのメモであれば、自己流の書き方でもかまわないのだが、他者と共有するような情報には、なるべく共通の表記法を使うほうがよい。UML もかなり普及してきたが、まだ使っていない人もいるようだ。言語（Language）は、使う人が増えるほど便利になる。UML に触れていない人には、気軽に取り入れてみてほしいと思う。スケッチとして UML を描くだけなら、それほど記法に厳密でなくてもいい。便利そうな記号を拝借するところから始めてもいいだろう。

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

※１
学校の授業では、先生が黒板に書く内容をひたすらノートに転記していたような気がする（今の授業がどうかは知らないが）。教師がレジュメを用意しないのは、書き写すという行為自体が、生徒が勉強する上で重要だからだろうか（例えば、手を動かすことで記憶しやすくするとか）？

※２
Martin Fowler 氏はブログの「UMLモード」という記事の中で、スケッチとしてのUML、設計図としてのUML、プログラミング言語としてのUMLという３つのカテゴリを考えている。

■関連記事
・話が通じない話

すごい!メモ術「ビジネス力」をアップさせる達人たちの手の内を盗め!

posted with amazlet on 06.09.25

中島孝志
実業之日本社 (2005/11/08)

おすすめ度の平均:

仕事の満願全席！

Amazon.co.jp で詳細を見る

独習UML 第3版

posted with amazlet on 06.09.25

株式会社テクノロジックアート長瀬嘉秀橋本大輔
翔泳社 (2005/02/02)
売り上げランキング: 58,903

Amazon.co.jp で詳細を見る

仕事が好きですね

学生時代にアルバイトをしていた時の話である。職場の課長は、バリバリと仕事をこなすタイプの女性だった。いつもフロアを駆け回って指示を出し、誰よりも遅くまで残業していた。何より、「業務改善」ということに対して意欲的なのは確かだった。私がそこで作ったプログラムのほとんどは、その職場の業務を助けるためのツールだったのだ（※１）。

ある時、私が、

「仕事が好きですね」

と言うと、どういうわけか、嫌な顔で否定された。

しかし、私は、好きでなければ仕事にそこまでのエネルギーを注げないだろうと思った。「否定はしているけど本当は好きなんだろう」と、勝手に信じていたのである。

★

しかし、今になって考えると、彼女の気持ちが分かるような気がする。自分も周りから見れば「仕事好き」のように見えるのだろうと思う。しかし、仕事が好きかと言われれば、否定するだろう。

私はシステムの設計やプログラミングのような「モノ作り」は好きだ。しかし、実際にやっている仕事の全てが好きなわけではない。むしろ、プロジェクト管理だの、顧客との折衝だの、見積だの、そういうことは大嫌いである。

嫌いな仕事はなるべくやりたくない。かといって、手を抜くわけにもいかない。失敗してやり直しが発生すれば、嫌な時間はもっと増えるからだ。

というわけで、なるべく嫌な仕事をしないようにするにはどうしたらいいか、ということを本気で考えるようになる。つまり、効率化の方法とかミスの低減方法などである。仕事を助けるような、ちょっとしたプログラムを作ったりもする（※２）。

そんな姿は、周囲の人から見れば、「仕事好き」に見えるかもしれない。しかし、本当は仕事が嫌いだからこそ、なんとかして逃れようとしているだけなのである。

先の課長も、そういう人だったのではなかろうか。仕事が好きなように見える人ほど、実は、仕事が嫌いなのかもしれない。

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

※１
SE 兼プログラマとして働いていたものの、そこは、システム開発を行う部署ではなかった。この課長は、業務に必要なプログラムを、自社の開発部門や他の開発会社に「発注」するのではなく、学生のアルバイトを使って「内製」していた。

※２
プログラマには、「手を抜くための努力は惜しまない」というタイプの人間が多いようだ。面倒な仕事をコンピュータにやらせる、というのがコンピュータを利用する上での基本だからだろうか。

■関連記事
・面倒くさいこと