ＩＴの品質も技術の「見える化」から？

お客様に対しての品質の基本はまず、機能的に要求を十分に満たしていること。動作が正しく安定して行われるシステムであること、そして、納期とコストを守ること・・・どんな仕事であっても、「最初に約束したことを守る」というようなことがなにより大切なことだと感じます。それは、前回のお客様と決めたゴールに約束した機能のシステムを約束した品質で約束した期日にお納めするということです。これが、品質管理の基本であり顧客満足のベースにあるものと思います。決してお客様の言うとおりに闇雲に仕事を進めることが（大多数はその為に納期と品質に問題が発生したりしがちです）、必ずしもお客様の満足に繋がる訳ではないということをよくよく心して、いろいろな調整事に取り組まなければなりません。
それと同時に、最初に約束したことをどのように表現してお客様とプロジェクトのメンバー全員に伝えたら良いのか、それも大きな問題であると感じるのです。たとえ気まずい空気が流れても、本当にプロジェクトを成功させるには、プロジェクト全体のリスクを管理し、ＱＣＤのトレードオフを管理する事が必要です。その結果システムが混乱すればそのリスクは？というようなことをお客様に提案し、一緒に考えていかなければならないと感じます。私達のプロジェクトは、お客様のビジネスを支えていく重要なものであるからこそ、我々お客様と私達ヒューマンシステムのプロジェクトチームだけが考える独りよがりなことではなく、先端技術を競う必要もなく（大切だけど、それがｍａｓｔではないでしょう）、きちんとお客様と一緒にシステムを創り上げていくプロセスを私達は大切にしたいと思っています。この開発のプロセスでの意見交換においても我々の「おもいやり」を十分に発揮してこそ、ヒューマンシステムの開発したシステムは良いシステムになれるのだと思っています。
さて、お客様との距離を正しくして問題を共有する為には「見えるか」が大切です。そのツールとしては、WBS（Work Breakdown Structure）を明確にすることが、プロジェクトマネジメントの第一歩であると考えます。ＷＢＳは、提案書や様々な約束が履行可能であるかという計画や様々なスケジュール調整の為の予測にも、大変有効なツールです。通常、スケジュールの作成、予算の作成など重要な計画はすべてWBSをベースにして作成します。ＱＣＤ（品質、コスト、納期）を守るということは、特に凄い技術者が仕事をすると言うことではなく製造段階においては、愚直な作業の積み重ねが最も重要であると考えます。
品質向上のトレードオフのシーソーの対局には生産性向上というものがあります。それぞれのプロジェクトで、効率化は大切ですが品質を守りながら効率化を図るのはなかなか容易なことではありません。そのスタートは、お客様との約束がどれだけわかりやすくお客様も含めたメンバーに共有されているかということ、それとどんな状況にあっても品質に対して常に決めたことを守るという愚直さ（そういうまじめな取り組み姿勢の熟練した技術者を育てること）なのかもしれません。
例えば、同じような受注生産型の業種である金型業界では、金型の品質を高くすることは、基本はどんな熟練工であっても決められた手順を守り、きちんと確認しながら進めていくことです。それで、1/150000以下の不良率（因みに誤差が1/1000ミリ単位の製品も作っているらしい）を達成して来た会社もあります。
どうしてＩＴはこのような「見えるか」や生産管理がされないのでしょうか？ＩＴは人がその都度考えるものでパターン化できないから・・・そう言ってのける人がいますが、本当にそうでしょうか。それぞれの個人の思いつきでプログラムを作るということがそんなに重要な事なのでしょうか？どうして自動化してはいけないのでしょう。そういう考えに基づいて、プログラムの自動生成や各種フレームワークというものが沢山作られました。が、その話ではなく、大がかりに考え方を変えなくともひとつ問いかけてみたいことがあります。与えられた制約条件（人、物、時間）の中で、最も品質が高く最も生産性の高い手法を選んでいますか？そしてそういう手法というのは、そんなに沢山あるものでしょうか。
私は、この点・・・ある制約条件を鑑みて判断し、ある手法を選んでその手法を正しく実施（決められた手順で実行する）して貰うことが出来るようになればいろいろな問題はかなり解決するような気がします・・・。その一歩は、標準化ということになるのですがこれが難しいということはよくわかります。でも、あきらめられない重要な問題だと思うのです。
私達のＩＴ業界は、まだまだ品質を高めることができるのではないかと、その素晴らしい先達である金型工場の見学の後で感じました。

お客様の満足は品質からそしてそのスタートは？

お客様の満足と社員のしあわせは両立する。そういうことを本気で考え続けて何年経っただろうか。これだけ厳しい経済状況であれば、どんな立場の人でも本当に必要な物しか買わなくなるし、買った物が本当に支払っただけの価値があるのか考えてみたりしたくなると思う。その結果、消費税を引き下げても英国では消費が活性化しなかったり、若い人が車を買わなくなったり、ソニーが14年ぶりに赤字に転落したりということになってしまった。デフレ経済の中で失速した世界経済がどの方向を向いているのかさえ、経済音痴の私にはわからない・・・・一つだけ心に強く思う思いは、我々のような受託型（コンサルティングだったきっとそう）のビジネスでは、製品の質のモノサシとしてはお客様の満足度がその基本となる。
そういう時代だからこそシステム化投資についても本当に必要なのか、相見積りをとったのか、値引き交渉したのかというような具合になって来ています。今年、私が社会人大学院で担当していた講座でもユーザの一人である学生（彼は技術を売りにしている金型屋さんの社員です）は、何回目かの授業でこう言い放ったのでした。「ところで・・・ＩＴの人はどうしていらん物を提案して高い見積り持ってくるんだろう。頼んだ物をちゃんとした価格で納期守ってきっちり作ってくれたらいいのに」大変耳の痛いご指摘だと思いませんか。お客様にとって必要なものを納期通りにちゃんと作って持って行くことがものづくりの基本。・・・・実は、これが難しいようです。
別に金型の世界に限ったことではなく我々ＩＴ業界の人間にも品質管理はちゃんと理解されていることなのですが・・・・実は、これが過剰なサービスに繋がったり、納期の遅延やコストの増加に繋がってしまうことは多いと感じます。それと困った事のひとつに、お互いの遠慮から来る費用の「見えない化」というものがあります。（見える化の逆・・・）例えば、お客様から貰うべき資料を担当者と相談して作ってしまうとか、仕様のちょっとした変更を開発工程の途中で行い手戻りが発生する等、特に大きな誤解が生じるのは、お客様が、御自身で意思決定しなければならない局面がシステムの開発には幾つかあるということ。ＩＴソリューションを提供する仕事をしている私達ヒューマンシステムですが、特に方針とかデータの振る舞いについては、どうしても企業毎に工夫されているビジネスルールがあることを理解して欲しい。こういう部分では、お互いの思惑が異なるケースが出てくるようです。（酷い場合はお客様の社内でも認識が異なったりすることすらあります）。お客様にとって当たり前すぎて、あるいは、ＳＩｅｒにとって常識過ぎて間違いを見落としてしまいトラブルに繋がることもかつてはよくありました。それはひとつひとつの企業の「おもい」が違うからでもあり、わかりやすくかっこよく言えば企業戦略によって違ってくるからなのだと思います。
そのビジネスの重要な部分については、我々ＩＴの会社が推測するというのは烏滸がましいというものかもしれません。我々ＩＴのエンジニアが、そう言う仕事が出来ればビジネスコンサルはいらないし、本来コンサルタントと名が付く立場の人はこういったトラブルや意見の相違問題が発生した時点で既に自分の仕事にマイナスポイントがついてしまったと心得ています。
我々が多大な時間をかけて創ったそういう方針が本当に十分な物であるのか・・・・作ったとしてもそれを正としてこの先進めていけるのか。その大きなリスクと誤りがあった場合の責任について、ざっと考えても思いつきではすまされないような問題が沢山出てきます。だからこそ、この部分・・・・要求はお客様がしっかりと考えないといけないのだと思っています。
なにより、要求を満たすということが品質管理の「いろは」だとすれば、お客様が要求を考えるというのはその最初の「い」ですから、要求を簡潔に必要十分に伝えるということが大切なことだと思います。全体を通しての要求をお客様から正しく聞き出すことは、本当に難しいことなのだと思います。決して、足し算と引き算ではビジネスの課題を明らかにしてシステムの目指す次のゴールを指し示すことはできないのですから。我々はお客様と最適なゴールとその方法を決めることが仕事の大切な一歩と心得ています。が、しかし、最終的な要求元はお客様であり問題を定義して、一緒に考えた答えを最終的に決定するのはお客様にしか出来ないことなのです。
だからこそ、もっとお客様に仕事の本質を「見える化」する誠意とプレゼンテーションの技術、そしてお客様を思いやる気持ちを大切にしていきたい。社員のみなさんにもそのように考えて仕事を進めてほしいと思います。

