ソフトウェアエンジニアのキャリアパスとして、色々とあるかと思われる。 ソフトウェアエンジニアのレベルというのは、ソフトウェア開発に従事した期間ではないのは明らかである。一方で、ソフトウェア業界で生きてきて40代、50代になっている人も多いようである。 年齢を重ねた時には、どのような職場でも、経験年数に相応の問題解決能力、解決に向けての提案能力、あるいはトラブルなどの的確な説明能力を回りの若い人達は期待する。 この「回りの若い人達は期待する」ということに対する自覚がなくて、単なる一プログラマーということで指示された仕事だだけをこなすのに精一杯だと、おそくら、指示された仕事もろくにこなせていないことになることが多い。 能力が高く評価されるというのは、相手の期待を越えた、例えば、110%の成果を出すことであり、自分が精一杯やったからという理由だけで高く評価されることはない。 ソフトウェア業界で、

Java研修を2000年から始めた頃は、PC実習室で行っていました。ネットで何か調べものをした方が良い場合もありましたがが、その頻度は低かったのです。しかし、講義の内容を聞くことなく、キーボードを操作している人がいたりしました。 最近は、新人でもデスクトップではなく、ノートPCを業務用に配布されて、それを持ち出し可能になるように手続きしていたりします。そのようなノートPCの配布がなかった頃は、Java研修にノートPCを持ってくる人は非常に少なかったし、誰も持ってこないのが普通でした。しかし、やはり、持ってきたいという要望が強くなってきたので、持ってくることをOKにしていました。その結果、Java研修でも普段使用しているノートPCをほとんどの受講生が持ってくるようになっています。 しかし、自分が当てられないような状況だと、講義内容を聞くことなく、ノートPCを覗いていたり操作していたりする受講

「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事

この本は改訂版であり、初版は2006年9月に出版した『プログラマ－現役続行』です。しかし、初版は書き下ろしではなく、雑誌の記事を再編集したものです。その最初の記事は、「XML PRESS, Vol.2」（2000年12月）に掲載された記事「論理思考と正しい知識」です。つまり、この書籍の多くは、私が40代前半までに経験したことがベースとなっています。そして、残念ながら、この書籍で述べている昔見た光景は、今でも見かけます。その主な理由は、ソフトウェア開発は複雑な作業である上に、家内手工業だからだと思います。つまり、常に頭の中で考えたことを手を動かしてプログラミングして作り上げる作業なのです。 考えないエンジニア 今日では、コンピュータ技術の急速な発展のおかげで、コーディングをしてからあっという間にコンパイルができ、すぐに実行可能です。プログラミング初心者の特徴として、コンパイルエラーのエラーメ

かなり前に「技術的負債」として、3つの記事を書いています。 技術的負債 技術的負債(2) 技術的負債(3) 「技術的負債（３）」では、次のように書いています。 見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負債に無頓着な人々が開発組織の大半を占めるようになり、会社は負債をますます増大させることになります。 さらに、一からシステムを作成した経験がないエンジニアが組織内に増えてしまうことにもなります。製品を出し続

技術を完全に消化し、いつルールを破るべきか知っている。また、技術記事などを執筆している。さらに、中級職人以下の職人を上級職人にすべく、組織に対して教育・指導を行っている。 社内の評価というのは相対評価であり、ソフトウェアエンジニアとしてのキャリアパスを続けるためのモチベーションを維持するためには、外向きの活動が必要だということで、「名人」「匠」を定義しています。 このソフトウェア・スキル・インデックスを吉澤正孝さんと検討してまとめたのは、かなり前のことです。2007年に出版した『プログラマー現役続行』には掲載していますので、2005年か2006年に検討したのだと思います。 残念ながら、ここで定義されている「名人」「匠」のような活動をすることで社外からは評価されるようになっても、日本の多くの企業（特に大企業）では、社内からは評価されないかもしれません。その理由の一つは、名人や匠で定義している

Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1　プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境

「本当は技術職を続けたかったけど、会社の制度上仕方なくマネージャになった」という人で、本当にソフトウェアエンジニアとしてソフトウェア開発を続けたかったの？と疑問符が付く人が多いです。ソフトウェア開発業界が面白い点の1つは、絶えることなく新たな考えやソフトウェアが登場することです。 したがって、会社ではマネージャ職であって直接手を動かして開発していなくても、学ぶことはたくさんありますし、自分が開発業務では経験しなかった概念や手法は書籍を通して学び続けることができます。 私自身は、直接自分で開発を行っている期間、コンサルテーションなど中心として、直接は開発していない期間を繰り返してきています。 1984年8月～1996年8月　開発していた期間 1996年9月～2003年1月　マネージャ、コンサルテーション等 2003年2月～2009年8月　開発していた期間、技術教育、マネージャ 2009年9月

