「ソフトウェアエンジニアの心得」教育

かなり前（たぶん2000年の頃？）から行っている「ソフトウェアエンジニアの心得」の教育を日本総合システム社の新卒新人向けに行いました。リコーに勤務していた2009年から2017年までは、毎年ソフトウェア開発系の新卒新人向けに行っていた研修です。

日本総合システム社近くの「小石川後楽園」

AITCセミナー

2017年6月16日（金）に、AITCセミナーで、「ソフトウェアエンジニアの心得 / Go言語の紹介」と題して2時間の話をしました。案内は、こちらです。

「ソフトウェアエンジニアの心得」はQ&Aを入れて2時間30分でいつも話すのですが、約1時間で話をしたため、省略した部分も多かったです。

「Go言語の紹介」は、Go言語の特徴をデモを含めて行ったのですが、45分だったので、用意した資料をすべて話すことはできませんでした。資料は、こちらです。

参加者は約40名程度で、セミナーの後は懇親会で、90分ほど参加者と色々と話をすることができました。

初心者だからと言って、汚いコードを書くことが許される訳ではない

いつも講演や教育で話をしている「ソフトウェアエンジニアの心得」の講演スライドの中に次の一文があります。

初心者だからと言って、汚いコードを書くことが許される訳ではない

会社で給与をもらいながらソフトウェア開発に従事する場合には、資産を残すことが求められます。

ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すことです。ソフトウェアエンジニアが、他人の書いたコードを理解することができない場合には、そのコードはあっさりと捨てられ、一から書き直されてもおかしくはないでしょう。残念なことに、このような書き直しは頻繁に起きています。コードを読みやすく保守性を高めることは、コードを正しく動作させることと同じくらい、あるいはそれ以上に重要です。正しく動作しないコードは、動作するように修正することはできます。保守できないコードは、がらくたに過ぎません。

Taligent’s Guide to Designing Programs

どこかの建築会社に自分の家の設計・建築をお願いして、完成したら、出来上がりがひどい箇所があった時に、そのことを指摘して、「経験の浅い新人が担当したのでそうなりました」という言い訳されたらどう思いますか？

プログラミング経験が浅いという事実によって、会社におけるソフトウェア開発で、汚いコードを書いて残すことが許される訳ではないのです。しかし、実際には、何が良いコードで何が汚いかを初心者が判断することは難しい訳です。そのため、新人が書いたコードであっても、開発組織としてレビューを行い、きちんとした品質に仕上げさせる必要があります。

このことは、コードに限った話ではありません。作成してもらう文書もそうです。当然、作成された文書をレビューして、説明不足や分かりにくい日本語表現などを指摘したりして修正させます。

ところが、最近は、大学でもそのような文書作成の指導を受けてこないようで、何度も何度も分かりにくい日本語を指摘されて、修正を指示された結果、文書作成そのものが終わらなかったり、完成までに非常に長い期間を要したりします。その場合、レビューでレビューアがOKを出さないので、自分の仕事（文書作成やコーディング）が終わらないのであり、自分の責任ではないと考える人がいたりします。

若手に対するレビューは、単にアウトプットの品質を担保するだけのものではありません。数年後には、その人が次の若手をレビューして指導できるようになることも期待しているのです。もし、数年後に次の若手を指導できるようにはならないと判断されたら、レビューを通した指導もされなくなるかもしれません。

「第７回とくしまＯＳＳ勉強会」で話します

とくしまOSS普及協議会の主催による「第7回とくしまOSS勉強会」で話をします。

日時：2015年3月20日（金）18時〜20時
場所：とくぎんトモニプラザ　４階　会議室３　（徳島市徳島町城内２－１）

詳しい案内は、こちらを参照してください。案内にも書かれているように、2つのテーマについて話をします。「ソフトウェアエンジニアの心得」と「Java SE 8オーバービュー」です。

四国には、「オープンセミナー2011@香川」で2011年9月に香川県に行きましたが、徳島へ最後に行ったのは、2003年11月ですので、10年以上前となります。徳島には、ジャストシステムに勤務していた1997年5月から1998年4月までの1年間住んでいました。

