仕事のリードタイム短縮のために

私の課題の１つは、仕事のスピード感が遅いことです。

個々の単位作業の速度が遅いわけではなく……

• 自分で抱え込みがち。
  　詰まったところで疑問点をまとめ、識者に持っていくタイミングが遅い。
• 自分の作業外の待ちが多い。
  　回答待ち、他人の作業待ちが多く発生する。

……ために、トータルでのリードタイムに遅れが出ることが多いです。

他人に聞くのが遅れる理由は２つ自覚していて、

1. 調べることで身につくスキルもある、とコストパフォーマンスを意図的に度外視している。
2. 他人の仕事を中断させることに遠慮してしまう。

というのがあります。
コストパフォーマンス度外視は、自分への教育効果が十分に上がる範囲ならアリかと思います。でも資料の場所を知ってるか知らないかといった単純なケースもあり、立ち止まって、得られる効果の価値を考えてみることも必要そうです。
他人への遠慮は、他人の作業とその時点での集中具合が見えないだけに難しいところです。「向こう一時間の間のどこかで10分時間を下さい」と割いてもらう時間帯を向こうに判断してもらったり、「この作業のここで困っています、今止めるとこういった後続作業も遅れます」と話したりして、全体でのコストベネフィットのすり合わせをしています。

また根本的に「他人に聞く」というのが「判断を求めている」のか「知識を求めている」のかで、かなり違いがあります。
他人の知識を求めることが多いのであれば、どこかでまとまった教育機会をもらうのも１つの手ですね。

他人の作業待ちの原因は

1. 相手の負荷状況が見えない
2. 相手に回答のプライオリティが伝わりきらない

ことがズルズルと遅れていってしまう原因のように思えます。
社外の人（連携先のシステム担当）やお客様が相手のケースが多いため、質問のところと同様の密度のコミュニケーションが取れてないのが問題のようです。

SQL の読み方

SQL をシークェルと読む人もいるようですが、エスキューエルですよね？

70 年代、IBM が System R に実装した RDB 言語は Structured English QUEry Language、SEQUEL です。SEQUEL はスペルのママ、シークェルと読むものでしょう。
ところが SEQUEL は他社の登録商標であったため、その後（本来 SEQUEL2 となるはずだったものに）SQL、Structured Query Language との名が付けられました。S の後に伸ばすのも、Q と L の間に 「ウェ」の音を補うのも無理があるので、これはエスキューエルと読むのが自然です。そして 80 年代以降、この SQL が、ANSI や ISO、JIS において標準となっていきます。

すると、SEQUEL と SQL の間には、
・IBM の System R の実装依存か、ポータブルか
・標準化されていないか、いるか
といった違いがあるわけです。

現在、私たちが SQL と呼んでいるものは後者の方なので、やはりエスキューエルと読むのが正しいように思えます。

用語辞典の類には両方の読み方が併記してあったり、モノによってはシークェルが本流でシロートさんはエスキューエルと読む、なんて解説をしているところもありました。

所詮は読み方なので、そう読む人が多ければ「そう読みます」でもいいんですが、シークェルという読みを説明しているところでも、こういった経緯に触れていないのには違和感を感じました。

スカウトとヘッドハンティングで知るギャップ

転職の際にお世話になった、リクナビ Next のバナーを右の方に貼り付けました。

前にもちょっと触れましたが、未だにリクナビ Next の登録はそのままにしておいてあります。
リクナビ Next では、匿名の履歴書を登録しておくことで、企業からスカウトメールをもらったり、あるいは転職コンサルタントからマッチする企業を紹介してもらったり、といったサービスが受けられます。

私の先月（４月）の履歴書の注目度ランキングは、同サービス利用者全 536,037 人中、16,904 位。上位 3% 。
高い数字だとは思いますが、もともと流動性の高い業界、かつ年代ですのでなんとも言えないところですね。今、どこにいるかよりも今後この数字がどう動くか、ウォッチし続けようと思います。
スカウトメール： 4 通
履歴書が検索された回数：153 回

当然ですが、上記の数字は私が望まないものも含めた反応量です。
私としてはあまり興味がない、前職の「会計パッケージ導入コンサル」の経歴を評価してのスカウトが圧倒的多数です。
転職後はあまり連絡を取っていませんが、ヘッドハンターから紹介される企業も、やはり会計絡みばかりでした。

やりたいことと、評価されることのギャップ。
あまり嬉しくはないのですが、受け入れなければならない現実でもあります。

逆に「使える踏み台なのだから、いかに利用してやろうか」という方向でモノを考えることも可能ですしね。

条件を意識する / 論理思考の基本態度

　ここでいう条件とは、制約条件と前提条件の２つです。

