So-net無料ブログ作成

教育、場、権限 [プログラマー現役続行]

転職してから気づいたことなのですが、私自身のソフトウェア開発の経験をもとに会社の中で若手のエンジニアの成長を後押しするには、次の3つの条件が揃っている必要があります。
  • 教育 - 基本的に知っておいてもらいたい事柄を技術教育や勉強会という形式を通して教えてく。
  • - 教育で教えたことを、設計レビューやコードレビューなどの日々のソフトウェア開発活動全般を通して指導していく。それにより、教育では伝えきれない部分を伝えていく。
  • 権限 - 日々のソフトウェア開発での指導ができる組織上の権限。
教育を受けただけで、日々のソフトウェア開発で実践指導されなければ、身につくことはないかもしれません。教育をすることだけが自分の仕事だと思っている人であれば、教育したという事実で満足するかもしれません。しかし、私自身は、場が与えられなければ教育の効果がないということを感じています。

日々指導するには、ソフトウェアの開発組織ライン上の権限が必要となってきます。たとえば、チームを構成するメンバーでもなくそのチームリーダでもなければ、チームリーダが指導しないことをそのチームのメンバーに指導することは簡単なことではありません。

つまり、若手技術者の育成には、「教育、場、権限」が必要だということになります。そうでなければ、ソフトウェア開発を何年経験していても、中途半端な技術者が増えるだけかもしれません。

(「教育と場」、「教育と場(2)」)

報告と指導 [プログラマー現役続行]

ソフトウェア開発組織におけるコミュニケーションは、非常に重要な要素です。毎朝のスクラムミーティングで状況の確認や指導、あるいは、毎週の週報会での活動報告を受けての状況の確認や問題点への対応の指示などを行う場であったりします。

しかし、リーダのソフトウェア開発経験や人材育成に関する考え方次第では、単なる「報告会」になってしまうのか、「報告と指導の場」になるのかという大きな違いが発生します。単なる報告会になっていると、チームで集まって報告を聞くことが無駄だと感じてしまい、全員を集めるミーティングは無駄という発想になってしまいます。

指導の場も兼ねるという発想だと、報告内容を深掘りする質問をしたり、他のメンバーにも分かるように説明を求めたり、あるいは、本来どうすべきかの指導をしたりします。そして、重要なことは、それらすべてを参加メンバーと共有することで報告者だけでなく全員への指導となる訳です。

コードレビューでたとえると、一行一行処理が正しいかとか読みやすいかとかのきちんとしたレビューをしないで、表面的に「何となくいいのでは」というレビューをしていくと、レビューを通して指導する場ではなくなり、無駄な時間と考えられてしまいます。なぜなら、レビューをしてもコードの品質は上がらないし、レビューを受ける側のレベルが上がるような指導を受けないからです。

別の例で言えば、現場の担当者がビルドを手作業で行っているとしたら、リーダはそのような報告の場で、自動化するように指導したり、自動化のために他の作業との優先順位の調整をしたりすることが必要です。しかし、技術的指導も含めて指導しない人がリーダの場合には、手作業で行うのが問題であるという認識がなかったりして、指導するという場面がなく、単なる報告会になってしまったりします。そして、全員が集まるのが無駄という感覚がメンバー全員に浸透してしまいます。

一対一の指導は、非効率です。同じ知識を全員に伝達するには多くの時間を要しますし、あるいは全員に伝える機会も時間もないかもしれません。そして、単なる報告会しか行わないミーティングばかりだと、基本的なことさえ開発組織全体に浸透しなかったりするかもしれません。

書籍『The Clean Coder: A Code of Conduct for Professional Programmers』 [プログラマー現役続行]

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

  • 作者: Robert C. Martin
  • 出版社/メーカー: Prentice Hall
  • 発売日: 2011/05/23
  • メディア: ペーパーバック

