SSブログ

社会人30年(3) [キャリア]

ソフトウェアエンジニアとして、業務時間にかなりの時間を費やして、自分自身で開発を行ってきたのは、2008年末までです。したがって、自分自身でプログラミングをしなくなってから5年も経過していることになります。自分自身でプログラミングしなくても、様々な設計レビューやコードレビューを続けてはいます。現在は、小さい開発グループをリーディングしていますが、自分自身で設計・実装・デバッグまでとできない状況となっています。

社会人31年目に入りますが、50代のこれらかの残りの年月をソフトウェアエンジニアとしての経験を積んでさらにスキルを向上させる活動に費やせればと思っています。
コメント(0) 

社会人30年(2) [キャリア]

1984年4月に就職し、それから7月中旬ぐらいまでは、塚原研修所で泊まり込みで研修でした。当時の研修は、ソフトウェア開発というよりは、ほとんどが複写機関連の研修でした。SEコースだった人達は、遅くまでソフトウェア関連の研修を受けていたと記憶しています。

研修を終えて配属した部署は、ワークステーションを開発している部署でした。その中でも、一からワークステーションの開発を始めたばかりのグループのソフトウェアチームへ配属されました。私の担当は、通信系のソフトウェアの開発でした。でも開発が始まったばかりだったので、最初は、Ethernetコントローラチップ用のドライバーの設計を行いました。その後、その上のプロトコルスタックの設計・実装などを行っていきました。

当時は、初めてUnixに触れて、C言語の学習をしながらの開発でした。今のようにインターネットが普及していた時代ではなかったので、少ない書籍で学習したり、英語のmanページでシステムコールを学ぶというのが普通でした。

インターネットが普及していないだけでなく、当時と今日で大きく異なるのは、プログラミングは会社に行かないとできなかったことです。家には、PC88はありましたが、C言語でプログラミングするにしても、有料のコンパイラを買わないといけない状況でした。ましてや、会社ではUnixを使用していましたので、PC88はもっぱらゲーム機でした。

今日では、言語処理系を購入しなくても、プログラミングを行うことができます。その結果、昔よりも今日の方が、社会人となる前から(たとえば、高校生の頃から)プログラミングを行っていると人と社会人となってからプログラミングを学ぶ人では大きな差がついてしまっているのが現状だと思います。そうでなくても、大学で情報工学を専攻した人とそうでない人では差がついています。しかし、残念ながら、全く専攻していない人達を大量に採用して、ソフトウェアを開発させようとしているのが、今日の日本の現状ではないでしょうか。

ちなみに、私が最初に配属された部署には、新卒新人が20名配属されましたが、そのほとんどが情報工学を専攻していました。1984年頃は情報工学科を持つ大学は増えてはきていましたがまだ少なかったので、会社はかなり意図的に採用活動を行ったのではないかと思います。
コメント(0) 

社会人30年 [キャリア]

1984年4月1日に社会人となってから、30年が過ぎようとしています。30年間ずっと製品開発に従事していたのではありませんが、従事した製品開発の多くが、プロジェクトの初期から参加しているというものでした。それは、既存のソフトウェアを保守するというのではなく、開発組織として、すべての一から構築するプロジェクトが多かったということです。そして、どのプロジェクトでも、新たなことを多く学びながら成長できたと思います。

プロジェクトの初期から従事するということは、様々な事柄を自分達で判断しながら進めなければなりません。誰かが、細かな要求仕様を提示してくれるわけではありません。

しかし、社会人となって従事するソフトウェア開発は、既存のコードを修正して新たな要求に対応させるという開発業務が多かったりしますし、新卒となってから、そのような開発しか従事したことがない人も多いと思います。

その結果、社会人となって、5年以上ソフトウェア開発に従事していても、既存のコードの修正ではなく、すべてを決めながら一からソフトウェアを開発する従事したことがない場合には、自分から主体的に仕様を決めたりするのではなく、仕様が決まっていないことに不平を言うだけのエンジニアになってしまっている場合があります。

幸い、私自身は、従事したソフトウェア開発の多くが、一からすべてを開発するプロジェクトであり、結果として、そのことが、今の私自身を形成しているのかもしれません。
コメント(0) 

初心者レベルの言い訳をしない(2) [プログラマー現役続行]

初心者レベルの言い訳をしない」では、冒頭に次のように述べています。
出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだから言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。

似たような話で、最近聞いたのは、「要求品質が明示されていないのでどれだけ時間をかければ分からない」というものです。作り込む機能の数で言えば、確かに、どれだけ時間をかけるかによって、その数は変わってきます。しかし、「品質」、特にソフトウェアの構造を含む設計の品質やソースコードの可読性を含めた品質というのは、担当者が時間を費やせば費やすほど高くなるのでしょうか?

