update it, Inc.社長のブログ

昨日、ずっと使い続けてきたPDA（CLIE）がついに壊れてしまいました。電源ボタンを押してもうんともすんとも動きません。リセットをかけても電源は入りっぱなしの状態でオープニングの画面以降に一向に進もうとしません。

今となっては非常に少数派になってしまったのですが、私はいまだにPDAをよく使っています。どうも忘れっぽいたちなので、予定はPDAに入れておいてその時間になったらアラームで呼び出すようにしておかないと不安でしょうがないのです。発売元だったSONYはPDAから撤退してしまい、Palm自身も日本では売っていないので、現在PalmOSで日本語が使えるPDAはたぶん売られていないと思います。困った。

と書いているうちに電池を使い切ったCLIEが復活しました。良かった。まだしばらくは使うぞ。

私の場合、普段机にいるときには入力はPCで行い、同期してCLIEに転送して使っています。ペン入力は遅いので、やっぱり入力はキーボードに限りますね。ペン入力はCLIEしかないときの非常入力手段です。

結構便利に使っているのがDiddleBugというアプリケーションで、手書きのメモをそのままま保存しておくことができ、かつワンタッチでアラーム設定を付けて、時間になったらメモを表示するようにすることができます。手書きのメモは入力が速いので便利です。さっと言われたことを書き留めておいて、アラーム設定しておけば、忘れっぽい私でもOKです。

CLIEは起動が早いのもありがたいです。取り出してボタンを押せばすぐに予定を確認することができます。

こんなに便利なPDAなのに、最近はあまり見なくなってしまいました。原因を考えてみると、こんなところでしょうか？

１．余計なお遊び機能がいろいろ付いたが、どれもこれも中途半端で結局使いこなせない。
２．携帯と２つ持つのがうざい。
３．ペン入力が使いづらい。
４．セキュリティー意識の高まりで会社のPCにPDAが接続できなくなり、会社の予定を持ち歩くことが難しくなった。（そもそもPDAを持ち込めないオフィスもある）

特に最近は４が顕著で、PDAはビジネスでは使えないということになると存在意義がなくなってしまいます。PDAは進化の方向を間違えたのでしょうね。もっとビジネス路線に特化して、遊びの機能はばっさり削って、セキュアに、ビジネスのスケジュールも個人のスケジュールも両方を持って歩け、入力も簡単なパーソナルオーガナイザーとして進化すればもう少し生きる道があったのではないかと思います。

