SSブログ

講演案内: 長野 10月12日(土) [「ソフトウェアエンジニアの心得」講演]

依頼があった時に不定期に行っている講演を、長野ソフトウェア技術者グループ(NSEG)様主催で行います。
  • 日時: 2013年10月12日(土) 14:00~18:30
  • 場所: 信州大学工学部 総合研究棟 1F SUNS 会議室
  • テーマ: 「ソフトウェアエンジニアの心得」「プログラミング言語Java教育」
詳細な情報および申し込みは、こちらです。過去の講演については、こちらを参照してください。

長野に行くのは、初めてです。当然、信州大学も初めて行きます。楽しみです。

信州大学といえば、信州大学経済学部を創設され、労働者派遣法の生みの親である高梨昌さんが思い出されます。偶然とは言え、今住んでいるマンションへ移った時に高梨さんは私の上の階でした。マンション管理規約改定専門委員会も含め、マンション内の様々な活動でご一緒させてもらいました。
※ 2011年8月30日に亡くなられました。

年数だけではないですが [プログラマー現役続行]

大学1年生(1978年)の時に、FORTRANでプログラミングを学んでからすでに35年が過ぎました。大学では色々な言語をちょっとずつ使用しましたが、4年生と修了の2年の合計3年間は、Z80アセンブリ言語でプログラミングしていました。

就職してからC言語でプログラミングするようになり、1993年頃までの約8年間ぐらいまで主に使用していました。途中、2年弱、Mesa言語でもプログラミングしていました。C言語で書き始めた頃はかなりひどいコードを書いていたと思います。1992年前後から抽象データ型を意識して、実装の隠蔽を行っていました。
※ 「Mesa言語」を参照してください。

1993年中から1996年中までは、C++でプログラミングしていたのですが、まだこの頃は、オブジェクト指向と言えば継承と言う時代で、継承ベースで設計していました。ただ、この時に、マルチスレッドプログラミングをかなりやりました。メモリーリークやメモリー破壊を検出するためにC++のnew演算子とdelete演算子を自分で作成したものと置き換えることもこの時に行いました。一方で、1996年夏から趣味としてJavaを学びプライベートプロジェクトでプログラミングしていました。

2000年からC++を用いたFuji Xerox社のデジタル複合機(MFP)開発のために、それまでに趣味で学んだJavaから得た設計知識を総動員して、C++でしたが、「インターフェース」に基づくメモリ管理を含むスレッドやコレクションのライブラリを整備しました。そして、2003年から2008年までは自分でもかなり(マルチスレッド)プログラミングをしていました。

ソフトウェアエンジニアのレベルを知るには、経験年数は当てになりません。プログラミング経験も長いから良いというものではなく、スキル向上を続けて、様々な知識を習得して実践してきたかが重要です。しかし、大学(あるいは大学院)を卒業し、22歳あるいは24歳で就職して、それから実質的にプログラミングを学んで開発業務を行い、30代の初めでプログラミングをしなくなって、開発組織の管理をするようになるのは、どう考えてもソフトウェア開発経験が少なすぎると思います。

書籍『プログラミング作法』 [プログラマー現役続行]

ソフトウェア開発では、ある課題を解決するための方法は複数あることが普通です。しかし、それぞれに、長所や短所があったりして、適用すべき状況に応じて選択できることが必要です。そのためには、それぞれの長所や短所を理解しておくことが重要です。

書籍『プログラミング作法』の第1章と第2章を用いた勉強会用に作成した「勉強会ノート」には、書籍の内容を深く理解するための「説明ポイント」として、多くの設問を用意してあります。設問の中には、「〇〇とXXは、どちらがよいか説明しなさい」というのがあったりします。そして、両方の長所と短所を説明してどちらが良いと断定できないというのが期待する解答の場合があります。

しかし、そこまで質問の意図を読み取れる人は少ないです。特にプログラミング経験が浅い人は、期待される解答の長所と短所を実際に経験したことがないため、どうしても2つの解法に白黒を着けた答えとなってしまいます。

