update it, Inc.社長のブログ

雑談ですが、「賢者の書」喜多川 泰 (著) を読みました。ファンタジックな自己啓発本なのですが、かなり面白く、のめり込むように一気に読んでしまいました。

本当の成功とは何なのか、またそれを実現するには、日々何をしなければならないのか、どんなことを考えなければならないのか、いろいろなことを考えさせられました。

私が特に気に入ったのは、5番目に出てくる賢者のデイルの言葉です。過去や未来に囚われることなく、今日一日を集中して生きることが大切だ、と説いています。成功した人の伝記を読むと、必ずしも最初から恵まれた環境ではなかった人が多い。でもそういう状態でも、その当時のエピソードを読むと、なるほど、この人はやはりなるべきして成功者になったのだ、ということが分かると記しています。つまり成功者というのは、他人から「この人は絶対成功する人だ」と思われるように、今日一日を過ごしているということです。

まあ、この手の本には良く書いていあることだと思うのですが、読んでみて、何か『腹に落ちた』感じがあります。私はまだまですが、ぜひ他の人から「この人は絶対成功する人だ」と思ってもらえるように、今日一日を大切にしていきたいと思いました。

前回の続きです。プロジェクト内でメールを使う問題点を聞いたところ、他にもこんなことを教えてもらいました。

(5) ドキュメントを添付して送るとき、パスワードをかけるのが面倒

(6) 単にドキュメントを送付するだけなのに、いちいち文面を書くのが面倒

(7) 添付サイズによっては送れない場合がある。

(8) サブジェクトの振り分けルールを作って運用するのだが、うまく機能しない

こうして見てみると、前回の(3)もそうですが、ドキュメントの添付に絡む問題が多いですね。プロジェクトでドキュメントを共有したい場合に、単にファイルサーバに置くという方法では共有できないケースがありますが、そのような場合には通常はメールでの送付で済ます場合が多いと思います。

さて、いろいろと問題があるプロジェクト内でのメールの使用ですが、果たしてメールに代わる別のソリューションがある場合、それにスイッチするものでしょうか？　スイッチするのであれば、満足化原則を満たしていなかった、ということになります。

そしてそのスイッチする先がcrossnoteだと皆さんに認めてもらえるよう、がんばります。

一昨日、「最適化 vs 満足化」というテーマを書きましたが、今日はその続きです。今日はメールについて、この「最適化 vs 満足化」を考えてみたいと思います。

メールは今や誰でも使う、非常に基本的なインフラとなっています。そして普通にメールを使っている人にとっては十分便利であり、満足している人も多いと思います。なので、これより少し便利なものが別に現れたとしても、なかなか普及しないでしょう。

でも、プロジェクトなど、チーム・コラボレーションに話を絞った場合にはどうでしょうか？　チーム・コラボレーションにおいても基本ツールとしてメールは欠かせないものですが、果たしてこのシチュエーションで使っている人たちは満足して使っているのでしょうか？　ぜひ皆さんに意見を聞いてみたいのです。

私がチーム・コラボレーションにおいてメールを使っている際に感じる不満としては、こんなことがあります。

(1) 送り先を指定するのが面倒。間違えてひどい目に合うこともある（いや、あった）。

(2) 後になって、「あ、このときの議論、文書に反映されていないけど、メールでやり取りしてたな」というシチュエーションが良くあるが、探すにの骨が折れる。またこういった情報はチーム内で共有されることがない。

(3) メールに文書を添付すると様々なバージョンのドキュメントが散乱して、どれが最終版なのかがわからなくなりやすい。最悪なのは、その添付されたドキュメントを互いにやり取りし合うものだから、本当に訳が分からなくなる。

(4) 重要な質問などを送っても、相手が忙しくてほったらかしにされてしまった場合、そこでその仕事が止まってしまう。

他にはどんなことがあるでしょうか？　ぜひ教えてください。

今日の小飼 弾さんのブログ「The best is not good enough for us」に best を求めているのか、good enoughを求めているのか、といった論旨の話が載っています。

ちなみに人々は必ずしも最適なものを望むのではなく、満足できるレベルのものであればそれをチョイスしてしまう、というのはハーバート・サイモンという方が満足化原理として提唱したことです。人々は必ずしも最適なものを求めているのではなく、満足できるれべるのものを選んでおり、満足できる状態であればたとえ最適な別なものを紹介されてもなかなか乗り換えないものだ、ということになります。