日本とアメリカのＩＴ業界を取り巻く文化的な背景

ひょんなことから、「今後のITの行方と日本のIT業界の動向」というレポートのテーマを頂いた。正直もの心ついてからこの仕事以外を知らず、ずっとこの業界にいるのにこんなことを考えたことなどあったかしらと思った。インターネット業界に代表されるIT業界は、様々な産業が互いに関係し合って成り立っているといわれている。
それを簡単にまとめると、IT業界とは、インターネット業界、パソコン・その他ハードウェア業界、ソフトウェア業界、通信関連会社・プロバイダといったキャリア、そして近年需要の伸びが見込めるアウトソーシング業界、教育もIT業界の一部であると考えられる。このひとつひとつの業界が、全面的にグローバルな市場での競争力が低下し、日経新聞の１月６日日曜日の社説にあるようなガラパゴス諸島で絶滅の危機に面した産業となっているのか、また、このＩＴ業界の競争力がかくも簡単にここまで低下してきた背景にはどのようなことがあるのかを掘り下げてみたい。

アメリカのソフト産業が世界で最も強いということについては、誰にも異論がないだろう。アメリカの国内は言うまでもなく、国際市場にも、６0％以上のシェアを占め、絶対なナンバーワンであると言える。アメリカのソフト産業と並び称されるのは、経済実力と科学研究の水準で見れば、アメリカと比較できる国は日本しかないと言われていた。例えば、トーマス・フリードマンの「フラット化する世界」を読めば、彼がいかに日本人のソフトウェア開発力を高く評価しているかがわかる。実際ゲームソフトの世界では、世界を支配しているのは合州国ではなく日本である。いつかのことそう私たちの大先輩の時代ではあるが、日本のサムライは車、家電、LSI製品の領域において、アメリカの牙城を一つ一つに攻め潰していき、これらの業界の世界一になった。しかし、この数十年間、アメリカのソフト産業は世界制覇を続け、その地位は少しも翳りをみせない。それにもかかわらず、日本は、経済・科学技術の大国といわれ続けていながら、そのソフト産業の有名さ、影響力は、インドやイスラエル、最近ではロシア、ベトナム、果ては中国よりも少ない。これはなぜなのだろうか？

ソフト産業は文化と深く関連する産業であるといわれる。アメリカは移民の国であり、歴史は長くない。ただし、普通の人々（日本人が考えるところの）と比べれば、移民達は豊かな想像力を持ち、冒険に好み、チャレンジに好きな人間だと言える。特に第二回世界大戦後、アメリカは世界の各国から数万、数十万の高学歴・高素質の新移民を集ってきて、世界の経済・文化・科学の中心になった。これらの発想が豊かで、創造力を持っている人材はアメリカの経済・科学発展のため、最も貴重な資源となったと言われる。それに、高度民主・自由な環境に置いて、相違の文化・思想が御互いにぶつかったり、争ったり、融合したりすることこそ、価値ある、新創意、新思想が生まれる環境に違いない。その上で、アメリカの先輩の移民が作った合理的な憲法、自由競争の市場体制は、創意の思想に他の国には比べものにならない発展の可能性と環境を提供してくれたのである。

それに対して日本はどうだろう？北海道にいる数少ないアイヌ民族、それに何十万の朝鮮・中国の移民がいることを除いて他に、日本国は殆ど唯一の民族である大和民族から構成される国である。日本国民の一致性はかなり高く、人々が問題を考える方法は、ほぼ同じと考えられている。「言霊」の国である日本は、その単一民族の独特のコミュニケーションとチームワークによって過去の戦いにおいて絶対的な優位性を持っていたのかもしれない。ただし、現代の「言霊」は全て電気的に処理が可能なデジタルデータで表現できさらにその利便性と引き替えに我々は言語化能力を問われることになったのだ。単独民族国家という特殊な条件に加えて、日本は長くて狭い島国で大陸とは繋がっていないので、長い歴史において大陸の影響をほとんど受けなかった。遠隔されていた楽園、これらの歴史的、地理的、人文的な条件によって、日本人は国際化に対する理解、他民族（同一の民族であっても）との交渉については不得意であると言えよう。なにより、現代人の間でも我々は空気をよみ様々なコミュニケーションを取れることが重要とされているではないか。

単独民族で多くを主張することなどなく、暮らしぶりも考え方もかなり類似するこの日本という国の国民には、様々な思想や、意見が激しくぶつかりあう環境はなかった。そしてこの国の中では、それぞれの違った考え方や思想を超えて、それらを支配できる偉大な政治力も哲学も戦略家も思想家も生れる必然性がなかった。それが必要でなかったほどに、この国は安全で価値観が統一された農耕民族が治める平和な神の国だったのだ。

ＩＴは、形の見えないものを形にするという創造力が要求される仕事である。その何ものにもとらわれない創造力や仮説を立てて物事を掘り下げていくようなものの考え方などは、成果と結びつけて考えると日本では成り行きで済ませてきたことがいかに多かったのかということがわかる。本来、かたちの見えないものだからこそ、前提を定めて仮説を検討し、その価値を計り、いくつもの答えの中から、最善の解を選び取っていかなければならないのだ。その答えを導き出すプロセスをいかに早く、沢山の可能性を考慮して判断することが出来るようになるのかが重要なことなのである。

これらの、歴史的文化的な背景は日本のＩＴ業界が、現在世界市場においての影響力を低下させてきた要因のひとつではないかと考える。次回は、それに加えて日本のＩＴ業界がどのようにして成長し、現在どこにその需要が見込まれるのか、問題はどこにあるかそして、我々はどこを目指しているのかについて考えていきたいと思う。

今週は、大寒ですね。東京でも雪が降るなどという噂もありますが、どんなものでしょうか。寒いときには、暖かくしてください。みなさま風邪など召されませんように。

お客様のビジネスを支える技術とは

全体研修が終わり、ようやく師走になった気がする。気がつくと１２月１０日、それでなくともクリスマスのお休みとお正月休みで短いこの一月の半分は過ぎてしまったような気がするのは私だけではないだろう。

コミュニケーションをプロジェクトマネージメントではルールを定義しそのルールに従って動くことでシンプルかつ効率的にしている。しかし、ここにひとりひとりのきちんとした目的意識と実施できる技術力、共有された情報がなければ、このルールは逆に大きな足かせにもなり得る。

我々の目的は、お客様のビジネスを支えることお客様に付加価値をもたらすシステムを構築することである。だから、我々自身も、常に生産性を高めよい品質のものづくりを行なっていくことが必要である。お客様の為に良い品質のシステムを創る技術を磨いているといっても過言ではない。