※ 開発経験年数を指していません。

『プログラミング作法』の翻訳が出る前で、英語の原著しかなかった頃に勉強会を開催した理由は、今でも決して解消されることはありません。その理由は、現場の若手エンジニアがハッシュテーブルなどの基本的な「データ構造とアルゴリズム」を全く理解していないことです。「ハッシュテーブルって何ですか?」に対して「そんな基本的なことは聞くな」という会話から始まった勉強会でした。

FXIS勤務の時は、私の部署に配属された新卒新人は、派遣会社からの新人も含めて、勉強会ノートの学習を終わらせるのが業務でした。早い人で2か月、遅い人で4か月以上要していました。しかし、半年過ぎても終わらないとなるとさすがにソフトウェア開発には向かないと判断したこともありました。今の会社では、私が直接指導できた人は1人だけなので、勉強会ノートをきちんと終えた人はその彼一人です。

The Practice of Programming
勉強会ノート

このドキュメントは、Brian W. Kernighan と Rob Pike の著書である「The Practice of Programming」の第 1 章と第 2 章を、新卒新人を中心として行った勉強会向けに作成したものです。

1999 年 2 月に米国で発売になった「The Practice of Programming」に書かれている内容は、全くの初心者に非常に難しく、一方、経験を積んでいるソフトウェア・エンジニアにとっては当たり前のことが書かれています。

したがって、経験があるソフトウェア・エンジニアが中心となって勉強会を開催する場合のサブノートとして使用されるように、勉強会参加者に対して問い掛ける質問を中心にまとめられています。

1 章と 2 章だけでなく、すべての章で有益なことが書かれていますので、是非全体を読んでください。初心者には分かり難い部分も多いですが、その場合には、職場の経験ある先輩に聞いてください。でも、正しく説明出来る人は多くないと思います。「The Practice of Programming」に書かれている内容がすべて説明できるようになれば、一人前のソフトウェア・エンジニアと言っても過言ではないでしょう。

2000年5月14日
柴田 芳樹

プログラミング作法

プログラミング作法

  • 作者: ブライアン カーニハン
  • 出版社/メーカー: アスキー
  • 発売日: 2000/11
  • メディア: 単行本


11月から第20期Java研修を開講・・・最後の期? [プログラミング言語Java教育]

振り返ってみると、Java研修を始めた2000年は、まだ40歳でした。第1期のテキストは、『プログラミング言語Java第3版』の翻訳原稿でした。それが終ると、ちょうど翻訳を始めた『Effective Javaプログラミング言語ガイド』の翻訳原稿で研修を続けました。

第1期は、朝10時から夕方5時までと短めで、1年半のコースでした。Java研修では毎回その日の研修が終ると懇親会(飲み会)です。一度だけ、講演のためには岡山へ移動する必要があった時に、研修後に新横浜から岡山へ向かい、懇親会はしませんでした。

11月に開講する第20期で、現在のテキストによるJava研修は最後です。おそらく通算で150名以上の修了生になるのではないかと思います。研修で唯一失敗したのは、私の代わりとして講師となれる人の育成です。今の会社で2度試みましたが、どちらも途中で諦めました。

当面、第20期で最後であり、その主な理由は次の通りです。
  • 2014年には正式にJava 8がリリースされて言語仕様も変わる。
  • 『プログラミング言語Java第4版』と『Effective Java 第2版』は、絶版となっている。
  • 『プログラミング言語Java第5版』と『Effective Java 第3版』となるであろう原著の改訂は全く未定。
新たなテキスト(あるいは翻訳原稿)で行うことができる時期がきたら、コースを再開して第21期としたいと考えています。

英語とTOEIC(3) [英語]

毎朝、いつもPodcastでNBC Newsの「Today」や「Nightly News」をながらで見ながら翻訳作業をしたり出かける準備をしていることが多いです。両方で、毎日約50分程度です。また、「Anderson Cooper 360」や「CNN Student News」もながらで見ています。