小飼 弾さんのブログからは内容が離れてしまいますが、ビジネスの世界では、この観点のことにはよく出くわします。現状に困っているのでなければ、「良くなる」ものがあったとして、なかなか乗り換えてはくれないのです。

逆にいうと、何に困っているのかがはっきりして、それを提供できるのであれば話は簡単、簡単に乗り換えてもらえることになります。何に困っているのか？　これをキャッチアップできるかできないかが、ビジネスにおいての成功の分かれ道なのだと思います。

今日の日経ITProの記者のつぶやき「学生とIT業界トップの公開対談で胸を衝かれたこと???IT産業を呪縛する“変われない日本” 」がおもしろかったというか、ああ、そうだな、と思いました。

変わらないことへの強い指向。これは日本の社会に今深く根付いているように思います。上記の記事では「私塾のすすめ――ここから創造が生まれる」（ちくま新書）という本から次のような内容を抜粋して紹介しています。

—
『時代の変化』への鈍感さ，これまでの慣習や価値観を信じる『迷いのなさ』，社会構造が大きく変化することへの想像力の欠如，『未来は創造し得る』という希望の対極にある現実前提の安定志向，昨日と今日と明日は同じだと決め付ける知的怠惰と無気力と諦め，若者に対する『出る杭は打つ』的な接し方
—

なんかここだけ読むと絶望的になりますね。でも確かに今日本の社会には変化しないことを指向する何かが根付いているように思います。ある意味で日本は一旦頂点を極め、それを過ぎてしまった、ということを経験しているために、没落していくのではないかという危機感から、自然に「変化しないこと」を指向しているのではないか、と私には思えます。

この記事の中で、「起業しよう，と呼びかけるIT産業のトップたち」と紹介していますが、でも今の日本には、米国式の起業ができるような受け皿がありません。日本のVCはStartupの企業にはほとんど出資することがないんです。この事実を理解しないまま、起業をあおるのは少し無責任ではないか？と思います。

もちろん、じゃあ米国式の起業をサポートできる受け皿を整備しよう、という建設的な意見は大賛成ですよ。  😀

＠ＩＴに2010年の冬には日本のIPv4アドレスがなくなるという記事が載っています。IPv4アドレスの枯渇は以前から騒がれている問題で、特に新規性があるわけではないのですが、2010年の冬という具体的な時期は、私は初めて知りました。

でも、そもそも、みんなそんなにグローバルIPアドレスが必要なんでしょうか？　グローバルIPアドレスが必要な場合って、本当は非常に限られていると思うんです。特に一家に１個、グローバルＩＰアドレスっていうのは無駄ですよね。

記事ではそんなに簡単に２年間でIPv6に移行はできないから、キャリアグレードNATが今すぐ必要だ、と書いています。まさにそうなのだと思います。各家庭なんて、普通はローカルＩＰでいいじゃん、って思います。グローバルIPアドレスが欲しい人は別途金を払って確保する、ってのが筋だと思うのです。

石油も枯渇するまであと何年、といわれ続けていまだに枯渇していませんが、IPv4も使い方を工夫すればまだまだ持ち続けられるのではないでしょうか？

アメリカのベンチャーが資金調達する際、このElevator Pitchというのをよくやるそうです。これは資金提供をしてくれそうな人と一緒にエレベーターにのって、そのエレベーターが目的階につくまでのわずか３０秒ぐらいで自分のビジネスプランを説明するということを指しています。エレベーターを使わなくても、ベンチャーがビジネスプランを発表する際には良く使われる手法のようです。

アメリカでは資金提供者側ではできるだけ大量のベンチャーと会って、そのなかから将来性のありそうなものをスクリーニングしなければなりません。できるだけ大量のベンチャーに会う、という意味で、このElevator Pitchというのはとても役に立つのだと思います。

振り返って考えてみると、私も自分のビジネスプランを話す機会があった場合に、短時間に印象的に話せていない場合が多かったと思います。これは事前に良く内容を練って、普段から練習しておかなければならないことなのでしょう。