　制約条件とは解決方法に対する制限のことです。
　実行不可能な解決案を出さないために、という意味もありますが、それ以上に、無意識のうちにありもしない制約条件を自分で勝手にかけていないかをチェックする意味でも重要です。超えてはいけない柵を越えないよう気をつける一方、本当に超えてはいけない柵なのか、ただの白線を勝手に「柵の代わりに用意されたものだ」と思い込んで近づかなかったりしていないか、検討します。逆説的ですが、枠を超えた思考をするために、枠とは何か、何が枠なのかを見つめなおすわけです。
　アルコールはソフトドリンクと比べて割高ですが、その理由は原価の違いの他に酒税の存在もあります。酒税という販売価格上の制約条件の中、ビール業界の各企業は戦っていました。その中、発泡酒という一見制約条件の枠の外にある戦場へ早く戦いを展開した企業が、業界の情勢を大きく変え、ひいては企業体力の差にまで繋がってしまったのは記憶に新しいところです。

　前提条件とは解決にあたって、成り立っていなければならない条件です。
　制約条件と違い、成り立っていることを利用して、解により近づけることが多いです。ちょうど数学の問題に現れる「条件」に似ています。制約条件を策や枠に例えましたが、前提条件はどちらかというと「足場」として積極的に判断材料として活用します。
　一方で、一般的な解決案を個別のケースに対して適用する場合やその逆の場合などに、これを意識しないと痛い目にあいます（一般論は多くのケースに当てはまるよう、前提条件を「仮定」していることが多いです）。演繹を話題にする際にまた触れますが、暗黙のうちに前提条件を立ててしまい、それを相手と共有できていないがために議論が平行線を辿ることもよくあります。また、本当に足をかけて大丈夫な足場なのかの検証も重要です。

何が問題かを考える / 論理思考の基本態度

　問題とは「望む状態と現状との差」です。

　何か問題を解決しようと考える際、まず問題自体についてきちんと考えておかないと、無駄が生じます。
　問題について「なぜ？を５回繰り返せ( 5 Why)」とよく言われますが、以下のようなポイントについて考えると効果的です。

• 症状を問題と取り違えていないか
  　「集中力が落ちた」は「睡眠不足」による症状で、「睡眠不足」は「業務負荷が高い」ことによる症状かも知れません。このケースで、集中力を上げる方法を検討しても効果的ではありません。


• 解法を問題と取り違えていないか
  　症状の話と似ています。「彼と同等のスキルを持った人をいかに調達するか」は１つの解法で、問題はあくまで「特定個人に業務負荷が集中している」ことです。作業標準化で要求スキルを下げる、可能な範囲で要求作業品質を落とすといった解法もありえます。


• 問題の所有者は誰か
  　問題が「望む状態と現状との差」である以上、誰かが「望む」ことが問題存在の前提です。その望んだ人こそが、問題の所有者です。問題の立ち振る舞いを少し変えたり、問題の所有者が考え方や価値観を変えたりするだけで、問題自体が蒸発してしまうこともあります。（多少のレスポンスの問題は、Now Loading...の文字とシンプルでユニークなアニメーションで蒸発させられるのは有名です）また、問題の所有者を意図的に変える/広げる/転嫁することで新たな視点が得られることもあります。


• 解決すべき問題か
  　問題を解決することに集中しすぎてはいけません。解決にかかる（時間的、スキル的）コストとベネフィットのバランスは常に意識すべきですし、また解決することが自己目的化してしまっては、本末転倒です。

お子様な IT 業界

ある意味悔しい話なのですが、前回のような「IT には適切なコントロールが必要」という考え方は、IT 自体がインフラとして未成熟な証拠でもあります。

Nicholas G. Carr が IT Doesn't Matter と言い切る背景は、神経系ですら簡単に買い換えられるような世界を前提にしています。

企業合併の際にシステム統合のリスクが一般紙でも報じられるような現状では、私にはそのような世界は（いつか来るにしても）まだ先の話のように思えます。逆説的ですが、私には Nicholas G. Carr ほど強く IT の力を信じられていない、とも言えます。

未成熟といえば、SI のゲンバもそうですね。

スケジュール通りにモノが作れない、予算通りにモノが作れない、品質は低いし、トラブルになると属人性の高い対応しかできない…製造業が遥か昔に解決していることに、未だにてこずっています。
成果主義などの話の時に、「我々の仕事は時間いくらの工場労働者とは違うので…」といったフレーズを見聞きすることがあります。これも失礼な話ですよね。産業として成熟し、作業の標準化や効率化が十分に行き渡っているからこそ、そして働いている間は怠けていないという前提が成り立つからこそ、時間いくら、というコスト計算が妥当なのに。

