美食を極めるには不味いものを食べるべし

美食の王様 ―究極の167店 珠玉の180皿　という本をご存じだろうか。この本の著者、来栖けい氏は若干26歳。なんと、この本のファンサイトまである。

自分が来栖けい氏を知ったのは、フジテレビ日曜PM10時からやっている週間人物ライブ『スタ☆メン』で取り上げられていたからだ。

ちょうど、グルメ評論家の山本益博氏が来栖氏の本を「読み終わっていやな感じがしない、店や料理をけなすようなことがひとことも書いていないのに、圧倒的な情報量で説得力があり、その店に行ってみたくなる」と語っていたところだった。

来栖氏は、こどものころ親に一流の料理店に連れて行かれたことが多くあったとのこと。小さいころから一流の料理人が作った料理を口にする機会があったということだ。しかし、他のグルメ評論家とは違って風貌はお世辞にもオシャレとはいえず、パーカーは高校生のときに買ったものを今でも着ているのだという。大衆店も一流店もその格好で入っていく。（でも、メガネだけにはこだわっているみたい）

カメラは来栖氏の一日の行動を追っているのだが、何しろたくさん食べる。一つに店に入って看板メニューや気になる料理を注文しまくって、テーブルいっぱいに並べる。おそらく４～６人前くらいはあると思う。これらの料理を来栖氏はすべて平らげる。『スタ☆メン』では来栖氏の朝と夜の体重差を計っていて、夜6Kgも体重が増えていた。

でも、彼はほっそりした体型なのだ。ようするに、あまり栄養を消化吸収しない体質なのだと思う。よく、大食いコンテストで優勝する人の中に痩せている人がいるが、これらの人たちに共通するのは食べても食べてもなかなか栄養を吸収できないらしい。

ただ、来栖氏の場合、そのような体質でありながら舌が肥えているという点が他の人たちとは違う。来栖氏は食べても栄養を吸収しないという特徴を活かして、一日に何件ものレストランをまわり食べまくる。そして、3ヶ月たっても記憶に残っている料理のことについて本に書くという。

来栖けい氏のことを今回ブログに取り上げたのには理由がある。ひとつは、「グルメ評論家のプロフェッショナルになるには、最高の料理をたくさん食べて、感銘を受ける経験が必要」また「美食を極めるには不味いものを食べるべし」という彼の発言に、組込みソフトエンジニアを極めるためのアプローチと共通するものを感じたからだ。

来栖氏は「不味いものを食べたときに後悔しないですか？」というインタビュアーの質問に「いや、不味いものも食べないと、おいしいもののすばらしさがわからなくなる」と答えていた。

これと同じことを、先日、娘のピアノの発表会で感じた。娘二人が通っている音楽教室は、個人の教室でありながらピアノだけではなく、バイオリンやマリンバ、サックス、ドラムなどいろいろな楽器を教えている。

発表会は一日2回、4時間ずつに分けて演奏が続く。今回は自分の娘の演奏だけでなく他の子供達の演奏と講師の先生の演奏合わせて4時間びっちり聴いた。

そこで感じたのは、印象に残るのは「こんなに小さいのに上手に弾くなあ」という感覚で、演奏会の最後に披露される講師の先生達の演奏は、子供達よりも遙かにうまいにもかかわらず記憶に残らないという事実だ。

子供達の演奏でも言っちゃ悪いがかわいそうに思えるくらいひどいものもある。特にバイオリンの初心者の演奏はそうだ。ピアノやマリンバやドラムは叩けば、一応意図した音が出るが、バイオリンは意図した音階の音を出すこと自体が難しいので、初心者の演奏は聴くに堪えないようなものもある。

しかし、その段階を抜け出して完璧ではないものの80%～90%きちんと演奏できると、「ああ、すごい。この子はよく練習している、上手だなあ」と感じるのだ。

講師の先生達の演奏は、うまいのが当然なのではっきりいって何の感動もない。

