柴田 芳樹 (Yoshiki Shibata)

訳者まえがき

　Objective-Cは、C言語とSmalltalkを組み合わせたプログラミング言語であり、オブジェクトの概念をSmalltalkから取り入れています。1983年に開発されており、その誕生からすでに30年が経過しています。Objective-Cは、C言語で記述されたプログラムをそのままObjective-Cコンパイラでコンパイルできて何の問題もなく実行されるという初期の決定に基づいて開発されました。その点では、C++言語と似ていますが、全く異なる発展を遂げています。C++言語とは対照的に、Obejctive-Cの生みの親であるBrad J. Cox氏は、現在のObjective-Cには関与しておらず、Apple社が独自に言語仕様を拡張してきました。
　私自身がObjective-Cという名前を聞いたのは、1990年頃であり20年以上前のことです。当時のMacintosh用の開発言語はC言語でした。そのため、Objective-Cのコミュニティは小さいものでした。本書の第1章で述べられているように、Apple Computer社がNeXT Software社を買収してから、Mac用の開発言語としてObjective-Cが採用されています。今日ではiPhoneやiPadの爆発的な普及により、多くのプログラマがObjective-Cを学び使用しています。
　本書は、初めてのプログラミング言語としてObejctive-Cを学ぶ人達を対象としていますので、C言語でのプログラミング経験がないことを前提として説明されています。結果として、C言語の解説は後半の章である第13章「基本的なC言語機能」で行われています。そして、本書全体が、初心者だけでなく、Objective-Cでプログラミングを行ってきた人にも役立つ内容となっています。
　当初は、原著Programming in Objective-Cの第4版で翻訳を始めましたが、XcodeとObjective-Cのバージョンアップにより、翻訳中に第5版が出版さました。そのため、第5版の修正内容を反映してあります。
　この日本語版が、読者のみなさんのObjective-CによるプログラミングとOS X/iOSアプリケーション開発の助けになれば幸いです。

『Objective-C明解プログラミング』

「総閲覧数が総計で100万を超えました」と書いたのが2年前ですので、ほぼ2年間で100万です。


この2年間で最も読まれたのは、次の2件です（閲覧数は、2013年6月13日7:00AM）。

• 継続インテグレーションは強みではなくなった （閲覧数：15,498）
• ソフトウェア開発が好きでないサラリーマンエンジニア （閲覧数：9,998）

訳者あとがき

　2002 年初めにSoftware Craftsmanship（『ソフトウェア職人気質』）を読んだのは、私が42 歳の時でした。大学で情報工学を専攻し、社会人となってから、すでに18 年が経過していました。会社内の立場は管理職であり、それまでの約4 年間は、技術教育、設計レビュー、コードレビューを行ってはいましたが、自分自身でプログラミングを行いソフトウェアを開発することはありませんでした。『ソフトウェア職人気質』を読んで決断したことは、もう一度現場に留まるために、2 度目の米国駐在を受け入れることでした。残念ながら2 度目の米国駐在は、プロジェクトの中止により短期で終わってしまいましたが、私にとっては転機でした。
　帰国してからの約５年間は、管理職という立場で、自分自身で設計・実装・デバッグまで行いながら、テスト駆動開発を行い、直接ソフトウェア開発に従事してきました。その一方で、若手の育成のために、部門全体を職人育成の場として、活動を行ってきました。振り返ってみるとアプレンティスを育て、短期間にジャーニーマンにするために、自分なりに考えたカリキュラムを実行していました。
　私自身が勉強会を主催することで、継続した読書の習慣を身に付けてもらうようにし、最初の言語としてJava 言語をきちんと学んでもらうために『プログラミング言語Java』および『Effective Java』を使用した教育を毎年行ってきました。本書がもっと早く出ていれば、職人を育成するための私のカリキュラムも、もっと良くなっていたかもしれません。
　本書には、ソフトウェア開発に従事して、これから貴重な人生を費やすための若い人々へのアドバイスが多く含まれています。私が就職した頃に本書や『ソフトウェア職人気質』の書籍があれば、今までの人生は違っていたかもしれません。私自身は、非常に遠回りしながら、長い道のりを歩んできたと思います。翻訳するだけでなく、自分の経験と照らし合わせながら、色々と考えさせられることが多い内容でした。
　本書は、これから熟練職人になることを目指す若い人々だけでなく、長年ソフトウェア開発に従事してスキルを伸ばしてきた人達にも読んでもらいたい内容です。現場の若手の育成は自分の仕事ではないと考えるのではなく、若手の育成も長い道のりを歩ませるために続けなければならない活動であると認識する必要があります。
　この日本語版が、日本での若手ソフトウェア技術者にとって、長い道のりを歩む上でガイドとなれば幸いです。そして、私自身もさらに歩み続けたいと思っています。