幸福の女神は前髪しかない、とよく言われます。ビジネスの世界ではやはりこのような練習を「事前に」やって、いつでも備えておなければならないのだと思います。

工事進行基準のレポートを以下のリンクで公表します。

工事進行基準レポート

実際にプロジェクトを回す側の立場として、自分達が知りたいと思った観点から調査し、レポートにまとめてみました。

ソフトウェアベンダーの経営者やプロジェクト・マネージャの方向けに、できるだけ現場の立場で書いたつもりです。

なお、この工事進行基準ベースでプロジェクト運営を行うためのコンサルティングを実施しようと思います。詳しくはレポートの最後の方に説明を載せましたので、ご興味のある方はご連絡ください。

前回のcrossnote リリース時(5/16)に同時に出していた機能なのですが、今になってアナウンスです。システム開発用の設計書テンプレートを増やしました。今回主に増やしたのは、「基本設計」向けのテンプレートです。

[基本設計編]
■ システム開発全体を通しての成果物一覧（Excelファイル）

■ ユーザーインターフェース設計者向け
　　-画面仕様書
　　-画面共通仕様書　

■ ソフトウェアアーキテクト向け
　　-アプリケーション開発ガイドライン
　　-ソフトウェアアーキテクチャ説明書

■ テスト担当者向け
　　-システムテスト計画

■ 開発環境管理者向け
　　-開発環境利用ガイド

[詳細設計編]
■ ＤＢ設計者用
　　-物理テーブル定義書

[その他]
■ ＵＭＬサンプル (Judeファイル）

ぜひお試しください。（なお、crossnoteの無料での試用については、crossnoteのページから左側のリンクの「評価してみたい」を選んで、お申し込みください）

工数を求める際、一般には「何人月」とか「何人日」といった単位で工数を求めることが多いと思います。これは対象の仕事の担当者だったら、どのくらいの期間でタスクを完了できるのか、という見積です。一人の人がすべての仕事をしている場合には、単純合計すれば全体のタスク量になることは明白ですよね。

でもこれが2人の人が担当する、という話だったらどうでしょうか？　例えば2人のプログラマー（Aさん、Bさん）が同じアプリケーションを作っていて、Aさんが担当の機能をBさんが利用しているような場合には、Bさんの都合でAさん側の機能の見直しをお願いする、なんてことは日常茶飯事に発生します。こんな場合にも、AさんとBさんで話し合って決めるための（コミュニケーション）時間や、BさんによってAさんのタスクが中断する時間、BさんはAさんが空くまでBさん側の該当するタスクを止めなければならない時間など、いろいろなオーバーヘッドが発生することになります。

1人で順次こなしていく場合に比べ、上記のオーバーヘッドが余計にかかるので、一般には1人で2人月かかる仕事を2人でやったも１ヶ月では終わりません。これがきれいに成り立つのは、2人の間のタスク間に互いに依存する部分がなくて、そのまま突っ走れるような仕事の場合のみです。

でも不思議なことにプロジェクトの見積を行う場合には、そのタスクを何人でやるか、ということをあまり気にせずに、何人月とか何人日だけで換算していると思います。これは上記のようなオーバーヘッドが実際にはどの程度なのかが見積もれないために、とりあえず無視しているからでしょう。

確かに2人程度ではそのようなオーバーヘッドはあまり大きくないと思いますが、これがもっと大人数で、しかも互いに絡み合っていたら、どうなのでしょうか？　当然このオーバーヘッドが非常に大きな値になってくるのは想像できますよね。

複雑な、絡み合ったものを対象とする場合、100人の人が1か月でできる作業量は100人月、1人の人が100か月かかってやる作業量も100人月ですが、実際にできることがどれだけ違うかはすぐ想像がつくと思います。おそらく後者の方は前者の数十倍の成果物をつくり出せるでしょう。逆に前者は出来上がったものの、使い物にならない代物になっている可能性すらあります。

上記の例は極端ですが、実際のプロジェクトでも同じようなことが良く起こっているのではないでしょうか？　もちろん実際のプロジェクトでは限られた時間の中で成果を求めらるので、やっぱり多くの人を投入せざるを得ないのですが、もし時間が許すならば、むしろ少ないメンバーでじっくり時間をかけたほうが非常に経済的に仕上げることができることになります。

少数精鋭のチーム、いいですよね。