ER（緊急究明室）

現在、ソフトウェアエンジニアの世界では多種多様な技術があるにも関わらず、まだまだ従来の方法でシステム開発を行っており、新しい技術にて開発ができる人、推進できる人が少なく、IT業界として危機的状況になりつつあります。もちろん、そういう状況であることは認識していても、実際にはどのように行動したらよいのかが分らず、問題を先延ばしにしているのが現状ともいえます。

私が在籍している株式会社豆蔵は、将来のIT業界を担うエンジニアを育成すべく、コンサルティングを行っている会社です。会社設立以来、オリジナルのコンテンツと豊富な経験を基に、人材育成について積極的に取組んできました。

一般的に人材の育っていく過程にはいくつかの段階が存在します。まず初めに集合教育による基礎研修（ビジネス研修やIT研修を含む）、次にOJT、そして現場での経験による成長です。そして、人材育成で最もクローズアップされ問題視されるのが基礎教育です。これについては、どの組織においてもほぼ同じだと思います。人材開発部の基礎教育でしっかり教育してくれていれば、「OJTがうまくいくのに」、「即戦力として実践で活躍できるのに」という声を聞くことがよくあります（人材開発部は経営者と現場との板ばさみになって困窮しているハズです）。

しかし、問題は本当に基礎教育でしょうか？

豆蔵では、こう考えます。人材育成には、「基礎教育」「OJT」「現場」の3つの視点で見る必要があり、それらが適切に実施されて相乗効果により即戦力が養われます。つまり、現在の人材育成の問題は「基礎教育」「OJT」「現場」に潜んでいるのです。

実際にどんな問題があり、どうすれば解決できるのでしょうか。

株式会社豆蔵では、そんな人材開発の課題を考え、将来のIT業界を担うエンジニアを育成するべく、その取り掛かりとなる問題解決のヒントを無料セミナー（2007年11月27日（火）14:30～17:30開催）でお話できればと考えております。是非、時間を割ける方は私たちと一緒に考えてみませんか？

私たちで、将来のIT業界を担う「世界に誇れるエンジニア」を育てる環境を作っていきたいですね。

会社でメールマガジン作ってみました。

この度、普段からお世話になっているお客様に有用な情報を提供すべく、メールマガジンを作ってみました。「豆蔵瓦版・豆尽(マメジン)」。
企画から創刊号送信まで約2ヶ月。いろんな問題にぶつかりながら先日やっと創刊号を送信することが出来ました。このメルマガは、セミナーやイベント、お得情報のお知らせはもちろんですが、読んでて楽しくて笑えるトピックがあり、お客様が毎号を楽しみにしてくれるような内容にすることが（最も）重要な要素でした。
メルマガのレイアウト自体はすぐ決まるのですが、初めは全て基礎となるものが無かったために、各トピックが具体的な形になるまで随分時間がかかりました。けれども、みんなでああだこうだ言いながら冗談を交えながら楽しく企画し、なんとか形にすることができました。結果、お客様にとっても楽しいメルマガになったと信じています(笑)。でも、それって重要だと思いませんか。どんなことでも、仕事をしている人達が楽しくないとお客様もハッピーにならないと思います。単純ですが、すごく疎かにされがちな事でもあります！

あとは、このメルマガ、もっとお客様に喜んでもらえる企画を増やして規模拡大して行きたいと考えています。

まだこのメルマガは過去に弊社のサービスを受けたお客様にしか提供していません。が、ゆくゆくは誰でもHPから登録できるようにしていきたいと考えています。

今年はこれをテーマにします。「自分がハッピー、お客様もハッピー」

最近のシステム開発は反復型の開発を行うことが多くなっています。

特に今のシステム開発には様々なリスクが多いため、単純なウォーターフォール型のシステム開発ではリスクに対応できなくなっているからです。様々な技術が乱立する現在において、選択した技術が問題なく動作する保障はありませんし、顧客の要求もシステム開発の初期段階において完全に固まっていることは少なく、仕様が開発中に変更されたり追加されることは当たり前です。その様な環境で初めから完璧なシステム構造を作るのは困難です。ですので、反復して最適な構造を考える必要があります。

しかし、現場で設計を担当している方のほとんどは、反復によってシステムの構造が洗練されていくイメージを持つことが難しく、たとえ決まっていない仕様であっても、構造を一回で確定しないとなかなか納得がいかないようです。そしてシステムの構造全てを俯瞰し、納得したいようです。もちろん巨大で複雑なシステムの全てを一人で完璧に理解することができるようにも思えませんが、安心ができないようです。

最近仕事をしたお客様から話を聞いてみると、いくつか原因が見えてきました。まず、システム開発は様々な役割を持ったメンバで構成されているという意識がないようです。そしてシステム構造を構築する際に契約による設計を行うという意識がないようです。システムを役割で分割し、それらの関係を疎にして、契約を設定して分業するという考えです。問題領域の切り離しというイメージがついていないわけです。

