ソフトウェア開発組織が持つべきカルチャー 009

Source Code Controlへ最低でも毎日コミットする

今更言うまでもないですが、SubversionなどのSource Code Controlを使用するのは当たり前です。しかし、意外と普段の開発で使用していない人やチームがあったりします。

たとえば、プロトタイプ開発で開発者のPCにしかソースコードが存在しなかったりします。開発者に、プロトタイプのソースコードはどこにあるのかとか、きちんとソースコード管理に入れているのかと聞くと、開発者のPCにしかなかったりするのです。そして、チームリーダがソースコード管理に関心を持っていないため、ソースコードがそのような状態で開発が続けられていることがあります。あるいは、時々一つのファイルにまとめてバックアップしていますとか。

日々の開発では、最低でも一日に一回はコミットして帰るのが原則です（本来、コミット頻度はもっと多いはずですが）。しかし、開発者のPCにしかソースコードが存在しないような状況であれば、本来チームリーダは、Subversionなどに入れなさいとか毎日コミットしなさいと言い続ける必要があります。そうでなければ、明日の朝、開発者のPCが立ち上がらなくなって、コミットしていないソースコードを失ったり、開発者が何かの事情で長期休みになった時に、開発が進んでいたはずなのに、実際にはソースコードが無いという状況が発生することになります。

ソフトウェア開発組織が持つべきカルチャー 008

コードをレビューする

最近では、コードをレビューすることの重要性は多くの書籍で述べられています。しかし、組織によっては「レビューを行った」という事実が重要視されて、「質の高いレビューが行われた」ということにほとんど関心が払われていない場合があります。そうなると、実際にシステム全体を結合テストすると、非常に初歩的なコーディングミスで障害が発生することになります。

1999年の頃だったと思いますが、2週間以上調査された不具合の報告会に出た時に原因が「変数の初期化忘れ」というものでした。それで再発防止策として何があるのかと聞かれて、コードをレビューすれば良いのではと回答したら、「じゃ、ガイドを書け」と上司から指示されて、「Code Review Guide」を書きました。

当然、ガイドを書いただけではレビューは定着しませんので、ガイドの教育を多くのエンジニアに行い、実際のレビューを私自身が行いました。当時、C++言語での組込開発が始まることもあって「C++ Coding Standard」を書いて、さらに「Memory Management Library for C++」「Thread Library for C++」と関連するライブラリの設計も行いました。そのようなガイドやライブラリを実際に使用する開発チームに対しては、2000年の後半から2002年初め頃まで、ほぼ専任のレビューアとして現場でレビューを行っていました。多い時には、週に4日ぐらい一日中レビューということありました。

今日では、フォーマルなレビューからペア・プログラミングを通してのレビューなど様々なレビュー形式があると思います。しかし、重要なことは、コードの読みやすさ、エラー処理、防御的プログラミングなど様々な観点からコードがきちんと書かれているかをレビューすることです。

特に初心者のコードは徹底してレビューする必要があります。そうでなければ、先輩達が経験してきたであろう間違いをもう一度実体験することで、結果的にプロジェクトの開発期間を延ばしたり、デスマーチを引き起こしたりする場合があります。

たとえば、C言語でローカル変数のアドレスを関数から返したり、他のスレッドやタスクに渡した場合にはどのような挙動になるのかは不定です。それが原因で発生する障害の調査には時間がかかったり、仮に障害が修正されても、QA部門によりバグ管理されて、そのためのバグDBの更新、ソフトウェアの再リリース、QAでの再確認という追加工数が発生して、結果としてプロジェクトの工数を増大させてしまいます。一方、開発内でのレビューでこの程度の初歩的な誤りは指摘して修正していれば、将来プロジェクト全体に余分な追加工数を発生させることを未然に防ぐことができる訳です。

ソフトウェアの品質を上げると同時にプロジェクト全体の工数を減らすには、きちんとしたレビューに工数をかける必要があります。しかし、現実は「品質の作り込みよりスケジュール優先」ということで途中の中間マイルストーンは守れても、結合テストに入ると多くのバグを出してプロジェクト全体のスケジュールを延ばしてしまうソフトウェア開発が多いのではないでしょうか。

ソフトウェア開発のスケジュールでは、いい加減な開発でも結合テストまではスケジュールが守れたという「奇跡」※を恣意的に起こすことはできますが、品質の悪いソフトウェアでは結合テストの終わりのスケジュールを守るという奇跡を起こすことはできません。

※ Robert Martin著の『アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技』の付録には「奇跡」の面白い話が掲載されています。

