ソフトウェア開発が好きでないサラリーマンエンジニア

ソフトウェア開発は、自分で考えて手を動かしてプログラミングして動くものを作ることを繰り返す訳ですが、そもそもソフトウェア開発という「物作り」を好きではないサラリーマンエンジニアが日本には多いのではないかと思います。

その理由は単純で、新卒新人でも中途入社であっても、自分で分析・設計から実装・デバッグまでするのが好きな人を採用していないからだと思います。たとえば、メーカーでソフトウェア開発部門に配属されるような新卒新人でも、大学ではほとんどプログラミングしたことがない人をメーカーは採用します。中途採用であっても、採用面接でプログラミングを伴う技術的な質問をほとんどしません。

その結果、企業の中には、本当にソフトウェア開発が好きなソフトウェアエンジニアと仕事だからというサラリーマンエンジニアがいることになります。そして、サラリーマンエンジニアは、そもそも好きではないので、業務がこなせるようになった時点で学習をやめたり、プログラミングそのものをしなくても何の不満もなくなったりします。

日本の企業は、ソフトウェア開発が好きなソフトウェアエンジニアとサラリーマンエンジニアを区別して開発組織を構成しないことがほとんどです。その結果、開発するソフトウェアが何であれ、両者の比率次第ではエキサイティングな開発になるのか、つまらない疲れるだけの開発になるのかに分かれます。

サラリーマンエンジニアが多い組織では、若くして開発しない人員やマネージャの人数比が高かったり、開発しているソフトウェアの難易度や現場のエンジニアのスキルをマネージャが把握していないということがあります。そのような組織では、ソフトウェア開発が好きなソフトウェアエンジニアは機会があれば去って行くことになり、状況は悪化することになります。

ソフトウェア開発が好きなソフトウェアエンジニアの場合、会社の開発業務以外に色々な技術に興味を持ちますので、今日では様々な勉強会やセミナーへ参加します。あるいは、直接会社の業務とは関係なくても、Google Developer Day 2011のDevQuizなどに挑戦して、参加資格を得ようとします。

会社の業務と関係なく、社外の勉強会やセミナーに参加しているエンジニアがみなさんの開発組織にはどれだけいますか？ DevQuizに挑戦した人が何人いますか？ もし、ほとんどいないとしたら、サラリーマンエンジニアから構成される組織かもしれません。

---

スポンサーリンク

ソフトウェア開発組織が持つべきカルチャー 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』などを学びます。もちろん、言語だけでなく、使用しているフレームワークなどに関する本なども含まれます。
• 興味がある技術　実際に自分で開発していなくても、興味があったり一度は勉強してみたいと思う技術はあるものであり、それらをテーマとして書籍を通してマネージャ自身も学習します。

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

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

オープンセミナー2011@香川（２）

9月23日（金）に、サンポートホール高松で開催されたオープンセミナー2011@香川で、「ソフトウェアエンジニアの心得」を話をしました。私を含めて4名の講師が話をされました。普段、聞けない話を聞けて良かったです。

高松での開催ですが、岡山や徳島から参加されている方もおられ、昨年岡山で私の話を聞かれた方も参加されていました。セミナーの後は、懇親会で楽しく話をすることができました。

オープンセミナー2011@香川の実行委員のみなさん、講師のみなさん、参加してくださったみなさん、ありがとうございます。

栗林公園

高松へ来たのは初めてでしたので、24日（土）は妻と二人で、栗林公園や玉藻公園などを見て回りました。持参したガイドブックには掲載されていなかったのですが、夜はホテルの近くにある「Mikayla」で夕食を食べてホテルに戻りました。

四国は、徳島に一年間住んだことがあります。地方は車が必要ですが、道も広く、住みやすいだろうと思った次第です。

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

共に学ぶ

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

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

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

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

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

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

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

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

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

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

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

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

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

---

スポンサーリンク

オープンセミナー2011@香川

9月23日（金）に高松で開催されるオープンセミナー2011@香川で話をします。

• オープンセミナー2011@香川
• オープンセミナー2011@香川
• オープンセミナー2011@香川懇親会

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

継続した学習習慣

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

Read Any Good Books Lately?

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

Steve Maguire, Debugging The Development Process

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

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

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

勉強会への強制参加

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

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

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

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

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

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

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

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

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

書籍『“捨てる”勉強法』

“捨てる”勉強法 (PHPビジネス新書)

• 作者: 和田 秀樹
• 出版社/メーカー: PHP研究所
• 発売日: 2011/04/26
• メディア: 新書

若い人向けの勉強法の本ですが個別の内容については読んでもらうとして、ソフトウェア開発者向けの書籍に書かれていることと同じことが書かれていると思った部分を紹介します。

”高原現象”が起きたら

　三十代からの勉強には終わりがない。だからどこかで、「もうこれ以上、勉強しても意味がないんじゃないか」と思うときがくる。学習曲線は、勉強を続けるにつれて一直線に伸びていくわけではない。何処かの時点で停滞して上達スピードが落ちる。
　どんな学習にしても効果がほとんど上がらなくなる現象を、高原のように平坦なことのたとえで「高原現象」という。そんなときは新たなインプットをしないことが重要である。
（途中省略）
　もうひとつ、あまりやる気がでないときには、得意科目ばかりをやるといい。それによって「自分はできる」という気持ちを増長できるからだ。

和田 秀樹、『“捨てる”勉強法』

同じことが、『アプレンティスシップ・パターン』の「得意領域への撤退」でも述べられています。

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得

• 作者: Dave H. Hoover
• 出版社/メーカー: オライリージャパン
• 発売日: 2010/07/08
• メディア: 単行本（ソフトカバー）

「やる気」はできる人からもらえ

(途中省略）
自分より出来のいい人たちのグループでビリでついていくのと、自分より出来の悪い人たちのグループに入ってトップにいるのでは、その後の成長が大きく変わってくる。
　自分より出来の悪い人たちと付き合っていると、気分はいいのだが、お山の大将になってしまって努力を怠ってしまう可能性がある。もちろん、自身の勉強内容を誰かに教えることで、記憶を定着させるというメリットはある。しかしそのポジションを活用するためには、「その集団を率いながら、自分の勉強を続ける」という確固たる信念が必要である。
　もし自分は意思が弱いと思うなら、ビリであっても、できる人たちのグループに入っている方が成長のチャンスに恵まれる可能性が高い。
　そして出来のいい集団とそうでない集団は、何よりも目標設定のレベルが違う。自分より出来の悪い人たちのグループでは、自分の設定した目標が、そのグループの最も高い目標になるはずだ。
　しかし、できる人たちのグループでは、もっと高い目標を持った人がたくさんいる。その影響を受けて、自分自身も目標のレベルアップを意識するようになるだろうし、高い目標を達成するための情報もいろいろと入ってくるようになるだろう。

和田 秀樹、『“捨てる”勉強法』

これは、ソフトウェア業界でいえば、『アプレンティスシップ・パターン』や『情熱プログラマー』で述べられている「最低である（Be the Worst）」と同じです。

情熱プログラマー ソフトウェア開発者の幸せな生き方

• 作者: Chad Fowler
• 出版社/メーカー: オーム社
• 発売日: 2010/02/26
• メディア: 単行本（ソフトカバー）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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