研修のまとめはまた、来週にでもレポートするとして・・・久しぶりに、先生のとなりにいていつもの問いを頂いた。「あなたは、品質の低下と人材の流出、受注力の低下のどれが心配なの?」昨年の今頃、卒業研究の発表の時に常に、何度も問い続けられたこと。そのときは、今日と全く別の答えを出していた自分を私もよく覚えている。

その頃は（つい最近まで)、人材の流出こそが大問題・・・だと思っていた。人数がいなければ良い仕事をしても継承できないし、継続的な成長などは望めない。実際のところ、ソフトウェア会社の多くは、人が最も大きな財産で人こそが付加価値の源泉で、技術や品質を支えるものである。それに加えて、人を大切に思うからヒューマンシステムという会社の名前がついたぐらいなのだから、これが一番大切である。そう思っていた。根本的にその考え方は、今も変わらない。当時はだからこそ、社員に好条件で働いてもらう為に付加価値を上げなければと焦っていた。そういう私に付加価値=売上－原価、原価は固定と変動に分かれるのだから、固定費を下げるには給料を下げるか、リストラするか・・・それが最も一般的なやり方である。そんな冷酷な答えをと現実の問題を幾度と無くさらりと指摘されたこと。本当に昨日のように覚えている。

しかし、今回の私の答えは少し違っていたのだ。「一番というのであれば、品質だと思う。品質を適正なレベルに保てなくなると優秀な人材が辞めてしまうでしょう、お客様もはなれていってしまうでしょう」・・・最近のいろいろな事件に対しての自分の偽らざる気持ちだった。幸運なことにこのケースはまだ弊社ではそれほど多くは無くて、どうしたら品質を上げられるかに取り組むひとが沢山いる。品質に拘る人が、お客様の喜ぶ顔が見たくてがんばる人が、この会社には沢山いるということはとても嬉しいことだ。それこそが、我々の強みだと思う。

もしも、疲れて倒れそうになったら、少し休んでまた走り出せる。いまは、まだそんな会社でしかないけれど・・・すこしずつ、経験を積むことで予測できることは多くなるだろう。技術は品質の重要な要素だ。そして、技術に裏付けられた確固とした品質を作りこめる人材を教育することが最もヒューマンシステムが大切にしていることなのだ。

我々はコンサルタントのように近い形の無いものを形にするという仕事の品質と、より構造的にわかり易く開発しやすくメンテナンスしやすい構造設計の品質、そして、最も地道な品質の作りこみが要求される製造フェーズ（詳細な仕様を明確にしてソースプログラムを作り単体テスト項目書をつくり、単体テストを実施してテストの結果を整理して報告する工程）の品質、網羅性を求める結合テストの品質、お客様の立場で考え運用をイメージする総合テストの品質。それぞれのフェーズで、同じシステムの目的のためにゴールとして定めるものの観点は異なるということ。それがソフト開発の難しいところなのだと感じる。下流の品質は、どうしても上流の責任においてその品質が担保されないといけないということ。そして、いろいろなリスクを正しくコントロールして対策案を立て、提案もできるということ・・・そういえば「気が利いている」そんな一言で表現したお客様もいらっしゃった。

私は今年、ある仕事で先生からそれらの大切さ、教え方、見守り方、フォローを学ぶことができた。あらゆる可能性を考えて、一つの答えを出す責任がプロマネにあるのだということ。決して品質に係わることを丸投げにしない責任感。そして、常に鮮やかなゴールを決めることのできる集中力を持ち続けることの大切さも。何度かのミーティングに同席してようやく自分の甘さを痛感した。ビジネスコンサルはビジネスの責任を一手に担う。そこで学んだ厳しさ、クオリティーを高める管理についてそのあと少しは、実践できているだろうか。

今年も沢山の汗と涙と・・・いつかそれがみんなの力になることを信じている。
今週も、よろしくお願いします。

コミュニケーションはプロジェクトの成功の第一歩

成功しているプロジェクトに多く見られる共通点は、プロジェクトのメンバーや関係者がプロジェクトの目的を正しく理解し、それぞれ課題やリスクを共有し、自らがその発見に努め、そして解決に向けて能力を発揮しているということがある。ポイントとしては、主体的な働き方になるという特性がある。さて、みなさんの参加しているプロジェクトは、みなさん自身はどうだろうか。

　ひとりひとりが自分の仕事と線引きした（もしかしたら勝手に）範囲に留まっていて、作業はプロジェクトマネージャの指示待ちという状態になっていないだろうか。このような状態に陥ると担当者間で作業の漏れや重複などを引き起こす一因となる。プロジェクトマネージャとして、メンバーが自分で考えて仕事をして貰えるよう配慮することが必要である。

　他の業界のプロジェクトと比べて、プロジェクトマネージメントにかける人員の数がＩＴプロジェクトの場合には比率的に少ない。たとえば、エンジニアリング会社のプロジェクトでは、メンバーが350人でプロジェクトマネージメントオフィスが50人・・・１／４もの人間がマネージメントをしていると聞く。例えば、ＩＴアーキテクトと兼ねるプロジェクトマネージャが弊社では多いのだけれども、これはやはり大変なことかもしれない。
　こんなとき、有効な手立ての一つとして朝会がある。毎日時間を決めて昨日の進捗を確認し、今日の作業を確認しあうこれは作業効率を上げるとともに忙しくて不足しがちなコミュニケーションを補間すること意味でも良い方法である。また、忙しくて時間が取れない、あるいは質問が要領を得ないということを解決するために、私達は課題表を社内で作るということを重要視してきた・・・課題はみんなが共通に思うものも多いから、だれかの課題をみんなで共有できたらとても便利。

　さて、そういう様々なコミュニケーションを上げる工夫をしたとしてもやはりベースとなる知識が同じでないとなかなか仕事がスムーズに進むことはない。そういう意味で、今回の全体研修では、プロジェクトからみたコミュニケーションマネージメントを前半としてとりあげる。それと後半では、もっともっと応用的なところでお客様や上司に嫌われないで自分の意見を伝える・・・営業の極意を特別にご教授いただけることになっている。

　コミュニケーションは、楽しく良い仕事をするために必要なものだから・・・
ひとりひとりが、できること。プロジェクトマネージャができること。みんなで考える全体研修にできればと考えています。

今週もよろしくお願いします。

徹底させよう！結合テストは最後の砦

ここ数ヶ月、Ｎプロジェクトのメンバーは本当によくがんばってきた。そういう意味で、結合テストの問題の多さなんか目をつぶりたい・・・その思いは、そばで見ていた私も同じ。でも、この結合テストっていうのが品質の分かれ道のような気がする。多分、それは普遍的な真実。もう少しだからがんばろうね。

テストリーダほど因果な仕事はないなぁ。同じ会社の隣で開発しているメンバーがどんなに大変だったか、一緒に設計していた彼らがわからないはずはない。同じテストを繰り返すことも、少し違うテストをするとまたいろいろな問題が起こるということも、幾度となく繰り返されたことなのだけれども、まだまだ、どこの開発の現場でも繰り返される。デジャヴ（既視感）を感じるのは私だけではないはず。

●単体テストの品質が悪い
●結合テストがとばしながらになっているので精度が低い
●横展開の不足
☆テスト項目とバグ表のリンクがとれていないので再現テストができない
☆直した後で、バグの確認がとれない

そうしてこういうことが必ずテストチームからはあがる
「こんな賽の河原みたいなことやってらんない。」
テストしてもバグが繰り返されるのでテストチームも疲弊してくるのはわかる。しかし、一般的に結合テストでは、これらの問題を全て解決しておくことが重要だということは、その先のシステムテストひいては運用が開始してから、いろいろと身にしみて明確になってくる。

以前に結合テストが最後の砦という朝礼メールを書いたことがあった。本当に毎回デジャヴだと思う。

