FORTRANから始まって41年（１０）

教育を行う能力

能力というよりも、ソフトウェアエンジニアとして経験した方がよいのが、技術教育です。教えることの長所はいくつかあります。

• 教えるためには、技術を理解する必要がある
• 教えることで、技術を理解できる

当然のことながら、ある技術を教えるためには、自分自身で理解する必要があります。一方で、受講生からの質問に答えるために、深く考えたり、調べたりたりすることで、教えている技術を深く知ることになります。

現在、私自身が行っている技術教育は、Go言語研修と『Effective Java 第3版』研修です。以前は、Java言語研修も行っていましたが、現在は行っていません。富士ゼロックス情報システムおよびリコーに勤務していた頃は、以下のような教育も行ってきました。

• ソフトウェアエンジニアの心得
• A Quick Tour of C++
• テスト駆動開発
• 書籍『プログラミング作法』の第1章と第2章
• デザインパターンや設計原則

各内容の説明は省略しますが、私自身は、技術教育担当の組織に属していたわけではなく、ソフトウェア開発組織に属していることがほとんどでした。

技術教育で難しいこと

技術教育の中で難しいのは、受講生からの質問に適切に答えることです。つまり、以下のことを行える必要があります。

1. 聞かれた質問から、本当は何を知りたくて質問しているかを引き出すこと
2. 質問者および他の受講生の技術的知識がどこまであって、どこから説明するのが良いかを考えること

Java言語研修やGo言語研修では、事前にテキストの指定された範囲を読んで疑問点を質問表に記入してもらうのですが、本当は何を知りたいのかについては、研修当日に質問者に聞かないと分からないことが多いです。

質問の意図が理解できたとしたら、どのように説明すれば理解してもらえるかを、その場で考える必要があります。そのためには、説明の基礎となる知識を質問者や他の受講生が知っているのかをまず聞くこともあります。たとえば、「O表記（O Notation）が分かりますか？」、「CPUとメモリはどのように接続されていますか？」、「スタックとは何ですか？」とかの質問をすることがあります。それは、質問に対する回答を理解するために必要だからです。

そして、よくあるのが、質問の回答を説明する前に私自身が質問をすることで、話が脱線することです。たとえば、Go言語ではゴルーチンのスタックが自動的に伸長するのですが、それに関する質問を受けると、「スタックとは何ですか？」「スタックにはどのような情報が保存されるのですか」「他の言語ではスレッドのスタックの大きさはどのくらいですか？」「他の言語ではスタックサイズが固定長なのはなぜですか」などと聞き返してから、私が発した質問に対する回答の説明を始めてしまうからです。一通り説明が終わってからGo言語に戻ると、「スタックが伸長することがどれだけ画期的か」という話題に戻る訳です。

FORTRANから始まって41年（９）

若手人材を育成していく能力

私自身は、37歳になるまで若手の人材を育成することには、ほとんど関心を持っていませんでした。どちらかと言うと、「レベルが低いエンジニアにプログラミングさせるな」という考えが強かったです。私自身の考えが変わったのは、日本オラクルに転職してからです（「40代最後の年」）。

若手の人材、特に新卒新人で入社してきた若手のエンジニアに対しては、最初の数年できちんと育成する必要があります。それは、単に目の前の開発業務ができるようにさせるという意味ではありません。今回、この一連の記事で書いている基礎知識の習得や、さまざまな習慣や能力の獲得を行うように指導する必要があります。

したがって、「若手を育成する能力」というのは、ある程度ソフトウェア開発の経験を積んでから伸ばすように思われますが、実際には2年目からある程度経験を積むことが可能です。つまり、最初の1年での経験をもとに指導を行うというものです。ただし、「きちんと」指導できる範囲は狭いと思います。そのため、本人も成長過程であることを認識しておく必要があります。

育成をあきらめることもある

