一人前になるには10年: 柴田 芳樹 (Yoshiki Shibata)
「ソフトウェアエンジニアの心得」と題した話は、講演として行ったり、技術教育として企業向けに行ってきています。基本的には、拙著『プログラマー”まだまだ”現役続行』に沿っていますが、その中で「一人前になるには10年」ということで話をしています。該当部分を拙著から抜粋したのが次の部分です。 一人前になるには10年 ソフトウェア開発は創造活動であり、創造能力を高めるには、「より良くできないか」という問題意識を常に持ちながら、多くの経験を積んでいくことです。 リチャード・ガブリエルは、「ソフトウェアを書くことは芸術であり、本当にうまくなるには10年を要する」とも述べています。 これは、「10年間ソフトウェア開発を経験した人が一人前である」という意味ではありません。実際の開発現場では、単に10年間を過ごしただけであり、一人前といえる経験・知識にはほど遠い人も多いのです。 デービッド・フーバーとアデワレ
悪いAPIは伝染していく: 柴田 芳樹 (Yoshiki Shibata)
企業内のソフトウェア開発では、常に新規の開発とは限りません。既存のソフトウェアに新たな機能を追加したり、既存の機能を修正したりすることの方が多かったりします。 既存のソフトウェアに対して新規の公開APIを追加する場合に、既存の公開APIを参考に作ることがあります。その際、既存の公開APIの出来の悪さを、そのまま引きずった新規の公開APIを作成するエンジニアが多くいます。 特に、経験の浅いエンジニアに担当させた場合には、何が良くて何が悪いかも判断できず、「どうして、このようなAPI設計になっているのか？」とか「どうして、このようなJavadocの文章になっているのか？」と聞くと「参考にしたコードがそうなっていました」という返事がほとんどです。つまり、放置しておくと、悪いAPIは駆逐されるどころか、伝染していくことになってしまいます。 上級職人※以上のエンジニアがいない組織では、誰も良いAPI
悪いAPIは伝染していく（2）: 柴田 芳樹 (Yoshiki Shibata)
以前、「悪いAPIは伝染していく」という短い記事を書きました。 APIが悪いライブラリを使用する別のライブラリを設計する場合には、元のライブラリのAPIの悪さを、新たなライブラリでは修正することが可能です。しかし、よく見かけるのは、使用する元のライブラリのAPIの悪さをそのまま引きずったライブラリが設計されることです。その意味で、低レベルのライブラリのAPIの悪さは、上位レベルへと伝染していきます。悪さが伝染しないように新たにAPIを設計できるエンジニアは少ないようです。 きちんとしたAPIを持つライブラリを使用しているのにもかかわらず、出来の悪いAPIを持つ上位のライブラリが作成されることがあります。私自身がかなりレビューしてAPIを整備させたライブラリを使用して、その上に出来の悪いAPIを持つライブラリが設計されているのを見ると、がっかりしてしまいます。 どんなAPIでも、最初のバージ
技術的負債（5）: 柴田 芳樹 (Yoshiki Shibata)
『リーンソフトウェア開発と組織改革』の一部を紹介した「技術的負債」でも引用したように、負債が破綻にいたらないように努めながらソフトウェア開発/製品開発を行っていくことが必要です。 技術的負債 成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・ （途中省略） 技術的負債の本当の姿を知らなければならない。負債が破綻に至らないよう、コスト上の重荷をふだんから取り除いておくべきだ。 技術的負債を軽減しながら、同時にソフトウェア開発/商品開発を進めていくことが重要です。技術的負債を積み上げないように努力をしながらソフトウェア開発を行っている開発
ビルドやテストも考慮したアーキテクチャ設計: 柴田 芳樹 (Yoshiki Shibata)
大規模なソフトウェア開発では、ビルドやテストも考慮したアーキテクチャ設計（あるいはシステム設計）が必要です。どのモジュールから順番にビルドして、テストできるかは、プロジェクト全体の開発効率に非常に大きな影響を与えます。 レイヤ構成のアーキテクチャであれば、当然、下位レイヤからビルド/テストを行い、それが上手く行けばその上のレイヤをビルド/テストするという順番で行うことが可能となります。 一方で、上手く出来上がった時には、確かに全体として機能するはずであるけれど、ビルドやテストが非常に面倒なシステム設計も可能です。このような設計では、ビッグバンインテグレーションが行われることがあったりします。そして、ちょっとした仕様変更でも多くの工数を必要としたりします。 アーキテクチャの検討において、ビルドやテストも考慮した議論が行われずに、単純に「機能が実現できるかできないか」という視点に陥る場合があり
書籍『APIs: A Strategy Guide』: 柴田 芳樹 (Yoshiki Shibata)
一昨年出版されている本ですが、Kindle版で通勤電車の中で読みました。下記の目次から分かるように、Web APIを提供する上で検討すべき項目がガイドとして上手くまとめてあります。 Chapter 1. The API Opportunity Chapter 2. APIs as a Buisness Strategy Chapter 3. Understanding the API Value Chain Chpater 4. Crafting Your API Product Strategy Chapter 5. Key Design Principles for APIs Chapter 6. API Security and User Management Chapter 7. Legal Considerations for Your API Strategy Chapter
Kindle版の電子書籍: 柴田 芳樹 (Yoshiki Shibata)
英語の技術書を購入する場合、従来だと、急いで取り寄せて読みたいのであれば、Amazon.co.jpとAmazon.comの両方をチェックして、どちらが安いかとか日本に在庫がありそうかで、注文先を決めていました。 2年前にKindleを購入（ 「Kindleがやってきた」）してからは、Amazon.comで電子版を注文することが最近では圧倒的に多くなりました。それでも、以前なら、会社ではPC版のKindleソフトウェアがプロキシ設定ができずに、会社にもKindleを持って行っていました。 しかし、最近では、Kindle用のCloud Readerを利用することで、通常のウェブブラウザーを使用して購入した本を読むことができます。 https://read.amazon.com/ その結果、Kindleを持ち歩く機会はかなり減りました。 Kindle版を読む利点は、リーダーをどれか1つに絞る必要
カンファレンスは、若い人ばかり？（2）: 柴田 芳樹 (Yoshiki Shibata)
2つのカンファレンスに参加しました。1つは、情報サービス産業協会（JISA）主催の 「SPES 2012 －サービス化により変わるシステム開発－」。もう1つは、日本Jenkinsユーザ会主催の「Jenkins ユーザ・カンファレンス 2012 東京」です。 SPES2012は、ソフトウェア開発がクラウドベースのサービス化によりシステム開発がどのように変わっていくかというテーマでのカンファレンスです。Jenkinsユーザ・カンファレンスは、その名の通りJenkinsに関するカンファレンスです。 カンファレンスの内容は、全く性質が異なります。そのためでしょうか、参加者の年齢層が明らかに異なっていました。SPES2012では、暑い日にもかかわらず、背広の上着を着用しているような人が意外と多く、40代、50代の人が多いカンファレンスでした。 一方、Jenkinsユーザ・カンファレンスは、20代、3
コードレビューの視点 011: 柴田 芳樹 (Yoshiki Shibata)
英語の綴りには注意する普段、英語を読むことがほとんどない人が書くプログラムでは、やたらと英単語の綴りの間違いが多いことがあります。 分かりやすい例で言えば、Java研修でGUI課題として「デジタル時計」を作成してもらうのですが、「DegitalClock」というクラス名で作成する人が必ず2、3割はいます。業務で開発してもらっているソースコードのレビューでも英単語の綴り間違いを指摘することが多いです。まだ、それでも綴りが間違っているだけなら良いのですが、それ以前に、意図を表す適切な名前になっていないこともあります。 コメントを除いて、日本語やローマ字でプログラミングすることはまれだと思います。英単語の綴りに自信がない時は、辞書で確認するように心がけてください。
マルチスレッドプログラムのデバッグ: 柴田 芳樹 (Yoshiki Shibata)
「コードレビューの視点 003」では、「マルチスレッドプログラミングに注意する」と題して、次のことが必要だと述べました。 マルチスレッドプログラミングに関する基礎知識をすべてのソフトウェアエンジニアがきちんと習得していること 書かれたコードは、マルチスレッドプログラミングに関する豊富な知識と経験を持つ人がきちんとレビューをする 書かれたコードは、自動テストが実行できるようになっていて、様々なプラットフォーム（単一コアから複数コア、あるいは、マルチプロセッサー）で長時間ランニングテストを行う。さらに、同時にシステムに別の負荷（CPU、HDなどへの負荷）をかけたランニングテストも行う そして、テストが止まっている場合には最優先デバッグすることも重要だと述べました。しかし、重要ことを書き忘れていました。デバッグは、テストが止まったままの状態でデバッガーをプロセスにアッタッチして行うということです
ハッシュテーブルの季節: 柴田 芳樹 (Yoshiki Shibata)
一年間のプログラミング言語Java教育を行っていると、「ハッシュテーブルの季節」と私が呼んでいる時期が到来します。どういうことかと言うと、テキストである『プログラミング言語Java第4版』の第3.8節「Objectクラス」（86頁）にhashCodeメソッドの説明があるのですが、その内容に関する質問を解説するために「ハッシュテーブルとは何か」ということから説明しないといけません。特にその節の最後の段落でIdentityHashMapの解説があり、その節になると誰も理解できていないのが毎年の恒例となっています。 そもそも、ハッシュテーブルとハッシュコードを、大学時代あるいは会社に入ってから研修で習っていないのか、習ったけど内容が浅かったのか、習ったけど覚えていないのか、どちらにせよきちんと理解している人は毎年皆無に近いです。 拙著『プログラマ”まだまだ”現役続行』の第6章「コンピュータサイエ
ソフトウェア開発組織が持つべきカルチャー 014: 柴田 芳樹 (Yoshiki Shibata)
知識教育だけではなく、良い行動パターンを促進する「技術の伝承と良い習慣の伝承」とも関連しますが、日本の企業でソフトウェア技術教育（特に新卒新人の技術教育）を担当している部門やグループは、何を教えたかということで教育体系をまとめようとする傾向があると思います。しかし、個々の教育コースの内容を見ると浅かったりします。 ソフトウェア技術というのは、毎年新しいものが登場し続けますので、すべてを教育コースで教えることはできません。そのため、ソフトウェアエンジニアに身に付けてもらうことは、知識だけではなく、継続して自発的に学び続けるということです。 たとえば、2000年から行っている「プログラミング言語Java教育」は、単にJava言語の知識を学ぶというだけではなく、膨大な自分の時間を使って専門書をきちんと学習する習慣を身に付けてもらうことも目的としてあります。実際、一年間の最後の成果発表会では、「学
コードレビューの視点 003: 柴田 芳樹 (Yoshiki Shibata)
マルチスレッドプログラミングに注意するJavaが登場する前は、C/C++でマルチスレッドプログラミングをしようとすると、別途POSIX Threadなどのライブラリを使用しなければなりませんでした。Javaは言語仕様そのものにマルチスレッドプログラミングの機構を持っています。しかし、マルチスレッドプログラミングというのは、同期も含めて正しく設計・実装するのは難易度が高い領域です。 そのため、同期処理も含めてかなり真剣にレビューしないといけません。さらに残念ながらレビューだけでは不十分であり、ストレステストも必要になってきます。そのため、マルチスレッドプログラミングを行うソフトウェア開発では、次のことが必須となります。 マルチスレッドプログラミングに関する基礎知識をすべてのソフトウェアエンジニアがきちんと習得していること 書かれたコードは、マルチスレッドプログラミングに関する豊富な知識と経験
組織の生産性: 柴田 芳樹 (Yoshiki Shibata)
拙著の「第12章 30代、40代の人たちへ」からの引用です。 組織の生産性 自分自身が継続して学習を続けるというのは、自分自身の成長だけでなく、若手エンジニアや自分が属する開発組織のメンバーにも大きな影響を与えます。ソフトウェア開発では個人差は確かに大きいです。作り出すコードの可読性も含めた総合的な生産性の差には、個人差があります。したがって、長い時間をかけて個々のエンジニアのスキルを向上させていく必要があるのです。そのためには、開発組織の中に見習うべき習慣を持っている先輩や上司がいなければ、その組織の中で若手が勝手に成長するのを期待するのは無理です。 開発組織の生産性の差は、個人差以上に大きいです。私自身は、様々な開発組織で働いてきましたし、自分自身の開発組織で若手を育成したこともあります。どんなに優秀な新卒新人であっても、間違った開発組織に属してしまうと、数年で変な癖がついてしまい、学
コードレビューの視点 001: 柴田 芳樹 (Yoshiki Shibata)
Copyrightを書く1984年に社会人となって開発に従事したFuji Xerox 6060 Workstationでは、ソースコードにきちんとCopyrightを書いていたかどうかは覚えていない※のですが、それ以降のプロジェクトでは、ソースコードにはCopyrightを表記するのが当たり前の文化の中で過ごしてきました。 ※ たぶん書いていたと思うのですが・・・ Copyright表記そのものは、XDE（Xerox Development Environment）のエディタでは自動的に挿入・更新を行ってくれたりもしましたが、そうでない環境でも手作業でも必ず記述する習慣となっていました。そのため、私自身が書いたC++言語用コーディング規約にもCopyrightを記述することを規定していました。 企業でソフトウェアを開発する上でCopyrightを記述することは、私にとっては当たり前だとずっ
新聞の用語辞典: 柴田 芳樹 (Yoshiki Shibata)
翻訳を行っている際に、「漢字」にするか「ひらがな」にするか迷った時に参考にしているのは新聞の用語辞典です。今まで使っていた用語辞典の改訂版が出ていないか調べてみたら、出ていました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
英語学習: 柴田 芳樹 (Yoshiki Shibata)
REST API関連の本: 柴田 芳樹 (Yoshiki Shibata)
Java研修 (6): 柴田 芳樹 (Yoshiki Shibata)
書籍『継続的デリバリー』: 柴田 芳樹 (Yoshiki Shibata)