ソフトウェア開発組織が持つべきカルチャー 007

カンファレンスへ積極的に参加させる

ソフトウェアエンジニアとしてのスキルアップに関しては、本来、会社に頼ることなく、自分の時間と自分のお金を使用することが重要です。そのため、講演（「ソフトウェアエンジニアの心得」）や教育などで次の言葉を紹介しています。

ソフトウェア業界で取り残されないようにするには、次の３つの事柄をあなた自身が認識することが重要です。

1. 重要な本、出版物を読み、主な専門的カンファレンスに参加すること。
2. あなたが今日読んだ情報は３年から５年で古くなるため、常に終わることのないプロセスであると言うこと。
3. あなたの会社は、良くても限られたサポートしか提供してくれないでしょうし、最悪何もサポートしてくれないと言うこと。

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

-- Edward Yourdon, Decline & Fall of the American Programmer

裏を返せば、組織内のエンジニアが井の中の蛙にならないためにも、開発組織としては積極的にカンファレンスなどに参加させることが必要だと言うことです。当然、業務として参加させるため、参加費用、交通費などが経費が発生しますが、その代わりにきちんと参加報告を書いてもらい、組織内で報告してもらえば良いのです。特に、若手の場合には、報告させることもトレーニングとなります。

そして、できるだけ多くのカンファレンスに、多くのエンジニアを参加させることも重要です。参加費用や交通費が必要なために、「一人だけ参加させて、その人が情報を展開すれば良い」という意見を聞くことがありますが、それではカンファレンスへ参加することに積極的なエンジニアを増やすことはできません。

もちろん、業務の関係や部門の経費予算の制約で人数やカンファレンスを制限する必要がある場合もあります※。それでも、本当に参加したいエンジニアは、自費で有休を取って参加します。しかし、組織として参加させることに積極的でない場合には、その組織内のエンジニアはカンファレンスなどに興味を持たなくなってしまいます。

※ 前職時代には、参加費用が有料の場合には参加人数を制限していましたが、無料のカンファレンスに関して、業務に支障がない限り、全員参加するように指示したりしたこともあります。

ソフトウェア開発組織が持つべきカルチャー 006

スキル向上に真剣に長期的に取り組む

Richard Gabrielの言葉を借りれば、ソフトウェアエンジニアとして一人前になるには10年以上要することになります。言い換えると、新卒新人で入社した若者を10年間きちんとスキル向上させなければ、10年後に会社を支える中堅エンジニアにはなりません。その点を認識して、ソフトウェア開発組織は、エンジニアのスキル向上に真剣に長期的に取り組む必要があります。

スキルの無い人々を、まともな教育をすることもなく、日々の開発できちんと技術指導もすることなく、開発に従事させれば、多くの障害が発生するのは明らかです。しかし、ソフトウェア開発を労働集約型と思っている組織では、個々のエンジニアのスキル以外の観点（プロセスやツール）で対策を打つことを検討します。知識集約型という認識であれば、スキルを重要視しますが、労働集約型だと思っている（あるいは、労働集約型にしたいと思っている）のでスキルの問題に抜本的に対策を検討したり、打ったりすることはしない訳です。

その大きな理由は、スキルの問題は、かなり長期的に地道な活動だからです。徒弟制度的に育成を行っている組織では当たり前に行われていることが、労働集約的な開発しか行っていない組織では、その地道な活動でさえ放棄してしまいます。つまり、「スキルの問題と言ってしまったら解決できない」と考える開発組織に限って、真剣に長期的な活動をほとんど行っていなかったりします。

「40代最後の年」で書いていますが、日本オラクルの初代社長である佐野力氏の次の言葉（正確には覚えていませんが）が今でも記憶に残っています。

5年後、10年後に日本オラクルを背負うのは、中途入社の皆さんではなく、新卒新人です。したがって、新卒新人は育てていきますが、みなさんは、即戦力として頑張ってください。

佐野力

ソフトウェア開発組織が持つべきカルチャー 005

プロセス中心ではなく、スキル中心

ソフトウェアは、人が頭の中で考えたことを手を動かして作り出すものです。つまり、家内手工業なのです。そのため、個々のソフトウェアエンジニアのスキルが重要であり、スキルを積み上げていくことが必要です。Richard Gabrielは、 「The Poetry of Programming」と題するインタビューの中で次のように述べています。

Writing software is an art, and it takes about ten years to really get good at it.
ソフトウェアを書くことは芸術であり、本当にうまくなるには10年を要する。

Richard Gabriel, 「The Poetry of Programming」