一人のソフトウェアエンジニアとしては、上司が自分を育成してくれると期待するのは間違っています。自分自身の成長は、自分自身の努力の結果であり、上司はその成長のための努力を後押ししてくれたり、サポートしてくれたり、指導してくれたりするだけです。矛盾しているようですが、一方でソフトウェアエンジニアとしては、若手を育成していくことも求められます（「ソフトウェア・スキル・インデックス」）。

しかし、現実には育成をあきらめる場合もあります。以下のような場合です。

1. 若手に対して、さまざまな指導や教育を行った結果として、伸びる見込みがないと判断した場合
2. 学習することをやめってしまった中堅のエンジニアの場合

1.に該当するケースはめったにありませんが、残念ながら私自身が途中で育成を断念したことが2回あります。半年以上の指導や教育を行った結果として断念するのですが、その後の対処は難しいです。その若手の面倒を誰かがみることで開発チーム全体の生産性が低下してしまう状況なので、開発チームから外す必要があります。

講演や教育で「新たな技術を学習しない中堅エンジニアはどうやったら変わってもらえるでしょうか？」と質問されることが多いのですが、私の回答は上記の2.に該当します。つまり、「あきらめる」ということです（詳しくは、「ソフトウェアエンジニアの成長カーブ」を参照してください）。

FORTRANから始まって41年（８）

テスト設計能力

今までの41年間を振り返って、十分に学習して実践できていないと思うのは、ソフトウェアのテスト設計です。もちろん、テスト駆動開発を行っていますので、テストコードを書いていないということはありません。

ソフトウェアのテスト設計は、品質工学的な視点を持って行う必要があるのですが、あまりきちんと学んで実践して来なかったというのが正直なところです。組み合わせ爆発を回避して効率よくテストを行うということに関しては、Hayst法がありますが、それもきちんと経験・実践することなく今日に至っています。

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

• 作者: 吉澤 正孝/秋山浩一/仙石太郎
• 出版社/メーカー: 日科技連出版社
• 発売日: 2007/07/26
• メディア: 単行本

書いたコードの品質を担保するために、経験のある先輩にレビューしてもらうように、テスト設計もきちんと経験がある専門家に指導を受けるのが、自己流になるのを避けるのによいと思っています。

10年以上前のことですが、当時マルチスレッドプログラミングによる複雑なシステムをテスト駆動開発で開発していたのですが、テスト設計として正しいのか、何か問題がないかという視点で助言をもらうために、私が部門長だった開発部で、秋山さん（上記の本の共著者）に指導を受けたことがあります。そして、行っているテストを説明したら、テスト設計が間違っているし、使うべきテスト設計手法が違っているという指摘を受けたことがあります。そして、指導に従ってテストを修正したらバグが見つかったという経験があります。

障害分析

テスト設計に加えて、障害を分析する活動も重要です。障害ごとなぜ発生したのかを分析して、どのような原因で発生している障害が多いかを整理して、対策を検討する必要があります。

障害分析というと、プロジェクトが終わった後に、振り返り的に行う組織が多いと思います。しかし、そのような障害分析では、効果的な改善はできないことが多いです。主な理由は以下の通りです。

• 障害の真の原因を知るには、障害対応した担当者からヒアリングする必要があるが、以前に行った障害対応なので、担当者が思い出せないことがある。
• 担当者は次のプロジェクトにすでに従事しており、障害分析のために時間を割り当てることができない。

障害分析は、開発中に始める必要があります。そして、開発組織（あるいは、開発チームやグループ）自身が行う必要があります。そうでなければ、上記の問題で、きちんとした障害分析ができないし、対策の検討を行い、開発中に対策の実施までを行って効果を見るというサイクルを回すことができません。障害分析は、プロジェクトの最初から行う必要はありません。障害がある程度の数、発生してから始めてよいです。そして、実際に分析を始めると、分析に必要な情報が不足していることに気づくことがあり、次に障害が発生したときに追加の情報を収集して分析に加えるというサイクルになります。