しかし、今回はおもしろい発見があった☆の項目なのだが、今までどんなプロジェクトでもこんなことは見たことがなかった。このプロジェクトでは、障害管理ツールも今までのエクセル版の障害ツールも使っていなかった。これは、新しいパターンかもしれない。
おそらく、短い期間で仕様変更が多発してその仕様変更の管理と同等に障害を管理すればよい。そう思ったのだとそれはなんとなくわかった。・・・その閃きは決して間違いではない。この仕様変更と障害を一元管理したいという要望は決して特別なことではないのだから。しかし、障害を対応するというプロセスの認識が、この場合薄かったのだろうか。そのあたりになると経験と失敗の数の問題なのかもしれないし、もともと、障害を確認することがどれだけ重要かの認識がされていなかったということなのだろうか。

障害を発見して、直して、確認して、リリースして、さらに本番で確認する。
これが、こんな基本的なことが理解されていないと言うことなのだろうか・・・。

そういえば、イトウヨーカ堂の話を聞いたことがあったのでその話をしようと思う。
以前、ロッカーの鍵のかけ忘れで社員のものが無くなったことがあった。ロッカーの鍵の施錠は会社のルールだったと聞く。それで、社長からロッカーの見回りをするようにという指令が出た。各店舗の総務部長はロッカーの鍵の見回りをし、1週間でどの店舗でもきちんと鍵がかかっていることが確認できた。その報告を鈴木社長に報告したところ、まだ見回りを続けるようにと指示があった。・・・・徹底したあと1か月見回りを続けたと聞く。

そうか、足りないのはこの徹底させるということなのか・・・これは、社長の仕事の重要なひとつに違いない。
今問題が発生しているとしたら、いろいろなことでなにか繰り返でそういった問題が起こっていると感じたら、ものごと徹底しているかについても確認してみるべきなのだと思う。

徹底させることは、なかなか大変なこと。だけど、徹底させてください。結合テストは最後の砦。必ず納得いくまでテストを実施し、品質見解を作り品質を見極めること。そういう地道な積み重ねが12月のカットオーバーまで続くのです。
徹底させることの難しさを今回の仕事を通してみんなと共有できれば、徹底できればよいと思っています。

といいつつ・・・また、帰りの退出者の記録を書かないで来た事に気がついた私です。
でも・・・気を取り直してまた明日から頑張る。自分自身もいろいろと徹底できてないことだらけだけど。

今週もよろしくお願いいたします。

モノづくりの危機ってどこにでもある

実は、先週この話を掲載しようと思った矢先に・・・目の前の危機って言う感じのことが起こってしまった。まだまだ、私たちの思いは、志し半ばという感じなのだけれども。
でも、「お客様のビジネスを支えるシステムを創っている。」そういう気持ちは無くさないでいたいと思う。いて欲しいと願っている。私たちは、お客様の利益から開発費を頂いている。お客様のビジネスプランを支えるシステムを自分たちが、責任を持って創っているそんな気持ちを常に持ち続けたい。我々の仕事上のひとつひとつのミスが、どれだけお客様に迷惑をかけているのか、真摯に受け止めることが必要だと思う。どうしてそんなにミスを繰り返すの？約束した手順を守らないの？報告が出来ないの？問題が起こるとなにか、抜け出せない迷路に迷い込んでしまったようにリカバリーがきかない。障害は連鎖する。他山の石だと思っていると足元をすくわれる。

日本経済において「モノづくりの危機」がいわれて随分たった。ミートホープに至っては、モノづくり以前の問題じゃないかとも考える。日本の職人文化というものについては、例えば江戸時代の驚くべき多様な職業をみてもわかると思う。酒屋、下駄屋、草履屋、ランプ屋、米屋、瀬戸物屋、花屋、ブリキ屋、豆腐屋、仏具屋、魚屋、鰹節屋、乾物屋、紙傘屋、荷鞍屋、古着屋、扇屋、屏風屋・・・・実に驚くべき職種があってそれで生計が成立っていた。マーケットは、これらの職人の出店でにぎわい、だれが作った扇なのか傘なのか下駄なのかはっきりとしていてそれぞれの仕事に責任を持って棲み分けが進んでいた。コンビニエンスなんていうような顔の見えない流通というのはなかった。“職分”という原則のもと素晴らしく仕事に特殊な愛着を持ち、社会に貢献し、満足と責任を伴う一定の地位を占める・・・いろいろな仕事に対して、その仕事への自信とこだわりを持って密度の高い仕事を仕上げていくそんな社会がそこには確かに存在したのだ。

最近、お客様に付加価値を生み出すのが技術であるということ、技術をサービスに変えてということを言っては来たものの弊社においても「モノづくりの危機」というものを感じることが多くなった様な気がする。例えば、単体テストの網羅性一つとっても随分と最近の障害の報告を見ていると低いレベルのものもある。これは、教育不足から来るものなのだろうか。個人的な問題と考えたほうがよいのだろうか。それとも、会社としての問題と捉えるべきなのだろうか。
面接で、「技術をサービスにかえるとしてもそのもととなる技術を磨く必要があると思う」そう主張したＰＭの力強い言葉を思い出す。弊社の社是は、「技術、おもいやり、豊かな人間性」この最初に技術を掲げているのは、実はこのことに通じている。

１５年前、バブルの崩壊後の大不況の中で全く何の後ろ盾も持たなかった、私たちヒューマンシステムにとって「技術」お客様の望む技術を提供すること。それが唯一の拠り所だった。それは今も、なにも変わらない我々の企業ＤＮＡに組み込まれているものだと思っている。
自分の仕事を誇れること、それが自信に繋がり、次の誇れる仕事に繋がる。チャンスをモノに出来るかどうかは、仕事への拘りであり自分のプロ意識に他ならない。そのプロ意識を持って仕事をしているからこそ、ちゃんとしたサービスが提供できるのだと思う。

Excelenceの自信なくしてそれが自分の仕事と言えますか？

行き先表示板の行き先

Ｓ君からメールを貰ったのは、丁度４月のはじめごろだったと思う。
常駐していたところで使っていたログインもしないで出来る行き先表示板をちょっと自分でも作ってみたので会社でみんなに使わせて欲しい。というようなものだった。（何故会社にいるのにメールなのかと言えば私が席に不在だから）折角、大切な余暇を費やして作ってくれたプログラムだから・・・ＯＫをだした。
５月から少ない人数で運用が開始されたある日こんなメールが届いた。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＜ここから＞
行き先掲示板の試験運用を開始して２週目に入りました。
現在、行き先掲示板の更新率は50%程度です。
予想通りの残念な結果です。

いきなり「行き先掲示板を作ったから使って下さい。」では
ご協力を仰ぐのに無理があったかと思います。申し訳ありません。
行き先掲示板を利用する事による利点を説明します。

ずばり、外出する人が行き先掲示板に記入しても利点はありません。
よって今のように更新して貰えない状態になっているのは、ある意味自然な流れです。
しかし、ちょっと待ってください！
社内に残る人にとって
貴方が何処に行って、何時戻って来るのかは重要な情報なのです！

------ ～用件はいつ片付く？編～ ------

例えば、
貴方に用があるAさんが貴方の席まで探しに来ましたが、席には不在でした。
そうなると、その用件は後回しになります。
問題は「どの程度、後回しになるか？」です。
少し席を外しているのか？　ハラビルの会議に出ているのか？
それとも外出しているのか？　または有給休暇を使っているのか？

貴方が何時戻って来るかが分からなければ、
Ａさんは今後の仕事の予定が立てられません。これは困ります。
もし「外出していて、そのまま直帰する」と行き先掲示板に記入されていれば、
Ａさんは「じゃあこの件は明日の朝にして、今日は帰宅しよう」
という予定を立てることも可能になるのです。

--------------------------------------