振り返ってみると、真剣に集中しながら英語のリスニングの訓練をすることは、大学生の頃からあまりありません。ほとんどの聞き取れないEnglish Journal のテープをながらで聞いたり、テレビ番組の音声を録音して、ながらで聞いていることが多かったです。

米国から流れてくるトップニュースは、日本では軽くしか放送されなかったりします。詳しく知るには、現地の放送が一番良い訳です。以前は、ケーブルTVでCNNjを見たりしていのですが、ケーブルTVそのものをあまり見なくなったので現在は解約しています。

時間帯は限られますが、米国サンフランシスコ地域のニュースとしては、ABC 7 News(http://abclocal.go.com/kgo/live)を見ることができます。ここは、何か事故があれば、本来の放送時間帯とは関係なくライブ放送をしていることがあります。サンフランシスコ国際空港での飛行機事故でもライブ放送を行っていました。

(「英語とTOEIC」「英語とTOEIC(2)」)

書籍『脱社畜の働き方』 [本]

脱社畜の働き方~会社に人生を支配されない34の思考法

脱社畜の働き方~会社に人生を支配されない34の思考法

  • 作者: 日野 瑛太郎
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/09/07
  • メディア: 単行本

この本は、サブタイトル「会社に人生を支配されない34の思考法」にあるように、働き方に対する様々な思考に対する考え方が述べられています。

第1章「日本の職場は理不尽なことばかり」では、「社畜の思考法」と「脱社畜の思考法」で様々な観点で説明されています。私自身は、「脱社畜の思考法」として紹介されている内容に同意することが多い章でした。おそらく、私自身が1社で働き続けたのではなく、4回転職し、5社での経験から、仕事のやり方だけでなく会社としての制度の違いを色々と経験し、転職ごとに会社での働き方のスタイルも変わってきているからだと思います。

第4章「プライベートプロジェクトのススメ」では、会社で働く一方で、自分が主体となって行うプライベートプロジェクトの勧めが筆者に経験を元に述べられています。私自身は、40歳になってから会社以外の執筆や翻訳の活動というプライベートプロジェクトを行っていますが、やはり、もっと若い頃からできていたらと思います。

現在は、アプリ開発というプライベートプロジェクトを行う場合でも、昔と比べるとはるかに色々なことができる時代となっています。その意味で非常に恵まれた時代だと思います。でも、残念ながら私の周りでは、アプリを開発をプライベートで行っている若い人達はごく少数です。

この本は、普段の会社での自分自身の働き方を見直すきっかけを与えてくれると思います。すべての内容に同意することはないでしょうが、思考のきっかけにはなるかと思います。

教育と「場」 [プログラマー現役続行]

様々な技術教育を行っても、実際に受講生が実践するのは難しことが多いです。その理由の1つは、教育教材が教育用であり、実際の開発物ではないからです。そして、本質的に重要なのは、日々の開発成果物での指導を受けることです。その指導を受ける「場」があって初めて教育が意味を持ちます。

そのような「場」がない組織、つまり、きちんとした指導を出来る人がいない組織では、技術教育で学んだことをさらに身に付ける指導を受けることがなかったりします。そうなると、どんなに技術教育担当部署が様々な教育を費用をかけて実施しても、あまり効果はありません。

私が長年行っているJava教育も同じです。たとえ、受講生が一年間膨大な時間を費やして学習しても、学んだことを実際の開発で一人で適切に適用できるようにはなかなかなりません。実際に成長した人達の多くは、さらに私の下で一緒に開発を行い、教育の内容を日々繰返し言われた続けた人達です。

今の会社では、Java教育の修了生で、私の部下として一緒に働いている人は一人もいません。前の会社では、私が部門長をしていた開発部門では、10名以上の修了生がいました。今は、それでも、修了生を対象として、業務で開発している(ソースコードを中心とする)成果物のレビューを行うためにフォローアップ・コンサルティングを月に1回行っています。

※ 私自身の工数の20%は、Java教育やこのようなフォローアップ・コンサルティングとして他部署(会社)に対して費やしています。残りは、開発業務です。

ソフトウェアエンジニアとしては、自分を成長させてくれる「場」を提供してくれる組織で働くことは重要です。また、会社としては、技術教育を充実しても、「場」として開発組織が存在しなければ、教育投資は無駄となります。
仕事の中に学習機会を見出すことができればそれだけで問題なく人間は成長できるはずだ。逆に、どんなに厳しくつらい環境に身をおていも、学習機会が仕事の中で見いだせなければ成長することはできない。
日野瑛太郎 著、『脱社畜の働き方』(p.85)

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

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

ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量もも圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。

1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えないということです。これは、ソフトウェア開発の話です。

経験の無い領域のソフトウェア開発だら、やる気が出ませんと言い訳しながら、いつまでも完成せず、可読性も含めて品質が悪く、バグだらけという状態が続くのであれば、「もう、仕事をさせない」というのが米国流だと思います。

日本では、仕方なく本人が出来る仕事を与えてしまいます。そうすると、勘違いする人がでてきます。自分のスキルの低さを棚に上げて、やる気がでないと言えば、自分が出来る仕事が与えられると。短納期だとかプロトタイプだからという言い訳は、やる気がでないという言い訳よりは、まだ良いのかもしれません。

経験年数が増えれば増えるほど、初心者レベルの言い訳は通じなくなります。しかし、単に年数を積み上げているだけでスキルが全く向上していない人は、そのことの重大性を認識することなく、いつまでも初心者レベルの言い訳を繰り返したりします。

「そんな、初心者レベルの言い訳をするな」と言われないようにしてください。


スポンサーリンク





Programming into a language [プログラマー現役続行]

私自身が1984年に社会人となってC言語を学び始めた時には、動作すれば良いという感じでプログラムを書いていたのではないかと思います。つまり、関数間のデータの受け渡しには、パラメータや戻り値だけでなくグローバル変数を混在させたりとか。

何をヘッダーファイルに入れて、どのヘッダーには何を入れるべきかも気にしていなかったと思います。公開APIとしての定義と実装用定義も混在させてヘッダーファイルに入れていたと思います。C言語で公開APIを強く意識してコーディングするようになったのは、1992年前後だと思います。

書きかけの「API設計の基礎」にそのあたりのことを書いています。C言語ではどのような設計でもできます。しかし、「API設計の基礎」にも書いている「Programming into a languageが重要です。
※ Steve McConnell著、『コードコンプリート第2版下』(日経BPソフトプレス)の34.4節

簡単に言えば、「Programming into a language」とは、「言語にとらわれずに、行いたい設計を与えられた言語で行う」ということです。たとえば、「公開するAPIには、実装の詳細は一切いれないで、実装の詳細は一切公開しない」というのも行いたい設計の1例です。

使用するプログラミング言語によっては、言語仕様として行いたい設計をサポートしているものもあります。しかし、言語によっては全くサポートしておらず、何らかの工夫が必要となります。C言語では、抽象データ型やオブジェクト指向プログラミングを言語仕様として直接サポートしていません。

様々なプログラミング言語を学ぶことは、言語仕様で直接サポートしている設計手法を学ぶことに役立ちます。その設計手法が有効だと自分自身で納得できれば、その設計手法を言語仕様で直接サポートしていない言語で工夫することになります。

その意味で、C言語だけで(特に組込システム)開発をずっと続けている人の場合、行いたい設計の範囲が非常に狭い場合がありますので注意が必要です。その結果、他の言語がサポートしている設計手法を理解できなかったりします。

再び日本で聴けなくなったKOIT [KOIT]

最近、iPadでKOITのアプリを起動しても音が全然でないので、調べて見たら、日本では聴けなくなっていました。同様に、KBayも聴けなくなっていました。非常に残念です。

KOITとKBAY」にも書きましたが、KOITは私が1991年5月から1993年5月までの2年間Palo Alto, CAに住んでいた頃に良く聴いたFM放送でした。