システムの世界では最近すっかり市民権を得たオブジェクト指向ですが、私が最初に関わったとき(1991年頃)はまだオブジェクト指向と言えば一般にはオブジェクト指向プログラミング（Object Oriented Programing = OOP）のことを指していました。それがいつの間にやらオブジェクト指向分析(Object Oriented Analysis = OOA）やら、オブジェクト指向設計（Object Oriented Design = OOD）やら、オブジェクト指向モデリング（Object Oriented Modeling = 00M）やら、いろいろなオブジェクト指向なんたらのバリエーションが増え、それらの概念が若いシステム・エンジニアやプログラマーの間でごく当たり前のように語られているのを聞くと、いい時代になったな、としみじみ思っています。

ただし、ちゃんと中身を理解して使っているかどうか。それを応用してきちんと現場で活用できているか。そういう話になると、ちょっと怪しい人も結構多いのではないでしょうか？　そもそもオブジェクト指向ってなんなのか、その良さをきちんと他人に説明できない状態で、OOP言語を使うことがオブジェクト指向だと思い込んでいる人も多いかもしれません。

以前Javaでプロダクトを作るためには、オブジェクト指向分析やオブジェクト指向設計を「しなければならない」と思い込まれていたケースに遭遇したことがあります。新たにJavaでシステムを作るという話になったときに、それまでのやり方をすっかり換えて、すべてオブジェクト指向分析やオブジェクト指向設計（のようなもの）でやらないとオブジェクト指向でプログラムを作ることができない、というのです。

そう思い込んでいる人は、上流工程の分析・設計時にもクラスという概念がでてくるので、それがそっくりそのまま実装の世界でも同じ単位でクラスとしてコーディングされるものだと思い込んでいるんですよね。そんなことをしていたらまともに動くプログラムにはならないってことは、おそらくいっぺん経験（失敗）しないとわからないのだと思います。

確かにオブジェクト指向分析、設計、プログラミング間では親和性が少しは高いと思いますが、「でなければならない」ということでは決してないはずです。通常に業務分析をしたり、データ指向分析をして、プログラミングをオブジェクト指向プログラミングとする、というのも別に悪い話ではありません。特に上流工程に関与する中心人物がオブジェクト指向分析や設計に長けた人ではない場合には、むしろ従来の手法を導入し、プログラミングの工程にオブジェクト指向を導入したほうがプロジェクト全体としてはうまくまわると思います。

昨日、弊社のホームページを立ち上げたことを告知いたしました。見ていただいた方は気づいたと思いますが、Communityというコーナーにはプロジェクト・アンチパターンとして、UMLのアクターの形をした主人公が活躍するユースケース記述が書いてあります。

(もし就業中に見ていて、上司からとがめられた人は、ぜひ「参考となるユースケース記述を見ています」と言ってみてください。ただし結果は保証しません。)

このようなコーナーを用意したのは、決してふざけているのではなく、実際にこれに近いことがこの業界でごく普通に起きているという現実を何とかしたいと考えたからです。実際にどこでも良く起こりがちなプロジェクト・アンチパターンをみんなで共有することによって、改善していくためのきっかけぐらいにはならないか、そんなことを考えてこのコーナーを企画しました。

ですので、ぜひ皆さんにも参加していただきたいのです。皆さん自身が体験した、もしくは見聞きしたプロジェクト・アンチパターンを教えてください。プロジェクト・アンチパターンを集めることができれば、実際にそのような状況に陥りそうになったときに、これを参照することによって、場合によっては役に立つことがあるかもしれません。

みなさんからの積極的な参加をお待ちいたしております。

日経ソリューションビジネスの4月15日号の特集ページ「胎動！ IT業界維新」で、NTTデータが「年内に『セル生産方式』のパイロットプロジェクトを走らせる」という記事が載っているようです。（「ようです」と書いたのは、私自身は日経ソリューションビジネスを取っていないので、ITProに公開されている記事の抜粋を読んだだけだから、です。  :grin:）

セル生産方式とはキャノンなどが取り入れて有名になった生産方式で、Wikipediaによると、「1人、または複数人の作業者チームで製品の組み立てを行う。ライン生産方式などの、従来の生産方式と比較して作業者一人が受け持つ範囲が広く、場合によっては最初から最後まで1チームで担当する。」となっています。製造業向けの生産方式の１概念なのですが、NTTデータではそれをシステム開発の現場に適用し、「NTTデータの社員がシステム構築における上流だけではなく、中・下流のソフト開発やテストをパートナーと共同で進める」ことを意味するそうです。

「そんなことはもうやっているよ」っていう会社もあるかもしれませんが、これだけ大手のSI会社が中・下流も自分たちが主体的に絡んでやっていこう、という姿勢が現れているということはとっても良いことだと思います。

このセル生産方式は、作業工程の一人ひとりのスキルの高さを前提に、優れた少人数のエキスパートチームによって製品を作り上げるということがポイントです。少人数のエキスパートチームということであれば、いろいろな雑多で複雑なことを扱うには大組織よりも明らかに向いていますし、中の人達の士気を非常に高く保つことができます。そう、システム開発というのは雑多で複雑なことを扱う、クリエイティブな作業であり、本質的にこのセル生産方式のようなやり方が向いているのです。

またこれを実現するためにはメンバーのスキルを非常に高く保つ必要があります。そのための教育コストは当然高くつくわけですが、結果として、そのコストを軽く補えるほどのリターン、つまりプレミアムが得られるはずです。

NTTデータのこの試みがぜひ成功して欲しいと、強く願ってやみません。

ホームページも作らずに先にBlogを始めてしまっていたのですが、ついに会社のホームページが完成しました。

これです。

ホームページを作るに当たって、「そういえば、我が社はまだ売り物ができていない → 紹介するものがない！」という事実に直面しました。  😀

このままでは中身のないスカスカのホームページになってしまいます。そこで、このままではイカンと考え、こんな企画（見てのお楽しみ）も用意してみました。

皆さんからのご感想、コメントなどはこちらのBlogで受け付けます。ネタなども大歓迎です。ぜひ覗いてみてください。

昨日のテーマ「システムを使う人、使われる人」の続きです。

またまた「私の履歴書」ネタですが、セブン＆イレブンでは日本初の本格的POSシステムが1983年に全店導入されるという話が4/18に載っていました。POSとは販売時点情報管理システムのことで、単に商品の売上げだけでなく、いつ、どんな人が、どんなものを、どれだけ買ったのかをデータとしてかき集め、それを販売予測に利用するというシステムで、少なくとも当時としては非常に画期的なシステムだと思います。でもこれって単なるレジ打ちのはずだった仕事に余計な仕事が増えるケースです。まあ実際にはちょっとしたオペレーションが増えるだけだと思うのですが、とはいってもオペレーションする側が面倒だと思ってやっていると、正確なデータは集まらず、うまく機能しなかったのかもしれません。

セブン・イレブンでやったことは、まずシステムを導入したのではなく、「各店舗の経営相談を行うOFC（オペレーション・フィールド・カウンセラー）を通して、オーナーからアルバイトまで単品管理の意識を徹底するように努めた。」とあります。つまり現場の意識改革を最初にやって、その後でシステムを導入したのです。

単品管理の重要性が予めきちんとわかっていて、それを実施したいと現場が考えているのであれば、そのために導入されるシステムは「使われる」ものではなく、「使う」ものになります。自分たちの行う販売予測（仮説と検証プロセス）をやりやすくするための、便利な道具に変身したわけです。

システムに使われる立場の人をなくすためのやり方は１つだけではないと思います。それぞれのシステムによってその方法は様々でしょう。しかしどのやり方にせよ、もともとは「使われる」立場だったはずの人達が主体的に参加できるように業務を改善すること、これこそが普遍的な王道ではないかと私は考えます。

システムを新規に導入しようとする際に忘れてはならない点として、今日は「システムを使う人、使われる人」というテーマで書いてみます。

システムを導入するとみんなが楽になる、というのが理想なのですが、現実にはシステムを入れることによって逆に仕事が増える人がいる場合があります。システムの提案・企画をする際にはシステムを使って楽をする人だけでなく、逆にシステムを入れることによって仕事が増えてしまう、拘束されてしまう人達のことをよく考えて設計しないと、「使われないシステム」になってしまう場合があるという話です。

システムを導入する際には業務全体の効率化という御旗の元、新しい業務フローができるケースが多いと思います。例えば何らかのデータを毎日入力する、みたいなものです。データを入力することを専門とする職の人ならばそれでも問題ないと思うのですが、通常の業務をやっている人に、追加する形でデータ入力を強制するような場合、彼らはシステムに「使われる」立場になります。こういった場合、彼らがちゃんとデータを入力するように、業務的に『強制』したりするわけです。

でもこれって、その「使われる」立場と同じ立場・視点で考えてみればわかりますが、面白くない話ですよね。一生懸命入力するまじめな人もいるとは思いますが、大半はまともに入力しません。最初は業務的に強制させることによってなんとか回っていても、いつの間にかきちんとした、意味のあるデータが入力されていなかった、なんてことがよくあると思います。

正直な話、私も過去にこの手の失敗をした経験があります。そのシステムはリリースはされたものの、あまり有効に活用されませんでした。

これはそもそも、強制させればきちんと回せると考えていることに問題があると思うのです。つまり上記のケースでも、データを入力したいと思わせる仕組みが必要だ、ということです。システムに「使われる」と思っている人がいる限り、うまくいきません。システムに関わるユーザがすべてシステムを「使っている」と感じることができるかどうか、にかかっていると思います。

ではそのためにはどうすべきか、これは後日ということで。

4月20日のITmediaによると、『米Googleが4月19日発表した第1四半期（1?3月期）決算は、売上高は前年同期比63％増の36億6000万ドル、純利益は同69％増の10億ドル（1株当たり3.18ドル）となった。』とあります。この売上高の36億6000万ドルというのは円に換算して約4300億円になります。ちなみに電通の調査レポートによると、2006年の日本のインターネット広告費は年間で3,630億円となっています。Googleの数値は四半期ベースなので、荒っぽいですが4倍して年に換算すると１兆7,200億円になり、日本全体のインターネット広告費の実に4.7倍にもなります。

まさにガリバーですね。

しかし同時に、日本国内の市場というのは小さいな、としみじみ感じてしまいました。実際Googleは世界各国で売り上げを立てているわけで、だからこそこんなガリバーになりえたのでしょう。日本の国内でシェアをとるというのは、それはそれでとてもすごいことなのですが、それだけでは結局は井戸の中の蛙ということなのかもしれません。

日本は製造業の世界では非常に競争力が強く、サービス業もそんなに捨てたものではないと思うのですが、IT系では残念ながらガリバーといえるほどの会社はありません。特にシステムの世界に限ると常に輸入超過状態であり、Made in Japanが世界に出ていっている例は本当に少ないのが実情です。（知的資産という意味ではRubyという輝かしい宝石もありますが）

一方で中国やインドという国々がこの分野では確実に力を付けてきているのは周知の事実です。日本も今後、どんどん攻勢をかけられるようになるのも間違いないでしょう。

1企業人としてどんなことができるのか？　そんなことを考えさせられる記事でした。

エスプレッソマシンってかっこいいんですけどね。

BROOKSのコーヒーのほうがやっぱり手軽なんで、あまり…

タイトルはスパムメールの話ではありません。

システム開発のプロジェクトではメールは必需品だと思いますが、あまりにも大量のメールがやり取りされていて、結局良く見ていない、なんてこと、ありませんか？

メールって言葉でのやり取りと異なり、やり取りしたことが記録に残るし、後で検索とかもできるので、使って当たり前、いまや空気のような存在に近い（？）のかもしれません。またCC:（カーボンコピー）で関係者に一斉に配布できるので、周知という意味でも非常に優れています。でもその便利さが故に、メール依存度が非常に高まり、システム開発プロジェクトにおいても非常に大量のメールがやり取りされるようになりました。

しかし結果としてあまりにも大量のメールのために、プロジェクトメンバが見なくなってしまっている場合があるとすると、情報共有という観点では本末転倒なのかもしれません。

メールの問題点として、以下のようなことがあると思います。

１．情報が分類されていない。欲しい情報にフォーカスしずらい。
２．メールで意見を表明すると「とげとげしく」見える。

メール自体には情報を分類するための仕組みがないので、自分で振り分けルールを一生懸命作ったり、件名の書き方に統一ルールを作って徹底的に守らせる、などといったことする必要があります。しかしなかなかこの分類をきちんと運用するのは難しいものです。でもこれが無いために、見る側が見たい情報かどうかが中身を見ないとわからないために、いちいち全部チェックするのが面倒くさい→見るのやめた、となってしまうのではないでしょうか？

もうひとつの問題点として、メールで意見を表明すると「とげとげしく」見えるっていうか、よく『炎上』したりすることがありませんか？　Face-to-faceのコミュニケーションだと相手の表情がわかるので、相手の感情を考えながら話す内容を変えることもできるわけですが、メールって書いた後にしか、しかも相手のリプライの文面からしか相手の感情が読み取れません。なのでメールだけでやり取りしていると、ちょっとしたことで炎上したりするんだと思います。

プロジェクトの中でそういった現象が起こると、傍から見てよくわからんことで大量のメールがやり取りされることになり、当然その中身はまともに見ない人が増えることになります。

ここはひとつ、メールの代わりにFace-to-faceのコミュニケーションをもうちょっと増やしてみませんか？