update it, Inc.社長のブログ

昔、PM（プロジェクト・マネージャ）の研修を受けたときなどに、「仕切る」ことの重要性を習いました。「仕切る」という言葉を辞書を引くと

１ 境を作って他と区別する。隔てとなるものを設けて、いくつかの部分に分ける。
２ ある範囲の物事を掌握し処理する。取り仕切る。
３ 帳簿または取引の決算をする。
４ 相撲で、両力士が土俵中央仕切り線の所で、両手を土俵に下ろして立ち合いの呼吸合わせをする。仕切りをする。
（Yahooの大辞林より）

PM研修のときに習った仕切るという意味は、上記のうち２を指しているように思いますが、実際には微妙に１の意味を含んでいると思われます。つまり、能動的に自分の身に引き受けて行う、という意味だけでなく、物事を「切り分ける」というニュアンスを強調するために、この「仕切る」という言葉を使っているように感じました。

取仕切る、つまり自ら一身に引き受けて行うことも重要ですが、実はそれだけでなく、いろいろと、こんがらがったことを「切り分けてあげる」ことこそが、この仕切ることのポイントなのだと私は勝手に解釈しています。つまり、切り分ける、つまり物事を整理し、分類し、さらにはそれを皆に知らしめることまでの一連の行為を「仕切る」という一言で表現しているのだと思うのです。

物事を切り分ける、とはすなわち、物事を構造化する行為です。これって実はかなり頭を使う行為なんですね。そして同時に「取仕切る」わけですから、そうして構造化して切り分けたことを皆に伝え、それで物事が回るように仕向ける。これは結構大変な仕事だと思います。

リーダーのみなさん、「仕切って」いますか？

ビジネスのアイデアには！（びっくりマーク）が必要です。この！には単なる驚き！だけでなく、なるほど！、とか、すごい！、とか、そういった「！」があるか、そこにかかっているのだと考えています。

今朝、会社に来る前にテレビをみていたら、フジテレビのとくダネ！という情報番組でKIZUNA JAPANという会社の勤怠管理システムを紹介していました。一般向けの情報番組でシステムの紹介をするというのはだいぶ異例なことだと思います。紹介していたシステムというのが、アルバイトの給与の振込みをアルバイトが自ら携帯で行えるようにした、という一見奇抜にも思えるアイデアを実現するものでした。

アルバイトの人達は日払いの日給が欲しいのだが、会社側としてはそれを実現するには事務コストがかかりすぎ、今までなかなか実現できなかったのを、このシステムを入れることで実現できるようにした、ということがこのシステムの目的です。

その事務コストを下げるための一環として、銀行への振込み業務をアルバイト自らが行うことによって事務の合理化を図ろう、というアイデアが盛り込まれていました。もちろん働いた時間のチェックは会社側が行った上で、システム上で金額が計算されるので、その振込み部分をアルバイトの人が行う、ということです。アルバイトは、24時間、自分が欲しいときに働いた分の給与を引き出せるようになります。

確かにこれは逆転の発想ですよね。こういう発想があるとみんなに注目を浴びるので、事業としても認知度アップに貢献するのだと思います。

ぜひ、この「！」となるようなアイデアを考えたいですね。

なんか、脈絡のない話ですが…

ビジネス活動においては様々な最適化が行われています。例えば少しでもコストを下げようとしたり、少しでもサービスを向上させようとしたり、少しでも品質を向上させようとしたり。こういった活動はすべて、何らかの目標（例で言えばコストや、サービス指標値、品質指標値など）の最適化を目指して行われているわけです。

実際には物事はもっと複雑で、例えば品質を向上させるためには、バグ発生率を下げなければならない、テストを大量・効率的に実施しなければならない、そのためには…と様々な連鎖的な最適化活動が大量に行われ、その結果として目標の最適化が実現されることになります。

難しいのは、そのようにブレークダウンされた部分最適化活動がそれぞれMAXになったからといって、必ずしもそれが全体最適化の解とはならないことです。目標の中には様々な相反する指標があります。例えば品質の向上には一般にコストがかかります。コストを抑えすぎると品質が悪化する場合もあるわけです。どの程度でバランスさせるべきか、という部分は、いくら部分最適化を実行しても答えは得られません。