今の日本の開発は同じ人が上流工程（要求分析）から下流工程（実装）まで実施するスタイルを取る事がおおいです。ですので、上流で下流を意識してしまい、分析で設計もしてしまいます。そうすると、本来、分析や設計でやるべき事があいまいになって、間違ったシステム開発へ繋がってしまいます。そしてシステムの構成要素間の依存度が非常に高いシステムになってしまい、問題を切り離せなくなり、全体を把握しないとメンテナンスできないことになるようです。それが当たり前になっているのですね。

そんな問題に対して気づきを得てもらうのが私たちの仕事です。もう少し解りやすく、そしてメリットが理解しやすい形で反復型の開発を体験学習できるセミナーを作ってみたいと思う今日この頃です。

久しぶりにGoogleEarthをいじっていたところ、偶然にも交通事故を見つけてしまいました。まさにぶつかった瞬間です。
正確に言うと、昨年の8月にインストールして遊んでいたときに見つけてマークしておいたものを再発見したのですが。
ネットにはGoogleEarthで見つけた不思議な地上絵や、軍施設、遺跡などを発見したという情報があり、見てみると結構おもしろいものです。それ以外にも海外旅行で行きたい場所などをみると、想像が膨らんで楽しいものです。いろんな人がこの映像を見ているんだな？と考えたとき、またもや昨年想像した記憶がよみがえってきました。
「これだけ空から見られるのであれば、ビルの屋上を広告スペースとして使えるな」
忘れていたことよりも、半年経っても同じ思考を辿る自分が情けない。

最近は引越ししたこともあり、「Googleローカル」で遊んでます。

自宅の周辺情報が地図付きでいろいろ検索できます。出張先の周辺情報検索にもいいかも知れません。これから重宝しそうな機能です。

「Googleサジェスト」も使いはじめました。

検索キーワードを入力すると入力途中で候補が出てきます。でも悲しいのは、クセで最後までキーワードを打ち込んでしまう自分。もしくは出てきた候補に興味を奪われ、本来検索したかったことを忘れそうになる自分。なかなか効力発揮しません。でも、うる覚えキーワードの検索にはいいですね。

動物園でビジネスの勉強ができたという話。

ちょっと前の話ですが、あさひやま動物園に行ってきました。久々の動物園でしたのでワクワク、遠足気分です。というのは冗談で、以前から気になっていた、「閑古鳥が鳴いていた動物園から人気動物園への躍進」をこの目で見るという目的です（ということに）。

場所は北海道旭川市。JR旭川駅からバスで40分程度です。いやぁ、遠いです。

園の周りは駐車場で、冬季は駐車料金がタダ。園内に入るとあさひやまというだけあって、斜面に作られた動物園でした。階段やスロープがありましたが、歩き難い事は無かったように思います。

一番先に入ったのは「ペンギン館」。入り口には係員がいて、雪が降っている事もあり、足元を掃いては「お気をつけください。来園ありがとうございます。こちらになっております。」と丁寧に対応してくれます（全ての館においてそうでした）。中に入るとまさに驚愕！ガラスのトンネルが続いており、その周りをペンギンが鳥のように泳いでいました。予想外の演出です。今まで見た事の無いアングル、それも自分がペンギンでは？と感じるような視点で見れ（人間の存在する空間と動物のいる空間を共存させる演出です）、「これなら、集客できる！」と即納得しました。水槽などはお金がかかっていると思いますが、一転、案内、説明文などはイラスト付きで、飼育係が手書きで書いていました。動物の説明も、ありきたりの説明ではなく、飼育係でしかわからない視点でおもしろおかしく書かれているのです。

お金をかけるところはお金をかけ、そうでないところは費用を抑えてアイデアでカバーする。それに、形の無い顧客の要望を絶妙な形で実現した（「あなたの望むものはこういうものですよね？」という提示）という手本といってもいいかも知れません。まさに見本のようなビジネスのやり方だと思いました。わたしの仕事でも考えなければいけないと痛感です。

行ったことが無い人は一度、「研修」と銘打って行ってみてください。

午後３時にはペンギンが檻から出て、園内を散歩するんです。

明けましておめでとうございます。今日から仕事初めです。皆さんはもっと早いかもしれませんね。

今日会社に来たら、机の上にDHLのメール便がアメリカから届いていました。中を開けてみると、OFFICE12ベータ１が入っていました。待ちに待っていたのでさっそくインストール。GUIも変わったし、XML対応になりました。

今日はOFFICE12のなかのPowerPoint12について書いてみます。

今回のOFFICE製品はXML対応になっており、アプリケーション自体をカスタマイズできたりといろんな変更がありました。しかし、そういうことよりまず使い勝手ということで、ちょっと使ってみました。

