ソフトウェア開発に幸せな未来はあるのか

　わたし自身は、ほとんど勉強しないガキでした。と、いうよりは、好きなことだけ勉強してきた感じでしょうか。だから学校の試験も科目によって成績が良い科目と悪い科目がハッキリしていたし、受験勉強に至ってはする気なんかさらさらありませんでした。唯一の受験だった高校の時も、自分の実力を考えて入れそうな公立学校を選びました（もちろん、電気回路の勉強がしたかったのでそれは外さず）。

　性格的に、疑問を持ったら自分で納得できるまでとことん追求するので、興味があることは勉強会に行く前に基本的に自己解決することがほとんどです。

　それでも他の人はどう考えているのか知りたい時があるので「勉強会に参加したい」と思うことはあります。でもなかなか行けません。理由は、スケジュール調整がつかないため、地方都市在住なので参加するためそれなりに費用がかかるためです。独身時代はまだしも、結婚してから、自分で自由に使えるお金なんてほとんどありませんから（涙）。

　逆に、年齢も30歳を超えたころから、少しずつ「勉強会」を開いて欲しいという要望がちらほらあります。自社や派遣先で行うこともあれば、ユーザー側からの依頼もあります。プログラム技術もあればネットワーク技術も。スケジュールさえ合えば断る理由もないので開催します。

　せっかくなので、わたしの開く勉強会のことを書こうと思います。

■教えませんよ

　わたしの勉強会は、基本的に教えません。スタンスは「考えよう」です。資料はA4で1ページから多くても2ページ、1コマ45分で構成します。長いと間延びするので、通常は何コマかに分け、休憩を入れながらやります。

　資料はだいたい「図」です。文字だけと言うことはあまりなく、せいぜい表ぐらいでしょうか。とにかく「読ませない」ことを大前提とします。やってみると分かるのですが、案外普通に資料を作るより難しいんですよ。

　前にも書きましたが、最近のエンジニアの傾向として、想像力が乏しく、すぐに答えを求めたがります（あくまでも傾向です）。特に真面目なエンジニアは「予習」してきます。

　図を多くすると、たいていの人はそれを見ながらいろいろ考えます。正確には想像するんでしょうか。とにかく（字がほとんどないから）読めないので、見て考えざるを得なくします。予習してきてもあまり意味がありません。暗記するだけの予習は不要だからです。

　とにかく、考えて覚えてもらう事を第一にします。

■シナリオを作る

　映画やテレビドラマなどは「起承転結」や「序破急」という方法でシナリオを作成します。日常のように何も起こらないと見ててもつまらない（飽きる）から、ストーリーに波を起こして視聴者の意識をドラマに向けさせるようにすることです。

　勉強会も同じで、こちらから一方的にアクションを起こしてもだんだん飽きてきます。そもそも「勉強会」なので、基本は双方向です。上手に双方向に持って行けるようにシナリオを作成します。

　資料として渡した図表を使い、1つずつ説明、質問、回答を繰り返します。このとき、ホワイトボードなどに一切何も書きません。せいぜい用語の漢字を書くぐらい。参加者1人ひとりが自分でメモします。特に最近は自分で字を書く機会も減っているので、とにかく参加者が聞き取り、考え、書き、ときどき意見を言うにします。順番はランダムにします。端からだと自分の順番が何となく分かるので。ここでドキドキ感を演出します。

　言語などの場合は演習を入れます。演習もただ、考えて作るだけでは面白くないので、お題を出して作成してもらい、何人かの人にそれを発表してもらいます。それを材料に全員で良い部分、悪い部分などを討論します。ここで気づいたと思いますが、これはソースコードレビューです。経験の浅いエンジニアがいる場合、必ずやらせます。つるし上げることが目的ではありません（当たり前ですが）。

　目指すのは、自分の考えたコードを人に説明できること、人から自分のコードの良い点、悪い点を指摘してもらって、それを経験として生かしてもらうことです。逆に、見ている側には1人1カ所以上、意見を言う義務を課します。良い点でも悪い点でも構いませんが、必ず理由を添える事を条件にします。ただ単に「汚い」「見にくい」「遅い」「いいんじゃない」だけではダメです。

■分かった気にはさせない

　わたしもそうですが、どこかに研修などで話を聴いて帰ってくると、どこか分かった気になります。でもこれは気のせいです。数日もすればまた元の業務の中で忘れてしまいます（聴いたことが即、業務に関係ある場合は別でしょうが……）。それよりは何となく分かったけど、どこか少し引っかかる状態にしておくのが一番だったりします。気になるぐらいにしておく方が後から考えるようになります。人によっては気持ち悪いらしく、後日聞いてくる人もいます。そうなれば、まず成功だといえます。

　勉強会はどんなものであれ、受け身では「へぇー」で終わってしまします。その時は良いのですが、後が続かないと意味がありません。感動は一時期でしかありません。積極的にメモし、考え、自分から質問するぐらいのめり込んだ方がどんなものでも自分の「スキル」の一部になると思います。

　少しでも参考になれば幸いです。わたしもたまに出かけていろいろいな勉強会に行きたいなぁ。これが結構刺激になるんですよね。

■偉大なるマイクロソフト帝国

　見出しに関しては、完全に羨望と嫉妬と皮肉です。わたしはもともとアンチインテル、アンチマイクロソフト、アンチ巨人でした。でも、今は仕事でインテルCPU搭載のWindowsを使用しています。開発環境もVisualStudio。家でも同じで、いじるために買ったゲーム機もXBOX360です。唯一のプライドがMacでしたが、そのMacも気がつけばインテルCPUで接続しているキーボードとマウスはマイクロソフトです。もう、アンチ巨人以外は完敗です（笑）。

　マイクロソフトのカンファレンスに、1度だけ参加したことがあります。ハッキリとした記憶はありませんが、確か.NET戦略を発表した前後だったと思います。でも、どちらかといえば不良エンジニアのわたしには、あまり面白い内容はありませんでした（だからあまり記憶に残っていない）。

　でも、1点だけ憶えていることがあります。それはマイクロソフトが定期的にOSやオフィスなどビジネスの基幹部分を、定期的に新しいものをリリースしているから、あなた方のような開発者に仕事があるのですよ、というような言葉でした。とにかくすごい自信と傲慢に満ちた言葉ですが、あらためて考えてみるとあながち間違っていないのが恐ろしいと感じました。当時はまだ現在のようないわいるオープンソースみたいなものはあまりなかった（と感じています）ので余計に思います。

　次回はまた元のシリーズに戻します。エンジニアの問題シリーズの最後はテストエンジニアと品質保証です。コラムニストにも何人かいらっしゃいますが、テストエンジニアが優秀だと、品質向上が望めますが、その反面、SEやPGからは予期せぬバグが出ることになり、人によっては戦々恐々です。わたしは以前、テストエンジニア部隊を立ち上げたことがあります。その時の話も含めて、書こうと思います。