でも、そういう風にしか受け取れないのは、たぶん自分の耳が肥えていないからなんだと思う。もっともっとセミプロや本当の一流の演奏を聞き込んでいけば、演奏のテクニックや表現力の違いを感じ取ることができるのだろう。音響設備も iPODだけでなく、性能のより高いアンプ、スピーカがあった方がいいし、コンサートで生の演奏を聴くことも必要だろう。

組込みソフト開発の世界も料理や音楽の世界と同じだと思う。ソフトウェアは要求された目的を達成するための方法はひとつではなく、無限に存在する。そして、アーキテクチャやモデル、コードが美しければ、品質が高くなり、顧客満足を高めることができる。

アーキテクチャやモデル、コードが美しいかどうかを見極めるためには、もちろん美しいアーキテクチャ、モデル、コードを見ることも大事だが、見るに堪えないコードやモデル、アーキテクチャも見ておかなければいけない。

見るに堪えないコード、モデル、アーキテクチャを見ることで、美しいコード、モデル、アーキテクチャがを書くためにはさまざまな知識やスキルが必要だということがわかる。

だから、ひどいコード、モデル、アーキテクチャを見つけたら感謝をしないといけない。教科書に載っているようなコード、モデル、アーキテクチャばかり見ていると、当たり前のように自分も美しい成果物を作れるような錯覚を起こしてしまいがちだが、実は自分たちもプロフェッショナルの作品とは言い難いものを平気でリリースしてしまっていることの方が多いのである。

人の作品と自分の作品を見比べて、反省したり、ほっとしたり、自信を持ったりする経験をたくさん積むことが大事なのだ。

なるほど、これが海外人材登用の新しいかたちなんだ

先日、渋谷のパソナテックのオフィスでパソナテック 海外事業部 部長の小平達也氏にオフショア開発（海外に開発を委託すること）についてお話を聞く機会があった。

小平氏との話にいくまえに軽く渋谷の複雑性について書いておく。

渋谷はいつ行ってもわかりにくい。パソナテックのオフィスは渋谷のマークシティウェストにある。渋谷マークシティは渋谷駅に直結しているのでJR渋谷駅の改札を出てからすぐにたどり着くかと思うとそうではない。渋谷マークシティに直結しているのは京王電鉄の渋谷駅の方だ。

だから、最短の行き方はJR渋谷駅の改札を出るときに京王への乗り換えの方（ホームから階段を上に上がる）へ行き、京王の改札を目指す。途中マークシティの表示があるのでその表示に従い京王電鉄の改札まで行ってしまうと行き過ぎとなる。改札まで到達する前にマークシティの4階に上がらないといけない。

4階に上がらないと改札を通り越してマークシティウェストまでたどり着けないのだ。4階に上がるとレストラン街が広がっており、オシャレなレストランがたくさん並んでいる。このレストラン街をどんどん進んでいくと、トンカツ屋があるのでそのトンカツ屋の手前のエスカレータを使って5階に上がり、5階のエレベータホールから17階に上がるとパソナテックの渋谷オフィスに到達する。

パソナテックのWEBサイトから案内図をダウンロードしておいてよかった。渋谷に近いからといって案内なしにたどり着けないのが渋谷の特徴だ。

パソナテックのオフィスは白が基調で赤がポイントカラーとして使われており、日本の会社らしからぬかっこいいオフィスだった。

さて、小平達也氏は海外事業部の部長で、パソナテックコンサルティング（大連）有限公司 の董事を兼任されている。中国でのエンジニア事情に詳しい方で、@it にも数多く投稿されている有名人だ。

個人的には『アジア技術者が採点する日本技術者の実力（1）中国編』の記事を興味深く読ませてもらった。

小平氏にうかがったお話の中で、強く印象に残ったのは、パソナテックの「理工系人材・グローバル採用支援サービス」の話だ。

「日本は中国の技術者の人件費の安さだけに着目して開発の一部を中国に移し、そう簡単にはいかないことが分かって撤退し、やっぱり国内では人材が確保しきれないのでまた進出するという“行ったり来たり”を繰り返している」という話をしたところ、パソナテック海外事業部の戦略は違うというのだ。

