株式会社メルペイを退職します: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。 週4日勤務「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました（週4日勤務で働くことに関して、入社前に合意してもらっていました）。10月からの会社では、週4日勤務の雇用契約で働きます。 初めてのウェブサービス開発富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に
知識への投資: 柴田 芳樹 (Yoshiki Shibata)
この書籍の18番目にベンジャミン・フランクリンの次の言葉が挙げられています。 知識への投資は、常に最高の利息がついてくる。 これは、「ソフトウェアエンジニアの心得」の教育や講演で紹介している言葉です。そして、本書では著者の次の言葉掲載されています。 典型的な一日を思い浮かべてみて。 その君の一日の中で、勉強にあてられている時間は、どれくらいある？ たとえば、典型的な一日の中に、英語の勉強が入っていない人は、 一生、英語をモノにできないんだよ。 毎日、少しずつなにかを進めることができるスキルほど、 重要なことはないよ。 英語ができる人が評価されるのは、 それが、コツコツやるっていうスキルの証明だからだよ。
ソースコードに技術者のレベルが現れる：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
新規に書かれたソースコードを見ると、それを書いた技術者のレベルがある程度分かります。特に、レベルが低いエンジニアが書いたコードほど、よく分かります。レベルが低いというのは、全くの初心者という意味ではありません。社会人となってソフトウェア開発に従事して数年を経過して、本人はプログラミングできると思って書いているレベルであっても、書かれたコードを見ると、レベルが低いということです。 レベルが低い大きな理由の1つは、自分が書いたコードをスキルが高い人にレビューしてもらうという習慣を本人が持たないし、組織も持たないからです。もう1つの大きな理由は、使用しているシステムや開発言語に関した、きちんとした学習をしていないということも挙げられます。※ ※ たとえば、Java言語で開発していても『Effective Java』を読んだことさえないとか。 「初心者だからと言って汚いコードを書くことが許される訳
レビューのアウトプットは、レビューアのレベルを超えない（５）: 柴田 芳樹 (Yoshiki Shibata)
「レビューのアウトプットは、レビューアのレベルを超えない（3）」で述べたように、ソフトウェア開発でソースコードをレビューすることを実践し始めたのでは1999年頃からです。 それから、コードレビューの重要性の教育やコードレビューを実際に実践して、一行一行コードをレビューしながら処理漏れはないか、バグはないか、読みやすくて理解しやすいかということをレビューしていきました。それは、きちんとしたレビューをしないとソフトウェアの品質が上がらないのと同時に、きちんとしたレビューを受け続けないと、レビューアが育たないからです。 そして、2000年前後から2008年までの期間で多くのコードレビューを実施し、自分自身でもコードを書き続けて、現場の若手の技術者を育成していました。そこには、レビューすることに対する開発組織全体の理解や中堅クラスのソフトウェア技術者でもレビューを受けるということで、全体で長期的に
どうしてミケランジェロになれないんだ？: 柴田 芳樹 (Yoshiki Shibata)
「たがねは買ってやった。なのに、どうしてミケランジェロになれないんだ？」すぐに生産性を高めようと必死の組織では、そんな問いかけが聞こえてくるが、そうした組織にかぎって、能力よりも給料の安さで人材を雇う。ミケランジェロ組織にはかならずと言っていいほど、買ったきり積まれたままのツールの山がある。 ツールが便利なことは言うまでもない。適切な使い手に渡れば、すばらしく生産性を高め、ツールがなければできなかったことを成し遂げられる。しかし、ツールの作り手も言っているはずだが、使いこなすためのスキルがあることが必須条件である。たがねは、ミケランジェロが手にとらなければ、へりの鋭い金属片にすぎない。 「基礎教育」でも書きましたが、スキルを向上させることを中心としてソフトウェア開発を行ってきた場合には、コードの品質を測定したり、バグを発見するような静的解析ツールの導入は、必ずしも必要ではありませんでした。
技術者のレベルとソフトウェア開発の難易度（8）: 柴田 芳樹 (Yoshiki Shibata)
「技術者のレベルとソフトウェア開発の難易度（6）」で技術者のスキルレベルと開発ソフトウェアの難易度の表を掲載しています。 ソフトウェア開発における外部公開用APIの設計の難易度は、非常に高いです。機能を提供するだけでなく、不正な操作に対しても堅牢であり、使いやすく、誤った利用ができないように設計するのは容易ではありません。一方、機能は提供しているが、不正な操作に対して脆く、使いにくく、誤った利用が簡単にできてしまうようなAPIを初心者は作ってしまいます。 両者の成果には大きな差があり、その意味で外部公開用APIの設計の難易度は高いのです。仮に難易度を5（「技術者のレベルとソフトウェア開発の難易度（6）」を参照）とすると、スキルレベルが5以上の人でないと正しくできないはずです。 ところが現実の開発では、スキルレベルが2の人が担当してしまって、酷いAPIを設計してリリースしてしまうことがありま
技術的負債（３）: 柴田 芳樹 (Yoshiki Shibata)
企業にとって、技術的負債があっても、商品を出し利益を出して、会社を維持する必要があります。しかし、技術的負債が大きい場合には、若手にとっては、良いコードを読んで学習する機会を与えるのではなく、汚いコードと格闘させるだけとになります。さらに、製品となっているコードは、手作業による膨大なテスト工数を考慮して、リファクタリングして良くする活動もできなかったりします。 見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負
技術的負債: 柴田 芳樹 (Yoshiki Shibata)
リーンソフトウェア開発と組織改革 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳出版社/メーカー: アスキー・メディアワークス発売日: 2010/10/09メディア: 単行本（ソフトカバー） 技術的負債 成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・ 誰が引き継いでも意図が明確に伝わるコードを書こうとせずに、不明瞭なコードがあっても受け入れてしまう。開発者は、特に経験の浅い開発者は、「クリーンなコード」の書き方を訓練されるべきだ。クリーンなコードとは、わかりやすいロジックに基づく、
転職（４）: 柴田 芳樹 (Yoshiki Shibata)
今日でちょうど一年となります。期待していた仕事を、過去一年間でできたのかで評価すると、残念ながら評価点はかなり低くなります。 個々のソフトウェアエンジニアが継続的に学習を続けて、組織全体が成長するという観点では、一年前と比べると良くなってきてはいます。しかし、その変化は、非常にゆっくりとしたものです。また、本を読めば書いてあることさえ、教育コースを作って教えなければならないという状況に、あまり変化はみられません。（「教育と場」） 自分自身の成長という観点からは、会社の業務を通しての技術的スキルの向上はほとんどないです。その主たる原因は、「Be the Worst」にはほど遠い環境だからかもしれません。一方で、ソフトウェア開発の最終成果物であるコードを軽視するというソフトウェア開発組織の文化を経験できたことは、「読みやすいコードを書くことの重要性」やそのための「継続した学習」を強調している私
技術者のレベルとソフトウェア開発の難易度（6）: 柴田 芳樹 (Yoshiki Shibata)
水色は最適な仕事の割り当てを示し、ピンクは、本人の成長を期待しての仕事の割り当てを示しています。 この表は、当たり前と言えば当たり前なのです。問題は、技術者のスキルレベルと開発するソフトウェアの難易度を第三者が測る方法がないことです。赤色に相当する部分の仕事をさせるには、少なくともピンク状態の技術レベルになるまで、エンジニアを教育するとか経験を積ませる必要があります。表から分かるように、仕事の難易度が5以上のソフトウェア開発に対して、技術レベルが3以下の開発者を投入すると、プロジェクトは失敗する可能性が高くなります。 問題は、どちらの軸も測る方法がなく、感覚的な言い方しかできないことが多いことです。 （ここまで、再掲載） 技術者のスキルに関しては、自分よりもスキルが高い人を評価する際に、「高い」というのは言えても「どれだけ高い」かは言えません。どれだけ高いかを言えるのようになるのは、その人
リファクタリングと作業: 柴田 芳樹 (Yoshiki Shibata)
テスト駆動開発はテストがパスするように実装して、テストがパスすればリファクタリングを行います。つまり、「Red Green Refactor」がマントラ（mantra）です。 書籍『Refactoring』が出版された当時（1999年）は、まだEclipseはまだ登場していなくて、リファクタリングを行うとうのは、「クリエイティブな活動」と「作業」の組み合わせでした。 どのようなリファクタリングを行うかを考えるのがクリエイティブな活動であり、人が行えるものです。たとえば、簡単なメソッド名の変更において、変更後の名前を考えるのがクリエイティブな活動です。その活動は、コンピュータは行ってくれません。そして、新たな名前に変更するというのが作業です。 Eclipseが登場する以前は、この作業を手作業で行わないとリファクタリングは終わりませんでした。しかし、幸いにこのような作業は、今日ではEclips
教育と場: 柴田 芳樹 (Yoshiki Shibata)
今年になってから、延べ何百人と様々な教育を社内で行ってきました。以前から私的に行っている「ソフトウェアエンジニアの心得」から始まり、「プログラミング言語Java」コース、C++、プログラミング作法、テスト駆動開発と様々です。 どのような技術教育も、あくまでも最初のステップに過ぎません。教育の後に、実際の開発現場での指導がなければ、ほとんどのソフトウェアエンジニアは、身に付けることなく終わってしまいます。特に、業務に必要な知識は会社が全部教育からお膳立てしてくれると思っている人はなおさらです。そのため、いくら教育を行っても、教育を実施したという履歴が残るだけです。 前職でも同様な教育は多くのソフトウェアエンジニアに対して行っていました。「ソフトウェアエンジニアの心得」「コードレビュー」「プログラミング作法（スタイル）」から構成される１日コースを受講された人も多いですし、「プログラミング言語J
バグが直りました？: 柴田 芳樹 (Yoshiki Shibata)
不具合が発生して、原因を調査していた担当者から、原因が分かって修正しましたと報告があった場合、報告を受けた側としては、以下の点を確認する必要があります。 不具合の原因の説明をしてもらう 修正内容を説明してもらう 同じような不具合が他の場所にも無いかの確認を行ったかを報告者に聞く 同じような不具合を今後未然に防止する方法はないかを報告者に聞く 報告を受けている側の経験によっては、原因の説明を聞いた時点で、残りの項目に関しては答えが出ている場合があります。しかし、あくまでも担当者に聞く必要があります。聞くことによって、担当者がどのような取り組み方をしているのかが分かるからです。 経験の浅い人でしたら、原因から論理的に不具合を説明できなかったり、修正方法が間違っていたりするかもしれません。経験がある程度あっても、3番目と4番目にまでは考えが及んでいなかったりします。 しかし、上記4項目を全く聞く
防御的プログラミングとカバレッジ: 柴田 芳樹 (Yoshiki Shibata)
防御的プログラミングでは、外部からの呼び出しから防御します。しかし、それ以外に、自分自身の誤りに対して防御するということがあります。 次のコードは、『Effective Java 第2版』（p.147）に掲載されているコードです。// 値によって切り替えるenum 型- 問題が多い public enum Operation { PLUS, MINUS, TIMES, DIVIDE; // 定数で表される算術操作を行う double apply(double x, double y) { switch(this) { case PLUS: return x + y; case MINUS: return x - y; case TIMES: return x * y; case DIVIDE: return x / y; } throw new AssertionError("Unknow
防御的プログラミングしない後ろ向きの理由（２）: 柴田 芳樹 (Yoshiki Shibata)
拙著『プログラマー現役続行』では、防御的プログラミングについて、次のように述べています。 防御的プログラミングを行っているか コードの読みやすさは、名前付けに最も左右されます。一方、効率よくデバッグするためには、防御的プログラミング（defensive programming）も重要です。 関数、コンストラクタ、メソッドなどに渡されたパラメータが正しい値になっているかを調べ、正しくなければassertする必要があります（Ｊａｖａ言語の場合には、assertではなく、この場合はIllegalArgumentExceptionをスローします）。 コードレビューでは、必要なassertが書かれているかを調べる必要があります。また、処理の前と後で、事前条件や事後条件が成り立っているかを検査したりする必要があります。 防御的プログラミングを全く行っていない開発は、「バグの原因を発見しにくい実装を行っ
防御的プログラミングしない後ろ向きの理由: 柴田 芳樹 (Yoshiki Shibata)
防御的プログラミングしない「後ろ向き」の理由として、私が経験した中では、次のようなものがあります。 きちんとした作りこみやテストを行わずに、システム全体の結合開始日が来たので結合したら、assertで停止してしまう。システムがブートできなからassertを外せと指示された。 自分のモジュールで防御的プログラミングを行っていると、呼び出し側が悪いのにいつも自分のモジュール内で停止してしまい、都度障害だと言われて調査させられる。そんなの嫌だから、防御的プログラミングをしない。 QAチームによるテストで、問題があって防御的プログラミングにより「システムエラーと表示されて」停止すると、詳細な報告を求められる。毎回詳細に報告させられるのが面倒なので、防御的プログラミングをしない。 このような後ろ向きの理由で防御的プログラミングをしないことにより、発生した障害の調査時間が長くなり、結果的にはプロジェク
防御的プログラミングとテスト駆動開発: 柴田 芳樹 (Yoshiki Shibata)
1978年に大学でプログラミングを学び始めてから1990年代まで、私自身は防御的プログラミングを行ったことはほとんどありませんでした。また、ソフトウェアのテストと言えば、手作業でテストするのが普通の時代でした。それは、私一人が防御的プログラミングをしていないとか、私だけがテストを手作業で行っているとかではなく、それまで属した開発組織がすべてそうでした。 2000年になり、コンサルタントとして設計レビューやコードレビューを行ってきたソフトウェア開発組織に対しては、徹底的に防御的プログラミングを指導してきました。防御的プログラミングを行うことは、トータルで開発コストを下げる活動です。 パラメータの値を検査するコードを書き加えるのは、ほんの数分のプログラミングで済みます。しかし、防御的プログラミングを一切行っていないモジュールを結合して、発生した不具合の原因を調べるのは、数分では終わりません。数
プロセス中心ではなく、スキル中心: 柴田 芳樹 (Yoshiki Shibata)
Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman 作者: David H. Hoover出版社/メーカー: Oreilly & Associates Inc発売日: 2009/10/21メディア: ペーパーバック 本書の「ソフトウェア職人気質とは」（What Is Software Craftsmanship?、p.3）からの引用です。 私達は、プロセス中心ではなく、スキル中心です。私達にとって、「正しい」プロセスを使用するよりは、高いスキルを持つことが重要です。Gawande は、次のように質問しています。「医学は、技能、それとも工業ですか。医学が技能であれば、職人の技を修得するために産科医を教育することに焦点を当てます。新たな技法を見つけるために研究をします。物事を誰が行っても常に上手くいくとは限
開発組織のDNA: 柴田 芳樹 (Yoshiki Shibata)
以前、「生産性の向上」と題してブログを書いています。その中で、ハーラン・ミルズの言葉を引用しています。 企業におけるプログラマーの能力差は10倍であるといわれている。しかし、企業自体の生産性にも10倍の開きがある。 ソフトウェアの開発組織における生産性には、様々な要因が影響を与えているのは確かだと思います。 最近、私自身が感じ始めているのは、ソフトウェア開発に対する取り組み方というかＤＮＡというか、上手く言い表せませんが、何か今まで私が認識していなかった要素があるのではないかということです。 組織が発足して、徐々に拡大していく過程があるのですが、すべての組織が同じ過程を経るのではなく、発足当初から異なったDNAを持って組織は大きくなっていくのではないかと。そして、そのDNAは維持され続けて、後から新卒で入っていった人がいても、受け継がれていくのではないかと。 たとえば、私自身が1984年に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
基礎教育（2）: 柴田 芳樹 (Yoshiki Shibata)