訳者あとがき『アプレンティスシップ・パターン』

Java研修の修了生をメンバーとしたグループをFacebookに作成しています。Facebookのアカウントも持っているJava研修の修了生は知らせてください。

最近、社内で昇格条件としてTOEIC点数が話題となったので、何か書こうかと思ったのですが・・・

私の英語勉強法に関して過去に書いた記事リンクです。

• 英語勉強法
• 英語勉強法（2）
• 英語勉強法（3）
• 英語勉強法（4）知らない単語に何度も出会う
• 英語勉強法（5）米国駐在時代

英語の勉強法は、「どうやって英語を学んだですのか？」と聞くと、人ごとに違った答えが返ってくると思います。私の若い頃と違って今では様々な学習方法が可能になっている時代ですが、何かの参考になればと思います。

Amazon.co.jpで予約できるようになりました。私の手元には、先週の金曜日に出版社から届きました。

目次は、以下の通りです。

訳者まえがき
第1章　はじめに

I. プログラミング言語Objective-C
第2章　Objective-C プログラミング
第3章　クラス、メソッド、オブジェクト
第4章　データ型と式
第5章　ループ
第6章　判定
第7章　さらにクラスについて
第8章　継承
第9章　ポリモフィズム、動的型付け、動的バインディング
第10章　さらに変数とデータ型について
第11章　カテゴリとプロトコル
第12章　プリプロセッサ
第13章　基本的なC 言語機能

II. Foundation フレームワーク
第14章　Foundation フレームワークへの序論
第15章　ナンバー、文字列、コレクション
第16章　ファイルを扱う
第17章　メモリ管理と自動参照カウント
第18章　オブジェクトをコピー
第19章　アーカイブ

III. Cocoa、Cocoa Touch とiOS SDK
第20章　Cocoa とCocoa Touch への序論
第21章　iOS アプリケーションの作成
付録B アドレスブックのソースコード例
付録A 用語集

最初のプログラミング言語としてObjective-Cを学ぶ人を対象としており、Objective-Cのプログラミング言語としての詳細が説明されています。もちろん、普段Objective-Cでプログラミングしている人にとっても、あらためて言語をきちんと学習し直すのにも適していると思います。

私は、最初にC 言語を教えないしC 言語の知識を持っていることも前提としないと決めました。代わりに、オブジェクト指向プログラミングの視点から単一の統合化された言語としてObjective-C およびそのベースであるC 言語を教えるという、今までにないアプローチを取ることにしました。本書の目的は、そのタイトルが意味する通りのものです。つまり、Objective-C でプログラミングを教えることです。はっきりと言えば、プログラムを入力してデバッグするために利用可能な開発ツールの使用方法を詳細に教えたり、インタラクティブなグラフィカルアプリケーションの開発方法を詳細に説明したりしないということです。プログラムの書き方をObjective-C で学んだ後に、それらの題材に関しては他の書籍などで詳細に学ぶことができます。実際、Objective-C でのプログラムの書き方の確固たる基本を習得すれば、それらの題材を習得することは非常に容易になります。本書は、今までに多くのプログラミング経験があることを想定していません。実際、あなたが初心者プログラマならば、熱心に真剣に取り組むことで、あなたの最初のプログラミング言語としてObjective-C を学ぶことができるはずです。本書の以前の版に対して私が受け取った読者からのフィードバックによれば、多くの読者はそうすることに成功しています。

『Objective-C明解プログラミング』（p.2）

5月24日（金）に、私にとって第17期となる「プログラミング言語Java」研修が終了しました。今回の修了は、8名でした。今回のコースは18名でスタートしたのですが、最終的には8名だけとなってしまいました。

また、私の後任なる講師を育成するということも当初活動としては行っていましたが、後半は結局私がすべて講師を行うということになり、育成に関しては、失敗したコースでした。と同時に、育成するのは、無理とも思ったコースでした。