日曜日までゆっくりしたかったのですが、3月22日（日）に「とくしまマラソン2015」が開催されるため土曜日のホテルが予約できませんでした。そのため、翌日の21日（土）に横浜に戻ります。

【2015年2月26日追記】
協議会が主催の懇親会はありませんが、参加者の方に懇親会の設定をお願いしましたので、懇親会へ参加される方は、こちらで申し込みをお願いします。

『ソフトウェアエンジニアの心得』教育（2）

『ソフトウェアエンジニアの心得』教育で書いたように、おそらく2001年の頃からだと思いますが、教育や講演会の中で「ソフトウェアエンジニアの心得」と題する話をしてきました。

会社の（集合）新人教育の中で行ったことがあるのは、以下の会社です。

• 富士ゼロックス情報システム
• 富士ゼロックス
• 富士フィルム
• 富士フィルムソフトウエア
• 日本総合システム
• 旭化成アミダス
• リコー
• リコーITソリューションズ

普通の講演として行ったのは、こちらに記載されています。

ソフトウェアエンジニアとしての日々の活動に対して、話を聞いて良かったと思っていくれている人はどれだけかは分かりません。しかし、5年前に鹿児島で行った講演に来てくれた人が、以下のように言ってくれていたと、講演を主催してくれた知人から昨日知らせてもらいました。

先週、最近電子工作を一緒に楽しんでいる人が、以前、柴田君に鹿児島で講演してもらった話がとても役に立ったと言っていました。

普段身近に接している人達には、様々なことを伝えることができますが、そうでない人とは、書籍、ブログ、講演を通して伝えることしかできないわけです。その中で、講演という形態は、直接話をできるよい機会となっています。

2007年から、要望があれば講演を行ってきましたが、昨年（2014年）は行っていません。今年は、3月20日（金）に徳島で話をします。2時間弱の間に、『ソフトウェアエンジニアの心得』以外にも、Java SE 8に関する話をするので、かなり駆け足になるかと思いますが、楽しみにしています。

地方での講演は、初めての地であれば、観光を兼ねたものとなります。3月の徳島は、初めての地でありませんし、1年間住んでいたこともあります。しかし、最後に行ったのは2003年なので、少しゆっくり見て回る予定です。

コミュニケーション力

「ソフトウェアエンジニアの心得」の教育（講演）で1枚だけのスライドとして、以下の内容のものがあります。

技術者間での議論において、自分の考えを、相手が理解できるように論理的に説明でき、相手が説明しようとしていることを、相手の立場になって理解できる。

つまり、

相手が理解していないと感じた場合には、相手が理解できる内容・用語・比喩に切り替えて説明できる。

相手の説明をきちんと理解できない場合に、相手が何を言いたいのかを逆に質問して、正しくコミュニケーションを取るように努める。

エンジニアによっては、相手が何を聞いているのか全く理解しようとすることなく、同じ説明を繰り返す人がいます。もちろん、こちらとしては、質問を変えたりして内容を理解しようとするのですが、それでも、説明を切り替えたりすることなく、全く同じ説明を繰り返すのです。会議などでは、最後に、見かねて別の人が「彼（彼女）が言いたいことは、・・・」と説明してくれたりします。

非常に基本的なことですが、「相手が理解していないと感じた場合には、相手が理解できる内容・用語・比喩に切り替えて説明できる」ことは、重要なスキルです。そのスキルがないまま歳を取ってしまうと、本人はきちんと説明しているつもりでも、周りから見るとコミュニケーション力がないと思われてしまいます。

外向きの活動

「ソフトウェア・スキル・インデックス」では、7つのレベルを定義しています。レベル6（名人）とレベル7（匠）がレベル1からレベル5までと異なる点の1つは、「その向きの活動」です。