『アジャイルソフトウェア開発の奥義』『Clean Code アジャイルソフトウェア達人の技』の著者であるRobert Martin氏の新著です。サブタイトルは、「プロのプログラマーの行動規範」という意味であり、著者自身の長年のソフトウェア開発の経験や失敗を紹介しながら、プロのプログラマーとしてはどうあるべきかが説明されています。目次は次の通りです。
Pre-Requisite Introduction
Chapter 1. Professionalism
Chapter 2. Saying No
Chapter 3. Saying Yes
Chapter 4. Coding
Chapter 5. Test Driven Development
Chapter 6. Practicing
Chapter 7. Acceptance Testing
Chapter 8. Testing Strategies
Chapter 9. Time Management
Chapter 10. Estimation
Chapter 11. Pressure
Chapter 12. Collaboration
Chapter 13. Teams and Projects
Chapter 14. Mentoring, Apprenticeship, and Craftsmanship
Appendix A. Tooling
目次を見てもらえれば分かるようにソフトウェア開発のいろいろな側面から説明がされています。今回は、Kindle版を購入してKindleで読んだのですが、アンダーラインをかなりたくさん引いています。その中で、私自身の身近な話題に近い事柄に関することをAppendix Aから一部を紹介します。
Source Code Control

When it comes to source code control, the open source tools are usually your best option. Why? Because they are written by developers, for developers. The open source tools are what developers write for themselves when they need something that works.

There are quite a few expensive, commercial, "enterprise" version control systems available. I find that these are not sold to developers so much as they are sold to managers, executives, and "tool groups." Their list of features is impressive and compelling. Unfortunately, they often don't have the features that developers actually need. The chief among those is speed.

An "Enterprise" Source Control System

It may be that your company has invested a small fortune in an "enterprise" source code control system. If so, my condolences. It's probably politically inappropriate for you to go around telling everyone, "Uncle Bob says not to use it." However, there is an easy solution.

You can check your source code into the "enterprise" system at the end of each iteration (once every two weeks or so) and use one of the open source systems in the midst of each iteration. This keeps everyone happy, doesn't violated any corporate rules, and keeps your productivity high.
青字の部分は、私が読んでアンダーラインを引いた箇所です(ボールドは私が単に強調した部分です)。また、Appendix Aには、「UML/MDA]」とタイトルされた部分で、次のようにも述べられています。
UML/MDA
(途中省略)

The dream was that software developers could leave behind the details of textual code and author systems in a higher-level language of diagrams. Indeed, so the dream goes, we might not need programmers at all. Architects could create whole systems from UML diagrams. Engines, vast and cool and unsympathetic to the plight of mere programmers, would transform those diagrams into executable code. Such was the grand dram of Model Driven Architecture (MDA).

Unfortunately, this grand dream has one tiny little flaw. MDA assumes that the problem is code. But code is not the problem. It has never been the problem. The problems is detail.
そして、detail(詳細)の意味を「The Details」で解説していますし、その後の「No Hope, No Change」でも解説が続いています(ちょっと長いので書籍を読んでみてください)。

書籍全体にプログラマーとしての行動規範や考えるべきことがが書かれています。そして、単にプログラマー向けというだけでなく、ソフトウェア開発組織のマネジャー層以上の人にも読んでもらいたい内容です。

「本質」を勉強する [プログラマー現役続行]

バカになれる人はバカじゃない

バカになれる人はバカじゃない

  • 作者: 小宮一慶
  • 出版社/メーカー: サンマーク出版
  • 発売日: 2011/05/25
  • メディア: 単行本(ソフトカバー)

この本の"仕事の時間外に仕事の「本質」を勉強する"(p.58)では、次のように述べられています。
(途中省略)
 本質を知る人と、知らない人、その差はあとあとになって明確になっていきます。たとえ本質を勉強していない人でも、器用な人は、表面的に事象をとらえて、上手に仕事をこなすことができます。でもそれでは一流にはなれません。
 本質を勉強した人と、していない人の差は、はじめはあまりあらわれません。とくに若いときは、単純な仕事が多いので、本質を知らなくても、仕事はこなせます。表面的に仕事を右から左にながしているだけのときは、差は出ないでしょう。
 でも、ある程度の年齢になって、いろいろなことを総合的に判断しなければならない立場になったとき、本質を知るのと知らないのとでは大きな差があらわれます。世の中は複雑で、年齢を重ね地位が上がるにしたがって仕事の複雑さは増していくからです。複雑なことを正しく判断するには本質を知らなければなりません。
(途中省略)
 本質の勉強は会社では教えてくれません。会社で教えるのはオンザジョブだけ。オンザジョブしか知らずに、本質を知らないようでは、応用がききません。
 だれしも仕事の経験を積んでいくと、仕事の幅が広がり、判断することも増えて、重要度が増していきます。そういう役職に就いたとき、方向性を誤ることなく、高度な仕事ができるかどうかは、本質を勉強することでしか身につかないものにかかっています。
 本質は、仕事の時間外のところで、自ら勉強するしかありません。週に二時間でも三時間でもかまいません。自分の仕事の本質的なことを勉強してみてください。
 仕事を始めたばかりの人はもちろんのこと、ベテランの人も勉強し続けることが必要です。本質をつかむ人とつかまない人では、人生のステージが違ってきます。