昔は物事を全て線形代数の世界で表現してOR(オペレーション・リサーチ）という手法で最適解を求める、などといったことが盛んに行われていましたが、最近実際の応用例はあまり聞かなくなってきたように思います。そもそも線形代数の世界で表現する、という前提に無理がある場合が多いのでしょう。

デリバティブ（派生証券）の分析手法として、昔は式を解いて解を求めるというやり方が主流でしたが、徐々に複雑な条件によってそのように解析的には解けない場合が増えた結果、モンテカルロ法といって、コンピュータ上で乱数によるシミュレーションを実施して解く、というやり方が増えてきています。ビジネス活動の全体最適化にも、このようなシミュレーションによる解析方法（コンピュータによるものとは限らないかもしれません)が最適なのかもしれません。

現在、crossnoteの「さくさく化」を進めようとしています。この「さくさく化」とは、さくさく設計書を作れるようにするにはどうしたらよいか、というテーマで改善ポイントを絞って対応していこう、ということです。

現状のcrossnoteでは、まだ「さくさく」設計書が作れるレベルになっているとは言いがたいです。もっとストレスなく、気持ちよく設計書が書けるようにしたい、と考えています。

設計書のパターンを解析し、その中で非常に良く使われるものについては、できるだけ簡易に作れるように工夫していきたいと考えています。

もし、設計書を書く上でこんな機能が欲しい、と思うことがある方はぜひ教えてください。よろしくお願いいたします。

昨日のマニュアルの話しの続きなのですが、どんなマニュアルは読みたいと思うのでしょうか？

一般には絵や図が多いこととか、適宜表などを用いてきれいに整理されていることとか、言われていると思います。でも、いくらきれいにまとめられていても、ぜんぜん頭に入ってこないマニュアルが巷に溢れています。（単に私の頭が固い、というのもあると思いますが）

たまに、お、これは、と思うマニュアルもあります。でも、そういうマニュアルは、そもそもその対象物（製品やシステム）がすごくいいもので、その内容を知りたいと思う強い意志が働くので興味がわきやすい場合が多いように思います。そういう場合には、ちょっとカッコいい図で説明されていると、それだけでもうイケてる、と思ってしまうのです。

では読み手がそれほど強く対象物に思い入れがない状態で、お、これは、と思われるマニュアルにするにはどうすべきか？　私なりに悩んでいるのですが、「読んで得した！」と思わせるマニュアルというのはどうでしょうか？　単に読み手に対し、聞かれたことを答えるだけではなく、＋αの知識を提供する、そんなマニュアルです。

ちょっと薀蓄が入っている、とか、気の利いた説明があるとか、その周辺のことについて、頭を整理してくれるようなマニュアルです。ウザいですかね？

今書いているマニュアルが果たしてその領域にたどり着けるかどうかはわかりませんが、私なりにTryしてみようと思っています。

少し前のブログで書いたように、crossnoteのマニュアルを準備中です。マニュアルを書いていて少し思ったことなのですが、皆さんはマニュアルに何を求めていますか？

思えば昔、OSのマニュアルなどは、1冊の厚さが結構あるような本が何十冊もセットになっていました。その当時、これを全部読む人はいるのだろうか？　とか、もし読まずに知らないことがいっぱいあった状態で、何かとんでもないことをしてしまったらどうしよう、などと今考えるとつまらないことを考えていました。

実際、誰からも読まれずに消えていったマニュアルも多かったと思います。

マニュアルって一杯あると、まずその中のどのマニュアルに目的のことが書いてあるのかを探し出すのに苦労します。これはマニュアルが電子化された今でもあまり状況は変わらないのではないでしょうか？

あともうひとつ、技術系のマニュアルを読んでいてよく腹立たしく思うこととして、使っている用語がチンプンカンプンだ、というのがあります。なんだかよくわからない用語がいっぱいちりばめられていて、それらの用語の定義や意味の説明もなしに、操作方法だけが書いているようなマニュアルを読むと破って捨てたくなります。

そこで、crossnoteのマニュアルの方針は、こうしました。

１．マニュアルは薄ければ薄いほど良い！

２．用語はきちんと説明しよう

1つ目は読みきれる量のマニュアルを用意しよう、ということです。些細なことが一杯詰まった、でも誰からも参照されないマニュアルではなく、とりあえず最低限のこと、知っておくべきことだけをまとめて書いたマニュアルを目指したいと思います。

2つ目は、操作を書くのが目的ではなく、背景の概念や意味を説明するようにしよう、ということです。マニュアルに求めるのは、操作方法ではなく、その意味を知りたいのではないかと。

どうでしょうか？　よろしければ皆さんのご意見といただければと思います。

今月の日経新聞の私の履歴書では、全FRB議長のアラン・グリーンスパンさんが書いています。今日でまだ8日目ですが、むちゃくちゃ面白いです。