一言で言うと、今までMicrosoftが蓄えてきたツールのノウハウが凝縮されているという幹事です。どういうことかというと、コンテキストメニューが非常に充実しています。何かをやりたい時には対象を選択して右クリックすれば大抵のことができてしまう。非常に感覚的に使用しやすいツールとなっています。

それ以外では、IGX Graphicというもの。

パワポで図を書くときに、IGXを使えば一度書いた図を違う見せ方に一発変換できるというものです。「見せたい物は決まっているが見せ方は決まっていない」ときに非常に有効です。

例えばこんな感じ。

これは、PowerPoint12の画面です。一見、従来と変わりませんが、メニューボタン周りを見れば違いが分かると思います。

例えばこのスライドに矩形を書いてみます。その矩形を変えたい時は右クリックしてメニューを出すと簡単に変更できます。

つぎに、矩形をいくつか書いて、テキストデータを埋め込みます。ここまでは従来と変わりません。

例えばここで、データの見せ方が決まっていなかったとすると、この3つの描画オブジェクトを選択して右クリックし、convert to IGX graphicを選択すると、IGXに変換されます。

あとは、図の見せ方を変えたい場合は、図を選択してメニューからレLayoutを選択すると、以下のような見せ方の候補が出てきます。

希望のレイアウトを選択すると、図を一発変換することができます。

これは、従来の描画オブジェクトと違って、データと見せ方を別々にXMLデータとして管理することで、実現されています。

これで画面レイアウトの苦手な方でも、そこそこのプレゼン資料ができますね。これからレイアウトも充実して行くとさらに嬉しい機能です。

それにしても、マイクロソフトはコンテキストメニューをうまく使いますね。直感的にある程度使えてしまうところがニクイです（もちろん、マイクロソフト製品に慣れ親しんでいることも一要因ですが）。

世の中には様々なツールがあります。しかし、直感的に使用できるツールは意外と少ないものです。また、こういう使い勝手に関しては、使い勝手を犠牲にして早くリリースしたり、コストダウンさせたりすることがしやすい部分でもあります。でも、実はそういう考えは間違っています。特にパッケージソフトは。。。使いやすいことがツールの普及に大きく影響するのです。いくらいろんな機能があっても、使い勝手が悪ければ広まらないのです。できるだけ操作性はシンプルで使いやすく利用者にストレスのかからない構造にすることがツールが成功するかどうかに非常に大きな影響を及ぼしていることをツールベンダは認識すべきです。

さて、OFFICE12の他のツールはどんな感じでしょうか？これから実際に使ってみることにします。

ある会社の社長が株主総会で泣いていました。自分は株主の事を考えていたのに株主はそうは考えていなかったからとのこと。

テレビニュースで見ている分には人事ですが、自分の業務に当てはめてみるとそうと言えなくなってきます。エンジニアと言えど、結果を出すには最終的に顧客満足であるかが問題になってしまうのが現状です（コンサルタントならなおさら）。全ては顧客満足に繋がっているかが重要です。もし繋がっていないならそれは自己満足でしかないという悲しい状況なのです。

顧客満足に繋げるには顧客視点になることですが、顧客視点は想像だけでは得られるものではありません。もちろん先人の経験等を基にそれらしい事はできるかもしれませんが、限度もあるでしょう。顧客視点になるにはやはり顧客と同じ立場に立つしかないでしょうが、転職するわけにも行きません（中にはそう考えて転職する人もいるだろうが、なかなかできるものでもない）。

そう考えると、顧客視点に立つにはどうするのが一番良いのでしょうか？

むずかしい。非常に難しいですが、やはり顧客と直接会って話をしないと駄目だとおもいます。そのときに、対顧客となってはいけません。そうではなく、顧客の組織、立場、背景などを理解し、なりきることが重要。要は自分が自分の顧客になり自分を見つめること。

そう考えて今の自分の業務を見てみると、まだまだですね。自分の得意分野に誘導してしまう事もしばしば。真の意味で顧客視点に立つにはまだまだ修行が足りません。

そんなことを考えた仕事納めの一日です。

以前にマイクロソフトのPDCに関するブログ（http://blogs.itmedia.co.jp/ryusystem/）を書きました。PDCでは残念ながら体は一つなので同時並行のセッションは当然の事ながら観ることはかないません。泣く泣く、観るのを諦めざるを得ない状況になります。しかも全体で数百のセッションがある事を考えると、見れるのはほんの一部に過ぎないのです。