「ソフトウェアエンジニアの心得」教育（講演）でも述べていることですが、会社に属して働いている場合の評価は、あくまでも、相対評価であり、「ゼロサムゲーム」です。つまり、配布可能な給与をどのように分配するかを相対評価で決めていく訳です。

しかし、このような会社の制度内でソフトウェアエンジニアとしてのモチベーションを維持することは、特に日本の会社では、容易ではありません。あくまでも、相対評価だからです。その結果、ソフトウェアエンジニアとしては、外向きの活動を行うことでモチベーションを維持することになります。

外向きの活動は、ブログでの発信、雑誌の記事や書籍の執筆、講演、オープンソースプロジェクト、オープンソースへの貢献といった様々な活動が含まれます。そのような活動による評価というのは、相対評価ではなく、ある意味、絶対評価です。今後のソフトウェアエンジニアは、何らかの外向きの活動が必要な時代になっていると思います。

読みやすいコードに対するエンジニアのレベル

「ソフトウェアエンジニアの心得」で説明している資料からの引用です。

---

1. 読みやすさどころではない
   • 初心者の場合には、読みやすさまでは注意がいかないし、コーディングが終わった後でも、読みにくいかどうかが判断つかないレベル。
   • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
2. コーディング中に気づかない
   • コーディング中はコードを書くことにのみ意識がいき、読みにくいコードや重複したコードを書いているかどうかまで注意が回らない。しかし、コーディングが終わった後で、見直してみたらそれに気づき、修正するレベル。
   • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
3. コーディング中に書き直す
   • コーディング中でも、常に読みやすさや改善すべき点に気づき、コーディング中にどんどん修正するレベル。
4. デバッグ後も重要だと認識している
   • 単体テストでデバッグが終わっても、コーディングが終了したとは考えない。さらにコードを書き直して出来る限り綺麗に読み易くして、コーディングが終了したと考える。
   • 常にコードをクリーンにすることを心がけている（ボーイスカウト・ルール）。

このおおざっぱなレベル1からレベル4ですが、社会人となってどのような開発組織でソフトウェア開発を行ってきたかによって、4、5年以上のソフトウェア開発経験があっても、レベル1かレベル2程度であったりします。

さらに、テスト駆動開発によるリファクタリングを経験したことがない人は、テスト駆動開発でリファクタリングが安心してできる開発に移ってきても、「Red-Green」で終わってしまい、「Red-Green-Refactor」ができなかったりします。

講演案内： 長野 10月12日（土）

依頼があった時に不定期に行っている講演を、長野ソフトウェア技術者グループ(NSEG)様主催で行います。

• 日時：　2013年10月12日（土） 14:00～18:30
• 場所：　信州大学工学部 総合研究棟 1F SUNS 会議室
• テーマ：　「ソフトウェアエンジニアの心得」「プログラミング言語Java教育」

詳細な情報および申し込みは、こちらです。過去の講演については、こちらを参照してください。

長野に行くのは、初めてです。当然、信州大学も初めて行きます。楽しみです。

信州大学といえば、信州大学経済学部を創設され、労働者派遣法の生みの親である高梨昌さん※が思い出されます。偶然とは言え、今住んでいるマンションへ移った時に高梨さんは私の上の階でした。マンション管理規約改定専門委員会も含め、マンション内の様々な活動でご一緒させてもらいました。
※ 2011年8月30日に亡くなられました。

一人前になるには10年

「ソフトウェアエンジニアの心得」と題した話は、講演として行ったり、技術教育として企業向けに行ってきています。基本的には、拙著『プログラマー”まだまだ”現役続行』に沿っていますが、その中で「一人前になるには10年」ということで話をしています。該当部分を拙著から抜粋したのが次の部分です。

一人前になるには10年

　ソフトウェア開発は創造活動であり、創造能力を高めるには、「より良くできないか」という問題意識を常に持ちながら、多くの経験を積んでいくことです。
　リチャード・ガブリエルは、「ソフトウェアを書くことは芸術であり、本当にうまくなるには10年を要する」とも述べています。
　これは、「10年間ソフトウェア開発を経験した人が一人前である」という意味ではありません。実際の開発現場では、単に10年間を過ごしただけであり、一人前といえる経験・知識にはほど遠い人も多いのです。
　デービッド・フーバーとアデワレ・オシニェイェは、『アプレンティスシップ・パターン』の中で次のように述べています。