どうか行き先掲示板のマメな更新にご協力をお願い致します。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＜ここまで＞

とってもよいメールでしょう。問題提起としても良いし・・・。
最初、ご存知ヒューマンワークスにも同じような機能があるので私は、どうしたものかと思った。同じ機能がいるのかなぁ。しかし、Ｓ君の熱意を感じて使う事に同意した。なにより、まだ新バージョンがテスト中だったから。
けれどもこれは、かえってＳ君（ヒューマンワークスのメンバー）の理解を深めるのに好都合だったと思う。
ヒューマンワークスの行き先表示板もＳ君の表示板も本当の目的はひとつのように思える。

Ｐ２Ｍのプログラムマネージメントにはプロジェクト統合の考え方というのがある。プロジェクトの全体の目的（全体使命の達成）の為に外部環境の変化に対応しながら、柔軟に組織の遂行能力を適応させる実践力のことです。この実践力の役割は、プロジェクト間の関係性や結合を最適化して、全体価値を高め、使命を達成する統合活動にあります。この統合に対しての考え方が全体の成功を左右するといっても過言ではありません。

プロジェクトマネージメントやプログラムマネージメントでは、価値を創造することや価値を高めること、使命を達成することを第一に考える。これは、目の前の問題ばかりに捕らわれずに高い視点と広い視野で考えることが必要である。

この２つの行き先表示板は、いい感じに統合出来そうな気がする。・・・Ｓ君少し私と話をしよう。
きっと、君ならわかってくれると思うから。

表現することはどうして難しのか

ある本を読んでいたら立花隆がこんなことを書いていた「ものを書くというのは、材料の仕込みがあって、それから自分でその材料から何かをつくり出して送り出す。要するに僕自身に情報を入れる仕事外に出す仕事があるわけです。」ほう・・・だから子供のころに本を沢山読むように言われたのかしらと思う。そういえば、卒論の前に毎週のように課題図書を渡されたのは、きっとこういうことからなのだと今さら思い当たったりした。
ものを書けない人の多くは、やはり情報がまだ足りないことが多いのかもしれない。提案書にしても報告書にしても書けない=問題があると断定的に言われたりするのもきっとそういうことからなのだと思ったりした。今週は、沢山の発表用のパワーポイントに追われていてなにかこのブログに書く内容が枯渇してしまった気分であった。
そんな今日はもう木曜日で、昨日は恒例のプロジェクト進捗会議であった。今回のプロジェクト進捗会議では、ある公共関係のプロジェクトで開発のスケジュールがとても厳しい中を半年で運用開始で弊社担当分のバグ０というプロジェクトから、どのようにして品質向上の活動を行なったかの発表があった。こういう、人達はきっと話す中身が充実しているのでこんなにも上手く表現できるのだと感動した。プロジェクトは、個別性と不確実性、複雑性を持ち期間が限定されているものなので、その制約の中でＱＣＤ（品質、コスト、納期）を管理することは難しい。今回のプロジェクトは設計が1.5か月で開発が２か月という期間的な制約が大きい中で発足したプロジェクトで参加したメンバーは本当に大変だった。しかし、その中でも几帳面に約束を守りながらお客様のスケジュールにしっかりと合わせられた事・・・このプロジェクト全体のムードメーカーとしてもリーダーシップを発揮してくれた・・・そうお客様からも誉められた。スケジュールをキープできないともしも弊社が手を上げたら・・・・他の会社もそれに続いて３か月は遅れただろう。そんな話を先方のマネージャから聞いた。なによりも、開発の納期終了後まで、品質向上に人を1か月キープしてくださったそのお客様にも感謝している。
ＱＣＤ（品質、コスト、納期）を管理することは難しい。だから、例えばコストの枠組みはできるだけ考えなくしてあげたら品質がよくなるのではないかと思いついたことがあった。そして、極力そういったプレッシャーを外してあげた時期もあった。最近も、それに近いプロジェクトがある。しかし・・・・結論からいえばそれは失敗することが多かった。理由は、コストの枠が外されるとどうしてもお客様の要件をストップする・・・いやお客様が要件を整理して必要なものだけを考えるというようなこと、早く仕様をもらって段取するというようなところに悪い影響が出てしまう。そうして、納期がずるずると延びて結局は品質の問題になってしまう。走りながら考えることもそれはできるものもあるのだけれども、これだけ複雑なシステムが増えてしまえばとても難しいことなのだ。
例えばこんなこと。「テニスコートを受注して競技場をつくるという例題」について考えてみよう。テニスコートを作ってくれということでコンペでテニスコートを受注したとする。我々ＩＴ業界では、この受注までにもプレゼンでいろいろなことを説明して受注してくるのだが・・・その担当者と開発のプロジェクトを担当する人間は違ったりする。プロジェクトの担当は、「この会社はまたテニスコートだのサッカー場だの発注してくれるかもしれないから、うまくやって良い関係を構築してくれ。」こんなことを社長から言われたりもするのでまず「どんなテニスコートを作りたいかイメージを説明してください。」そうお客様に聞いてみる。「屋根がついて、椅子もつけて、売店も必要で、更衣室には当然パウダールームも・・・」そう言って説明されたものはとうてい受注額では作れないものだとプロジェクトリーダは思う・・・ここで、彼が生産性や技術力や過去の資産などの魔力に頼ると大変なことになる。そもそも、テニスコートってなんだろうこのプレゼンに含まれる機能はどこまでなのかイメージが出来なければお客様にオプションとしての選択指を提示することはできない。オプションを過去の資産（モジュール群）から作れなければ、過去の資産による生産性の向上などということは全く見込めない。その結果、全てが新しい設計でそれは評価されていない新しい部品での開発となり結局は品質を低下させたり、納期を厳しくさせたり、大変な労働時間になったりしてしまう。
最善の方法を決定する為には、ビジネス・・・要件と優先順位とコスト、時間といった制約事項を明かにすることが必要なのだ。こういった部分についても中身をしっかりと吟味して、お客様にきちんと表現できなければと思う。

特にリリース前であってもプログラムの変更は影響範囲の洗出しの時間を見ておかないといけない。そんな絶対に必要で簡単なみんなが知っているルールさえ、もう説明できなくなっていることがよくある。その氷山の一角の下に隠れている冷たく大きな氷塊に思いを馳せて、お客様に論理的に説明できるように考えてみてはどうだろう。

今週も、よろしくお願いいたします。

サービスを提供する為に大切なこと

先週、お客様にサービスを提供するものとしてとても悔しく、残念なことがあった。このことを私は、真剣に重く受け止めなければならないと感じている。お客様は、ＲＦＰによるコンペで我々を沢山の業者から選んで下さった。それは、我々がその業種に特化していたことと我々の熱意を信用してのことだったと思う。この時には、会社として選ばれたという思い・・・その嬉しかった思いは、プレゼンに立ち会ったメンバー全員のなかにしっかりとあったと思う。

開発が終わり、グランドオープンを迎えた頃から、その気持に少しづつ変化があったのだろうか。システムのトラブルが多発する。その時に、我々は運用を見越した体制に切り替えることが出来てはいなかった。これが、最大の問題だったように思う。運用と言う業務は、責任ばかり重くて決して楽しい仕事ではない。できてあたり前、できていなければ今回のように大きな問題に波及してしまう。しかし、この仕事はお客様のビジネスを支える意味でとても重要な仕事であることは間違いない。

お客様のビジネスは、カットオーバーと同時にスタートしている。安定した運用ができること。これは、いかなるサービスにおいても重要なポイントである。フィールセーフ（フィールセーフとは、もし機械・設備に故障が発生した時に、安全側に故障する仕組みをいう引用。）この言葉は、丁度昨年の今ごろもこのブログで取り上げた問題だった。