時間をかけたからと言って高い品質にならないことは明らかです。仮に、高い品質になったら、すべてのデスマーチプロジェクトでは、超高品質のソフトウェアが開発されることになります。

一人一人のソフトウェアエンジニアが作り出すソフトウェアの品質は、その人が費やした時間で決まるのではなく、その人のスキルレベルで決まるのです。たとえば、私が、社会人になった頃に開発したソフトウェアを今見ることができたとしたら、きっとかなり品質の悪い可読性の低いソースコードを大量に書いていたことに気付くでしょう。

「要求品質が明示されていないのでどれだけ時間をかければ分からない」というのは、「品質が悪いのは、費やす時間を具体的に指示されなかったからです」とか「自分のスキルは今後も向上しないと思います。スキル向上の努力をしながら、同じ時間でより高い品質のものを生み出せるように努力をする気はありません」と言い訳しているように私には聞こえてしまいます。
コメント(0) 

悪いAPIは伝染していく(3) [プログラマー現役続行]

以前、「悪いAPIは伝染していく」「悪いAPIは伝染していく(2)」という記事を書いています。
最初からきちんとしたAPIを作成できるようにはなりませんが、優れたAPIを作成するために、様々な学習を続けて実践していくことがソフトウェアエンジニアには求められると思います。「サラリーマンエンジニア」であれば、API設計に必要な書籍を読むことなく、悪いAPIを伝染させたり、APIを改悪していくことになります。

ほぼすべてを新規に開発するプロジェクトでは、「悪いAPIが浸食していく」ということが起きたりします。

きちんとしたAPIを持つライブラリが最初に作成されたとして、そのライブラリを拡張する際に、元々の作成者とは別のエンジニアが悪いAPIへと改悪していくことがります。追加されたAPIのドキュメントを書かない、さらに、追加されたAPIのための実装の詳細を公開してしまっているとか。

実装の詳細を公開している理由が非常に単純で、本来のAPIのテストコードをきちんと作成するのが面倒なので、実装の詳細である情報を取り出して確認しているということだったりします。

開発言語に関係なく、APIをきちんと設計できて、テストコードもきちんと書けることは、ソフトウェアエンジニアに求められるスキルだと思います。

【参考図書】

Practical API Design: Confessions of a Java Framework Architect

Practical API Design: Confessions of a Java Framework Architect

  • 作者: Jaroslav Tulach
  • 出版社/メーカー: Apress
  • 発売日: 2012/06/06
  • メディア: ペーパーバック

翻訳本は、こちら
APIデザインの極意 Java/NetBeansアーキテクト探究ノート

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

  • 出版社/メーカー: インプレス
  • 発売日: 2014/05/23
  • メディア: Kindle版

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/03/11
  • メディア: 単行本(ソフトカバー)

コメント(0) 

読みやすいコードに対するエンジニアのレベル [「ソフトウェアエンジニアの心得」講演]

「ソフトウェアエンジニアの心得」で説明している資料からの引用です。


  1. 読みやすさどころではない
    • 初心者の場合には、読みやすさまでは注意がいかないし、コーディングが終わった後でも、読みにくいかどうかが判断つかないレベル。
    • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
  2. コーディング中に気づかない
    • コーディング中はコードを書くことにのみ意識がいき、読みにくいコードや重複したコードを書いているかどうかまで注意が回らない。しかし、コーディングが終わった後で、見直してみたらそれに気づき、修正するレベル。
    • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
  3. コーディング中に書き直す
    • コーディング中でも、常に読みやすさや改善すべき点に気づき、コーディング中にどんどん修正するレベル。
  4. デバッグ後も重要だと認識している
    • 単体テストでデバッグが終わっても、コーディングが終了したとは考えない。さらにコードを書き直して出来る限り綺麗に読み易くして、コーディングが終了したと考える。
    • 常にコードをクリーンにすることを心がけている(ボーイスカウト・ルール)。
このおおざっぱなレベル1からレベル4ですが、社会人となってどのような開発組織でソフトウェア開発を行ってきたかによって、4、5年以上のソフトウェア開発経験があっても、レベル1かレベル2程度であったりします。

さらに、テスト駆動開発によるリファクタリングを経験したことがない人は、テスト駆動開発でリファクタリングが安心してできる開発に移ってきても、「Red-Green」で終わってしまい、「Red-Green-Refactor」ができなかったりします。
コメント(1) 

読めないコードは書き直せ [プログラマー現役続行]

プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマー”まだまだ”現役続行 (技評SE選書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2010/09/04
  • メディア: 単行本(ソフトカバー)

第4章「読みやすいコードを書く力」からの引用です(p.79)。

読めないコードは書き直せ

 もちろん、コメントやドキュメントを書くこと自体を否定するつもりはありません。
 ただ、本来コメントやドキュメントというものは、プログラムが十分読みやすく書かれていることを前提に、プログラムを読んだだけではわからない事柄を補足するために書くものであって、読みやすさを考慮していない複雑なプログラムを読むための手がかりとして書くものではありません。
 つまり、読めないプログラムにコメントやドキュメントを書くぐらいなら、プログラムそのものを読めるように書き直すべきです。そして、可能なら、最初から読みやすいプログラムを書くべきなのです。
 しかし、ほとんどの人は、最初から読みやすいプログラムを書くことはできません。
 なぜなら、「どのようなプログラムが読みやすく、どのようなプログラムが読みにくいか」を認識していないと、自分が書いているプログラムが他人にとって読みやすいかそうでないかを、自分で判断することはできないからです。
 そのため、自分では読みやすいプログラムを書いているつもりでも、実は他のエンジニアにとっては読みにくいプログラムを書いてしまうのです。
 この判断能力を身につけるには、自分が書いたコードを他のエンジニアにレビューしてもらうのが最適ですが、どうすれば自分のプログラムを改善できるかを、書籍を通して学ぶことも有効です。お勧めの書籍としては、『プログラミング作法』『コードコンプリート第2版』『リファクタリング』『クリーンコード』『実装パターン』などがあります。
 レビューしてもらったり、本を読んだりして、常に読みやすいコードを書くことを意識して行う必要があります。そして、意識して行うことを継続することで、無意識に読みやすさに注意を払うようになるまで習慣化することが必要です。

プログラムは「臭う」

 初心者にはわからないかもしれませんが、ソースコードを見たり、UMLで描かれたクラス図を見たりしていると、「何か臭う」ことがあります。ある程度きちんとしたソフトウェア開発経験を積んでいる人の成果物であっても、「少し臭う」ことがあるかもしれません。
 その場合、「何か臭うな」と感じて、プログラムの動作や、さまざまな境界条件を考慮しながら、頭の中でそのプログラムを実行すると、間違いや抜け漏れに気づく場合も少なくありません。
 あるいは、間違っていなかったとわかる場合もあり、その場合には、なぜ臭いを感じたのかを検討し、臭わないようにプログラムの改善方法を考えたりします。
 一方で、プログラミング経験が浅い人や、プログラムの読みやすさに注意を払わないで長年ソフトウェア開発を行ってきている人のプログラムなどは、「悪臭」を放っている場合があります。
 ソフトウェアの設計やプログラムの臭いに対する最低限の嗅覚を身につけるには、個人差はありますが、数年は要します。
 これは新卒などに限った話ではなく、変な癖がついてしまった中堅の人たちにも当てはまります。むしろ、変な癖を身につけてしまっている分だけ厄介かもしれません。 幸運にも職場の先輩で優れた人がいる場合には、悪臭を放たないソフトウェアを開発するために、いろいろとレビューしてもらったり指導してもらったりすることができるかと思います。
  そうでない場合には、書籍等で学習し、それを日々のソフトウェア開発に自分で意識しながら応用することで、地道に身につけていくしかないかもしれません。
書籍としては、最低限以下の書籍を読んで、自分自身でソフトウェア開発に応用する努力を行ってもらう必要があります。
  • プログラミング作法
  • 達人プログラマー
  • リファクタリング
  • アジャイルソフトウェア開発の奥義
  • コードコンプリート第2版
  • パターン指向リファクタリング入門
  • クリーンコード
  • 実装パターン
 『プログラミング作法』は、ソフトウェア開発に関係するさまざまな観点からまとめられています。
 『達人プログラマー』には、実践的なプログラマーが心がけて、日々のソフトウェア開発に応用すべきことが書かれています。
 『リファクタリング』には、ソフトウェアの機能を変更することなく、プログラムの構造をどのように改良するかについて書かれています。そして、書かれているリファクタリングの手法の多くが、EclipseなどのIDEによってサポートされています。
 『アジャイルソフトウェア開発の奥義』には、オブジェクト指向開発において習得しておくべきさまざまな設計に関する事柄がまとめられています。
 『コードコンプリート第2版』では、プログラムの読みやすさについて、プログラミングのさまざまな観点からまとめられています。
 『パターン指向リファクタリング入門』では、プログラムをリファクタリングすることでデザインパターンを適用するという観点から、多くのリファクタリング手法が紹介されています。
 『クリーンコード』では、読みやすくクリーンなコードとはどのようなコードであるかを、豊富な例を用いて説明しています。
 『実装パターン』は、著者のケント・ベック氏がコードを書くときに、なぜそのような書き方をするのかをまとめたものです。サンプルコードが少ないので、初心者向けではありませんが、多くの観点が紹介されています。
 職業としてソフトウェア開発に従事する以上は、このように多くの良書から、自分自身で技術を習得していく必要があります。ここで紹介した書籍は、いずれも1998年以降に原著や翻訳本が出版されたものです。
 しかし、実際のソフトウェア開発の現場では、継続して自己学習する習慣が身についていない人の場合、せいぜい書名を聞いたことがある程度でまったく読んだことがないという人も、残念ながらかなり多いのではないかと思います。


コメント(0) 

ボーイスカウトルール [プログラマー現役続行]

5年前に「The Boy Scout Rule」として書いている内容の英語部分を日本語にしたものです。


Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

  • 作者: Robert C. Martin
  • 出版社/メーカー: アスキー・メディアワークス
  • 発売日: 2009/05/28
  • メディア: 大型本

読みやすいコードを書くことの重要性については、拙著(『プログラマー現役続行』)の中でも述べていますが、書籍『Clean Code』には、次の記述があります。
コードを上手く書くだけでは十分ではありません。コードは時間が経過してもクリーンに保たれなければなりません。時間の経過に伴ってコードが腐り、品質が低下するのを誰しも目にしてきています。したがって、我々はこの品質の低下を防ぐために積極的な役割を演じなければなりません。

アメリカのボーイスカウトには、我々の職業に適用できる単純な規則があります。

キャンプ場を、来た時よりも綺麗にして帰ること

コードをチェックアウトした時よりも少しでも綺麗にしてチェックインすれば、コードが腐ってしまうことはありません。綺麗にするのは大げさでなくても良いのです。より良くするために変数名を変更したり、大きすぎる関数を分割したり、if文の連なりを綺麗にしたりするのです。

時間の経過に伴ってコードが本当に良くなっていくプロジェクトに従事することが想像できますか。これ以外のやり方が、プロフェッショナルだと思いますか。継続した改善こそが、プロとしての本質的な部分ではないでしょうか。
ここで述べられているように、些細な改善であっても、常に改善する心がけにより、コードは腐ることなく、時間の経過に伴って良くなっていくことになります。

今日では、テスト駆動開発により、開発しているソフトウェアの機能を確認するためのテストコードが書かれているプロジェクトも多いと思います。そのような開発では、コードの改善による機能のデグレードがないかをテストコードの実行により容易に確認可能であり、このボーイスカウト・ルールが容易に実践できることになります。

また、テストファーストによる開発では、最初にテストコードを作成して、そのテストに合格するように実装してくわけです。そして、すべてのテストに合格したら、実装が終了と思っているエンジニアは多いのではないでしょうか。しかし、そこで実装が終了と思っているようでは、駄目です。

コードがクリーンに書かれているかを見直し、そうでなければクリーンにするためのリファクタリングを行う必要があります。そして、自分で見てもある程度納得できるクリーンなコードになったら、最初の実装が終了となります。誰でも最初からクリーンなコードを書けたりはしません。したがって、テストコードによる動作確認が済んでも実装は終わりではなく、コードをクリーンにする作業を行って実装が終了と考えることは、ソフトウェアエンジニアにとっては重要なことです
コメント(0) 

丸善出版から再出版されたコンピュータ関連書籍 [本]

ピアソン桐原で扱っていた書籍で、丸善出版から再出版されたコンピュータ関連書籍です。

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/03/11
  • メディア: 単行本(ソフトカバー)

新訂版MORE EFFECTIVE C++ (ADDISONーWESLEY PROFESSIONAL CO)

新訂版MORE EFFECTIVE C++ (ADDISONーWESLEY PROFESSIONAL CO)

  • 作者: スコット メイヤーズ
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/02/28
  • メディア: 単行本(ソフトカバー)

Effective C++ 第3版 (ADDISON-WESLEY PROFESSIONAL COMPUTI)

Effective C++ 第3版 (ADDISON-WESLEY PROFESSIONAL COMPUTI)

  • 作者: スコット メイヤーズ
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/03/18
  • メディア: 単行本(ソフトカバー)

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

  • 作者: Jon Bentley
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/02/28
  • メディア: 単行本(ソフトカバー)

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

  • 作者: アラン・シャロウェイ
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/03/11
  • メディア: 単行本(ソフトカバー)


『人月の神話』がまだ再出版されていないようです。

人月の神話【新装版】

人月の神話【新装版】

  • 作者: Jr Frederick P. Brooks
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/04/25
  • メディア: 単行本(ソフトカバー)

コメント(0) 

募集:第2回Jolt Awards読書会 [Jolt Awards読書会]

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

  • 作者: Brian W. Fitzpatrick
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2013/07/20
  • メディア: 単行本(ソフトカバー)

3月15日(土)に開催した第1回は5名がリコーグループからの参加で、、私を入れて9名の参加者でした。

最初に、参加者に簡単な自己紹介を行ってもらい、基本的に1ページ単位で順番に読んでいって、気になる点があれば都度ディスカッションする形式で進めました。

第2回は、第3章「船にはキャプテンが必要」からです。参加申し込みは、こちらからです。
コメント(0)