知識の伝達の場コードレビューは品質を向上させるだけでなく、様々な効果があります。その1つが、知識の伝達の場だということです。特に、レビューアーとしてレベルの高い人、つまり、様々なソフトウェア開発経験を経た人がいる場合、コード上の問題点を指摘する際に、なぜ、それが問題になるのか、修正しないとどのようなことが起きたり、将来起きるのかを説明できたりします。もちろん、それだけでなく、プログラミング言語に関しても初心者が知らない落とし穴や書き方を指摘することもできます。 初心者が何もかもすべて教えてもらえると期待してもらっても困りますが、ソフトウェア開発組織としては、きちんとしたレビューが行われることは、知識を伝達するという行為でもあるということを認識する必要があります。

「プロセス中心ではなく、スキル中心」というテーマで、過去に記事を書いています。 プロセス中心ではなく、スキル中心 プロセス中心ではなく、スキル中心（2） ソフトウェア開発組織が持つべきカルチャー 005 ソフトウェア開発組織が持つべきカルチャー 006 個々のソフトウェアエンジニアのスキルを向上させるには、そのエンジニアのレベルを最初に知る必要があります。そのエンジニアのレベルを知るには、直接会話するだけでなく、普段の開発成果物をレビューしてどのような考えに基づいて作成しているかも把握していく必要があります。そして、開発に必要な知識が不足している場合には、教育を行うとか勉強会を開催したりすることも必要だったりします。 私自身、ソフトウェア開発に加えて、30代の終わりから技術書の社内勉強会、技術教育、設計やコードレビューと様々な活動を行ってきました。ソフトウェア開発は、人が行う非常に複雑な活

CIツールであるJenkinsの解説書です。目的に応じて、様々な設定について説明されています。継続的インテグレーションやJenkinsに興味がある人にとっては、導入する際に手元に置いておいて参考にすることができます。すでに、Jenkinsを使用している人であれば、自分が知らない新たな発見があると思います。 継続的インテグレーションは、どのような開発プロセスを使用していても必須だと言っても過言ではありません。ウォータフォール開発しているとかアジャイル開発ではないから関係ないというものではありません。 この本のカバーには次のように書かれています。 「手作業でミスが多発」 「別の環境だとビルドできない」 「結合テストで修正地獄に] 「リリース直前なのに動作しない」 ↓ 自動化でストレスはゼロに 品質は最高に どのようなソフトウェア開発でも起きる問題なのです。 私自身が初めてビルド作業を完全自動化

「教育、場、権限」では、私自身のソフトウェア開発の経験をもとに会社の中で若手のエンジニアの成長を後押しするには、次の3つの条件が揃っている必要があると述べました。 教育 － 基本的に知っておいてもらいたい事柄を技術教育や勉強会という形式を通して教えてく。 場 － 教育で教えたことを、設計レビューやコードレビューなどの日々のソフトウェア開発活動全般を通して指導していく。それにより、教育では伝えきれない部分を伝えていく。 権限 － 日々のソフトウェア開発での指導ができる組織上の権限。 そして、最後の「権限」に関しては、次のように述べています。 日々指導するには、ソフトウェアの開発組織ライン上の権限が必要となってきます。たとえば、チームを構成するメンバーでもなくそのチームリーダでもなければ、チームリーダが指導しないことをそのチームのメンバーに指導することは簡単なことではありません。最近分かってき

今日、多くの製品でハードウェア開発だけでなく、ソフトウェア開発が製品開発に占める比重が高くなっています。ソフトウェア開発もマイコンを使用し始めて、最初はアセンブリ言語から始まり、C言語やC++言語へ移ってきた歴史を持つメーカーも多いかと思います。つまり、日本ではアナログなハードウェアからデジタルなハードウェアへ発展する過程でソフトウェア開発の比重が高まっている企業も珍しくはありません。 ソフトウェア業界をリーディングしている米国のソフトウェア企業（マイクロソフト、Google、Oracle、Facebook等々）は、そのほとんどがベンチャー企業としての歴史を持ち、そこではソフトウェア開発が重要であり、そのためソフトウェアエンジニアは企業の中でも重要な役割を持ちます。当然のことながら、優秀なエンジニアを採用する必要があるため、採用面接にしても、日本とは全く異なる面接方式が取られている訳です。