しかし、観れなかったセッションを観る方法があります。それが、Post Conference DVDです。セッションの映像を纏めたDVDですが、これがPDC参加者に後日配られます。いつ配られるかは不明。1ヶ月か、2ヶ月か。今回のDVDはなかなか到着しませんでしたが、3ヶ月後に届きました。昨日、机の上にあるじゃないですか。これで観れなかったセッションを見る事ができます。しかし、DVD観るのも多すぎて大変。どれから観ようか思案中です。

このようなDVDは非常にありがたいですね。聞き逃したものや観れなかったものが観れます。参加者としては非常に嬉しいです。しかし、この話は前フリ。

実はこのDVDに感化されたわけでは無いですが（いや確実に感化されていますが）、私も会社でやっている技術者教育ビジネスの中でCDを使って参加できなかった人に・・・という試みをしてみようかと企画中。いえ、妄想中です。もしかしたらここから違うアイデアが生まれてくるかもと微かな予感がしているのであります。

ちょっとした事がヒントになって良いアイデアが生まれるのですが、そのヒントをなかなか感じられないのが悔しいですね。

システム開発の現場でUMLが必要であるという事は色んな人が言っていますし、色んな書籍で言われています。最近ではシステム開発においてUMLが浸透してきており、多くの利用実績があります。しかし、実際はプログラミング前の設計についてのみ適用していることがほとんどで、それ以外の場面で利用されている事は稀です。システム開発のライフサイクルには、ビジネスの分析からソフトウェアシステムの分析、設計、実装まで様々なワークフローがありますがそれら全てに一貫してUMLを適用している例は皆無です（それが正解というわけではありませんが）。なぜなら、UMLを表記法としての利点でのみで理解、利用しているために、それだけではプロジェクトが成功するわけがないと考えているからです。ある意味これは正しいことですが、もう一歩進んで考えると、UMLの本当の利点とその効果を引き出すための「システム開発への正しい適用方法」を知っているかいないかがプロジェクトで効果を出せるか出せないかにかかっています。大抵はUMLの正しい理解が無いままUMLを妄信しすぎ、その落とし穴にはまっていくのです。

システム開発で効果的にUMLを利用するには、正しいUMLの知識を持っていなければいけません。正しいUMLの知識とは、

1. UMLの利点
2. UMLの不足点
3. UMLでできる事、できない事
4. 正しい導入方法（プロジェクトや組織として）
5. 導入時の注意点

といった内容です。これらをしっかり押さえて、正しい場所で正しく利用することが大事です。最近はそういった内容に関する案件が多くなってきています。

UMLに対して、What（なに）からHow（どのように）へ関心が移行してきているようですね。

最近、IT業界でよく聞く言葉があります。気になる言葉についてアンケートを取るとどのような結果になるでしょうか？でもやっぱりその言葉は上位に来るに違いありません。

その言葉は「ITアーキテクト」という言葉です。みなさんもよく聞くのではないでしょうか？私はそれをSOAと同じぐらい連呼されておりSOAと同じぐらい人によって認識が異なると感じています。

雑誌などでも、「ITアーキテクトの平均年収・平均年齢」とか見たりしますが、果たしてそのITアーキテクトとはいったい何者なのでしょうか？（私はITビジネスを考慮してシステム構築の計画・立案から設計までを責任をもって行える人と自分勝手に解釈しています）

実はITアーキテクトの確固とした定義はありません。場面によって違うものとして捉えられているようです。ですから、一言でITアーキテクトと言ってもその人材像は異なるのです。ではこのITアーキテクトの人材像を定義すればいいのでは？と思いますが、非常に難しい問題です。一部、ITSS(http://www.itssug.org/)ではITアーキテクトの必要スキルが定義されていますが、共通認識として浸透していないのが現状です。

ITアーキテクトの言葉にあるアーキテクトという言葉ですが、この言葉に対してソフトウェアエンジニアは特別の感情を持っています。ソフトウェアエンジニアにとって崇高な存在なわけです。ですので、「アーキテクトとはこういうものだ！」「アーキテクトはこういうこともできなければいけない！」という気持ちが先行し、人が定義したITアーキテクトという人物像を受け入れたがらないという風潮があるのでしょう。

しかしそれではいつまで経ってもITアーキテクトという言葉は形を持たず、意味のない単語になってしまいます。どうすれば良いのでしょう？

もしかしたら、誰もが認めるスーパーエンジニアが定義するしか無いのかもしれません（そうすればみんな納得するのかな？）。

ただ、ITアーキテクトというものに興味がわいているということは少なからず、システム構築時にロールが重要ということは認識されている証拠だと思います。ただ、そのロールがジェネラリストでは意味がないのです。なんでもできるのでは役割になりません。

さて、この「ITアーキテクト」という言葉、この先どこへ行くのでしょうか？

この「ITアーキテクト」ですが、前回の横浜で行われたTechEdでも最終日の最後のパネルディスカッションにてITアーキテクトの話が議論されましたけど、JavaOneでも話されるようです。