未成熟だからこそ面白い、という見方もできますが、我々の仕事の目標の１つが、我々の仕事自体を消滅させることである、というのは心に留めておきたいものです。

CIO による IT のコントロール

前のエントリの通り、 IT 自体に戦略的価値はなくなりました。

IT 化では他社との差別化は図れません。
普遍化し、他社も簡単に追随できるようになっているからです。
持続的な競争優位に結びつけるには IT だけでは不十分で、他社に追随されるまでの間に、規模やブランドなど簡単には模倣できない差別化要因に展開しておかなければなりません。

しかし、既にコモディティ化した他の技術と IT とでは決定的に違う点があります。
IT 自体がビジネスプロセスやビジネスモデルを体現している点です。
情報はもちろん、４大経営資源のどれもが、IT を通じて管理されています。
いわば他の技術は企業にとって道具ですが、IT は神経系です。

IT 自体には戦略的価値はなくとも、何らかの戦略を実行に移す際、IT 抜きにして実施することは非現実的ですし、そうである以上、いかなる戦略も IT による制限を受けます。

例えば、メーカーが SCM を導入することによって差別化を図るのはもはや困難です。（＝SCM 自体に戦略的価値はありません）
一方、正確な需要予測を可能にするため、独自の販社を起てることで消費者までの距離を短く、太くしようというアクションは十分な差別化要因になりますし、戦略的です。

では SCM を抜きにして、この戦略的施策が実行可能でしょうか？
また既に SCM が稼動していたとしたら、独自販社という大きな業務インパクトをそのシステムは吸収しきれるでしょうか？

こういった戦略への影響は、電気やガスにはない、IT 独自のものです。
今後も CIO は経営戦略上の立場から IT を適切にコントロールすべきだと、私は考えます。
Nicholas G. Carr が示した４つのガイドラインにも賛成ですが、もう一歩踏み込んだ管理をしなければ、まだ不十分でしょう。

IT 自体にもはや戦略的価値はない

「IT にお金を使うのは、もうおやめなさい」ですが、思っていたほど否定的、攻撃的な内容でもありませんでした。埋めるべき隙間はありますが、主旨としてはほぼ全面的に賛同です。同僚にも薦めたいですね。

IT 自体にもはや戦略的価値はないです。
その点に関しては異論はありませんが、戦略を体現し、時に戦略に制限を加えかねない IT は、引き続きトップエグゼクティブによる適切なコントロールが必要だと考えます。

企業に競争優位性（言い換えるなら武器）をもたらすのは差別化です。
ライバルでなく自社を選んでもらうには、ライバルと自社の間になんらかの違いが必要です。
差が作れなければ、価格以外に勝負するネタがなくなり、ひたすら価格を原価に近づけ、自社の粗利を削ることでしか勝負できなくなります。
その中から抜き出て粗利を確保するには、なんらかの差別化要因が必要です。（無論、コストリーダーシップ戦略もあります）

投資は競争優位というリターンを得るために行われます。つまり、差別化のために資金を投じます。
ところが IT で差別化することは可能でしょうか？
もはやどこのライバルも ERP を入れ、SCM が在庫管理システムと生産管理システム、販売管理システム、発注管理システムをつなげ、システム間連携で半自動的に決算書と管理会計資料が出てきます。
IT 自体が差別化のポイントとなることは、まずないでしょう。
この意味で、 IT 自体にもはや戦略的価値はありません。

新しい技術が登場した時、いち早く取り入れることで競争優位を確保できます。それがライバルとの差だからです。
しかしその技術が普及するにつれ、その技術から競争優位を得ることは難しくなります。

かつて、鉄道ができたばかりのころは、鉄道で商品や原材料を運ぶこと自体が戦略的でした。
発電が始まったばかりのころは、工場のコンセント配置にその企業の戦略がありました。

技術は初期は個別の企業に利益をもたらしますが、普及期を過ぎると、その進歩は個別の企業よりも社会全体、業界全体に貢献するようになり、個別企業はコモディティ化した技術によるベネフィットよりも、技術に依存することによるリスクに注目するようになります。

コモディティとなった鉄道物流や電気において、重要なのは価値創出でなくリスク管理です。
カリフォルニアの大規模電力不足がシリコンバレーの各社に与えたインパクトは記憶に新しいところです。

そして IT は（まさにドッグイヤーのスピードで）かつての鉄道や電気を追いかけています。
グリッド、ユビキタス、ユーティリティコンピューティング、オンデマンド、オートノミック、SOA …どれもコモディティへと強力に推し進める技術です


では、今後の IT との付き合い方に関してはまた次のエントリで。