アーキテクトはお客様に代わって、目に見えないものを見える形にしていくのが仕事である。ＩＴアーキテクトは、本来のそういった具現化ということだけでなく、ビジネスプロセスを形にすることも重要な仕事のひとつである。運用をイメージした設計とは、使う人のビジネスをイメージした設計なのだと思う。ＰＢＲも結局は、この運用を明らかにするひとつの手法でしかない。システムテストもサイクルテストも広義での目的はこのビジネスを支える運用をゴールとしてのことである。

一方では、プロジェクトはひとつとして同じものはなく、しかし、ＩＴ化には必ずトレンドがある。運用のトラブルの予兆を見つけることは、実は、そう難しいことではない。それは、ひとつだけの条件を満たせば・・・。その条件とは、問題の本質を見極め広く情報を共有することができればということである。我々は、沢山のお客様の信用を得て現在がある。時には、トラブルも発生させてしまうことも、言葉足らずでお客様を怒らせてしまうこともあるかもしれない。しかし、その連鎖はどこかで断ち切ることが必要である。その為に、その連鎖をプラスに替える為にこそマネジメントシステムは必要なのである。

私が、最近深く反省するのは、私自身がこのマネジメントサイクルを今まで狂わせてきたのではないかということ。・・・しかし言い訳だけど、キャリアの違いということが今までは大きかったから、仕方なかったこともあったとは思う。引継ぎをしている担当よりも、一言二言で聞いた私のほうが、本質を見極めるのは早いことも多かった。そう、今までは・・・。しかし、これからは、もっともっと私の引き出しをみんなに共有しなければと思う。私が考えていることを感じていることを伝えなければと思う。それが、サービスを提供することに大きな力となるはずだから。そうして、みんなは、その引出しをいかに活用するかをもっともっと考えればよいのだと思う。少なくとも、この会社のＳＥで私よりも経験がある人は、ほんのわずかのはず。

サービスを提供するものが一番大切にしなければならないことは、無我の境地でお客様の運用を考えられるということかもしれない。そこには、だれかの能力ではなくお客様に対する責任とお客様のビジネスに対する思いが重要なのだと思う。そのスイッチをきちんと切り替えられることが、本当は大きなポイントではないかと思う。スイッチ入ってますか？その判断はお客様のものと同じですか？

今週も、一週間宜しくお願いします。

「質問から派生する疑問に応えること」

○ある夕方のＮマネージャとＯ君の会話から
「ＩＤと番号って両方とも一意の数字なのにどう違うのですか・・・」
「ＩＤはDBアクセスに使うプライマリーキーで数字、番号は表示用で文字」
確かに・・・正しいけどちょっと待って!多分、その答えは、正解だけどすべてじゃないのです。質問者の引っかかりは、本当は別のところにあったのだよね。「どうして、同じ値の２つのフィールドが存在するのか?」きちんと単体テストをしている彼は、このフィールドの存在意義にふと疑問を持ったのだ。最近、こういうささやかな疑問に対して答えだけを教えてしまっていないだろうか。毎日、仕事に追われて納期に追われている人が多いのかもしれませんが・・・まぁちょっとだけ話を聞いてみてください。

○質問と疑問
ＩＤと番号の説明は、実は上記の説明で十分なのですが、実は質問者はその本質に近いところで疑問をもったのだと思います。コッド博士のＤＢ設計の第一正規化の目標は、繰り返しを排除し冗長な構成を無くすること。彼の質問は、とても理屈にあった質問だったのだ。同じようななにかの番号を扱うフィールドが２種類あるということは正規化の目標からは外れています。そういう意味で、とてもポイントをついた良い質問だったのです。

○本質的な疑問に応える
回答者は、その使い方を適確に説明しています。ＩＤはDBアクセスに使うプライマリーキーで数字、番号は表示用で文字です。これは使い方の説明としては正しくて実務的です。でも、どうしてこうなっているのか？と考えてみて欲しい。こういうテクニックはよくシステムの現場で使われる方法でとても一般的なやり方なので応えられなかった人はここで覚えて欲しいです。番号（一般的にはコードが多い）という項目は、お客様がつけている番号であってお客様の業務の都合で変更されてしまうことがある。たとえば、企業の合併によってとか組織の変更によってとか新しいシステムになったからとか・・・・。そんな経験を活かして表示項目を文字型で設計し、ＤＢのリレーションはキーであるＩＤを使用するというふうに設計することが多い。だから、２つの項目になっているのだ。

○疑問から学習し次の為に活かす
一歩進めてみて、このような質問を改善活動に繋ることはできないのかと考えた。エンジニアとマネージャは常に学習の視点を忘れてはならない。この「ＩＤ」と「番号」というフィールドをＤＤに明記しておくこと。ドメインの設計を行い設計書をまとめること。表示用の場合は説明にも明記すること。そんなことを思いついた。それと、基本は冗長構成を外して行くことなのですから、この方法でなんでも２重に項目を持つというのは間違いであり、できる限り、一意の情報を見つけてプライマリーキーにすることの重要性も同時に説明してあげたい。

○1980年代～1990年代の日本の技術力を支えたのは
よく聞く話だけれども「Ｊａｐａｎ　ａｓ　NO.1」の時代には、日本人は技術指向が高いまじめに働く人が多くて、その働き手の意識の高さが日本の経済活動を支えて来たと。トヨタの改善活動もそうだし、アメーバ経営だって根本的には同じ根っこを持っている。だからこそ、年功序列の高度成長が実現できたのだと最近は特に思う。草の根活動・・・現場からの改善活動から生まれた工夫が日本の技術力を支えて来たと聞いている。ＩＴの世界でも、その中に含まれるちっぽけな私たちの会社でもそういう現場感や実務能力を高くして行かなければと思っている。考えることをやめてはいけないなぁ。どんな時も、考えることこそが我々の経営資源なのだから。

○我々の目指す技術と取り組み
ＩＴのプロジェクトマネージメントにおいては、新しい技術にいち早く対応しその技術を広めて行くことが一番大切なことだった。それは、そういう開発の現場力の集合であり、プロジェクトマネージメント用語を知っていることでも、経済活動に長じていることでも、戦略に詳しいことでもない。ＩＴ主導型、ＩＴ環境型の社会では、我々のそういう智恵がきっとナレッジとして付加価値に繋がる。実務家として血の通った（知の通った）現場の課題を解決する為の方法を学ぼう。真剣に考える姿勢を続けよう。生産性向上は、実は経営革新の為ではなくそういった目的意識の共有の為にも必要なものなのだから。ちょっとした生産工場では、ストップウォッチと万歩計が必須です。ラインの効率化を一歩の歩数から問題を抽出し改善して行く。一日１５分の生産性向上を考えると弊社では１日２５時間、1か月３人月のコスト削減に繋がる。粗利率を仮に30％とした場合、９人分の粗利が稼げてしまう。こうして時間を作ることが、豊な人間性を育みいろいろな疑問に応える為には必要なのではないか・・・そう思う。そうして、そういった取り組みが無いＩＴ会社がお客様の生産性向上のお手伝いはできないに違いない・・・そうも思う。

プロジェクトは不確実性の高いものだからこそ、常に考えて常に問題を掘り下げて深いところで捉えられるようにしたいものです。質問から派生する疑問に応えることは思いも寄らない問題を明かにしいろいろな学びの機会を与えてくれます。もしかしたら、表面化していない問題を明かにすることができるかもしれない。
時間がない時は、私まで持ってきてくださいね・・・出したことのない情報が引出しにまだ少しはありますから。

今週もよろしくおねがいします。

「サービスを買って頂くものの宿命」