十分に長い期間続けていれば、「経験者」と呼ばれ始めますが、それがあなたの目標であってはいけません。経験が示すのは、あなたが生き延びてこられたことだけです。学んだ量を示しているのではなく、過ぎ去った時間を示しているだけです。ソフトウェア業界のある部分では、能力の大幅な向上をしなくても、一年で経験したことを10回繰り返すのは非常に簡単です。実際、これは時として、反経験（anti-experience）になることがあります。つまり、年を重ねることが、単に身に付けた悪い癖を強化しているだけの現象です。したがって、あなたのゴールは経験を積むことではなく、スキルが上がることであるべきです。

　いかなる芸術でも、何の練習もなく優れた作品は生み出されません。多くの練習を積み、何が本質的なのか、何がそうでないのかを見極める能力を養っていくことが必要となります。

『プログラマー”まだまだ”現役続行』（p.25）

ずっとC言語でしかプログラミングをしたことがない場合、1990年初頭であれば、オブジェクト指向設計やオブジェクト指向プログラミングをした経験がなくても、不思議ではありませんでした。しかし、今日、10年以上の経験者（実際には「反経験」）が、「オブジェクト指向の指導・教育を会社で受けたことがない」からオブジェクト指向が分からないという答えられる時代ではないと思います。「オブジェクト指向を勉強したことがないから分からない」と言うのであればまだ多少は救いがあるかもしれませんが。

確かに会社での仕事を通して学ぶことも多いです。しかし、会社は、会社にとって必要と思われる投資で無い限り、技術教育に投資したりしません。たとえば、C言語での開発しか行っていない会社が、会社の業務と関係ない言語の教育に投資したりしない訳です。

大多数のプログラマーやシステムアナリストは、自分の専門性が時代遅れにならないように維持することを会社に頼ることはできません。ソフトウェア業界で取り残されないためには、自分から進んで自分の時間（休暇さえも）や自分のお金を投資しなければなりません。

Edward Yourdon, Decline & Fall of the American Programmer

意外に思われる人が多いですが、私自身は、Javaを使用した開発業務に直接従事したことはあまりありません。今は、作成されたJavaコードのレビューなどは行っていますが、そのようなJavaの製品コードのレビューを行うようになったのも2009年以降です。実際の製品開発で1993年以降(2008年まで）使用してきた言語は、C++です。

振り返ってみると、私自身は、会社で新たな技術を教育してもらったという記憶があまりありません。仕事で使うために初めての開発でC言語を学び、C++も独学に近く、Javaも1996年から趣味で学んでいるという状況です（Mesa言語だけは、Xerox社内の言語なので会社で覚えましたが）。会社で教えることはあっても教えてもらったという経験は非常に少ないです。

私自身は、実際には、多くのことを書籍を通して学んできたのだと思います。そして、学んだことを実際の開発で実践することを繰り返してきたのだと思います。今日私自身がレビューなどを通して指導していることのほとんどは、書籍で学んで実践して経験して、その中で本質的だと理解した事柄に基づいているのだと思います。

Read Any Good Books Lately?

新しい知識と見識を得るために、私は常に本を読んでいます。一冊の良い本を選べば、他の人が何十年もかかって修得してきた見識を、数日で得ることができます。それなのに、なぜ、何年もかかって試行錯誤により学ぶのですか。非常に大きな差ですよ。もし、チームのメンバーが一年間に6冊の見識深い本を読んだとしたら、そのことがメンバーの仕事にどのような影響を与えるか想像してみてください。

Steve Maguire, Debugging The Development Process

自分の知識のなさやスキルの低さを「会社で教えてもらったり指導してもらったことがない」と言い訳しているようでは、20年たっても一人前になることはないかと思います。