中国で優秀かつ日本語ができるエンジニアの卵（優秀な大学を卒業したポテンシャルの高い人材）の中から、さらにクライアントの要求に近い人材を抽出し、これらの人材を日本の企業に派遣する。そして派遣先の企業でドメインに特化した技術・知識を学ばせ、将来幹部候補になりそうな人材にまで成長する見通しが立ったところで、その企業に正社員として登用するというサービスを提供しており、これが非常に評判がよいとのこと。

この話を聞いて真っ先に思ったのは、その高い教育を受けた中国人の人材が自分の獲得したスキルを活かして他社に転職してしまう危険性はないのかという点だ。

これについて小平氏は「中国の大学を卒業して、欧米の企業で1年契約の更新を続け、人がどんどん流動している様子を見ていれば、当然自分も条件のいいところに移りたいと思いますよ。」「でも、大学を卒業して真っ白は状態から、長期雇用の日本の企業文化にふれさせて、幹部候補にもなれる期待をかけてあげれば、他社に転職されてしまう危険性はほとんどないんです。」と語った。

そして、日本の企業はその人材が本当に自分の組織に適しているかどうかを見極めるまでは、正社員として登用しないので、雇用のリスクを最低限に抑えることができる。

もちろん、日本の学生を採用する際に支払う給与よりは高い派遣費用がかかるが、そもそも人口の多い中国から厳選して厳選して人材を見つけてきているだけに、いい人材が見つかる確率が高いのだそうだ。

中国を含めた東南アジアのマーケットに進出するつもりがなく、日本発でプロダクトアウトしていく企業が中国の技術者の人件費の安さだけを求めてオフショア開発を進めるとうまくいかないという点については自分も小平氏も意見は同じだ。

日本の組込みソフトとオフショア開発については、技術評論社の組込みプレス vol.4 （2006年8月発行予定）に SESSAME Workshop 2006 の続きの座談会ということで記事が載るので、そちらも参照していただきたい。

また、日本のエンジニアは長期雇用の前提があるため井の中の蛙になりがちで、外国人のインターンを組織的に受け入れて、プロジェクトに配置することで、日本人の技術者達に刺激を与えることができるという話もあった。

日本の技術者には技術を磨き続けなければ生き残れないというプレッシャーも与えないといけない。

世界は広いということを認識しなければ・・・

権限もいらないから責任も取らないってあり？

責任者が誰だか分からないという ソフトウェアプロジェクトを見たことがある。実際にはマネージャ的な存在の人物はいるのだが、どうもだれも自分が責任者だと認識したくないらしい。

組込みソフトの世界で、技術者として長年やってきてベテランといわれるようになったものの、管理職としてプロジェクトマネージャになるのは嫌だというケースは昔もあった。自分は一生技術者でやっていきたい、管理職にはなりたくないという人の気持ちはわかる。

組込みスキル標準 2006年板 キャリア標準 Version 1.0（IPA ソフトウェア・エンジニアリング・センター）によると－組込みソフトウェアエンジニアの職種分類－は以下のようなものがあるという。

・プロダクトマネージャ（開発製品の要求仕様策定と統括管理）
・プロジェクトマネージャ（プロジェクトのマネージメント）
・ドメインスペシャリスト（専門的な知識、技術、経験でプロジェクトを支援）
・システムアーキテクト（アーキテクチャ：構造を設計する）
・ソフトウェアエンジニア（ベーシックなプログラマ）
・ブリッジSE（分散開発における橋渡し）
・開発環境エンジニア（プロジェクトで使用するツール・設備を構築、運用する）
・開発プロセス改善スペシャリスト（開発プロセスを調査し改善を推進する）
・ＱＡスペシャリスト（成果物の品質を保証する）
・テストエンジニア（テストのスペシャリスト）