残念ながらこのように障害分析を行っている開発組織は少ないと思います。障害分析もきちんとできるようになるまでは、それなりのレビューや指導を受ける必要があります。幸い、私自身は、10年以上前に、上記の書籍の共著者である吉澤さん（現在は、品質工学会の副会長）から指導を受ける機会があり、私が部門長をしていた開発部で一年ほど指導を受けていました。

FORTRANから始まって41年（７）

テスト駆動開発の実践

開発対象のソフトウェアのテストを自動テストで行うテスト駆動開発の経験については、過去にまとめて書いています（「テスト駆動開発の経験（6）」や「不具合が発生した場合、必ず再現テストを書く」）。

「テスト駆動開発」という言葉が登場したのが、41年間の経験の後半に入ってからです。そして、本格的にテスト駆動開発を行うようになったのが、2003年からです。それだけ、ソフトウェアを手作業でテストする時代を長く経験したことになります。そして、2003年から経験したテスト駆動開発は、単に自動でテストするというだけでなく、テスト対象がマルチプロセス構成で、各プロセスがマルチスレッドで構成されているという非常に複雑なシステムでした。

テスト駆動開発を経験・実践することは、簡単なようでも、実は所属している開発組織によっては困難な場合があります。テスト駆動開発を実践していない開発組織では、すべてのテストが手動による目視確認になります。そして、そのような開発組織では、開発しているソフトウェアは製品やサービスのソフトウェアだけのこと多いです。そして、手作業でテストをするため、開発全体のコストがそれなりに高かったりします。

このような開発組織では、追加の自動テストコードを書いて、それらが動作するような何らかのフレームワークを作成したり、既存のレガシーコードを自動テスト可能になるように修正したりすることは、「余分な追加の開発コスト」とみなされて、却下されたりします。このような開発組織では、テスト駆動開発を実践して経験を積むことは困難な場合が多いです。テスト駆動開発を導入することをマネージャや開発部門のトップ（場合によっては年配のエンジニア）に対して説得しようとして、納得されずに徒労に終わってしまうことも多いのではないでしょうか。

私個人は、私自身が部門長という権限を持っている立場の時にテスト駆動開発を推進し、実際に自分で経験できました。しかし、若い人達がテスト駆動開発の経験を積むための近道は、「きちんとテスト駆動開発をしている開発組織で働くこと」です。

しかし、テスト駆動開発といっても、単に単体テストを書いているだけでインテグレーションテストは書かれていないとか、何らかのモックライブラリを使いすぎて意味のないホワイトボックステストだらけになっているような組織があったりもしますので、注意が必要です。

また、「マルチスレッドプログラミングにおける重要な４要件」で述べているような要件が求められるテスト駆動開発を行っている開発組織を見つけてそこで働くことは非常に難しいと思います。なぜなら、そこまで必要なソフトウェア開発を行っている組織が少ないと思うからです。たとえば、現在メルペイ社でbackendエンジニアとしてマイクロサービスを開発していますが、「マルチスレッドプログラミングにおける重要な４要件」が求められるような複雑なソフトウェア開発ではありません。これは、おそらく多くのウェブサービス開発に当てはまると思います。

FORTRANから始まって41年（６）

読みやすいコードを書く能力

大学時代、読みやすいコードを書くことの重要性は残念ながら教えてもらってはいないです。私自身も読みやすさに意識して注意を払い始めたのは、いつの頃かは思い出せないですが、おそらく『Code Complete』の初版や『Practice of Programming』を読んだ頃だと思います。

CODE COMPLETE (Microsoft Programming S.)

• 作者: Steve McConnell
• 出版社/メーカー: 日経BP社
• 発売日: 1998/04/04
• メディア: ペーパーバック

Practice of Programming, The (Addison-Wesley Professional Computing Series)

• 作者: Brian W. Pike, Rob Kernighan
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 1999/02/04
• メディア: ペーパーバック

読みやすいコードを書くことに関しては、「継続した学習（3）」で書いていますので、そちらを参照してください。