学生症候群とは、期日が決まっていると、その日までに終わらせれば良いと思い、ギリギリまで何もしないという特徴がある。

そう、まるで夏休みの宿題を夏休みが終わる直前になってやっと始める学生のように。

まだ、プロジェクトのメンバというレベルであれば、リーダおよびマネージャがフォローする事ができるが、リーダおよびマネージャが学生症候群を患っていると性質が悪い。

スケジュールなんてあったもんじゃないし、結局メンバがリーダおよびマネージャのロールをサポートせざるを得ない状況になる。つまり、逆管理状態。

メンバがそれなりにフォローできる能力を持っている場合は良い。

だが、メンバがメンバとしてのロールしか果たせないレベルの場合は、ぐだぐだになってしまうだろう。

きっと、アラームも納期直前に上げるのだろうから、ぐだぐだである事が発覚する時には既に手遅れになっている可能性が高い。

ぜひ、プロジェクトのメンバはメンバである事以外に、つぶさにリーダを観察するという事をしてほしい。

もし、学生症候群を患っているなと思ったら早期の段階からフォローする必要がある。

また、場合によっては、より上位のロールを持った人にアラームを出し、よりダイナミックな対処を施す必要がある。

もちろん、上述した事はプロジェクト失敗に至る原因の一つでしかなく、ほかに原因がある場合も少なくないので、あくまで一つのパターンとして留めておいてほしい。

ちなみに、学生症候群というキーワードについては下記の本が詳しい。

はてなに来て一番嬉しいのが、「このページに言及」ブックマークレット。

昔、ライブドアブログで書いていた時に、ツールバーを使わなくても自動トラックバックできる仕組みがあったらもっとトラックバックが普及するんじゃないかと言っていたが、それが具現化されたもの。

どうしても、

• 引用する記事をコピーして、
• タイトルはって、
• トラックバック用のURLを持ってきて
• トラックバック欄に貼付けて

という作業が掲示板等に比べると、面倒だったのだ。

今まで、めんどくさくてトラックバックしたり、ほかのページに言及する事を避けていたのだけれど、これからはもう少し気楽に出来そうだ。

もちろん、そういった傾向は良い面だけではないのかもしれないけれども。

さすが、２年くらい前に書いたコードだけに、

今のコーディングスタイルと違うなぁ。

出されたお茶に毒が入っているかいないかを知らないで飲むようなものだ。

コメントとはソースコードに挿入する事ができる注釈みたいなものである。

注釈とは「本文中の語句に解説を付ける事。」である。

つまり、わかりにくい、伝わりにくいところにだけコメントを記述する必要がある。

必要以上に多すぎてはいけない。

読めばわかるようなコードにコメントを付けてはいけないという事。

コードと同じ意味をコメントで記述する事にも意味を持たない。

それは注釈ではない翻訳だ。

まぁそれでも、関数ヘッダくらいは良いかなとも思う。

説明文書の自動生成くらいには使える。

でも、ソースを読むにあたっては、あまり役に立つとは言えない。

それでも、関数内に無駄に多いコメントよりは良いだろう。

関数内にむやみやたらとコメントが多いと以下のメリット・デメリットがある。

メリット

・なんとなく分かりやすい気がする。

デメリット

・コメントに頼りきったコーディングをするようになる。つまり、「コメントがあるからいいや。」という精神のもとコメントが無いと分からないような命名がされる。

・後から読むときにコメントとコードが同じ内容なので無駄である。その為、１画面に表示されるコード量が減るし、無駄なコメントが目に入るのでわかりにくい。

・仕様変更への対応でコメントを修正し忘れると、コードとコメントがミスマッチになる。つまり２重管理の弊害が出る。ミスリードをまねく。

ちなみに、メリットに挙げた項目は本当はメリットではないと思っている。

コメントを書く局面は下記の通りで良いと思っている

・TODO(最終的には消えるコメント）

・一見しただけじゃ何をやっているか分からないコードへの注釈

（一見しただけで分かるコードに変換し、それでも読み難いならコメントをつける。というステップを踏みたい。）

・なんらかの解説を付けたい時

つまり、ほとんど書かなくても良いって事。

そういえば、以前、「コメントレスコーディングのススメ」というエントリを書いた。

いまでも、それで保守性が上がると思っているし綺麗で整理されたコードになると思っている。

プログラムに不具合があった時は自分が担当した部分から疑いましょう。

というか、最近は逆の人が多いですね。

開発環境とかのバグを先に疑う人が多いように見受けられる。

技術者は本を読め。

技術関連書籍を読めという意味ではない。

IT関連書籍を読めという意味ではない。

とにかく、沢山本を読め。小説でも良い。

読んでいくうちに、読みやすい文章、読みにくい文章、綺麗な構成、汚い構成に出会うだろう。

そこで知るはずである。

読みやすい文章と、綺麗な構成。

読みにくい文章と、汚い構成。

その経験が、開発に生きてくる。

スケッチとして使うけど、手で書くのって面倒だし、所詮、手で書いてる限り思考のスピードには追いつけないからじれったいので、結局、頭の中でスケッチしてる感じ。

人に説明するときは、仕方ないから手で書くけど・・・。

その点コードがそのまま反映されるラウンドトリップは楽だよなぁ。

ボーランドのTogetherとか欲しいなぁ。

会社で導入しないかなぁ・・・・

「いやー、めいっぱい残業して頑張らせて貰ってますよ。えぇ、えぇ、納期には必ず間に合わせますから心配しないでください。」

と、いう奴がいたら、その会社には気をつけろっ！

残業の量に比例して品質はがた落ちのはずだっ。

納期日に納品されても、その後から不具合で、まともにシステムが使えないに決まっている。

間違いないっ。（長井秀和風）

大半の開発者は大抵コンサバティブである。

新しい開発技術が自分の仕事を軽減してくれると十分に知っていても、それを覚えようとしない。今の慣れた開発技術から離れようとしないのだ。

だが、それでも彼らの仕事は軽減される。

なぜなら、新しい開発技術を適切に使用する少数の開発者が彼らの分まで仕事してしまうからだ。

そしてそのうち、彼らの仕事は無くなってしまう。

なぜなら、新しい開発技術を適切に使用する少数の開発者で事足りてしまうからだ。

そしてそのうち、彼らは自分の仕事を見つける。

それは、新しい開発技術を適切に使用する少数の開発者の仕事を増やすことである。

なんつって・・・。