そして、"「一番良い教科書」を丁寧に読みなさい"(p.64)では、次のように述べられています。
 本質を勉強するときにおすすめしたいのは、そのジャンルで一番良いとされている本を教科書として読むことです。
 良い教科書さえ見つければ、いわゆるあんちょこ本や入門書は必要ありません。
 かいつまんで書かれた本は、どうしてもその世界の深い部分まで説明することがむずかしいのです。入門書を読んだだけで、分かったつもりになるのも良くありません。少々たいへんかもしれませんが、ともかく良い教科書で勉強することが大切です。
この本は、ソフトウェアエンジニア向けではもちろんないのですが、ソフトウェアエンジニアにもそのまま当てはまる内容だと思います。

コンパイル時のワーニング(-Wallと-Werror)(2)  [プログラマー現役続行]

プログラミングの伝承としてif文の中で変数をある特定の値と比較する際に、その特定の値を==の左に書いて、変数を右に書くというものがあります。たとえば、C++であれば、
if (0 == ptr) {
     // ...
}
このように書く理由として、==とタイプすべきところを間違って=と書いてもコンパイラがエラーにしてくれるからだと説明されます。しかし、上記の書き方は、プログラムを読む際には、「0ptrか」と読むことになり、意味としておかしいものとなります。本来なら素直にptr == 0と書いて、「ptr0か」と読み手に読ませるべきです。※1

gcc/g++では、-Wallをコンパイルオプションで指定すれば、ptr = 0と間違って書いたとしても、次のように警告します。
warning: suggest parentheses around assignment used as truth value
当然、-Werrorを指定すれば、コンパイルは中止されます。つまり、C/C++でGNUコンパイラを使用する環境では、-Wall -Werrorを標準でコンパイルオプションにしておけば、意味的におかしいコーディングをする必要がなくなります。※2

※1 C++では、ポインターを0と比較することは容認されています。 NULL(void *) 0と定義されている場合には、NULLと比較するとコンパイルエラーになるためです。
※2 私自身は、==と書くべきところを=と書いてしまった経験は、記憶にある限りではありません。でも、おそらく、プログラミング初心者の場合には、間違って書いてもおかしくはないかと思います(覚えていないだけで、ひょっとしたら若い頃には私も間違って書いてデバッグに苦労したことがあるのかもしれませんが)。

C++とメモリ関連エラー [プログラマー現役続行]

私自身がC++言語で初めて開発に従事した商品はFuji Xerox DocuStation IM 200でした。1996年初めのことです。Solaris 2.3をOSとして、白黒でしたがデジタルコピー/Faxそれにペーパーユーザインタフェース(Paper User Interface)が搭載されていました。その開発で苦労したのは、やはり、メモリ管理でした。メモリーリーク、メモリ破壊、不正なメモリ解放などを検出する仕組みを開発途中から入れるために、C++のnew/delete演算子を私自身が独自に実装したものを使用することでシステム全体の安定化を図りました。

その後、C++用のメモリ管理モジュールの仕様を2000年に再設計しました。そのメモリ管理に基づくスレッドライブラリーやスレッドセーフなコレクションライブラリーの設計を同時に行い、優秀なエンジニア2名※1に実装してもらいました。作成した一連のライブラリーは、その後のデジタル複合機開発では早期にメモリ関連のトラブルを防ぐために活用されましたし、現在でも使用されています。※2

CやC++でのシステム開発では、性能を落とさずにある程度の最低のメモリ関連のチェック機構を作り込むことで、開発期間全体を通してそのチェック機構に助けられます。IM 200を開発した頃に、purifyが登場したのですが、チェック機構は非常に強力でしたが、システム全体が非常に遅くなってしまい、常時組み込んで使用することはできませんでした。

※1 一人は木南英夫さんです。
※2 よく考えてみると10年以上使われ続けるライブラリーを策定したことになります。

英語の書籍による勉強会(2) [読書会]

英語の書籍による勉強会」でも書きましたが、英語の書籍を使用した勉強会を1999年から継続して行っています。現在は、昨年から始めた『Linux Kernel Development, 3rd Edition』の勉強会を毎週月曜に継続して開催しています。