午後2時までは、『Effective Java 第2版』の残りの部分のQ&Aを行った後、2時からは成果発表会ということで、一年間の振り返りとデジタル時計課題のデモを行ってもらいました。


これで、リコーグループでの修了生は合計57名ですが、17期生には2回目の修了生がいるの、延べ56名です。

まだAmazon.co.jpを含めてどこも予約注文できませんが、近日中に発売されます。出版社は、ピアソン桐原です。今回も、翻訳だけでなく、組版もLaTeXを使用して私自身で行っています。

原著はこちらの本です。原著の第5版の翻訳本であり、原著は第4版までは翻訳されていません。

以前、「悪いAPIは伝染していく」という短い記事を書きました。

APIが悪いライブラリを使用する別のライブラリを設計する場合には、元のライブラリのAPIの悪さを、新たなライブラリでは修正することが可能です。しかし、よく見かけるのは、使用する元のライブラリのAPIの悪さをそのまま引きずったライブラリが設計されることです。その意味で、低レベルのライブラリのAPIの悪さは、上位レベルへと伝染していきます。悪さが伝染しないように新たにAPIを設計できるエンジニアは少ないようです。

きちんとしたAPIを持つライブラリを使用しているのにもかかわらず、出来の悪いAPIを持つ上位のライブラリが作成されることがあります。私自身がかなりレビューしてAPIを整備させたライブラリを使用して、その上に出来の悪いAPIを持つライブラリが設計されているのを見ると、がっかりしてしまいます。

どんなAPIでも、最初のバージョンは完璧ではないです。しかし、それを理由に、出来の悪いAPIを設計してい良い訳ではありません。

私自身の経験から言えば、2000年にC++言語用のメモリ管理ライブラリとそれを使用した基本的なライブラリ（スレッドやコレクション関連）※1を設計しました。私自身がAPIを設計したライブラリでしたが、実際に私がそれを使用してコードを書くことはありませんでした※2。しかし、2003年からそのライブラリを使用して、自分でもかなりのコードを書くことで、いくつかのAPI設計の誤りに気付いたのです。その誤りのほとんどは、些細なものでした。しかし、1行で書けるべきところを2行書かなければならなかったりして、非常に面倒に感じたのです。結局、その場合には、後方互換性を保ったままAPIを修正することが可能だったので、APIを修正しました。

※1 Fuji Xerox社のカラー複合機ApeosPortで使用されているライブラリです。
※2 私自身は、主に設計コンサルタント的な活動をしていました。

私が大学で情報工学を学んだ頃には、優れたAPIを設計することに関する教育はありませんでしたし、今でもないのではないかと思います。社会人となっても、体系的に教えられたりすることもなく、自己学習しながらでした。ただ、その中でも、様々な書籍を読むことで、著者が体験して習得したこを学んだ部分は大きいです※3。

※3 私自身にとって、もっとも衝撃だったのは『Effective Java プログラミング言語ガイド』でした。

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

『リーンソフトウェア開発と組織改革』の一部を紹介した「技術的負債」でも引用したように、負債が破綻にいたらないように努めながらソフトウェア開発/製品開発を行っていくことが必要です。

技術的負債
成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・

（途中省略）

技術的負債の本当の姿を知らなければならない。負債が破綻に至らないよう、コスト上の重荷をふだんから取り除いておくべきだ。

『リーンソフトウェア開発と組織改革』

技術的負債を軽減しながら、同時にソフトウェア開発/商品開発を進めていくことが重要です。技術的負債を積み上げないように努力をしながらソフトウェア開発を行っている開発組織では、「どのような商品を作るのか」に集中しても、開発そのものが技術的負債を積み上げる可能性は少ないです。しかし、毎年のように技術的負債を積み上げている組織では、技術的負債を返済することを諦めてしまうと、ある時、突然破綻してしまってもおかしくはないかもしれません。

ソフトウェア開発は非常に複雑な活動です。その複雑さにどのようにきちんと取り組んでいくかを考えていかないと、技術的負債は積み上げられて、開発に従事したエンジニアのスキルは向上することはないかもしれません。私個人のソフトウェア開発経験から言うと、技術的負債が積み上げられて、負債を解消することを行っていないソフトウェア開発だけにしか従事したことがないソフトウェアエンジニアで、その経験年数に見合ったレベルのスキルを獲得している人はほとんどいません。単に、XX年の開発経験がありますという程度に過ぎないということです。