なぜ働くのか？生活のためではありますが、お金のためではありません。充実した人生を生きるためと言ったほうがしっくりきます。
ではなぜ生きるのか？この世に生を受けた以上、自分という存在を自覚してしまったからには生きないわけにはいきません。
充実した人生とは？う～ん。妻と子供、家族、仲間、友達、公私ともに関わりのあるすべての人と、達成感や幸福感、満足感など、共有する時間、場所、思い出を持つこと。そこに精神的にも物質的にも自分らしく日々を送ることができれば満足です。
こういうことを考えると、仕事の意味は、自分の成長と人の成長の相乗効果だと思います。仕事を通して学び、楽しみ、疲れ、反省し、経験し、成長していきます。その過程でいろいろな人にお世話になったり、お世話をしたり、助けられたり、助けたり、教えられたり、教えたり、人と関わっていきます。自分がさらに高みに行けば、より多くの人との影響が広がり、より自分の人生に良い効果が生まれます。
この本からそんなことを感じました。いい本です。一度しかない人生を最高の時間として生き抜くにはどうすればよいのか、会社のみんなにもひとり一冊プレゼントします。
1980年代後半、サン・マイクロシステムズはバーチャルマシンを組み込んだUNIXウィンドウシステムをオブジェクト指向で設計していました。このときの技術がのちにJavaに生かされるわけですが、このウィンドウシステム（NeWS）は当時の既存勢力であるHP、DEC、IBMらの提唱するX Window Systemに敗れます。
この挫折感からサンのパトリック・ノートンという若きプログラマが、その頃スティーブ・ジョブズが立ち上げたNeXTに移りたいとスコット・マクニーリに打ち明けたといいます。NeXTのNEXTSTEPは当時、スタイリッシュな外観と洗練されたGUIをもつUNIXとして注目を浴びていました。
マクニーリは「辞める前にサンのまずいところを書き出して欲しい。解決策も、神様になったつもりで教えて欲しい。」と言ったそうです。このときのやり取りが、サンがJavaへ向かうきっかけになったと言われています。
ただ、ビル・ジョイにとってはJavaは単なる思いつきではなく、必要に迫られた開発言語であり、実行環境でした。このようなことを背景にして、ジェームズ・ゴスリングがオフィスの窓から樫（oak）の木が見えたことから名づけられた家電を制御するための組み込み用の開発言語Oakを前身として、1995年Javaが誕生しました。
ゴスリングはJavaを開発する上で、オブジェクト指向本来の良さを損なうことなく言語仕様をいかにシンプルにするかということを一番に考えた、と言っています。まさにその思想がJavaの成功だと思います。
その後、Javaはインターネット技術とともに注目され、さまざまなAPIライブラリが揃い、改訂を繰り返し今に至ります。オブジェクト指向特有の難解な概念はJavaによって市民権を得たと言えます。
[参考]
ビル・ジョイの冒険―ネットワークをコンピュータにした人々
ドミノ倒しの瞬間は爽快です。それまでの苦労が一気に解放される瞬間でもあります。
ドミノをならべるときはその列が長くなればなるほど慎重になり、終点に近づくほど緊張してきます。それはドミノをならべるために費やした時間が、ひとつのミスで水の泡になる恐れを感じるからです。このミスを防ぐために、駒抜きといって不意に倒れたドミノが伝播しないように工夫をします。
ソフトウェアの開発に当てあてはめるとこうなります。
ドミノ ＝ ソースコードやドキュメントなどの成果物
ならべる ＝ 開発作業そのもの
駒抜き ＝ バックアップやバージョン管理
倒す ＝ 運用
もちろん、ソフトウェアはドミノのように一回だけの動作ではありません。構築すれば、何回も運用されます。そして、ならべたドミノの間隔や角度が、ソフトウェアの品質に相当します。ドミノが途中で倒れずに残ってしまうと、品質に問題があるということです。
そう考えると、品質はさまざまな要因が関係しています。
作り上げるもののニーズ、リーダーシップ、人の参画と協力、人が持つスキルセット、効果的なマネジメント、環境、そして何よりもドミノをならべることが「好き」というひとりひとりの心持ちです。
本質は、好きなこと → 楽しい → 多くを学ぶ → よい結果を生む という循環だと思います。
すべてのドミノが思ったとおりに倒れたら圧巻です。つまり、要求事項を満たしたソフトウェアを作り上げてお客さんが喜んでくれたら、やりがいがあるというものです。
この最後の瞬間のために、仕事をしていると言ってもいいかもしれません。
1970年代、ビル・ジョイがバークレー校で、オブジェクト指向言語Smalltalkに触れていたころ、カナダのカルガリー大学ではジェームズ・ゴスリングが最初のオブジェクト指向言語であるSimulaを学んでいました。この二人は後にサン・マイクロシステムズの躍進とともにJava言語の開発に携わります。
1963年にアイヴァン・サザランドという優秀な技術者がMITの研究所においてオブジェクト指向が実現される最初のきっかけとなった、ライトペンによりディスプレイ画面に図形を描写する「スケッチパッド」を開発しています。その次の年にはインターネットの原型となるARPANET（アーパネット）の母体となったアメリカ国防省の高等研究計画局の情報処理技術部長に26歳の若さで就任します。
その後1966年にサザランドは国防省の地位をロバート・テイラーに譲りハーバード大学の助教授になります。後にサザランドと一緒にサンに行くことになるボブ・スプロウルはハーバードでサザランドの科目に応募した学生でした。
1968年サザランドはハーバードを出てディビッド・エヴァンスとコンサルティング会社を設立し、そこで、連続的に変化する陰影をリアルタイムに表現できる最初の三次元グラフィックスを開発します。同年エヴァンスがユタ大学にコンピュータサイエンス学科を創設したことをきっかけにサザランドはユタ大学の教授となり、バーチャルリアリティをソフトウェアで実現するNITE-VIEWを発表します。その一方で、のちにSmalltalkを開発することになるアラン・ケイは1966年ユタ大学の大学院でエヴァンスとサザランドに出会い、オブジェクト指向の権威の道を辿ることになります。（つづく）
ここで、もっとも感銘を受けたアラン・ケイの言葉を紹介しておきます。
「コンピュータは、他のいかなるメディア－物理的には存在しえないメディアですら、ダイナミックにシミュレートできるメディアなのである。さまざまな道具として振る舞う事が出来るが、コンピュータそれ自体は道具ではない。コンピュータは最初のメタメディアであり、したがって、かつて見た事もない、そしていまだほとんど研究されていない、表現と描写の自由を持っている。それ以上に重要なのは、これは楽しいものであり、したがって、本質的にやるだけの価値があるものだということだ。」（Alan Kay）
ビジョナリーカンパニーとは、ビジョンを持っている、先見的な、業界で卓越している会社のことを指します。本書では、目先のことにとらわれない原則（理念）を持ち、一貫性のある進歩が会社を繁栄させると説いています。
「時を告げるのではなく、時計をつくる」という言葉が印象的です。
カリスマ的な経営者がすばらしい言動で組織を導くことは現時刻を正確に「告げる」ことであり、一方でひとりの指導者の時代を超えて組織が繁栄し続ける会社を築くことは現時刻を告げる「時計をつくる」ということを表しています。時計（仕組み）をつくることの方が、その組織にとって、将来に渡って意味のある仕事を残すことができるということです。
その繁栄し続ける会社を築く要素には、利益を超えた動機付け、継続的な進歩、自主性と失敗を恐れない寛容さ、奮起する大胆な戦略、価値観を共有できる組織作り、決して満足しない精神、などがあり、原則（理念）を中心に行動を起こす大切さを改めて考えさせられました。勉強になる本でした。
そして「変化か安定か」「低コストか高品質か」「利益か理想か」といった相反する考え方をどちらか一方しか実現できないと判断するのではなく、両方を同時に追求する方法を考える、というポジティブな力強さが大切です。二兎は追えない「これしかない」と言うよりも「これとこれは同時にやる」というある種の欲張り的な肯定論のほうが魅力的です。
僕も基本的に"Never give up"が好きなので、この本は非常に共感できました。
ただ、ここにはどのような理念を作るべきかは触れられていません。
一言でいえば、ビジョナリーカンパニーの理念に不可欠な要素はない。わたしたちの調査結果によれば、理念が本物であり、企業がどこまで理念を貫き通しているかの方が、理念の内容よりも重要である。
と書いています。つまり、絶対なる大儀や善の理念が必要なのではなく、組織に浸透し活力となりうる身の丈に合った理念を持つということの方が重要だということです。
昨日、情報処理技術者試験がありました。
弊社のメンバも多くが「基本情報」を受けました。実は僕も「ソフトウェア開発」を受けました。みんな頑張ったと思います。受かっているといいね。
今回は、半年前から情報処理試験対策として、月１回、各人持ち回りで情報処理に関するテーマを選んでプレゼンをしてもらいました。資料を作り、準備をして、みんなの前で説明します。各々工夫を凝らしたプレゼンが印象的でした。これをきっかけにみんなで合格できれば嬉しいです。
よく情報処理技術者試験は、実務と関係ないとか言われますが、正直僕も去年まではどこかでそう思っていました。
仕事が忙しくて勉強する時間がない、とか今の仕事に資格は関係ない、など言い訳していた自分もいました。ですが、最近思います。ある一定の基準なり水準をクリアすることができれば、自信につながることは当然で、さらに次のステップに上がることができます。資格を取ることで、ナチュラルに成長できるのではないでしょうか。
資格が仕事に即効性を与えることはありませんが、言わば登龍門をくぐることで視野が開けるということです。計算力や論理的思考力も養われますし、用語も覚えます。しかしその効果を実感することはずっと先にならないと分かりません。
そういう意味で僕も心を改めてチャレンジしたわけですが、また落ちたら正直ショックですね。
受けた人はみんな同じ気持ちだと思います。でも落ちてもまたチャレンジしましょう。受かった人はおめでとう。てもまだいろんな試験区分がありますよ。
「資格取得はゴールではない、始まりにすぎない。」（By Kaneko）
1965年、AT&Tベル研究所が中心となりOS「Multics」（マルチックス）が開発されます。しかし複雑さゆえプロジェクトは座礁します。
AT&Tベル研究所のケン・トンプソンが1969年、メインフレームで動いていた研究中のMulticsの上でゲーム"Space Travel"（宇宙船を操作し、惑星に着陸させる）を走らせていたところ、当時の計算機の利用には使用料が課金されていたのでしょう、なんとか安く動かせないかと、デニス・リッチーとともに、研究所の片隅に転がっていたガラクタ同然のコンピュータ（DECのPDP-7）でMulticsを単純化して走らせました。これがUNIXの誕生です。
UNIXという名前は、共同研究者だったブライアン・カーニハンが、撤退した「Multics=Multi+cs」を皮肉ってMulti（複）に対してUni（単）として「UNIX=Uni+cs」と名付けたという逸話があります。
同じ頃、ケン・トンプソンはB言語を作ります。B言語はその後、トンプソン自身とデニス・リッチー、そしてブライアン・カーニハンによって改良を加えられ、NewBを経てC言語へと発展していきます。アセンブラで記述されていたUNIXはC言語で書き直されます。
1976年、AT&Tベル研究所からUNIXを持ってカルフォニア州立大学バークレー分校にやってきたケン・トンプソンは、UNIXを授業で使う傍ら、教育のため、PascalをUNIX上に移植しています。彼がバークレーから去ったあと、そのPascalを完成させたのは、彼の助手をしていた、ビル・ジョイとチャック・ヘイリです。ビルの関心は数学がベースとなる理論としてのコンピュータでした。しかしUNIXとの出会いがその後の進路を大きく変えることになります。
ビル・ジョイは、1977年にPascalコンパイルを仕上げ、その後コーディングのためのviエディタを書き、バグを修正したUNIXを友人に送ったのが契機となり、UNIXを発展させる活動がネットワーク上で広まります。
ビル・ジョイが中心になってバージョンアップを続けたUNIXが「BSD（Berkeley Software Distribution） UNIX」と呼ばれるようになります。
1982年、BSD UNIXを開発していたビル・ジョイは、スタンフォード大学の大学院で学んでいたビノッド・コースラ、アンディ・ベクトルシャイム、スコット・マクニーリらとともにサン・マイクロシステムズを設立します。
サンは当初から"The Network is The Computer"（ネットワークこそがコンピュータだ）という言葉を使い、そのとおり90年代にはインターネットサーバの会社として急成長を遂げます。この言葉はどんな人、モノであれ、ネットワークに接続することで、コンピュータとしての価値を享受できることを意味しています。まさに現在のインターネット社会を予見していたようです。
そんなサンの戦略として、Javaはビル・ジョイが中心となり、ネットワークを包括的に機能させるためのプラットフォームを超えたアプリケーションを構築するための開発言語として生まれました。（つづく）
サラミソーセージを少しずつスライスして、減っていることがばれないように盗むやり方です。銀行・証券システムなどで多額の口座から1円づつ自分の口座に振り替えれば、気づかれないようにお金を集めることができるコンピュータ犯罪の手口です。
次のうちサラミ法はどれでしょう？
ア 回線の一部に秘密にアクセスして他人のID、パスワードを盗む
イ ネットワークを流れる音声やデータを不正に傍受する
ウ 不正が表面化しない程度に多額の資産から少しずつ詐取する
エ プログラム実行後のキャッシュなどの内容を密かに入手する
解答は ウ です。（フォント色を白で書いています）
逆の発想で、もし本人が気づかないうちに情報処理の知識を身につける手法があれば、ポテトチップス法と名づけたい。（無意識に手が伸び食べてしまうことから）
さらに、たまに情報処理技術者試験に申し込みたくなる手法を、カップラーメン法と名づけたい。（たまに食べたくなることから）
僕が仕事でJavaを使い始めたのは2001年ごろからです。
それまではもっぱらC言語で、当時Javaの仕事がしたいな、といつも思っていました。
Javaはサン・マイクロシステムズによって、プラットフォームに依存しない、ネットワークを意識した、コンパクトなオブジェクト指向言語として開発され、1995年に世に出てきました。その当時、幕張メッセで何かの展示会があり、SunのブースでJavaを初めて見たときのことを記憶しています。ブラウザのなかで、あのマスコット（なんていう名前だったっけ？Dukeだ！）がアニメーションとして踊るアプレットが印象的でした。（その後1998年ごろにはサーブレットという形でサーバサイドの開発言語として開花します）
そんなJavaを是非やりたいと、当時お付き合いのあったお客さんに「やる気」を見せたのですが、君は経験がないと言われて、使ってもらえませんでした。アプリケーションサーバは知っていますか？と聞かれ、よく知りません、と言ってしまって後悔したものです。
なので、Javaさえ使えればどんな仕事でも。。と営業をしまくりました。
今だから言えますが最初は勉強しながらコーディングしていました。当時のソースを見ると恥ずかしくなります。ですが、そのときに試行錯誤して感じたオブジェクト指向的なアプローチは、今でも知的好奇心をくすぐり、シンプルで美しくおもしろみのある言語だという印象は変わっていません。
オブジェクト指向の３大要素である、カプセル化、継承、ポリモーフィズムはこの本で学びました。Javaのコードが読めることが前提ですが、オブジェクト指向の考え方が分かりやすく書かれています。参考までに。
会社経営においては、トップダウンという経営者から下位へ指示・命令を伝達していく経営スタイルと、ボトムアップという社員ひとりひとりの発言・主張から意識が広がる企業文化とを比べた場合、ずいぶん印象が違います。
どちらも一長一短で、偏りすぎはよくないのですが、僕は会社のあり方についてボトムアップの方を好みます。トップが社員をひっぱるのではなく、社員ひとりひとりが主体的に会社をひっぱる発想の方が、強固な力を生むことになると思うからです。
一般に管理的に考えるのであればトップダウン、自主性を重んじるのであればボトムアップです。経営はそのバランスが大切だと思います。
経営者のやり方や考えが強く、社員は会社について行くことに慣れると、トップダウン的な社風になり、最悪のケースでは、社員は会社に対して意見したり、主張したりすることをしなくなります。会社の変革は経営者の判断に委ねられ、継続的改善はなかなか訪れず、社員数、売上高の限界に達します。しかし、そのトップダウン経営が上手く浸透すれば、その経営者が生きている間は繁栄します。つまり、トップが鍵を握っているわけです。
ボトムアップは逆で、企業風土に主体性が根付きます。なぜ仕事をするのか、お客さんに喜んでもらうためにはどうするか、自分の取り分を増やすにはどうするか、など、やりがいと仕事の意味が、個人レベルで理解されます。その結果、個人の士気が上がり、個人の集合である会社はよりよい製品・サービスを社会に提供できるようになります。そして、その精神が社員から社員へ伝えられ、会社や仕事に対するやり方、考え方が遺伝子として時を越えて継承されます。
言い換えれば、個人の可能性を信じるボトムアップというわけです。
僕個人のことを話せば、新卒から入社した会社を29歳のときに退職したわけですが、このときの理由はこうでした。
自分の未知なる能力を開発すること。つまり、それまでやって来なかった、経営や営業、財務や人事などの会社の成り立ち、本質を知り、勉強したかったということ。それにチャレンジするためにはすでに出来上がっている会社組織を離脱し自らをピン（独り）と捉えて再スタートする必要があった、ということです。
今思えば、自分の自由にやりたい仕事をやりたいようにしたい、ということでした。自分の頭で考えたことを自分の足で稼ぐことが出来れば、さらに人生の自信につながると考えたわけです。この主体性が未来を切り開く手段になる、ということです。
主体性 ： 自分の意志・判断で行動しようとする態度。
PDCAとは、戦後、日本の製造業の品質と生産性の向上を牽引したウォルター・シューハート、エドワード・デミングによって提唱された、業務における基本サイクルです。
これは、分野を問わず、日々の業務や品質管理の基礎として、広く知られている管理手法です。
次の４つの頭文字を取って「ピーデーシーエー」と読みます。
1. Plan （計画） これからどのように仕事を進めるか計画を立てます。
2. Do （実行） 計画に従って仕事をします。
3. Check（評価・確認）計画に対する進捗や成果を評価します。
4. Act （改善・処置） 計画/実行/評価の結果を分析し改善させます。
これは、より効果的な仕事の進め方を具体的に教えてくれます。P（計画）から順番に作業を進めて最後のA（改善）まで完了したら、次のPDCAにつなげます。P→D→C→A→P→D→C→A→P...この繰り返しを螺旋（スパイラル）を描くように、輪を広げていきます。まさに品質マネジメントシステムで要求される継続的改善の具体例です。
このPDCAは実は、全ての物事の根底に位置する考え方と言っても過言ではありません。
TODOリストは作業管理のためのツールですが、TODOリスト作成がP、実行でD、TODOの取消線でC、反省して改善がA。このPDCAサイクルを短くすれば、簡潔なTODOリストの効率的な消化が可能となり、その繰り返しが生産性向上につながります。
子育ては、妻との話し合いがP、子供への教育がD、子供の成長を確認してC、次の子作りがA。（子供の場合はこんなに理想的には進みませんが）
人生における成功への道は、目標を持つことがP、行動することがD、達成したかどうか判断するC、次の挑戦がA。これを繰り返せば必ず成功できます。（よし明日からやろう！）
トレーサビリティを実現させるために、構成管理が重要なポジションに位置しています。
構成管理とは、ソフトウェアの場合、最終製品（システム・プログラム）を構成しているソースファイル、設定ファイル、文書などの構成要素のひとつひとつの設計・開発の「過程」を管理することです。
具体的には、作成日、作成者、更新日、更新者、バージョン、など改版履歴を管理したり、上位文書（インプット）と下位文書（アウトプット）、およびレビューの記録や問題管理との対応付けを明確にしたりすることが要求されていると解釈します。
考えてみると、問題発生から原因を「追う」ときに必要になる情報は、ひとつひとつの構成要素の作成（変更）情報であるWho（誰が）、When（いつ）、Where（どこで）、What（何を）、Why（どうして）、How（どのように）という、いわゆる5W1Hの情報に集約できるのではないでしょうか。
これらが管理されていればトレーサビリティを実現できると、現時点では結論付けておきます。
一般的にソフトウェアは開発規模の拡大に伴って、開発工数が指数関数的に増大すると言われています。（情報処理技術者試験にありました）なぜかというと開発すべき機能が拡大すると、次のようなことが必要になるからです。
よく機能数、画面数が２倍なので、工数も２倍と思いがちですが、それは危険ですね。
しかし、システムを使われるお客さんに視点を移すと、機能数と工数は比例するという思いが定着していると思います。家を建てるときに建坪を倍にしたからと言って、値段が跳ね上がることはないのと同じです。
むずかしい問題です。
低価格化と短納期化が進むなか、要求事項の多様化と技術革新の早さ、品質と生産性の問題、求められる信頼性・可用性・保守性、我々の抱える課題は数多く横たわっています。
もちろん、工数を抑える工夫は、設計段階に織り込んでいきますし、経験的に培われたノウハウは類似システムで活用されます。
考えなければいけないことは多いのですが、問題は、忙しさが指数関数的に増大するのではという「不安」に身をゆだねるのではなく、楽観的に考えて、仕事を「楽しむ」という方向でやっていけばよいかと思うのです。
ピノキオの良心であるコオロギのジミニーをご存知でしょうか？
ディズニーアニメの話です。ジミニーは紆余曲折のピノキオを木彫りの人形から本当の人間の子供へと変身させます。
僕はこの歳になって初めて「ピノキオ」をまともに観ました。人間のエゴの醜さ、良心の大切さ、謙虚さと誠実さがテーマですが、このジミニーの役どころは、人を育てることを教えてくれます。
人に仕事を頼んだり、任せたりすることは、ある意味むずかしいことです。
それは、自分より経験、能力の低い人間に教える時間があったら、自分でやったほうが早いと思えてしまうことに起因します。
任せてミスされたり、何度も教えたり、自分のやり方を教え込むのは大変だ、と考えることが多いのです。
しかし、ジミニーはピノキオの良心を育て、彼を信じています。言い換えれば、上司は部下のやる気を育て、信じてみるということです。
信じて任せて、失敗も寛大に受け止める、ということが大切なのではないでしょうか。いつか返してくれる、と。
僕の原点です。
昨日、５ヶ月ほど続いたプロジェクトの終焉を向かえて、ほっとした気持ちで関係者で打ち上げを行いました。お疲れ様でした。
写真を載せられないのが残念です。ついつい飲んでしまって撮るのを忘れてしまいました。
ということで、プロジェクトの打ち上げについて。
打ち上げは大事ですね。関係メンバーの労いはもちろんのこと、みんなの本音が聞けます。
たとえば、あのときのお客さんとの打ち合わせは大変だったとか、スケジュールがきつかったとか、あのドキュメントの作成に苦労したとか、自分とは違った見方、感じ方を知ることができます。
プロジェクト進行の良し悪しや設計・実装の良し悪し、いろいろな反省、改善のヒントが隠されています。
今回のプロジェクトはそんなにひどくなかったと思っていますが、火の車のようなプロジェクトもいずれは終焉を迎えます。そういう「終わり」に成功体験として、みんなで一息入れられるのは幸せなことです。
トレーサビリティ（追跡性）とは、ISO9001:2000の解釈から言うと、出荷した製品に品質問題が発覚したときに、その原因を追究できることを保証する仕組みです。
ちなみにISO9001:2000とは2000年にISO9001品質マネジメントシステム要求事項（国際規格）が改定されたものを指します。2000年版とも言われているようです。
ソフトウェア品質の世界でトレーサビリティを実現するには、どうすれば効果的で簡便かを考えたいと思います。
まず、納めたシステムがお客様サイドで運用中にバグが発覚したと仮定し、その原因を追究する流れを考えたいと思います。
これぐらいが頭に浮かびますが、重要なのは問題発生から原因特定までの過程で、経験と勘で警察犬が鼻を利かせて犯人を追うような行動に、どうやって客観性を持たせるかだと思います。
（つづく）