Linux Kernel Development (3rd Edition) (Developer's Library)

Linux Kernel Development (3rd Edition) (Developer's Library)

  • 作者: Robert Love
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2010/07/02
  • メディア: ペーパーバック

参加している人達は、私より二回り近く若い人達です。私の勤務地は海老名RTCなのですが、大森事業所からも電話会議で参加してもらっています。朝7時40分から8時45分までの1時間です。残念ながら、7月から9月は会社がサマータイム制を導入するため始業時間が1時間早くなるので、勉強会は休会となり、10月から再開します。

英語の書籍を読むというのは、初めての人にとってはやはり、難しかったりします。しかし、継続して参加することで、当初よりは英文の理解力が徐々に良くなっていきます。技術書は、1つセンテンスが長いことが多いのですが、そのため頭から読んで構文を読み取ることが難しいです。しかし、回を重ねるごとに、構文を理解する力が徐々に良くなっているのが分かったりします。

残念ながら、長年、英語の書籍での勉強会を開催した経験からすると、勉強会で使用する書籍しか英語を読まない人は、あまり英語力は伸びていきません。他の技術書や小説なども英語で積極的に読むとか、継続してリスニングを続けるといったことも並行して行っている人は伸びていきますが、そうでない人はある程度で頭打ちになって伸びていかないようです。

しかし、週に1回1時間とはいえ毎週継続的に参加することで、英語に対する抵抗感は少なくなっていきますし、最後まで続ければ英語で技術書を読み終える達成感を得ることができます。一人で英語の技術書を読み続けるというのは、ある程度の英語力がなければ続けるのが困難だったりしますが、勉強会への参加を継続することで、若い時から技術書を英語で読むことを習慣にすることができます。そして、英語でも読むことができるソフトウェアエンジニアになれば、書籍選びの範囲が非常に広くなります。

開発環境(5) [プログラマー現役続行]

開発環境(4)」でも述べましたが、開発環境・ビルド環境は、ソフトウェア開発の一部であり、開発のリーダはその重要性を認識した上で、現場の開発者を指導していく必要があります。

かなり時代遅れの開発環境・ビルド環境から、完全な継続的インテグレーション環境を整備して移行しても、その移行により、どれだけの効率改善と問題の未然防止に役立っているかを開発現場のリーダが認識して上手く活用する必要があります(「リーダはコードに関心を持つ(3)」)。

しかし、何かちょっとしたトラブルがあると「昔はこんなことはなかった」と実際には自分でビルドを行ったことがないにもかかわらず、リーダがビルド環境を構築したエンジニアを非難したりすることがあったりします。あるいは、手作業でビルドしているようなので、自動化する必要はないのかと聞くと、「自動化した方が良いですか?」と逆に聞かれたりすることもあるかもしれません。

ソフトウェア開発は、非常に複雑な活動です。頭数を揃えれば良いというものではありません。そして、コンピュータではなく人がソフトウェアを開発するために様々な問題が起きます。それらの問題を解決するために様々な手法、設計方法、開発方法が生み出されています。防御的プログラミング、テスト駆動開発、継続的インテグレーションなども、人が犯す間違いを最小限に抑えて、仮に間違いを犯したとしても早期に発見・修正するために生み出されたものです。

開発現場のリーダがこのような手法にどれだけ精通していて、現場を指導できるかによっても、ソフトウェア開発組織の生産性と作り出されるソフトウェアの品質が左右されることになります。

開発環境」、「開発環境(2)」、「開発環境(3)」、「開発環境(4)

リーダはコードに関心を持つ(4) [プログラマー現役続行]

「ソフトウェアエンジニアの心得」と題する講演や教育では、次のことをスライドの一枚の中で述べています。
初心者だからと言って、汚いコードを書くことが許される訳ではない
初心者の場合には、最初からきちんとしたコードを書ける訳ではありません。したがって、ソフトウェア開発組織としては、初心者の書いたコードをきちんとレビューして良いコードを書かせることを地道に繰り返し行っていく必要があります。何度も書き換えさせたとしても、きちんとコードを書いていくことの重要性を認識させて訓練していく必要があります。

言い換えると、コードをレビューして指導する力がない人やコードをレビューする習慣を持たない人の下で初心者を働かせてはいけないことになります。そのような人の下で初心者を働かせて、その初心者がひどいコードを書き続けたとしても、ひどいコードの責任は経験の浅い初心者の責任ではありません。ソフトウェア開発組織の責任です。