ＩＴサービス業は、どんどんものつくりの仕事からサービスを売る仕事へとシフトしていることは、常々感じることである。先日も、お客様の打ち合わせで弊社のＩマネージャがさらっと構成を説明した。その後にエレベータホールで２人の間でこんな会話になった。
私「どうしてＡ技術を採用しなかったの？Ｂ技術より新しいしお客様の前回の指摘は問題が違っていたんじゃなかったの？」
Ｉ・マネージャ「それは理解していますし、説明もしていますがどうしてもＢ技術にお客様が拘られましたので、また、Ａ技術の場合にどうしてもポートを空ける必要があります。わかってます。それは大きな問題とは思いませんがなによりも、お客さんが納得される方式を採用したいと思ったのです。」

なるほど、たしかにＡ技術とＢ技術だけに拘るのであればＡなのだが、バランサーを内と外に配して最強のバランシィングを施しているのだから、問題は起こらないに違いない。正しい状況判断だ。いつもギリギリの予算のシステムばかりで、パフォーマンスを技術だのみで乗り切ることが多い他のプロジェクトとは訳が違うのか・・・。いつから、こんな腹芸ができる人になったのだろう。まだまだ若いＩマネージャがにっこりと微笑んだ。本当に若い線の細いスマートな彼にこんなコンサルタントの秘密を教えてもらうとは・・・ちょっと感動した。まかせきりだったけど、本当に期待どおりに（それ以上）よくやってくれている。どこでこんな技を仕入れてくるのかしら、○○さんかなぁっと彼と一緒に仕事をすることが多いお客様でもあるマネージャの顔が浮かんだ。昔、「君は、技術で勝っても勝負で負けてる・・・」ってよく叱られたことを思い出す。

この間ある国内銀行系大手のコンサルタント会社のコンサルタントのお話を伺う機会があった。その方は、大学卒業後ホワイトカラーとブルーカラーという別の組織を持つメーカーには入りたくないということで百貨店に就職された。経済学部卒なのになぜか給与計算や人事畑を歩くことになり、百貨店系列の関連会社の給与や人事面の企画、労使関係の調整などのコンサルティングもおこなうようになっていた。そのなかで、新聞広告の○○○総研コンサルタント募集という広告に惹かれ現在の職場に転職された。その後、人事、総務、財務、経理、システム系と言われるインターナルな分野と戦略、マーケティングといったエクスターナルな分野の両方の経験を積まれて現在に至っているということ。

なにに驚いたかといえば、最初のご挨拶だった。
「みなさんの抱かれる「コンサルタント」のイメージ、その華麗な、派手なイメージには、私はあまり合っていないかと思います。実は、私は昨日から帰っておりませんで一睡もしておりません。徹夜で仕事をしていました。本日は、午前中は、千葉のクライアントへ行き、午後は銀座、それから（１８：３０～）ここでお話をして、終わり次第、会社に戻って部下の人事評価を行います。昨夜から寝てないというお話をしましたが流石にそのままですと気持ちが悪いので常に用意してある、置きシャツ・置きくつした、置き下着を持って秋葉原の玉の湯でお風呂を浴びてからクライアントに行きました。」（ＩＴは３Ｋとか聞きますが、コンサルタントも大変そうですよね。この方は絶対間違いなく40歳以上だった）

お話のなかで、無形のものを売る難しさについてのお話とか、様々なお話をして頂きとても勉強になった。その中から幾つかのお話を抜粋してお話したいと思う。

○ヒアリングとインタビューの違いについて
fact（事実）を集める為にインタビュー調査を行うのだが、インタビューとヒアリングの違いは、聞くほうがシナリオを持って聞くのがインタビューであるということ。お客様側にプロジェクトを作ってもらってミーティングを実施する。ただ、ヒアリングを重ねても事実にはたどりつかない。（・・・仮説を立ててこちらがリードしてインタビューするということね。Ｐ２Ｍでも習ってるよね。納得。）

○コンサルタントの意識すること
胡散臭さ・・・総○屋の定款には必ずコンサルタントと入っているという話から、そういう胡散臭さを払拭する為にはどうするかを意識する必要がある。メソトロジーはきれいだけどこだわらない。外見には、こだわる必要がある。(相手の会社の雰囲気にあわせる。広告代理店ならブランドスーツ・工場ならグレーの地味めのスーツと使い分けが必要) ロジックの首尾一貫性が必要である。そういうことで、信頼を得るということ。

今日この工場に人事コンサルティングに来た。例えばコンサルフィーが１０万円かかるとして、１００人の工員に10本づつ焼き鳥をもって帰す以上の成果を上げられているだろうか?そんな風に自問する。こういった気持ちが大切だとその方は仰った。（正直、涙が出てくるぐらい共感を覚えた）
ある人から、「人事コンサルティングで経営側と現場の意見が違う場合・・・クライアントである経営を優先するのですよね。」という質問を受けた時の回答にまた、とても感動した。「私は・・・確かに賃下げもしたことはありますが、働く人に最善の方法を提案して来たつもりです。人を幸せにする人事組織をつくる。その志を無くさないようにしています」と。おそらくその人は、働く人あっての企業ですからというような意味を含めて仰ったのだと思う。経営の本質として人事という分野があり、その方面の経営を熟知されている方なのだと感じた。

その先生も、私が教えていただいているＰ２Ｍのコンサルタントの先生も、顧客満足度把握術は、常にちょっと上を行くことと教えてくださった。Ｉマネージャの判断は、そういう意味でも正しくて納得のいくものだったといえる。彼は、パフォーマンスまで考慮にいれてＢ案を採用したのだから。こういうことも、ちゃんとした経験値がきちんと彼に蓄えられているからなのだなぁと思った。地アタマのよさ+経験値+志・・・これがスペシャリストの成功する為に必要なことなのだね。いや、サービスという無形のものを買って頂くことを生業としているものにとって必要なことなのだと強く思った。

地アタマで勝負する人も、経験値で勝負する人も今週もよろしくお願いします。

「視点を高く広い視野でものごとを考えるには」

最近、景気が上向き基調であらゆる企業で業績の底上げ感が感じられます。しかし、企業の競争力を短期的な業績だけで判断するのは非常に危険なことです。短期的な数値だけではなく大局観から、経営の本質を考えることが大切な時それが現在です。一方で、ものづくりの経営は複雑で難しくなって来ているといわれます。これは、ＩＴの分野においても同様で、大量生産的な難易度の低い開発は、ほとんどが中国やインドに流れています。面倒な仕事や、厳しいスケジュール、仕様が未確定で試行錯誤しながら開発するものなど、とかく個別な対応が必要なものだけが、国内で開発されていくと考えて貰う方が正確というものです。

技術を構築するには長い積み重ねが必要ですが、市場の動きはそれを待ってはくれません。長い時間が必要な技術開発とスピードが優先されるマーケットの変化をどのように融合してプロジェクトをマネージメントしていくのか。先日の日経のセミナーでは、ガードナーのピーター・ソンダーガード氏が現在のシステム投資の8割は間接費である、ＰＣは5年のうちにその地位を負われ他の様々な機器から基幹情報へのアクセスが可能になり、10年までには世界中で10%のＳＥとＰＧが職を無くすと指摘していました。この職を無くす10%のエンジニア達は、中国かもしれないしベトナムかも、インドかもしれませんがご存知のように我々の1/5で中国で開発が可能で、インドは1/10とも言われています。果たして、エンジニアが職を無くすといわれているのはどの国に一番あてはまることになるのでしょうか。

成果主義といわれて久しいですがチームでものを創る会社や研究開発の分野の多くでは、一人一人の業績評価についても難しさが増しています。こういった複雑な問題は、視点も期間も目的も達成度も異なる環境の中で発生し、簡単に解決できるものではありません。このように企業を取り巻く外部の環境の変化は激しさを増し、それに伴って企業組織、そして組織を構成するひとりひとりに求められるスキルも多様化してきています。ゼネラリストからスペシャリストへそれが2000年のキーワードでした。