グリーンスパンさんの非常に緻密な分析力というのは、若いときのミクロ経済分析で培ったもののようですが、とにかく徹底的に調べ上げ、専門的なことまで自分で理解し、できるだけ現場から正しいデータを大量に集め、それを元に分析する、という分析スタイルが成功への流れを作ったのだと思います。これだけ徹底的に調べ上げているので、皆が信頼を寄せ、長きに渡り世界の金融の世界の番人になりえたのだと思います。

数日前の回に書いてあったのですが、なんと彼はそういう分析の一環として、以前はコンピュータを理解するためにプログラミングもやっていたそうです。でも今は複雑になりすぎで、理解できなくなり、フラストレーションがたまっている、と書いていました。しかし、すごい。日本のシステム開発のプロジェクト・マネージャーの中にはプログラミングをやったことすらないって人がいるのに、です。

振り返ってみると、残念ながら私の分析力はまだまだ甘々です。物事を徹底して分析できているか？　どれだけ把握できているか？　もっともっと徹底して調べ上げ、裏づけをとる「くせ」を付けていかねばなりません。

できるだけ広い範囲において、徹底的に理解すること、客観的な事実で物事を把握すること、などなど、今後経営者としてぜひ実践していかねば、と心しました。

雑談ですが、年賀状をやり取りしていて気づいたことを書いてみます。最近では徐々に年賀状のやり取りが減ってきているようですが、そうはいっても年賀状でしかやり取りできない人もいるので、そうそう止めてしまうわけにはいきません。

昨年の年賀状の時には、忙しくて手書きのメッセージを添えずに出してしまっていました。今年は（汚い字ですが）手書きのメッセージを添えるようにしました。というのも、自分が年賀状を受け取ってみると、結局手書きのメッセージ欄にばかり集中して読んでいることに気づいたからです。

たいしたことが書いてあるわけでなくても、手で書いてあるメッセージというのは、いわば「自分に向けられたメッセージ」になっているわけで、それが重要なのだと思います。

相手に情報を伝えるときに、相手に向けたちょっとした一言を添える、たったそれだけのことだけで、その情報のもつ意味や、伝わり方が変わるのかもしれません。

以前、同じタイトルでオーケストラとシステム開発の類似点というのを書きました。ドラッカー名言集の中の言葉で、「オーケストラが明日の組織のモデル」というのを紹介して、それとシステム開発プロジェクトとの類似性を書きました。「高い専門性をもった人たちが調和して進めるプロジェクトスタイル」こそが、明日の組織のモデルであり、それを具現化しているリファレンスとして、ドラッカーさんはオーケストラを紹介しているのですが、私はシステム開発も同じだ、と考えています。

さて、いきなりテレビの話で恐縮ですが、私はクラッシックファンで、「のだめ」というドラマが非常に気に入っています。先週末、その「のだめカンタービレ」のドラマスペシャルがあるということで、非常に楽しく見ていました。

このドラマの主人公は男女の二人いて、男性側の主人公は指揮者を目指しています。今回のドラマスペシャルの1回目では、その指揮者を目指す男性側の主人公が指揮者コンクールに出て、オーケストラのメンバーとの確執などを通しながら最後はうまく纏め上げてコンクールに優勝する、というストーリーだったのですが、その最後にうまく纏め上げることができた最大の秘訣は、直接この言葉をドラマで使っているわけではありませんが、Respectすること、でした。

プロフェッショナルの集団をうまくまとめるための秘訣とは、互いにRespectし合うこと、またそうできるように、切磋琢磨し、自分を磨き上げておくことなのだと、私はこのドラマを見て感じました。

振り返ってシステム開発の現場も様々な役割をもったプロフェッショナルによる集団であり、プロジェクトマネージャーというコンダクターの下、システムを作り上げる作業に一致団結して望まなければなりません。ぜひこのドラマのオーケストラのように、Respectし合えるようにしていきたい、と強く感じました。

あけましておめでとうございます。今年もよろしくお願いいたします。さっそくですが、私の今年の抱負を書いておきます。

１．crossnoteをより多くの人に知ってもらう

２．海外の企業との契約を増やす

３．crossnoteの使い勝手の向上に努める

４．2008年末までに契約利用ユーザライセンス数 3,000 を超える

なかなか高いハードルもありますが、これらの目標を超えられるよう、精一杯がんばっていきたいと思います。

また、今まで以上に皆さんとの強い関係を築いていきたいと思います。叱咤、激励、提案、いずれも大歓迎ですので、皆さんの応援をよろしくお願いいたします。