ソフトウェア開発においては、個々のソフトウェアエンジニアのスキルを向上させる活動をしながら同時にソフトウェアを開発してく必要があります。

しかし、日本のメーカーは、ソフトウェア開発を労働集約型の開発であり、人を投入すれば何とかなると思っているために、単価だけを問題にしたり、まともな教育や指導（レビュー）を行うことなく、大量に経験の浅い人たちを投入したりすることがあります。

個々のソフトウェアエンジニアのスキルを測ることは容易ではありません。たとえば、一年間で開発組織全体として、どれだけスキルが向上したかを測定することは困難です。私の経験から言えば、個々のエンジニアのスキルは、成果物のレビューの場で本人の考え方を聞いたり、成果物の品質を直接目で見たり、学習態度や普段のコミュニケーションなど多くの側面から接して判断しないと分からなかったりします。

初心者5人が集まってソフトウェアを開発した場合と、スキルの高いエンジニアが5人で開発した場合、その生産性と品質の差は明らかです。しかし、労働集約型的な開発を行っている組織では、スキルの低いエンジニアを大量に投入したりします。そして、多くの障害を発生させて、デスマーチ・プロジェクトを繰り返す訳です。

初心者のスキルの低さをプロセスで補強しようとして、設計レビューやコードレビューを義務づけても、そもそもきちんとレビューできるスキルの高いエンジニアが参加しなければ、レビュー結果の成果物の品質が高くなることはありません。設計レビューやコードレビューというプロセスを実行することだけに主眼が置かれていれば、当然のことながら、レビューしたけどバグだらけということは起こりえます。

本来、レビューというのは、品質を作り込むためのものであると同時に、経験の浅い人のスキルを向上させるためのものでもあったりします。その両方の目的を果たすには、スキルの高いエンジニアがレビューに参加している必要があります。

スキル向上のための施策の方が、プロセスを定義してそれを強制的に実行させるという施策よりも優先されるべきです。スキルの高い組織であればプロセスは開発者自身により自然と改善されていくものです。逆に、スキルの低い組織はプロセスは固定化されて強化され、開発者のスキルは向上しないという悪循環に陥る可能性があります。

（「プロセス中心ではなく、スキル中心」「プロセス中心ではなく、スキル中心（2）」）

ソフトウェア開発組織が持つべきカルチャー 004

マネージャが勉強会を主催する

開発の現場から離れてしまうと、技術の勉強そのものをしなくなる人が多いですが、実際に自分で開発していなくても、技術を学び続けることが必要です。そして、マネージャという立場上、現場のエンジニアのスキルレベルも把握できていなければなりません。そのための手段の一つとして、マネージャ自身が勉強会を主催することです。

マネージャが主催する勉強会というのは、その内容は３つに分類されます。

• 基礎として知っていて欲しい技術　マネージャ自身は長い開発経験から知っていることですが、若手は十分な基礎知識を持っていないようなテーマです。たとえば、ハードウェアの基磯知識、OS（Operating System）の基礎知識、データ構造とアルゴリズム、デザインパターン、リファクタリング、etc。
• 業務で使用している技術　実際の開発業務で使用している技術に関するきちんとした書籍を読みます。技術の表面だけをかじって開発するのではなく、本質を理解しながら開発するという態度を若手にも身につけてもらうため、使用している技術に関するバイブル本を学習します。たとえば、Javaであれば、『プログラミング言語Java第4版』や『Effective Java 第2版』、Rubyであれば『プログラミング言語Ruby』などを学びます。もちろん、言語だけでなく、使用しているフレームワークなどに関する本なども含まれます。
• 興味がある技術　実際に自分で開発していなくても、興味があったり一度は勉強してみたいと思う技術はあるものであり、それらをテーマとして書籍を通してマネージャ自身も学習します。

開発で必要な技術に関して、書籍を指定して読むようにと指示する場合もあるでしょうが、できれば勉強会として一緒に学習することで、若手技術者の理解レベルを同時に把握することが時には必要です。本人任せにしていると、ちょっと難しくて本人が理解できない部分は読み飛ばしているかもしれませんし、本を読んだと言っても本質的な部分を理解していなかったりするかもしれません。

マネージャに求められる技量の１つが、開発するソフトウェアの難易度と担当者のスキルレベルの両方をきちんと把握して、仕事をアサインすることです。そのための手段の１つとして、自分で勉強会を開催して、開発組織としての底上げを行うだけでなく、自分自身も使用している技術を理解すると同時に個々の担当者のスキルを把握することが重要です。

ソフトウェア開発組織が持つべきカルチャー 003

共に学ぶ