こういう複雑な多様性を持った現在だからこそ、使命（ミッション）を受けて課題を解決し企業価値を高めるプロジェクトマネージャの役割は大きなものとなっています。プロジェクトの概念は、ＩＴ業界だけのものではありませんが、ＩＴ業界においても、課題解決の為のマネージメントと捉えてみれば重要なスキルであることに気がつくはずです。

　今、私達を取り巻くビジネスの世界＝複雑な多様化した社会では、原則に従って実行して勝利する方程式というものはなかなか見つけられません。課題を分析し、プロジェクトを計画し、しくみを考え、自分で目的を達成するシナリオを描いてビジネスプロセスを創造できる人間が求められています。そして、その計画に則って、あるいは計画を修正しながらプロジェクトを実践し、目標を達成していく人間（使命達成型職業人）＝プロフェッショナルが求められています。

視点を高くして視野を広めて、様々に進化する時代に適合して行くことが必要です。

今週、勉強会の打ち合わせがあってある女性経営者のお話を聞く機会がありました。そのなかで言葉は少し違ったのですが、今までの自分のことに比べて考えるととても納得の行くお話を伺うことができました。「視座、視野が広がる＝物の見方・考え方が広がる」というお話でしたが、年代別にテーマがあってそのテーマに対していかに真剣に幅広く深く仕事を通して取り組むかがポイントであるということでした。そのテーマとは20代は経験、30代は技術、40代は責任、50代は信頼、60代は智恵・・・・
それが直角三角形の積み木の階段のように表現されていました。そして、この経験や技術の幅を広くすることでより高いところまで昇れるということそれが、視座、視野が広がるということなのだと。この会社さんは婦人服の販売で30人の社員が10億円売上、経常利益も素晴らしい会社です。その入社時の教育で最初にこの話をするとのことでした。・・・お話を直接聞かせてあげたかったなぁ。↓以下に東京同友会の例会のページを載せます。
http://www.tokyo.doyu.jp/tokyo-doyu/common/meeting.php?meeting_id=2725

「今を生きること、その一日一日の微差の積み重ねが人生では大きな差になる」
「夢を持てる人は能力がある」
「経営者が成長しなければ会社は成長しない」
「仕事に精通していくことが物を創る人に感謝すること」

・・・・ｅｔｃ、沢山の人生のエッセンスがつまったお話を聞くことができました。
みなさんに感動を伝えられなかったとしたら、私もまだまだですね。視点を高くして視野を広めるということは少しぐらい勉強したぐらいでは身につかないことです。毎日心がけて行くことで、すこしづづ自分の視野を広めることができるのでは無いかと思います。目標を心に描いて、ひとつひとつのことに真剣に取り組み、いつも工夫する気持ちを忘れないでください。それが、視野を広くし視点を高くする訓練になる・・・そのように私は感じています。

失われた10年は設計力と管理力を奪ったのか

「私は、人からスケジュール管理など教わったことなどない・・・」
先日、お客様が弊社に来られていろいろなお話をされているその話しのなかでの発言。この10年にＩＴの技術者がオープン化の波で今までに培ってきたさまざまな基盤技術をどこかに忘れてしまったのではないか・・・という指摘だった。

汎用機の時代、プロジェクトマネージメンとは確固とした技術基盤の上に則って、多少融通の利かないきっかりしたものだった。（正確には私は汎用機は全く知らないのだが・・・ＵＮＩＸだって、制御用のミニコンだって似たようなものだった。）
それは、コンピュータがとても高価なものだった時代にいろいろな制約条件のなかで「約束をまもる」為に必要な智慧であり、それが徹夜もあたりまえ・・・ストックフォーム（若い人は知らないだろーなぁ）に包まってサーバの後ろで眠った話とか今でもそういった伝説が残っている業界・・・それがＩＴサービス業である。

当時の自分のまわりでも、スケジュール管理なんか3年目以降であればだれだって経験していたような気がするし・・・現に自分も2年目の後半からはスケジュールは自分で書いていたが特に教わったことはなかった。（・・・いや、全員ではなかったかなぁ。そういえば私は先輩の仕様書を書いていたような記憶もある。）ただ、そんなに難しいことではなかったということ。それをお客様も仰っているのだと思う。確かに、1980年代までの開発はもっとわかり易く、技術も安定していたような気がする。

ダウンサイジングといわれて既に久しい、最初にパソコンでクライアントサーバのシステムを使い始めたのは、お客様の一部の進んだ部署の話で、机に一人1台のパソコンと言われるようになったのは・・・ほんの1998年以降の話である。

2000年を境にして急激な業務革新の中、ダウンサイジングの領域に加えて、インターネットを業務に取り入れて情報を共有し戦略的なＩＴ化を進めるということが、先進的な企業で
取り入れられることになった。もうそれから6年も経っている。今では、インターネットの特徴を活かして、アジアの生産拠点や場合によっては全世界を繋ぐシステムだってそんなに夢のような話しには聞こえない。

基幹業務を取り仕切っていた人達は、コボラーとか呼ばれてクライアントサーバやＷＥＢの時代・・・この10年ほどの間には世代更新が起こった。しかし、コボラーは、きちんと仕様をまとめて調整をして・・・という現在のプロジェクトマネージメントスキルやお客様の仕様や運用を理解するといったスキルは高かった。なにより、大手企業のシステム部の若い人達はそういうソフト会社の人間と一緒に研修に行ったり、同じようにプロジェクトに所属して開発現場での密な人間関係を構築していることが多かった。なにより、仕事の内容が、入力して、計算して、帳票を出すというようなシンプルなものであったこともあるとは思う。

いくつかの理由は、当時のコンピュータの市場状況が現在と違うことにある。当時、コンピュータは現在と比較にならないほど高価なもので私が新人の時代には、まだマシンタイムということが本当にあった。・・・今は、ほとんどの人はこんな言葉すら知らないのかもしれない。制約が多ければ、マネージメントが必要になる。また、最近の傾向として、システムが複雑化している為に不確実性が高まりここでも、プロジェクトマネージメントが必要とされているのではないか・・・そんなことを考える。システムがビジネスの基盤であるものも数多く存在する。つまり、我々の仕事の領域は、どんどんと上流工程であるビジネスの領域に近づいているということなのだ。ビジネスの創業支援が出来るソフト会社・・・このサービス領域を我々の会社は得意としているのだが・・・それは、まだ少ない。

一方で、ダウンサイジングで創られたシステムを統合して企業の情報システムに組み込むような仕事も増えている。そして、このような仕事の大きな問題は、統合的なドキュメントが不足していたりソースには手を入れたがドキュメントが置き去りにされたり・・・といったことがよく言われる。しかし、これはコボルやＲＰＧの世界でも全く同じで、取り立てて新しく言われたことではない。その結果、既に15年前の時点でさえシステムの40％は使われていないという調査報告書が出ているぐらいだ。ということは、失われた10年が奪ったものは・・・管理能力なのか？と考え込んでしまうのだが、ひとつ重要な事としては、システムがいろいろなところに使われてＩＴ経営が進んだ結果、複雑なシステムが増えているという現実もあるように思う。それは、ＷＥＢ技術の特徴の１つでもあると思うのだが、いろいろなシステムを連携して情報を引き出す蜘蛛の巣は、今ではＷＥＢの向こう側まで広くその技術の適応先を延ばしている。

複雑なものだから、計画も立て難いし管理も難しいから昔よりもできる人が不足しているのかもしれない・・・つまり、こういうところに会社を差別化する為のキーワードが落ちているのかもしれない。複雑なシステムだからこそ、これから益々プロジェクト管理というものが重要度を増すことだろう。

そのはじめの一歩は、まず自己管理ということかもしれない。自分の健康管理、自分のスケジュール管理・・・今日の仕事の予定はあるか？そんな足もとから確認してみたらどうだろうか。