私自身は、転職を4回行い様々なソフトウェア開発の職場を経験し、自分でもソフトウェア開発の組織を持ったりしてきました。その経験に基づいて、ソフトウェアエンジニアの心得としての『プログラマー”まだまだ”現役続行』や、私自身の経験を織り交ぜて書籍を紹介している『ソフトウェア開発の名著を読む』を執筆してきました。 ソフトウェアエンジニア個人に焦点を当てるのではなく、「ソフトウェア開発組織が持つべきカルチャー」と題して、これからしばらくは、組織としてどのような文化を持つべきかを中心に書いていきたいと思います。あくまでも、私自身の経験ベースなので、かなり偏っているかもしれませんし、過去のブログの記事や拙著の内容とダブっている部分も多いかと思います。 良いカルチャーを持つ組織というのは、これからソフトウェア業界で働き始める若い世代には非常に重要です。ブログ記事「人生は自分が触れたものになる」では、次の文

この書籍では、サービスとして優れている色々な会社が紹介されているのですが、その中で「ホンダカーズ中央神奈川」に関して、詳しく説明がされています。ホンダカーズ中央神奈川は様々な活動を行っているのですが、その活動の1つとして次のことが紹介されています。 ⑥月に1回、読書感想文を提出する 同社では、一ヶ月に一度の割合で、従業員が読書感想文を書き提出するという試みを20年も継続して行っています。会社のお金で内容の良いビジネス書などを購入し、営業マンはもちろんのこと、サービススタッフや事務職員など、すべての従業員が同じ本を読み感想文を提出しています。それを会長が添削し、全員が提出した読書感想文をファイルに綴じて、いつでも誰でも読めるように保管します。本代だけで年間1000万円はかかるそうです。 社員は、最低でも年間12冊の良い本を読むことになりますから、10年続ければ120冊になります。良書を読むこ

ソフトウェア開発に従事して、開発チームや組織内でコードをレビューすることを私自身が実践したのは、ソフトウェア開発の経験の中でかなり後になってからです。実際には、1999年後半か2000年前半ぐらいだと思います。それまでは、チームとしてコードをレビューすることはありませんでした。 記憶が定かではありませんが、まず、着手したのは「Code Review Guide」を書くことでした。それと同時に、プロジェクト用に「C++ Coding Standard」を書いて、コードレビューの重要性を教育で教えて、さらに、現場でコードレビューを実践するということを日々行っていました。 コードレビューは、コーディングという行程において、できる限り品質を作り込むために行うものであり、一行一行処理内容を確認しながらレビューしていました。それにより、後工程であるテストの工数を減らすためです。当時は、テスト駆動開発で

開発組織としてメンバーのスキル向上を行うためには、経験豊富なエンジニアの知識をレビューという形式で伝えていくことが重要です。そして、たとえ初心者であっても、繰り返しきちんとしたレビューを受け続けることにより、成長させていく必要があります。コードレビューは、ソフトウェアの品質を作り込む場でもあるのですが、同時にエンジニアを教育する場でもあったりします。 しかし、開発組織がコードレビューに関して否定的だと、開発プロセスでレビューすることが規定されているというだけの理由で、初心者レベルのエンジニアだけでレビューを行わせたりします。ここで「初心者レベル」というのは、ソフトウェア開発経験年数が少ないという意味ではなく、きちんとしたコードを書くということに関して初心者レベルという意味です。 コードの品質に興味がない人がリーダとして開発チームをリーディングしている場合には、開発が遅れてくると大量に初心者

拙著『プログラマ”まだまだ”現役続行』では、コードレビューに関して以下のことを述べています。 コードを複数の開発メンバーでレビューした結果のコードの質は、レビューに参加したレビューア以上のものにはなりません。つまり、いくらコードレビューが効果的だとはいっても、プログラミングの初心者どうしが集まってお互いのコードをレビューしたところで、その質には限界があります。 ペアプログラミングによって、コーディングを行いながらレビューした場合も、まったく状況は同じです。つまり、ペアプログラミングによってコードの品質が向上するかどうかは、誰とペアプログラミングしたかに依存します。 時間をかけてコードをレビューするのですから、レビュー結果として高い質を求めるためには、対象とする領域に関する技術知識を持ち、読みやすいコードを書くことに関しても知識とセンスを持つソフトウェアエンジニアがレビューアとして参加する必

ソフトウェア開発には多くの暗黙知があり、それらをすべて、OJTや教育を通して教えることは無理です。では、何を教えるべきかというと、「学び続ける」ことを教えなければなりません。 私が1978年に大学に入学してコンピュータに初めて触れて以来、この32年間で、学んだり、経験してきたことすべてを教えることは無理です。日々の開発を通しての指導や、教育コースを作って教えたとしても、ごく一握りのことしか伝えられません。 若い世代へ伝えるということは、次の事柄が重要だと思います。 実際の開発業務だけでなく、学習の継続と、学んだことを実践してみることを習慣付けさせる。 そのためには、自分自身もその習慣を持ち続ける。 そして、日々の活動を通して、指導を続ける。 これが上手く行ったとしても、すべてを伝えきれる保証はありません（『アプレンティスシップ・パターン』の第7章「結論」で述べられているアントニオ・ストラデ