開発者が自発的に社内で勉強会を開催して、早朝、あるいは、定時後に様々なテーマで学習を継続することは、組織として重要な習慣です。その場合に、社員だけでなく、協力会社（派遣もしくは常駐型業務委託）のエンジニアも誘って一緒に学ぶとさらに良いです。

勉強会というのは、書籍を通して新たなことを学ぶ場であると同時に、書籍の内容に関して参加者が経験したことを共有する場でもあります。したがって、本来、技術の勉強会には会社という境界はなく、同じプロジェクト、同じ職場で働くエンジニアが共に学ぶことが大切です。

今日では、社外での技術の勉強会は様々なものが開催されており、所属する会社に関係なく、色々な人達が参加し、共に学びながら経験を共有したりしています。

協力会社の人達は、契約の関係である期間だけ一緒に仕事をすることになります。その際に、意識しておくべきこととしては、「あの会社で、誰々さん達と仕事をした時は楽しかったし、多くのことを学べた。機会があれば、もう一度一緒に仕事をしたい」と思ってもらえるように努めることです。

ソフトウェア開発組織が持つべきカルチャー 002

コンピュータの基礎を教える

今日、コンピュータサイエンスを学ぶことなくソフトウェア業界に就職する若者は増えています。彼ら・彼女らが今後ソフトウェア開発に従事してキャリアを積んでいくことを考慮すると、コンピュータの基礎を教えておく必要があります。教えておくべき基礎的な事柄としては、以下の項目があります。

• コンピュータの基本原理　CPUの基本構造、メモリー回路、割り込み動作、etc
• オペレーティング・システム　Linuxなどのオペレーティング・システムの基本的な仕組み
• データ構造とアルゴリズム　リスト、木構造、ハッシュテーブル、探索、O標記、etc

このような基礎的な事柄を一切教育せずに、オブジェクト指向分析とかJavaプログラミングを教えたとしても、その後の知識の獲得のための基礎が不足したりします。その結果、表面的な理解しかしていない技術者となってしまいます。

「このような教育は不要であり、業務を通して覚えれば良い」と言う人もいますが、実際に問題に遭遇した時に学んでいる暇はありません。極端な場合、数万件のソートされているデータを検索するのに二分探索法さえ思い付かず、線形探索をするコードを書いて、チーム内でレビューしても誰も線形探索は問題であることを指摘できないチーム※ができあがってしまってもおかしくはありません。

本来、ソフトウェア開発組織としては、「若い人が将来どのようなソフトウェア開発に従事しても困らないように」という視点を持って最初に基礎教育を行っておく必要があります。しかし、そのような教育は不要だと考えて、その組織で必要な技術を最低限学んで開発に投入してしまう組織も多くあったりします。その結果、他の種類のソフトウェア開発に従事できない技術者を増やすことになってしまいます。

逆に言えば、最低限の基礎知識を持っているかを確認したければ、上記項目に関連した質問をすれば容易に分かったりします。

※　このようなチームはいくらなんでも作り話だろうと思われるかもしれませんが、実際に遭遇したことがあります。

---

スポンサーリンク

ソフトウェア開発組織が持つべきカルチャー 001

継続した学習習慣

会社でのソフトウェア開発業務のみを通しての学習では、何年ソフトウェア開発を経験しても、経験できる範囲は非常に狭いです。業務を通しての知識や経験を積み上げることによる不足分を補うには、書籍を通しての学習を継続していく必要があります。つまり、他者の経験から学ぶことも重要になってきます。

Read Any Good Books Lately?

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

Steve Maguire, Debugging The Development Process

学習は個人の問題のようですが、組織として学習を促進していない場合には、学習する人が中にはいたとしても、全体として学習をしない組織となってしまいます。

個人が学習をしなくて、業務遂行のための最低限のことしか学ばない場合（あるいはネットで調べる程度）、社会人となって数年が経過した時点で、学習する態度を失ってしまいます。学習をしない先輩の下に新たな新人が配属されると、その新人も学習しなくなってしまいます。

学習を促すためにどのような方法が最善なのかは分かりませんが、私自身が過去に行ってきたことを話します。

勉強会への強制参加

新卒新人は、職場で開催している勉強会に対しては「業務扱い」で強制参加としてきました。業務扱いということは、勤務時間内ということになります。しかし、同じ勉強会に、私も含め多くの先輩が非業務として参加しています※。業務扱いが続くのは、半年から一年です。それ以降は、業務扱いを認めないということを行ってきました。勉強会で使用する技術書も基本は自費購入ですが、新人だけは強制参加ということもあり、部門の経費で購入していました。