この職種分類が実現するなら、技術者→管理職というキャリアパス以外にいろいろな選択肢が出てくるのだろう。でも、今現在、ほとんどの組織ではまだ、技術者で何年もやってきてベテランといわれるようになるとプロジェクトマネージャになるという流れが多いと思う。

でも、同じ製品に携わったことでドメインの知識はあるが技術力がないという状態で、プロジェクトマネージャはやりたくない、技術もないけど管理職もイヤというのはないだろう。

このパターンで最悪なのは、何か問題が起こると技術を持っている協力会社に問題の解決を押しつけて、再発防止にはちっとも乗り出さないというケースだ。「しょうがないよ。誰も悪くないんだ。」「緊急事態だから、ここはなんとか頼むよ。」といいつつ、明らかに協力会社のアウトプットしたものに誤りがあった場合は「次からは気をつけてくれよ。」という態度にでる。

ようするに発注者の立場を利用して外注いじめをするようなタイプだ。

以前、英語でしゃべらナイトにカルロス・ゴーン氏がゲストで出演していたとき、一番大事な英単語は何かと聞かれて“commit”と答えていた。commitment の意味は、必ず果たすと約束 と理解している。

カルロス・ゴーン氏は社員に「あなたが必ず果たす約束は何か？」と聞くわけだ。責任と権限が曖昧な日本では、この質問をされると躊躇する者もいるだろう。

組織の中で commit する＝必ず果たすべき約束をする ということは、技術者なら大抵は現状で足らないスキルを獲得するというオプションが付いてくるだろう。足らないスキルを獲得する努力なしに、組織と約束したことを実現することはできないはずだ。だから、commit するのに躊躇するエンジニアは足らないスキルを獲得できる見通しが立っていない、もしくは、最初から無理だとあきらめているのだと思う。

でもソフトウェアの品質を高めて顧客満足の高い商品を作りたいのなら、足らないスキルを何とかして獲得しなければいけない。

また、責任と権限という観点で考えれば、自分たちでルールを決めてそれを守るという習慣を付けなければ何事もうまくいかない。

ツールに任せるのにも限界がある。人間はもともと過ちを犯しやすく、技術者が毎日毎日作り込んでできあがるソフトウェアの品質を高めるには、自戒的アプローチは必須である。プロジェクトメンバーは多種多様であり、メンバー全員にルールを守ってもらうためには、メンバー一人一人の責任と権限を明確にしておく必要がある。

プロジェクトメンバー全員が「あたたかい人間関係の中のやさしい一員」という認識のもと、困ったことがあったら誰がということもなくみんなが自己犠牲を払いながら問題を解決していくというアプローチは非常に日本的であり、これでうまくいくのならそれもいいように思う。

しかし、この考え方はともすれば、自らを律してスキルアップすることからエスケープしたり、責任回避の結果、ユーザーにしわ寄せがくる可能性がある。誰も責任を取らずにユーザーが不利益を被るようだと、その組織の存続は危うい。

「あたたかい人間関係の中のやさしい一員」という考え方だけでものづくりができる時代はとっくの昔に終わっている。「創造性と個性にあふれた強い個人」と「あたたかい人間関係の中のやさしい一員」のバランスを取る必要があるのだ。

だから、権限もいらないから責任も取らないという選択肢はない。そんなあまあまな体質のプロジェクトで顧客満足の高いプロダクトができるはずがない。

後5年もすれば、組込みスキル標準「ETSS」で当たり前のように技術者のスキルが診断されるようになり、プロダクトマネージャやプロジェクトマネージャの素養のない者は、責任や権限から解放されるかもしれない。

でも、管理職から解放された技術者は他人よりも優れた技術を持って、スペシャリストとしてやっていけなければ、どんなにベテランでもプロジェクトの中でやることがなくなってしまう。

ベテランの技術者は自分の技術の優れている点が何かをもう一度チェックし、特に優位な技術がないのであれば責任と権限を意識して、プロジェクトマネージャとして組織から信頼を得られるようにしなければいけない。

これって厳しすぎ？