※　フレックス勤務の場合には、コアタイム以前に勉強会を開始し、新人は勤務時間としますが、先輩は自発的な参加ということになります。

非業務扱いになったとたんに、勉強会に参加しなくなるという人は非常に少ないです。なぜなら、先輩もずっと非業務扱いで参加しているからです。

このような勉強会の開催は、実は簡単ではありません。なぜなら、①勉強会が開催されていなければなりません。②新人が業務で参加することをマネジメントが認めなければなりません。③勉強会というのは原則業務時間外に継続して行うのが当たり前というカルチャーが必要となります。

組織としては、非業務扱い業務扱いに関係なく、業績評価ポイントには勉強会参加を加算します。そのためには、半年で何回以上参加というような目標値を設定します。

昔からそうですが、継続して学習する習慣を失うとソフトウェアエンジニアとしてのスキルは低いままとなり、そのまま歳を取っていくと、新たな技術を学習しない年取ったエンジニアとなってしまいます。つまり、ソフトウェア開発組織としては、長期的に本人が自立して成長し続けることを促すためにも、組織全体が継続して学習する習慣を持つ必要があるのです。

マネージャが学習を継続する

継続的に学習するというのは、マネージャや管理職になったからしなくて良いというものではなく、むしろ逆に、実際の開発はしなくても学習を継続し、自ら勉強会を主催していくことが求められます。しかし、多くのソフトウェア開発組織では、マネージャ自身が学習を止めてしまっているのが現実ではないでしょうか？

つまり、組織として継続した学習が行われるかどうかは、個々のエンジニアの問題というよりは、マネージャ層以上の問題だったりもします。自分は学習をしないのに若い人が学習をすることを期待するだけでは何も改善されなかったりします。

ソフトウェア開発組織が持つべきカルチャー

私自身は、転職を4回行い様々なソフトウェア開発の職場を経験し、自分でもソフトウェア開発の組織を持ったりしてきました。その経験に基づいて、ソフトウェアエンジニアの心得としての『プログラマー”まだまだ”現役続行』や、私自身の経験を織り交ぜて書籍を紹介している『ソフトウェア開発の名著を読む』を執筆してきました。

ソフトウェアエンジニア個人に焦点を当てるのではなく、「ソフトウェア開発組織が持つべきカルチャー」と題して、これからしばらくは、組織としてどのような文化を持つべきかを中心に書いていきたいと思います。あくまでも、私自身の経験ベースなので、かなり偏っているかもしれませんし、過去のブログの記事や拙著の内容とダブっている部分も多いかと思います。

良いカルチャーを持つ組織というのは、これからソフトウェア業界で働き始める若い世代には非常に重要です。ブログ記事「人生は自分が触れたものになる」では、次の文章を紹介しています。

「人生は自分が触れたものになる」と私は考えています。
三流のものに囲まれて、三流のものに触れていたら、三流になる。
一流のものに囲まれて、一流のものに触れていると、やっぱり、一流に近づいていくようになります。
（途中省略）
自分の環境をどうつくるか－それで、その人が変わります。

本田 健、『20代にしておきたい17のこと』

新卒新人で社会人になる若い人達は、大学でコンピュータサイエンスを学んだかどうかに関係なく、ソフトウェア業界で成長する可能性は秘めています。どれだけ成長できるのかは、個人の問題ではありますが、属している組織によって大きく変わっていきます。

ブログ記事「技術の伝承と良い習慣の伝承」で述べたように、単なる技術だけなく、良い習慣が組織カルチャーの重要な部分を占めます。

一時的なノウハウ（技術）の伝承よりは、ソフトウェア開発全体に対する良い習慣を若い人たちに伝承することが組織としては重要になってきます。そして、その習慣を通して、ソフトウェア開発に関する技術の伝承をできる人材が育っていく必要があります。

ブログ記事「技術の伝承と良い習慣の伝承」

個人ではなく組織として持つべき習慣※として次のようなものがあると思います。

• 継続した学習・教育の習慣
• 継続したコード品質重視の習慣
• 継続した自動化の習慣
• 継続した改善活動の習慣
• コミュニケーション重視の習慣

残念ながら日本のソフトウェア業界では、良い習慣を持った組織は少なく、時代遅れの開発手法やプロセスに束縛されて、「知識集約型開発」ではなく「労働集約型開発」を行っている職場が多いのではないかと思います。

習慣としては他にもあるかとは思いますが、これらをテーマとして今後ブログ記事を書いていきたいと思います。

※　あと2つ追加するか、分割して「7つの習慣」とすると響きが良いのですが・・・・