人気ブログランキング |

カテゴリ:ビジネス( 222 )

IT、OT、ET、そしてマネジメント・テクノロジー

前々回、そして前回と続けて、本サイトのテーマである『マネジメント・テクノロジー』の領域について、あらためて考えてきた。

マネジメント・テクノロジーは、目に見えにくい領域における技術である。わたし達の文化は、目に見えるもの(五感で感じられるもの)に対しては細部にまで徹底してこだわるが、見えない物事や抽象的概念には、いたって無頓着、という傾向が強い。

たとえばカレー屋さんの場合、料理の味と、その材料やレシピには研究を怠らない。しかし客の注文をどうとってどういう順序でデリバリーするか、何をストックし作る量をどう予測するか、といった店を運営する過程や仕組みには、なりゆきで応対する。これが多くの店のあり方だろう。

カレーの料理法は「固有技術」で,店の運営の仕組みは「管理技術」(マネジメント・テクノロジー)に属する。もちろん固有技術(味)は、いわばビジネスのベースで、これが不味ければ商売は成り立たない。しかし管理技術(運営の仕組み)ができていないと、商機に乗って展開することも、急な環境変動にうまく応対することもできず、気づかぬうちに非効率と機会損失を出してしまう。ここが弱いと、皆が必死に働いているのに、なぜか儲からなくなるのだ。

わたし達の社会は、このマネジメント・テクノロジーの存在と、その重要性を見過ごしてきたことで、長い不況を抜け出せずに来たのではないか。それが本サイトの問題意識だ。

そして、マネジメント・テクノロジーは、隣接する3つの固有技術領域、すなわちIT(Information Technology)、OT(Operational Technology)、ET(Engineering Technology)と少しずつ重なり合いながら、その方向性を広げてきた。では、このIT、OT、ETとは、それぞれどのような技術なのか。
e0058447_15133814.jpg
マネジメント・テクノロジーの領域図(再掲)


ITについては、すでにネットの内外に、数多くの情報があるため、いまさらここでは解説不要だろうと思う。コンピュータのハードウェア設計から始まり、OS、通信ネットワーク、ミドルウェア、データベース、そしてその上で活躍する応用ソフトウェア群(とくに業務系システム)の設計・実装・運用技術までが、ここに含まれる。

本サイトでも、随分前だが、『ITって、何?』という連載をのせた。長い記事になっているが、あそこで書いたコアのメセージは、
ITの本質は、データと情報のサイクルを回すこと
である。データとは定型化された符号の並びで、他方、情報とは人間に意味を与える(不定形な)ものだ。だから情報を機械に与えて蓄積・処理できるようにするには、定型化してデータにすることが必要だ。データは上手に組織化し提示しないと、人間に意味をもたらさない。この双方向をうまく回すのが、IT=情報技術である。

固有技術としてのITの基礎を支える科学は、コンピュータ・サイエンス(計算機科学)である。それは数学・論理学から電子工学さらには言語学まで、様々な科学領域にまたがって存在している。だから、大学のコンピュータ・サイエンス学科を卒業して、専門職としてのITエンジニアになる、というのが米国流の普通のキャリアパスである。日本があまりそうなっておらず、大学にも「計算機科学科」がめったに存在しないのはなぜか、わたしはよく分からないが。

さて、これに対して、OT(Operational Technology)とは何か?

OTについては最近、IoT技術に関連して注目されるようになり、世の中にもいろいろな解説が流布している。ネットでちょっと調べただけでも、以下のようなものが出てくる。

「交通手段やライフラインといった社会インフラにおいて、それに必要な製品や設備、システムを最適に動かすための「制御・運用技術」を意味します。」(キーエンス IoT用語辞典

「データを収集・分析し、経営に生かすテクノロジーがITであるのに対して、ハードウェアに働きかけ、制御・運用を行うためのテクノロジーを言います。(中略)OTの構成要素には、PLC、SCADA、DCS、CNCおよびcomputerized machine toolsといった制御装置と、制御装置と産業用ロボット・パワーサプライなどを結ぶフィールドネットワークがあります。」(Mono-watch IoT用語集

「ガートナーは、様々な装置のオペレーションを高度化する技術のことを、OT(オペレーショナルテクノロジー)と定義している。ファクトリーオートメーション(FA)などが、OTの代表例だ。」(日経コンピュータ World IT Watch 2011-09-01)

こう見ると、社会インフラ向けと言ったり産業機械向けと言ったり、定義には幅があっていろいろだ。最後の米国ガートナー社の定義は2011年のもので、中では一番古い。ちなみに現在はこうかいてある:

"Operational technology (OT) is hardware and software that detects or causes a change, through the direct monitoring and/or control of industrial equipment, assets, processes and events.” (Gartner Glossary)

この定義は英語版WikipediaのOperational Technologyの記事にも冒頭で引用されている(日本語版ウィキペディアの記事は、現時点ではその部分的抄訳でしかない)。

ただ、このガートナー社の定義は、わたしの目から見ると、少しだけ制御系や通信系の仕組みに偏りすぎているように感じられる(ガートナーはIT系コンサルティング会社だから、主な顧客はITエンジニアである)。

たとえば、NC(数値制御)のマシンを対象に入れるのだとしたら、その加工プログラムは、明らかにOTに入るはずであろう。そうなると、そのための切削条件決定や、加工ツール・バイト(刃先)の選定も、OTに含まれなければ、おかしい。搬送やチャッキングや検査の仕組みだって、そうだ。こうした機械工学系の加工技術は、現場の熟練者たちの手中にあって、ITコンサル会社には見えにくいのだろうが。

いいかえると、OTとは加工技術や機械制御といった、直接ものづくりに関わる固有技術だと、広く捉えるべきであろう。もちろんNC装置の加工プログラムや、SCADA, PLC、DCS、MES(とくにLower MES)など制御系も、この領域に入る。

日本のIT分野は世界の最先端に比べて遅れつつある、という認識が最近は広まっているが、それに比して、OTの分野に関しては、まだかなり世界的な強みを維持している。この点は強調しておいていいと思う。NC工作機械やマシジングセンタ、ロボット、物流搬送系設備、制御システムなど、世界トップレベルの企業がごろごろいるのが、この分野だ。

最後に、図の下の方に配置したET(Engineering Technology)に触れておこう。ETとは、製品設計や工程設計・レイアウト設計などに関わる固有技術領域である。ここには、機械・電気・制御・建築・空調・化学プロセスといった、いわゆる工学系技術が活躍する。そしてCAD/PLM/BIMなども、この分野のためのツールだ。

もっとも、IT・OTに比べて、ETという用語はあまり広く用いられていない。調べると、たとえば米ARC社は次のように使っているが、これが唯一の用法という訳でもない。

"ARC defines ET as those technologies that comprise digital models. … In the digital data environment of IIoT, engineering technology, those technologies that create virtual models must be included in the convergence conversation.” (ARC Insights, IT/OT/ET Convergence, May 25, 2017)

じつはETという用語が広まらないのには、別に特殊な理由がある。米国の大学教育コースの中に、”Engineering Technology”という学科が、”Engineering”とは別に設けられているところがあるのだ。たとえば英語版WikipediaでEngineering Technologyをひくと、Engineering Technologistという項目に自動転送されて、こういう説明が出てくる。

"Engineering technologists are more likely than engineers to focus on (post-development) implementation or operation of a technology but this is not a strict rule as they often do design original concepts.” (英語版Wikipedia: Engineering Technologist)

設計よりも実装に近い仕事を受け持つ技術職。日本の高等教育で言えば、高専のカリキュラムに近いのかもしれない。ET(Engineering Technology)というと、米国ではこちらのことを連想するらしいのだ。ともあれ、他に適切な言葉も見つからないため、上記の図ではETと表記しておいた。

そしてManagement Technologyは、OT+IT+ETの三本柱の上に乗っており、一部は重なっているのである。重なった部分は、それぞれ
OM(Operations Management)
EM(Engineering Management)
IM(Information Management)
と呼ぶべき領域である。

そして、これら3つのマネジメント・テクノロジーは、日本ではいずれもほとんど教えられておらず、知られてもいない。理工系はもちろんのこと、いわゆる文系の経営学でも、またビジネススクールでも、ほとんど等閑視されている。米国にはちゃんと、OMやEMを教えるコースを持つ大学・大学院があるのに。

なお、ITと重なる領域を、IM(Information Management)と表記したが、この言葉はプラント・エンジニアリング業界では、ある特殊な狭い領域の業務を指すことがある。本当はより一般的に、DM(Data management)とか、KM(Knowledge Management)などと併用すべき用語に思われる。

そして、図中には、他にもSCM(Supply Chain Management)PM(Project Management)MM(Material Managemen)といった、やはり物づくりに関連するマネジメント・テクノロジーの領域を入れておいた(ただし図中の位置は場所的に散らしているだけで、必ずしもPMがIMとEMの中間にあるという意味ではない)。

ちなみに、上の説明ではOTに属するPLC/DCS/SCADAや、ETに属するCAD/PLMなどを、ITとは別のものとした。だが、これらはみんなコンピュータのハードとソフトで実現するものだから、ITの一部ではないか、という議論もあるだろう。

しかし現実を見ると、業務系システムと、制御系・組込系システムと、科学計算系システムでは、作る人達も売る企業も、業界的に分かれている。技術の要素も相当に違っており、昨日まで製造原価報告書を設計していた人が、今日から偏微分方程式の収束計算を設計できるかというと、まあ無理であろう(逆も真なりだ)。繰り返すが、図中の「IT」は、主に業務システム系の領域を主に意識している。ITとOTの融合が語られはするし、そうした動きを否定するつもりはないが、それは、建築と機械の融合、くらい大変な話であることは理解しておいたほうがいい。

ともあれ、これがマネジメント・テクノロジーの領域の見取り図である。固有技術の領域では、日本の技術者たちはそれなりに優秀だ。みな真面目だし、ほぼ例外なくハード・ワーカーでもある。だが、縦割り組織と分業病におかされているため、固有技術を束ねて、全体をオーケストレーションする部分が弱い。オーケストレーションの技術、それがマネジメント・テクノロジーである。

もちろん、マネジメント・テクノロジーを学ぶとしても、この図の全部に通暁する必要はないし、そんなスーパーマンもいないと思う。ただ、わたし達は、自分が何を知っておらず、どこを探しに行けば先人の知恵を学べそうか、その方角を知るために、こうした地図を必要としているのである。


<関連エントリ>
 →「マネジメント・テクノロジーの領域を知ろう」(2019-10-05) https://brevis.exblog.jp/28610522/
 →「マネジメント・テクノロジーの技術地図を見渡す」(2019-10-13) https://brevis.exblog.jp/28623704/
 →『ITって、何?』https://brevis.exblog.jp/i12/


by Tomoichi_Sato | 2019-10-20 17:36 | ビジネス | Comments(1)

マネジメント・テクノロジーの技術地図を見渡す

前回の記事では、技術(Technology)とは2種類あり、固有技術と管理技術に分類できる、と書いた。わたし達が大学の工学部などで習う技術のほとんどは、固有技術である。これは対象分野に固有の科学法則に基づくテクノロジーだ。これに対し、管理技術(Management Technology)とは、仕事の仕組みそれ自体に関する技術で、たとえば、プロジェクト・マネジメントの分野では、CPM(Critical Path Method)やEVMS(Earned Value Management System)などがこれに相当する。

わたしは大学でプロジェクト・マネジメントを教える際に、いつも「この講義で教える内容は、ほぼすべて社会人になってから学んだことで、わたし自身は大学ではほとんど教わった記憶がありません。だけれど、それでは非効率なので、こうやって大学に来て皆さんに講義をしているのです」と説明している。

実際のところをいうと、大学の学部生レベルでは、プロジェクト・マネジメントの講義をしても、あまり響かない。人と一緒に仕事をして苦労した経験が乏しいからだ。これが大学院の修士課程くらいになると、一度は「卒論」というチャレンジを経験した後なので、少しは話を聞く態度に身が入る。そしてもちろん、一番皆がちゃんと学ぶ姿勢になるのは、社会人大学院生や、企業相手の講義のときだ。

まあ、だからといって大学での講義が全くムダだとは、思っていない。アーンド・バリューだのクリティカル・パスといった概念の意味は忘れても、いざ自分が卒業して、仕事で問題に直面したときに、「そういえば、昔なんだかこれに関連する話を聞いたよな」と思い出せれば、あとは自分で探して調べることができる。

自分が本当にニーズを感じているときほど、良い学びの機会はない。このとき、頭の中に、たとえぼんやりとでも「技術の地図」のイメージが残っていれば、(ああ、あっちの方に探しに行けばいいんだな)と、希望を持つことができる。技術者という人種は、「技術的に可能だ」という希望を持てることが、いちばん大切だからだ。そして優秀な人なら、自分で調べて勉強していく。

しかし、わたし達の社会では、管理技術をほとんど大学で教えないため、そうした技術の地図を知らないまま、世の中に出てしまう。つまり、そもそも「仕事の仕組み」には技術があること、人・モノ・情報などの配置と流し方に、ちゃんと先人たちの叡智と工夫があることを、知らないのだ。その結果、各人がゼロから車輪を再発明することになる。いや、それどころか、「リーダーシップ」「気合と根性」でなんとか乗り切れ、という話がまかり通る。

これに関して、わたしがよく使うたとえは、オーケストラの指揮者である。指揮者という仕事は、ちょっと見たところ、リズムに合わせて棒を振っているだけで、誰でも(楽譜さえ読めれば)できそうに思える。自分では笛を吹くわけでもなければ弦をこするわけでもなく、何の音も出さない。そもそも、管楽器や弦楽器の演奏技術も持っているまい。ただ、オケに指揮棒で指示を出すだけである。

では、指揮にはとくに技術はないのか。指揮者は、どのように育成するのか?

日本の組織では、幹部やリーダーの地位に登っていく人を、「ジェネラリスト」として育てるところが多い。その典型は官庁で、「キャリア職種」と呼ばれるエリート候補生たちは、2〜3年ごとに部署を変わっていく。しかも前職とろくに引き継ぎもしないことが多いので、役人と付き合う民間人たちは、相手が変わるたびに一から説明し直しになる、という。

技術者の場合、専門的な仕事を覚えて一人前のプロとして通用するには、ふつう10年くらいかかる。それがスペシャリストというものだし、医師や弁護士だってそうだ。それなのにキャリアと呼ばれる人たちは、わずか2〜3年の間で、その領域の仕事を概略理解し、何らかの成果を上げて次のポジションに進んでいく。だから、こうした制度は、彼らエリート層の優秀さの証左なのだ、という説明も聞いたことがある。優秀かどうかはともかく、スペシャリストを束ねて指揮するのは、ジェネラリストだ、という思想がそこにある。

こういう話を聞くたびに、じゃあ日本社会では、オーケストラの指揮者もジェネラリストとして育てることになりそうだな、と思う。指揮者のキャリアパスは、まずビオラで3年、次にフルートで2年、さらに打楽器とトランペットなどを経験し、最後に第一ヴァイオリンでコンサートマスターを5年ほど務めた後、めでたく指揮者の地位になる、と。

こんなバカなやり方で指揮者を育てる音楽界は、世界中どこにもない。指揮者は、専門家であり、指揮は専門技術だ。音大には指揮科があり、そこで指揮の理論や技術を学ぶ。それから指揮者の見習いとして、先輩について指揮法の実際的なスキルを学んでいく。たしかに、ときにはピアニスト出身の指揮者やヴァイオリニスト出身の指揮者もいる。だが、彼らだって、ちゃんと指揮法を学んで棒を振っているのだ。ただやみくもに棒を振ればついてくるほど、オーケストラという集団は甘くない。

人が集団で仕事をするとき、とくにその専門分野が多岐にわたり、規模が大きくなればなるほど、専門的なマネジメントの技術が必要になる。そして、そこには理論もあるし、学ぶことも、伝えることも可能だ。

では、そうしたマネジメント・テクノロジーを学ぶとしたら、それはどのような範囲をカバーすべきか。いいかえると、「技術の地図」は全体として、どのようになっているのか。

もちろん、それはかなり広い領域にまたがることになる。プロジェクト・マネジメント(PM)はその一部分にすぎないが、それだけでもPMBOK GuideやP2Mなど、分厚い教科書的な本がいくつも存在する。

そこで、ここでは一般的な製造業における物づくり分野について、その全貌を考えよう。また、マネジメント・テクノロジーを考える際には、隣接する固有技術との関係で理解したほうが分かりやすい。わたしの考える、物づくりに関わるマネジメント・テクノロジーの領域と、隣接する固有技術との関係マップを示しておく。

e0058447_15133814.jpg
隣接する3つの固有技術とは、以下の3つだ:
IT(Information Technology)
OT(Operational Technology)
ET(Engineering Technology)

それぞれが具体的に、どのような種類の技術領域を表すかについては、長くなりそうなので、次回書くことにしよう。
(この項続く)


<関連エントリ>
 →「マネジメント・テクノロジーの領域を知ろう」(2019-10-05) https://brevis.exblog.jp/28610522/
 →「オーケストラの指揮者かジャズ・バンドのリーダーか - プロジェクト・マネジメントの4つの類型を知る」(2014-02-02) https://brevis.exblog.jp/21641066/


by Tomoichi_Sato | 2019-10-13 15:32 | ビジネス | Comments(1)

マネジメント・テクノロジーの領域を知ろう

本サイトの主要なテーマは、(知らなかった人もいるかもしれないが)『マネジメント・テクノロジー』である。マネジメントと言う仕事には技術があって、学ぶこともできるし、蓄積したり磨いたり、人に伝えることもできる。決して気合とか根性とか、生まれつきのセンスとかだけで能力の決まる仕事ではない。そういうことを多くの人と共有したくて、ずっとこのサイトを運営してきた。

そもそもTechnology(技術)には2種類ある。固有技術と管理技術(マネジメント・テクノロジー)だ。固有技術とは、対象固有の科学法則に縛られる領域におけるTechnologyである。たとえば、機械設計、材料開発、システム設計、といった技術がそれに当たる。ちなみに、わたし自身の大学の専門は化学工学(Chemical Engineering)だった。これは化学プラントの設計に関わる工学だが、やはり固有技術である。

これに対して、管理技術とは、仕事の仕組みそれ自体に対して適用すべきTechnologyをいう。「仕事の仕組み」では分かりにくければ、人・モノ・情報などの配置と流し方、と言い換えても良い。たとえば、プロジェクト・マネジメントの分野では、CPM(Critical Path Method)やWBS(Work Breakdown Structure)、生産マネジメントの分野なら、在庫理論とか生産スケジューリングといった技術だ。

こうした管理技術(Management Technology)には業種・分野固有の部分がない。製品開発プロジェクトだろうが橋梁建設プロジェクトだろうが、CPMは当てはまるし、在庫品がダイヤモンドでもトイレットペーパーでも、在庫理論は使える。このため、マネジメント・テクノロジーは業種分野を超えて、汎用的である。だから、まったく畑違いの分野の知恵も、学んでうまく応用すれば、自分の仕事を楽にするために使える。

ところが残念なことに、日本の大学教育では、この『管理技術』の教育・研究を、伝統的に軽視してきた。その1番の証拠は、東大と京大に、学部レベルで経営工学や管理工学の学科が存在しないことである。この2つの大学は、日本の文科省の高等教育政策を映し出す鏡のようなものだ。つまり国の側にも、管理技術という意識が欠けているのだ。

ちなみにかなり以前から、慶応には管理工学科が、早稲田には経営システム工学科があり、東工大にも経営工学科があった。だが、肝心の東大と京大には、ずっと存在しなかった。さすがに、今世紀に入ってからようやく、大学院レベルで、東大に技術経営戦略学専攻が、京大に経営管理専攻が設置された。

だが学部レベルでは、相変わらず存在しない。だからこの二つのエリート大学を卒業してくる人たちは、基本的に、「仕事の仕組みにはテクノロジーがある」ということを理解せぬまま、社会に出て働くわけだ。

なぜ、国の側に管理技術=「マネジメント・テクノロジー」への認識が欠けているのか、わたし自身はよく知らない。ただ、もしかすると、わたし達の国の上の方の人たちは、「管理とは法学部出身者の仕事である」、と考えているのかもしれない。そう疑わせる兆候は多分にある。そうでなければ、なぜこの2つの大学の法学部出の人たちばかりが、中央官庁や政界財界のトップの座をあれほど席巻しているのか。

だが、話を元に戻そう。わたし達の社会では、残念ながら、「マネジメントにも技術がある」という概念が希薄である。だから、マネジメントの上手下手は、まったく属人的なものだ、という思想が強い。その結果、マネージャーの地位は、学歴・年功序列・出身等により選ばれることが多い。マネジメントは「地位に付随する権力・権能」 であって、前もって研修・訓練が必要な技術とは考えられていないのである。

なおここでもう一つ注意しておきたいことがある。それは、『経営』という言葉とマネジメントとの違いだ。本サイトは、「ビジネス・経営」のカテゴリーに分類されている。他に適切なカテゴリーがないから、そうしているだけだが、あまり本意では無い。なぜなら、このサイトでは、ほとんど経営について語ったことがないからだ。わたし自身、経営者ではないし、経営の仕事もしたことがない。

普通、日本語で経営と言うと、会社レベルの組織をまとめて運営する仕事を指す。しかし、私がここでマネジメント・テクノロジーと呼ぶ技術は、もう少し中間層のレベル、言い換えると経営者層と現場をつなぐレベルの技術である。クリティカルパス法だとか、在庫理論だとかいった技術知識は、会社経営のレベルではあまり必要がない(無論、知っているに越した事はないが)。

少し具体的な例で考えてみよう。今、ある所にカレー屋さんが開業した。ご主人はもともとエンジニアだったが、長引く不況と、先の見えない業界にうんざりして、心機一転、脱サラを決意したのだ。昔からカレーが得意料理で、親戚知人に披露すると結構評判が良かったので、自分で店を開こうと思いたったわけだ。

愛想の良い奥さんと二人三脚で、幸い、店は順調に滑り出した。ご主人が料理を作り、奥さんが客の応対をする。1年経つと、ピーク時には店の前に行列が並ぶほどになった。今のスペースは手狭なので、近くに3倍位の広さを持つ店舗の空き家を見つけ、そこに移転することにした。そうなると夫婦2人では手が足りない。厨房とフロアの手伝いに、2人ずつ人を入れた。

ご主人はこれに加えて、持ち帰りのカレー弁当も売ることにした。長年のオフィス勤めで、昼食に皆が苦労していることを知っているからだ。オフィス街に小さな机を並べ、昼の間だけそこでお弁当を見ることにした。当然そこにも人が必要だ。

だが、こうして店の業容を広げていくうちに、少しずつ問題が起きてきた。例えば、お弁当の仕込みの数をどう決めるべきか。作り過ぎれば売れ残るし、数を絞れば利益が出ない。それに、仕込んだカレーだって、賞味期限がある。3日も4日も前に煮込んだカレーをお客様に出すわけにはいかない。

店を広げた際に、カレーのメニューの種類を増やしたことも問題だった。厨房の中で、洗い場と、調理台と、冷蔵庫との導線が錯綜して、3人の人がぶつかりやすくなった。しかもメニューの数を増やしたために、フロアからの注文の聞き取りミスも増えてしまった。注文してから料理を出すまでの時間が長くなったとなじみの客にクレームされたこともある。

おまけに甚だ厄介な、今回の消費税対応。朝から晩まで寝る間も惜しんで忙しく働いているのに、利益は上がらない上に、客足も少しずつ鈍ってきている。カレーの味自体は変わっていない。むしろ腕は上がっている自信がある。だが商売の利益につながらないのだ。ご主人は深夜、自分の席で、ため息をつくことが多くなった。

これが典型的な「仕事の仕組み」の問題だ。今のご主人に必要なのは、カレー作りの品質向上ではない(それは固有技術に属する)。大事なのは、人と物と情報の配置・流し方の工夫である。つまりマネジメント・テクノロジーが足りないのだ。

夫婦2人で小さな店をやっているときには、それはほとんど必要なかった。だが品種を増やし、人を増やし、売り上げと生産量を増やしたときに、次第に目に見えない非効率が生まれてきたのだ。適切な厨房のレイアウト、適切な在庫量の設定と発注、需要の読みと臨機応変な対応、店舗から弁当売り場への搬送、注文と会計のシステムの導入・・こうしたことが必要になるのだ。だがそれを実現するテクノロジーを、どこで学べばいいのか?
e0058447_20141464.jpg
これと同様の問題が、おそらく最初は東京オリンピックの翌年の「昭和40年不況」のときに、多くの中堅中小企業で噴出した。そして、より大規模な形では、高度成長期を終えて、消費者ニーズの多様化と輸出拡大に直面した80年代以降に、日本企業を襲ったのだった。

ただ残念ながら、マネジメント・テクノロジーは、目に見えない領域に属している。そして、目に見える物の品質やディテールには大変こだわるが、目に見えない事には至って無頓着な傾向を、わたし達の文化は持っている。加えて、国家レベルでの認識不足。こうして、バブル崩壊以降の90年代から、長らく不況を出せずにきたのだ。

わたしのこの、ささやかなサイトが、国家レベルの問題を解決できると夢想しているわけではない。ただ、たまたまここを訪れた方のうち、たとえわずか数人でも、問題解決のヒントを提供できればいいと思っている。ネットの世界では、マネジメント・テクノロジーの情報源は、あまりに少ない。話題のほとんどは、固有技術か、さもなくば経営論に行ってしまう。それでは、問題に悩むカレー屋の店主の助けにはならないのだ。

それと同時に、わたし達は、マネジメント・テクノロジーについて、フェース・ツー・フェースで情報交換し、議論する場を必要としているように思う。ネットでの匿名による意見交換は、限界がある。工場作りに関しては、互いに勉強でき議論できる場を、(財)エンジニアリング協会で、立ち上げているところだ。そちらもいずれ近いうちに、より広くアナウンスできるようにしたいと考えている。そうやって、かつての東京オリンピック後と同じ状況に、日本の製造業が今度は陥らないよう、今から準備しようと思っているのである。


<関連エントリ>
 →「マネジメントのテクニックと技術論について」 https://brevis.exblog.jp/22951856/ (2015-04-22)




by Tomoichi_Sato | 2019-10-05 20:24 | ビジネス | Comments(2)

ミニレビュー:ポータブル・オルクハンガー



以前も書いたことだが、冷房が苦手である。若い頃に、南国に1年ほど暮らしたことがあったが、その時に冷房病にかかってしまった。それ以来、体温調節の機能が低下したらしい。もともと汗かきの方だったが、冷房の効いた場所に入っても、しばらく首から背中にかけての汗が止まらず、それが冷えて風邪をひく原因になりやすい。

自衛のために、夏は、替えの下着を持って歩くのが常である。おまけに、冷風による「冷え」から体を守るために、薄手のベストや上着を持って歩くことも多い。まして客先を訪問する時ともなれば、なおさらだ。かくして、夏場はかえって荷物が増える、という奇妙なことになる。

ことに面倒なのは、上着の扱いである。サラリーマンなので、上着を持って歩かなければいけないことが、結構ある。上着というやつは、畳んでバックに入れるとしわくちゃになるし、かといって、腕にかけて持ち運ぶのはけっこう面倒な上に、腕にも汗をかいてしまって、汚れやすい。

どうしたものかと悩んでいた時に、携帯型の小さなハンガーを、知人が見せてくれた。伸縮可能なステンレス製のポールに、ストラップのついただけの簡単なハンガーだが、小さいし、持ち歩きやすい。たたむと20センチ以下だが、伸ばすと40センチ位になる。小さな袋が付属していて、使わないときにはたたんで、バッグの中で邪魔にならないように、しまうこともできる。

上着を持って歩くときは、ボールを伸ばし、上着を2つ折りにし、そこにかけて、外側のストラップを引っ張る。すると、内側のストラップがボールに密着して、上着がずれて落ちないようになっている。簡単だが巧妙な仕掛けだ。
e0058447_19283362.jpg
e0058447_19290596.jpg
このままストラップを肩にかけて、持ち歩くのでもいい。だが、わたしはあえて、トートバッグの口に、このハンガーの両端を引っ掛けて、上着が外から見えないような形で持ち歩くことにしている。

新幹線の中などでも、上着をこのハンガーにかけて、自分の座席の前にかけておくと、シワになりにくく、扱いが楽である。上に述べた小さな袋を使うと、リュックやバッグの外側に、このハンガーを固定して、一体で持ち運ぶこともできる。なかなか小技が効いているのは、ユーザのことをよく考えている証拠だろう。

この頃は毎年、暑い夏が続いている。本当は、日本のような高温多湿な地域で、夏も冷涼な英国発のスーツ・ワイシャツ・ネクタイの風俗に従っていることに、無理があるのだ。近年はお上の主導で、ようやく夏場のネクタイをしなくて済むようになり、少しは助かった。

しかし、米国ハワイ州のように、気候風土に適した服装(=半袖のアロハシャツ、女性ならムームー)が『正装』の地位を占めるようになるまでは、まだ時間がかかるのだろう。あそこの島では、知事だろうが州議会議員だろうが、アロハ姿で仕事をしえいるのだが。そして、冷房抜きで過ごせる気持ちの良い夏は、日本の大都会には望みようもないらしい。だとしたら、しばらくは、こうして上着を持ち歩く道具に、少しばかりの知恵を注ぐのが賢明なのだろう。



by Tomoichi_Sato | 2019-08-17 19:45 | ビジネス | Comments(0)

敗北から何を学ぶか 〜 その2・結果よりもプロセスに学べ

--敗北から学ぶために必要な方法にも、いくつかある。ここでは4つぐらいあげようか。

まず第一に、勝敗の結果だけではなく、プロセス中間目標を設定しておく。本当はこれは、戦う前に、やっておく必要がある。その上で、個別の戦局や、あるいは全体における達成度を吟味する。

「どういうことですか?」

--つまりさ、ローマは1日にしてならず、というだろう。たとえば何でもいいけど、大学受験を例に取ろうか。難関の名門校に入りたい、と。そうしたら、受験科目のどれが得意か、どう勉強するのか、予備校には行くのか、考えるだろう? また、模試を複数回受けるとして、現役1回目は何点くらい、2回目は何点、と想定して、直前模試でA判定になればいいはずだ。

こう言う風に、単なる勝ち負けだけでなく、プロセスと中間目標を設定する。そして、途中途中で、目指した通りに進んでいるか検証する。うまくなければ軌道修正する。仮に現役では合格できなくても、もう一度チャレンジするべきか、考え直す。そして反省点を翌年の試験に生かそうとするだろう・・それなのに、受験生のときにはできていたことが、ビジネスマンになるとすっかり忘れてしまうとしたら、奇妙なことだ。

「確かにそうですね。でも、その中間目標というのは、実際にはどう立てたらいいんでしょう。ビジネス上の戦いは、受験ほど単純じゃありません。偏差値の表もなければ、予備校の模擬試験もありませんし。」

--もちろんだ。だから2番目に大切なことは、適切な戦略を選んでから、中間目標に落とし込むと言うことだ。

「戦略を選ぶ、ですか? 戦略って、毎回個別に考えるものかと思っていました。」

--もちろん、そうさ。そうだけれども、戦略にはある種の定石ないしパターンがある。まあ、戦略論は多岐に渡るから、ざっくり簡単なパターンに絞って説明することにしようか。

たとえば市場における競争戦略は、その会社の立場によって異なる。チャンピオンの戦略と、挑戦者にとっての戦略と、ニッチプレイヤーの戦略は異なる。あなたのところの会社は、チャンピオンかな、それとも挑戦者か、ニッチプレイヤーなのかな?

「えーと・・あまり考えたことがありませんでした。今回の戦いに限って言うと、トップ企業じゃないから、チャレンジャーかなぁ。」

--なるほど。どんな業界も大体、少数のトップ企業と、それに次ぐチャレンジャーたちと、多数の小さなニッチプレーヤーからなる、いわばピラミッド構造になっている。

業界のトップ企業は、その規模を生かして、製品もフルラインナップを揃えているし、営業ネットワークもあるし、物量を生かしてローコストで大量生産ができる。だから最終的には価格競争に持ち込んで、顧客を囲い込む。これを『コストリーダーシップ戦略』という。戦争に例えるならば、正面攻撃の戦術といってもいい。

「はい。」

--一方、チャレンジャーたちは、正面から価格競争を挑んでも、勝てそうもない。そこで普通は、『差別化戦略』を考える。大手が販売する製品とは、かなり異なった特徴のある製品を売り出して、価格とは別の面で顧客に訴求する。側面攻撃の戦術と言っていいだろう。

「確かにある意味で、僕らが戦う上でとっていた方策は、差別化を志向したと言ってもいいかもしれません。意識してやったわけではありませんが。」

--なるほど。そして大多数の、中小零細規模のプレイヤーたちは、ある狭い局地的範囲内のみに、自分たちの持てる経営資源を集中して、そのニッチなマーケットだけは死守しようとする。例えば顧客との長いつながりで商売を続けている、地方の老舗の商店を考えればわかるかな。あるいはごく特殊な製品のみを扱う、その分野でのみ全国的に名の知られている企業なんかも、これに近い。いわば局地戦、ないしゲリラ攻撃の戦術だ。これを『集中戦略』という。

そしてこの3つの戦略ごとに、立てるべき方策も、中間目標も異なっている。
e0058447_22472150.jpg
「なるほど、そういう風にロジックを持って考えると、中間的な目標も立てやすいですね。」

--ただしね、ここに挙げたのはパターンに過ぎないから、実際には具体的に何をどうするかを考えないと、戦略の名に値しない。戦略とは、固有名詞が入って初めて、役に立つものだ。

たとえば第二次大戦中、ドイツ軍に占領されたフランスを奪還するために、連合軍が作戦を考えるとしよう。その時、側面攻撃しよう、フランスの大西洋岸から上陸だ、だけでは戦略とは呼べない。具体的に、カレーを攻めるのか、ノルマンディーから上がるのか、それとも別の攻略ポイントを探すのか。具体的な地名と、時期と、兵力と、方法がなければ、戦略にならないし、準備もできない。わかるだろう?

「たしかに。」

--もしも、あなたの会社がチャレンジャーで、差別化戦略を志向するなら、どのような訴求点を持つべきか。どの程度他社を引き離すべきか。それによって得られる金銭的なアドバンテージはいくらぐらいか・・といったことについて仮説を立て、目標設定して、検証していくんだ。

戦略とは仮説だ。「こう戦えば、きっと勝てるはずだ」という仮説だ。だがしばしば、仮説には間違いがある。だから途中途中で検証しながら進む必要がある。人間は誰だって、自分たちが有利であると言う思い込みにとらわれやすく、そこから間違った仮説が生まれやすい。したがって、仮説を文字に残しておくことがとても重要だ。

「でも、方針というのは、いったん書面にすると、仮説どころか、絶対化されやすいですが。」

--そうだね。だから、3番目に大事なのは、戦いを始める前に、状況を客観的・数値的に分析しておくことになる。たとえばマーケットの戦いならば、敵は誰と誰で、どういった商品を揃えていて、どんな販売チャンネルを抱えているのか。これまでの売上高や、受注確率はどれくらいなのか。顧客はどんなセグメントからなっており、どういう好みを持っているのか。こうしたことを事前に分析しておかなければいけない。

「具体的には、例えばどんなことですか?」

--そうね。例えば営業における受注競争なら、過去の勝率はどうだったのかという事さ。もしも自社の平均的な勝率が約3割で、今期の受注目標が10億円だったら、最低でも合計33億円以上の可能性のある競争案件を、営業リストに載せなければ、目標は達成できない。また、既存顧客には強いのか、大型の案件には弱いのか、といったことも分析の対象だ。

「それってでも、案件ごとに条件が違うと思います。確率なんか言われても、個別の現場担当として役に立ちません。問題はむしろ、勝敗の質じゃないか、って感じるのですが。」

--勝敗の質ね。そう言いたい気持ちはわかるよ。でも、あなたは製造業の人だから、あえて尋ねるけれども、じゃあ不良品はモノの質が低く、良品はモノの質が高い、と言えるだろうか。むしろ、検査結果にデコボコがあって、予測し難い点に、問題があるのではないか。つまりモノの質ではなく、プロセスの質を上げるべきではないか。

同じように、個別の戦いの勝ち負けだけが問題なのではなく、勝敗が予見し難いことが問題ではないのか? そうなると、自社の体制や人材も、前もって適切に準備できないだろう。それはやはり、プロセスの問題なのではないか?

「つまり、事前にもっと計画しておけ、ってことですね。でも、ウチのボスは、『どうせ計画した通りには現実なんか運ばないんだから、計画を立てるなんて時間の無駄だ。現場を見て状況に応じて考えればいい』と、つねに言っています。」

--もちろん現場を見て考えるのは、いつでも大切だ。しかし、計画抜き・現場判断、というやり方が通用するのは、ごく小さな戦局か、あるいは自社がリーダーで、戦い全体を自分たちの思惑通りに運んでいるときに限る。連合軍がノルマンディーに上陸するか、カレーに上陸するかを、現地を見て決められると思うかい? 上陸する兵士や機材を動員するのに、数カ月はかかる。上陸地点によって、必要な装備も違うだろう。数字に基づいた計画がいるんだ。

第二次大戦の英雄だった米国のアイゼンハワー大統領は、「計画通りに現実は動かない。しかし計画を立てるプロセスは絶対に必要だ」と言っている。君の上司との違いがわかるよね。

「たしかに、違いはありますね。」

--計画のための情報収集と分析は、分担を分けた方が良い。なぜなら分析は、総合的な情報を集めて行うべき仕事だからね。個別の情報入手した時点で、勝手にローカルな分析を行って解釈した結果を、中央に集めたりするのはあまり良いやり方ではない。データ収集には、必要ならば第三者の知恵を借りることも、するべきだろう。市場調査会社とか、コンサルタント、エージェントといった人たちだ。

そして、戦いの中間の要所要所で、データを集めて状況を分析し、戦略を補正する。ターゲットとすべきセグメントが間違っていることもある。あるいは顧客の要求を読み間違えることだってある。それを一つ一つ、データによって検証する。ときには、撤退を考えなくてはならない場面もある。

前に「マジックナンバー=5」という話をしたのを覚えているかなあ。対等だと思った勝負に5連敗したら、もう対等だという仮説は捨てたほうがいい、という数学的法則だ。こういう判断は、データを積み上げないと出てこない。

「データを集め、数字から学ぶ、ってことですか。確かに、ウチに一番欠けていたのはそこかもしれません。」

--そして最後の4番目は、戦いが終わったら、根本原因(Root cause)の分析を行うことだ。Root causeの定義とは、「論理的に見つけられる基本的原因で、かつ、マネジメントによって解決可能であるもの」だ。

表面的に、客が悪いんだとか、運がなかったとか、不況や円高などの環境のせいにしては、いけない。それは自分たちには解決可能でない。だから根本原因に選んではならない。選ぶなら、なぜ客筋をきちんとアセスしなかったのか、なぜ為替リスクのヘッジを怠ったのか、運不運で決まるような案件に、なぜ大きな勝負を賭けたのか、を問題にすべきだ。

「リーダーの責任というのは、どうなるんです?」

--根本原因分析をするときに気をつけるべき点は、「責任追及の場にしない」ことだよ。もし責任追及が主目的だったら、誰もが自分をかばって、本当のことを言わなくなる。本当のことがわからなかったら、根本原因分析なんて、どんな意味がある? 

根本原因分析の最大の目的は、同じ種類の間違いを繰り返さないこと、つまり再発防止にある。そのために、自分たちの仮説や行動に足りなかった点は、どこかを明らかにする。そして教訓を文字に残す。

敗北などのトラブル事象を、リーダーとか誰かの責任、で説明してしまうと、対策はその人間をポストからはずす、しかなくなる。じゃあ、他の人間をそのポストに据えたら、同種の間違いは決して起きない、と言えるのか? それに、失敗したら責められる、という組織では、だれが新しい創造的な仕事に挑戦するだろうか。

「ふー。結構大変ですね。とくに、勝負の前にやっておくことが多いですし。・・これ、ウチでやりきれるかなあ。」

--まあ、わたし自身だって、正直言って、いつも全部はできていなかったさ。ただ、こうすべきだったと思うから、偉そうに聞こえたかもしれないけれど、あえて喋らせてもらった次第だ。

「でも、自分のところは、計画立案能力も弱いし、データ活用も、からきしダメです。片方だけでも大変なのに、両方なんて到底無理かな。」

--でもないさ。計画とデータ活用は、じつはワンセットの能力だから。

「そうなんですか?」

--うん。計画を立てない組織には、ちゃんとした「ふり返り」もない。客観的なふり返りを知らない組織は、後で活用するためにデータを蓄積する、と言う姿勢もない。最初に用意しないまま、あとになってからデータを分析しようとするのは、予算も立てずに決算だけするようなものだ。

「その財務の喩えは、よく分かります。計画とふり返りが、データ蓄積の基本なんですね。」

--計画とは、いいかえれば具体的なアクションの塊だ。そして計画を立てられないようなビジョンは、と言う。夢を見ているだけでは、現実は近づかない。

夢に近づきたかったら、まず事実と経験から学ばなければ。たとえそれが、痛い経験であってもね。昔の人も言ったじゃないか、「過ちて学ばざる、これを過ちと言う」ってね。


<関連エントリ>
 「失敗の無限ループから抜け出すマジックナンバー『5』」 https://brevis.exblog.jp/15454723/ (2011-09-15)


by Tomoichi_Sato | 2019-08-07 23:12 | ビジネス | Comments(0)

敗北から何を学ぶか 〜 その1・学ばないための5つの方法

久しぶりに会った年下の知人が、なんだか元気のない顔している。理由を尋ねてみると、数カ月間打ち込んで懸命にやった仕事が、見事にライバル会社にかっさらわれたのだそうだ。勝負に打って出たが、負けてしまった。疲れて意気消沈し、他の事にもあまり手がつかない。気がつくと、失った仕事のあれこれを考え、頭の中が堂々巡りの状態だという。

「まったく参りました。早く忘れて気分を切り替え、次の仕事に取り掛からなければと思うのですが、何か良い方法は無いでしょうか? 」

--どうだろう。本当に早く忘れるのが一番良いことなのかな。必ずしもそうではないと思うけど。

「なぜですか? 同じところで足踏みしてたって、先には進めません。職場の先輩にもそう言われましたが。」


彼の言葉を聞くまでもなく、職場の皆がそう言いたい気持ちは、もちろんわかる。敗北は早く忘れて、次の一歩を考えろ。Don’t cry over spilt milk. 英語にもそんな感じの諺があるではないか。過去をいつまで振り返っていても仕方がない・・。

だが、それなりの年数、受注ビジネスに従事し、入札にも何回も関わってきた(そして、残念ながら負けた経験も少なくない)わたしは、少しだけ違う意見を持っている。敗北を忘れるためには、その前に、失敗経験からの「学び」を、ちゃんと記録しておく方が有用だ。そんなふうに、最近は考えている。

もっともわたし自身は、この何年間かプロジェクトの現場を離れて、企画部門に働いているので、必ずしも自分があるべきと思う通りに、仕事ができているわけではない。だが、自戒と反省を込めつつ、わたしは彼に答えた。


--だって、将来、全く同じでは無いかもしれないけれど、似たようなビジネスにまた君の会社がチャレンジしたくなる可能性もあるだろう? だとしたら、今回の教訓をちゃんと記録して、共有しておいた方が良いはずだ。

「・・うーん、まあそうかもしれません。ただ、自分ではもう二度と御免だ、と言う気持ちですが。」

--もちろんわかるよ。何も今日すぐに、とは言わない。少し気持ちが落ち着いて、でも具体的なディテールを忘れない内に、早めに取り組むことをお勧めする。

「といっても、一体何を学ぶんですか? ビジネスは結果が全て。今回は、武運拙く負けた。でも結局、負けは負けじゃないですか。」


(ビジネスは結果が全て。よく聞く言葉だ。勝ちか、負けか。1か0か。確かにそこからは、何も学びようがない。だが本当にそうなのだろうか?)


--もしもビジネスが、サイコロを転がして、出る目を当てるだけのようなゲームだったら、前回「1」が出ても、今回は何の目が出るか全くわからないのだから、結果からは学びようがないね。じゃあ君も、今回はサイコロのようにまったくの偶然で、勝敗が決まったと言うのかい?

「いや、そうは言いませんよ。ですが、偶然の要素は大きいんじゃないかな。偶然というか、自分ではどうしようもない環境要因ですかね。」

--なるほど。自分も受注競争に負けた後は、よくそう考えていたものだ。だけどね、ひと月経ち、三月経ち、頭も冷静になってから振り返ると、やはり負けた時は、『負けるべくして負けたのだ』と、考え直すことが多かった。よく、ラッキーによる勝利はあるが、偶然のアンラッキーによる敗北はない、と言われるのは、根拠のないことじゃない。

「でもそれって、論理的に矛盾していませんか? 偶然による+100があるのなら、偶然による− 100もある。そういう風に思えるのですが。」

--じゃあ、野球の世界で言う『 1点差の負けは、監督の責任』って諺は聞いたことがあるかな。大差で負けた時は、戦力自体に大きな差があるか、あるいは勝敗の大きな流れみたいなものに左右されて、抗いがたい。明らかに自分たちのリソースや、技術や体制に問題がある訳だ。だが、僅差での負けは、ちがう。マネジメントの判断ミスによるものなのだ。

「そうかなぁ。どうしてですか?」

--どんな勝負事やスポーツでも、チャンスが巡ってくる時というのが、あるだろう? それも、2つ3つ、続けてやってきたりするものだ。なぜだか知らないけどね、まるでエレベーターみたいに団子になってやってくることが多いのさ。(「なぜエレベーターは(そして仕事も)、一度にまとまって来るのか」 https://brevis.exblog.jp/27699308/ 参照のこと)

「そういうことは、あるかもしれません。」

--その時に、良い判断ができる監督は、最初のチャンスでうまくアドバンテージを掴んだら、それをさらに次のチャンスで増幅する。ちょうど、賭け金を増やしていくようなものかな。ところが判断の悪い監督は、賭け金を増やすことを怠る。逆に、チャンスを失うと、次の賭け金を増やしたりする。君は、連続するチャンスに上手く乗ることのできる判断能力を持つ人と、一つ一つをバラバラにしか判断しない人と、どちらが、より信頼できる監督だと思う?

「それは、ちゃんと賭け金を増やす判断のできる監督でしょう。」

--だよね。しかし、負けた直後には、自分ではなかなかわからないものだ。自分自身がその渦中にいて、事態を客観的に見る余裕がないからだ。とくに貴方みたいにリーダーの立場だったら、なおさらだね。しばらく経ってから、ようやく振り返って、やはり負けるべくして負けたのだと悟ることになる。

「うーん。では、どうしたら良いのですか?」

--そうだね、まず敗北したときの振り返りで、やってはいけないことをあげよう。5つ位あるかな。


  • 失敗に学ばない5つの方法

まず第一。誰かのせいにしてはいけない。顧客のせいにしてはいけない。上司のせいにしてはいけない。無能な部下や同僚や、勝手な営業のせいにしてはいけない。誰かのせいにした途端、思考がそこで止まってしまう。それでは学びにつながらない。

顧客が馬鹿だった、は禁句にする。賢い顧客なら、貴方の会社が勝ち、馬鹿な顧客だったら、あなた以外の会社が勝つ。もし本当にそうなのだったら、あなたのビジネスモデル自体が、根本から間違っていることになる。

「どうしてですか?」

--世の中にはね、会社の門前に、いわば見えない行列ができて、その中から自分の好ましい顧客の仕事だけを、選び取って受注していくような会社だって存在するんだよ。貴方がもし、馬鹿な顧客の仕事を取ろうと、ライバル会社と競争しているのだったとしたら、賢い顧客からのみ選ばれるようなビジネスモデルをめざさなければいけない。そうだろう?

「・・反論しにくいですね。」

--ちなみに、敗北は誰かの責任だと考えて、悪者探しを始める代わりに、全員の気合が足りなかった責任だと考えて、総懺悔するというのも、もちろん学びには通じない。だって、負けるたびに総懺悔しているのであれば、毎回、全く同じ反省内容になってしまうわけだからね。

2番目。敗北に別の名前をつけてはいけない。たとえば、一番極端な例をあげると、戦前の大本営発表のように、敗退を「転戦である」と 言い換えたりする。これも良くない。ひどいときには、戦いなどそもそもなかった、と強弁する。

「もしも負けていないのなら、学ぶ必要など全然ないですものね。」

--その通りだ。人間は、だれでも心の中に、見てはいけない・触れてはいけないアンタッチャブルな思考停止の領域を持つと、全体として思考能力が低下する状態に陥りやすい。これは断じて避けなければいけない。

3番目は、競争の制度やルールが悪いと批判することだ。

「だめですか。僕は今回、そこのところにけっこう不満があるんですけれども。」

--競争のルールやあり方そのものに、問題がある場合は結構多いし、それは改善していかないと世の中全体が良くなっていかないよね。しかし不公平なのは、相手側にも同様なんじゃないか。それとも、完全にフェアで公正な競争だったらば、君の会社が必ず勝って、不公平なルールだったら君のライバルが必ず勝つ、と言うようなゲームなのかな? だとしたら、そんな勝負の土俵に上がらないとビジネスが続けていけないこと自体に、問題があると言えるだろう。

「うーん・・」

--4番目は、『結果が全てだ』と考えて、途中のプロセスを考えないことだ。勝敗の結果は、すべてプロセスの積み上げによって決まる。野球だってサッカーだって、序盤、中盤、終盤戦があって、それぞれ布陣や作戦を変えるものだ。いや、試合が始まる前から、様々な準備や情報収集がある。ビジネスだって同じだろう?

「そうかもしれません。」

--これが競争入札なら、顧客の案件察知という準備段階から始まって、顧客要求の理解と読み込み、見積設計、サプライヤーへの引き合い、納期とスケジュールの計画、コスト積算、リスクのレビュー、提案書の作成、魅力あるプレゼンテーション…と言う具合に、様々なステップからなっているプロセスだ。

こうした作業一つ一つを、万全に積み上げてこそ、ようやく勝利が手に入る。このプロセスのどこまでがうまく進んだのか。どこでつまずいたのか。どこら辺から、戦況がおかしくなったのか。それを知ることこそ、次の学びにつながるんじゃないか。

「戦況の変化かあ。潮の変わり目は、たしかにあの辺りだったかもしれないなあ・・」

そして5番目は、敗北後の総括や情報収集を怠ること。客観的で正確な情報把握ができなくては、どんな反省をしても、意味のない無駄なものになってしまうからだ。たとえば入札だったら、技術面と価格面と納期と、どこで負けたのか。競争相手とどんなに開きがあったのか。こうした情報を取ってこなければならない。

ただ現実には、ここが1番難しい。ここは組織の行動習慣(いわばOS)が、問われる部分だ。特に顧客や競合相手の情報収集に対しては、営業部門の力が必要にある。だが、負けた仕事はすぐに忘れて次の仕事にかかるべし、と言う部門方針だと、ここが機能しなくなってしまう。

それと、上位マネジメントの姿勢も大切だね。現場に対して十分な支援をしなかったくせに、末端のリーダーだけ責任を負わせて査定を下げる、みたいな状態で、うまく『学び』が働くわけがない。最初に言ったように、誰かのせいにして終わり、だったら何も学ぶ必要はないのだから。

「・・なるほど。やっちゃいけない、『べからず集』みたいなものは、多少わかりました。じゃぁ具体的に、敗北から学ぶには、何をどうしたらいいのでしょうか?」

(この項つづく)


<関連エントリ>
 「トラブル原因分析を、責任追及の場にしてはいけない」 https://brevis.exblog.jp/22555315/ (2014-11-09)
 「なぜエレベーターは(そして仕事も)、一度にまとまって来るのか」 https://brevis.exblog.jp/27699308/ (2018-12-05)



by Tomoichi_Sato | 2019-07-28 19:48 | ビジネス | Comments(0)

モチベーション重視という名の危険思想

息子がまだ小さかった頃、幼稚園でお泊まり会というのがあった。みんなで先生と一緒に、一晩、幼稚園でお泊まりをする。それだけの行事だ。だが、親元を離れたことがない幼児たちにとっては、一大試練だった。


息子もその日は朝から緊張して、ああだこうだといろんなことを母親に要求していた。でも何とか夕方幼稚園に送り出した。翌朝、夫婦で迎えに行ったら、機嫌よく幼稚園の門から出てきたから、どうやら何とか楽しく過ごせたらしい。


その日の午後には、遠くに引っ越した仲の良い友達・ツーちゃんが、遊びに来てくれた。ひとしきり一緒に遊んであげて、友達を送ってから、わたしは息子に言った。


「ツーちゃんが遊びに来てくれて、よかったね。昨夜お泊まり会で頑張ったからだよ。がんばるとね、きっといいことがあるんだ。」


頑張れば、必ず良いことがある』--これは子供が小さいうちに、親が伝えるべき大事な教訓だ。だから、わたしもそうした。


ところで、わたし自身は、この教訓を信じているだろうか? 実は、あまり信じていない。特に「必ず」と言う部分については。世の中には「無駄な頑張り、役に立たない努力」というものもある。今はそう考えている。


例をあげよう。


一番端的な例は、上司や先輩よりも先に帰りにくいために生じる、長時間残業やサービス残業と言うやつだろう。実質的な成果につながらない時間の使い方をしているおかげで、能率は下がるし、疲れは溜まるし、会社は余計なコストを払うことになる。良いことなど一つもない。


まぁもしかすると、上司の覚えめでたく、次の人事評定で少しは良い点を稼げる、という副次的効果があるのかもしれない。でも、部下に無駄な残業を強いるタイプの上司は、人事評価においては、だいたい減点主義者なので、あまり大きな効果は望めないだろうが。


あるいは、競争見積における過剰なコストダウン努力も、見かけることがある。これは見積設計を必要とするような、個別仕様の案件で生じやすい。なるべく安い値段で見積もって、受注競争に勝とうとするあまり、顧客の示した技術条件を、無理に都合よく解釈して、少しでも安く設計しようと努力する。


見積期間は大抵短いから、通常の見積設計だけだって大変なのに、その上さらに無理なコストダウンの工夫をしなければならない。この社会では、お見積は全て無料サービスだから、受注できなければ努力は全て水の泡である。


仮にめでたく受注できたとしても、今度は仕様条件上の解釈をめぐって、発注者との厄介な交渉が待っている。こうしたネゴシエーションは、発注者の言い分の方が、ずっと強い。結局安値で受注したのに、赤字が増える結果に終わる。


競争相手が3社も4社もあったら、自社の受注確率は3割以下だろう。また顧客との関係から見て、有利な競争も不利な競争もある。顧客サイドの情報を収集し、的確な案件の分析を行って、無駄な競争を避けるのが良い営業戦略のはずだ。だが、どんな案件にも等しく「頑張りズム」だけで応じよう、と言う営業部門の態度が、この問題に拍車をかける。


最初に挙げた過剰残業の例は、頑張る行動が、仕事の目的に対してずれているケースである。また、2番目にあげた見積における無理なコストダウンは、大きな見通しや戦略もないまま、現場の頑張りだけで目的を達成しようとするケースを示している。


ところで、払う努力の方向性が、仕事の目的と合っており、かつ、仕事の見通しも立てているのに、努力が報われない場合もあるのだ。それはいわば、仕事における科学法則を知らない、ないし無視した場合に生じる。


次の図は、少し前に書いた記事「EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ」https://brevis.exblog.jp/28381225/(2019-06-09)で使った、非常にシンプルなプロジェクトのスケジュールの例だ。

e0058447_00001939.jpg

例えばこのプロジェクトで、納期を短くするために、サプライヤーと交渉の努力を重ね、25日間かかるハードウェアの納品を、5日短縮して20日間にしたら、どういう結果が生じるだろうか? もちろん言うまでもない。プロジェクト全体の納期は1日経って短くはならない。なぜならば、ハードウェアの納品は、クリティカル・パス上にないからだ。


もしもプロジェクト全体の納期を短くしたければ、ソフトウェア開発の方をなんとか短縮しなければならない。例えば30日間かかると見積もられているソフト開発のアクティビティーに、人を増員して、期間を短縮する。これが正しい方向の努力だ。無論、それに伴って、余計なコストがかかるかもしれないが。


ただし、この時も考えなければいけないことがある。例えば、ソフト開発の要員を、倍に増員して、30日間かかる作業を半分の15日間に短縮できたとしよう。もちろん人数を倍にしたからといって、単純に期間が半分になるわけは無いのだが、仮にそれが実現したとして、ではプロジェクトの全体期間は15日分減るだろうか。


実は、減らない。なぜならば、その時にはハードの選定と納品の方に、クリティカルパスが移動してしまうからだ。こちらのパスは、現在10日間のフロートをもっている。という事は、ソフト開発の方法を11日以上短縮しても、プロジェクト全体の納期は10日間までしか減らないのだ(これを、「ハード納品のCritical Path Drag値=10日間である」、と表現する)。


仕事の個別の局面に払う努力と、仕事全体の成果やパフォーマンスの間には、ある種の科学法則が成り立つ。そして、その法則に従って、最も効果的な方策を立てるべきである。ところが、わたし達の社会は、あらゆる局面において、過剰な努力を要求することが、あまりに多い。


わたし達は「報われない努力」というものに、もはや疲れている。長い不況の時代を通じて、疲れきっていると言っても過言では無い。


それはわたし達の社会が、仕事のマネジメントにおける科学法則やテクノロジーを、理解していない、ないし軽視していることから生じている。でも、それを軽視しているのだとしたら、一体何を重視しているのだろうか?


答えは「モチベーション」だ。仕事の成果を上げる最大の方策は、働く人のモチベーションである。--これが平成の30年間を通じて、日本社会が信じてきた最大の信念であり、イデオロギーではないかと、最近考えるようになった。


この信念は、冒頭に挙げた、「頑張ればきっといいことがある」と言う教訓と、密接にリンクしている。


モチベーションを第一の信条としている人たちの会話はこんなふうに始まる。


「あの仕事だがねえ、どうしたら成果が上がると思うかね?」

「それはやはり、やっている人間のモチベーションから生まれるものでしょう。」

「ふうむ。つまり、責任感をもって取り組んでもらう、という事だね。」

「はい。やはり、ある程度、現場に任せる必要があると思います。」


ここまではまあ、ノーマルな会話である。ただし、この人たちが言っている仕事の成果とは、つまり売上と利益であることが多い。損益計算書の「ボトムライン」である。


それと、「任せる」といっても、現実の企業では、権限移譲は簡単ではない。重要な決定権限(たとえば予算や人事権など)は、ラインの部門長は譲りたくないし、譲れないものである。したがって、仕事を任せるとは、実は「やり方(プロセス)を任せる」と言うケースがほとんどになる。


「まぁ、やり方は自分で考えてもらいましょう。やり方にまで、こちらが口をはさむと、結果に責任感がもてなくなる可能性もありますし。」

「その通りだね。何もかも指示してしまうと、言われたことしかしない、指示待ち人間をつくることになりかねない。」


ということで、責任感を持つことでモチベーションを上げるといっても、そこで言う責任とは、『結果責任』と言うことになる。言い換えれば、


「甘えるな! 結果が全てだ!」


と言う、よく聞くセリフと同じことを言っているのである。


ところで仕事の成果がモチベーション、つまり個人の主観的な頑張りに依存するのだとすると、成果は予見が難しい、ということになる。誰だって、他人の先々の気分までは読み切れないからだ。


したがって、このようなマネジメントスタイルをとっている組織では、売上目標や利益目標は立てるが、その確度は高くないことになる。当然、生産計画や要員計画のベースラインには使えない。そうなると、なるべく固定費になるものは(人も設備も)抱えない。急な変動のリスクは、外注先にヘッジする、という方策をとるしかなくなるだろう。


また、従業員のモチベーションを鼓舞するためには、当然、成果主義の報酬体系を組み入れることになる。頑張れば、その分報われる。逆に頑張らなければ、首切りリストラによる脅威にさらされる。アメとムチである。そして同期や同僚たちの間で競争させる。


かくして、平成を通じて進んできた、三つのトレンド:

・成果主義

・非正規雇用化

・競争原理の導入・強化

は、モチベーション重視という信念からも正当化される。すなわち、年功序列主義からの脱却であり、これを別名、構造改革ともいう。


またモチベーション重視は、主観主義に結びつきやすい。物事の状況判断において、客観的な事実やデータを積み上げる代わりに、自分の側の主観的な解釈や希望によって、対策を考える。何かを試みて、うまくいかなったとしても、それは頑張りが足りなかったのであり、もう一度がんばり直せば今度はきっと成功する。こういう信念が強いと、結局、失敗した経験からレッスンを学ぶことができなくなる。


・・それにしても、ここまでの説明は、日本企業におけるカイゼン文化とPDCAサイクル重視と矛盾していないだろうか? 作業プロセスを標準化し、PDCAサイクルを回して改善を重ねていくことが、マネジメントであると多くの製造業で考えられている。プロセスを標準化することで、誰でも一定の成果を出せるようにする。これがカイゼン文化の思想であった。


そうしたやり方は、とくに繰り返し性の高い業務(量産型工場)にフィットする。だから高度成長期から、昭和の終わり頃までの日本の製造業では、TQCとカイゼン活動が、とてもよく機能したのだ。


しかし、平成の時代に入って増えてきた、個別性の高い業務、クリエーティブな仕事はその限りではない。だって毎回個別なのだから、改善しようがないではないか。そうした状況においては、仕事の成果はモチベーションから生まれる。こう考えるのが自然な成り行きだったろう。そして、総員がその持ち場で全力を尽くせば、良い成果が生まれるはずである・・


わたし達は一体、どこで間違えたのか?


仕事の成果は、関数系で表すと、


 f(人の能力、業務プロセス、モチベーション、環境条件)


といった形になるだろう。仕事の成果は、人の能力と、仕事のやり方(業務プロセス)と、人のモチベーションと、そしてその仕事を取り巻く環境条件の、いずれにも左右される。

関数f(x) は、仕事と成果を結ぶ科学法則だ。それは単なる足し算にはならない事も、しばしばである。


カイゼン文化の思想では、PDCAを回すことがマネジメントであると考える。4つの中では、業務プロセスを重視するといえるだろう。ただし、それは繰り返し性の高い業務でないとあてはめにくい。また、A(改善アクション)は、個人の創意によるものだ。TQC七つ道具などの技法はあれども、肝心の部分は、じつはモチベーションに頼っていたのかもしれない。


では、個別性の高い業務のマネジメントとは、どういう意味なのか? それは、まず、結果を予見できるように(計画可能に)することである。次に、その業務を、繰り返し可能にすることであるはずだ。そうすれば、皆がお手の物であるPDCAサイクルに接続することができるようになる。そのための技術、マネジメント・テクノロジーの知恵を、皆が共有していく必要がある。

e0058447_23563119.jpg

わたし達の社会は、どうやらこちらの視点を、忘れていたように思える。かわりに、モチベーション重視と、科学法則を無視した足し算の論理が闊歩している。モチベーション重視という思想においては、上記の式の4つの項の中で、モチベーションだけが異常にに肥大化している。あとはこれに従属する、と考える。


当たり前だが、モチベーションは仕事において、とても大切な要素である。だれだって、ロボットのように、やりたくもない仕事を無理やり、やらされたくはない。ここで今さらマズローやダニエル・ピンクの議論を紹介するまでもないだろう。だが、それなりに長い平成の時代を通して、成果に結びつかない無駄な頑張りによって、わたし達は大切なモチベーションの感情を浪費してきたように思う。


平成の最初の数年間は、バブル経済の時代だった。あの頃は、環境条件が最大の項目で、相場が上がるかどうか、あるいは東京で家付きの家庭に生まれるかどうかで、人生が決まると皆が信じていた。それが崩壊した後の長い年月、人々が頼るのは、やる気・頑張り・モチベーションだった。


平成が終わって新時代に入った今、できればもう一度、仕事の成果の方程式を眺め直すべきだろう。そして何が一番肝心なのか、全体を一番支配する律速段階は、どこにあるのかを探るべき時が来たように思う。それを理解した時、初めて、わたし達は安心して、子どもに「適切に頑張れば、きっと良いことがある」と教えることができるようになるはずである。



<関連エントリ>

 →「EVMSとアーンド・スケジュール法の弱点 ~ プロジェクト予測のミクロとマクロ」https://brevis.exblog.jp/28381225/(2019-06-09)

 →「新しい決意と、『今のお気持ち』主義」 https://brevis.exblog.jp/21798589/ (2014-03-18)



by Tomoichi_Sato | 2019-07-13 23:56 | ビジネス | Comments(1)

ITシステムのオーナーシップとは何か

男が道を歩いていたら、「言葉を話せる犬、売ります」という看板を見つけた。興味を惹かれて門をくぐり、中にいた犬にたずねた。「お前さんがその犬か。これまで、どんなことをしてきたんだい?」

すると犬は答えた。「自分はとても充実した生活を送ってきました。まず、アルプスで雪崩の犠牲者救助をしてました。その後は、イラクで米軍の補助犬として働き、今は近くの老人ホームの人たちに本を朗読してあげているんです。」

感心した男は、オーナーに向かってたずねた。「こんな立派な犬を、何であなたは手放すんです?」
オーナーは答えた。「大嘘つきだからだよ。そいつが言ったことなんて、実は何一つやってないんだ!」

・・アメリカのジョークである。犬はまあ、それなりに知的な生き物だが、人間の所有物だ。オーナーの役に立つことをするから、飼ってもらえる。役に立たなければ、オーナーは手放したり売ったりするだろう。特に、それが「できる」と称している機能と、現実とにギャップがあれば。おまけに、米国の商品には(ソフトを含め)案外その手の品質ギャップが多いのだ。

前回の記事『プロジェクトのオーナーシップとは何か』https://brevis.exblog.jp/27925736/ で、わたしは「プロジェクト」という目に見えない活動のオーナーについて考えた。今回は、ITシステムという、同じく目に見えない道具について検討してみよう。

そもそも、オーナーシップとは何か。それは、端的に言って、何らかの対象を「自由にできること」を意味する。自由とは、例えば、利用したり、譲渡したり、変更したり、破棄したり、といったことだ。

もちろん、そのためには、自分がその対象を、正当に取得した(ないし自分で作成した)のでなければならない。そして、自分はその対象の価値を知っているし、はかることができる能力を持つ。
法律的には、いろいろなモノに対し、所有権とは区別して「利用権」を設定でき、他者に譲れる。土地がその良い例だ。所有しているということと、現在使っているということは、別なのである。

オーナーは、所有する対象から直接生じる便益や損失についても、対外的に責任を持つ。経済的な利益も損害も、そしてそれに伴う栄誉も、不名誉も、オーナーに帰せられる。犬を飼う人は、犬が他人に迷惑をかけたら、賠償したり詫びたりしなければならない。

また、その対象に依存して何かを行う他者がいる場合、オーナーはその維持にも責任を持つ。自動車の場合、特定他者とは、例えば家族の場合もあるだろう。あるいはレンタカー業で、ユーザと個別に契約を結ぶ場合もあろう。さらに、利用者が不特定な場合だって、何らかの社会的な責任というものは生じる。
要約すると、何らかの対象について、お金を出して取得し、その価値を活用し、さらに改善し、無価値になったら破棄することを、責任を持って行うのがオーナーシップである。つまり、
 PDCAサイクルを回す主体 = オーナーシップ
だと考えていい。
さて。読者諸賢の職場では、IT予算は誰が決めて、誰が払うのだろうか。情シス部門? ユーザ部門? それともケースバイケース?

IT予算に関する調査レポートは、日本情報システムユーザ協会(JUAS)をはじめ、いくつかの調査機関が出しているが、あまり予算の出所や管理権の所在について、書いたものを読んだ記憶がない。わたしが気づいていないだけかもしれないが。
じゃあ、別の聞き方をしよう。IT開発プロジェクトのオーナーは、誰か。IT開発チームのプロマネの上司である、情シス部長やCIOか。

ここで問題にしたいのは、社内の業務で使うタイプの業務系ITシステムのことだ。外部顧客向けのソリューション商品とかの話ではない(その場合は、プロダクト・オーナーが当然いるはずだ)。
実は、そのシステムを使って実現する「業務プロセス」のオーナーが、オーナーシップを発揮すべきだ、というのが今回の話だ。それが販売系プロセスであれば営業部門、製造系であれば生産、設計系であれば技術、物流系であれば物流部門がオーナーであるはずだ。

業務ユーザ側の部門が、開発予算の実質的スポンサーであり、IT投資からその価値を引き出す任務に当たる。である以上、開発投資(予算)の決断も、その内容とスコープ(範囲)も、その主たる業務機能も、業務ユーザ側部門が最終的な判断権を持つ。(なお、サーバやネットワークといったITの基幹インフラ系システムは、情シス部門がオーナーで構わない)

そして、業務ユーザ側が、IT投資に見合う価値があるかどうかを、判断する。これが、あるべき姿ではないか。
こう書くと、早速反論が寄せられそうだ。「ITのことなんか何にもわかんないユーザ側が、決められる訳ないだろ。第一、開発工数のことも、運用保守の負担も、テクニカルなアーキテクチャーの良否も、判断できないじゃないか? だから、俺たちが一番良いように、ちゃんと考えて決めてやるさ。俺たちが作って与えた通り、ユーザは使ってればいいんだ・・」
あえて嫌味な書き方をしたが、こういう感覚を内心持ったことのあるITエンジニアは、案外多いのではないか。
だが、これは危険な、官僚主義への道だ。その昔、汎用計算機しか世の中になくて、1台なん億円もした時代の感覚だろう。高価なリソースを管理し、使わせてやっている、という時代は、「専門家判断」に全てを依拠するのが主流だった。

だが、こうしたあり方は、かつての鉄道事業や電気通信事業のあり方を思い出す。あの当時、10円玉と100円玉の両方を使う公衆電話で、技術的にはできるくせに100円玉にお釣りを出さなかった電電公社のことを、覚えている人はまだ多い。こうした官僚主義のサービス事業は、みんな民営化されてしまった。

同じように、社内の情シス部門が聞く耳を持ってくれないと感じるユーザ部門は、しまいには自分たちで外部に直接アウトソースし始める。つまりITサービスが社内で「自由化」され、外部との競争にさらされることになる。今はそれが、十分可能な時代だ。昔の汎用機の時代とは違うのだ。そうして、社内バラバラなシステムが横行したら、最後に困るのは自分たちITエンジニアではないか。

「いえいえ、わたしは言われた通りのものを作るだけです・・」そういう受け身のITエンジニアたちも、もちろんいる。ただ、その姿勢はどうかというと、ユーザ部門の要望に従って作った結果、どうなっても、それは知りません、という印象をしばしば与える。つまり、オーナーシップを忌避ししてる訳だ。だが、ユーザ側にオーナーシップを求めている訳でもない。
結果として、「オーナー不在」なまま宙に浮いた業務システムが、社内に多数存在することになる。そうした業務システムは、PDCAサイクルを誰も回さない。いずれ、アーキテクチャ的にも機能的にも、温泉旅館的つぎはぎ構造になっていき、誰もまともに保守できなくなる。それもありがたくない話だ。

一番望ましいのは、ユーザ側が企画構想と実業務適用と評価・改善のPDCA責任を持ち、IT部門が開発と運用についてプロの専門家として委託される形だろう。

そして、IT機能の実現方法について、複数の案が存在するときは(たいていの場合はそうだが)、IT側が比較表を作成してユーザ側に提示する。比較表に記載すべき項目は、以下のようなものだ:

  • 実現手法
  • 実現できる機能要件
  • 想定される非機能要件(レスポンスタイム、スケーラビリティ、オペラビリティ等)
  • 初期コスト及び運用コスト
  • 長所
  • 短所

そして、ユーザ側が総合的な観点から、比較評価して決める、という手順を取るべきである。この時、開発予算や運用予算は、ユーザ部門側がオーナーシップを持って起案することになる。

ただ、ユーザ側がITにまるきり無知なままでは、ちゃんとしたオーナーシップを持てないのも、事実だ。結局、これは社内一般ユーザのIT的な育成という課題にたどり着く。

無論これは、かつてのような社内OA講座みたいな「コンピュータ・リテラシー教育」の問題ではない。ITとは何で、ITシステムとはどういうもので、開発プロジェクトはどう進められ、運用保守は何が大切か、といった研修が必要なのだ。業務をITに合わせるべき点はどこで、逆にITシステムにはどういう機能要件を持たせるべきか、という最適バランスを、ちゃんと議論できるようになってもらわなければ、良いITシステムは作れない。
ところで、単独の部門の業務に関わるシステムの場合はいい。複数の部門にまたがるような、複雑広範な業務プロセスのITシステムは、誰がオーナーシップを持つべきなのか?

これがまた、現実には厄介な問題なのである。ここでも、前回と同様、「ステアリング・コミッティ」方式を取るしかない。関係する部門からメンバーを出してもらい、委員会方式でコンセンサスをとっていくのだ。

ただ、その場合でも、リーダーとなる部門は明確に決めるほうがいい。そうしないと、意思決定の責任所在が不明の、いつもの「日本型無責任体制」になりかねない。

なお、米国などのグローバル企業には、「業務プロセスのオーナーシップ」という考え方がある。例えばマイクロソフトには、数名のエグゼクティブがいて、彼らがそれぞれ業務プロセスについてグローバルに責任を持っている体制だと、数年前に聞いた。しかし日本企業では、こうした体制になっている例は、寡聞にして聞いたことがない。目に見える「モノ」には非常にこだわるが、無形の「プロセス」には興味がない人が多いから、だろうか。

だが、ITシステムというのは、より競争力の高い業務プロセスを実現するための、ツールなのだ。だから、本当はITシステムではなく、『業務プロセスのオーナーシップ』を考えるのが、より適切なのだろう。ただ、これまた、確立するには、随分と道のりの遠い話だ。だが、そうしないと、言葉はペラペラ喋るが、内実は全く伴わない犬を飼っているのと同じで、カッコいいけれど出費だけが虚しく続く生活に陥るのである。



by Tomoichi_Sato | 2019-01-27 21:21 | ビジネス | Comments(0)

望みと抱負とふりかえり

一年の計は元旦にあり、という言葉がある。ときおり、これを「一年の総決算は元日にあるという気概で、最初の日を過ごすべきだ」みたいな意味にとる人がいる。だが、これは誤解だ。ここでの「計」とは、総計の意味ではない。一計を案ずる、のように、計る・計画を立てる、という意味である。

ついでに言うと、旦と言う漢字は、地平線の上に太陽が昇っていく有り様を表し、朝のことを意味する。つまり元旦と言うのは、元日の朝のことである。まぁ漢字というものは、わかっているようで、案外わかっていないものだ。

ところで、これに対して、大晦日は一年のふりかえり、などと言う言葉はあまり聞かない。だが、年の瀬に1年のことを想い起こすのは、とても大事な習慣だと思う。

1年間のふりかえりは、まず、あれがあった、これもあったという、「10大ニュース」的な思い出しから始めるのが良い。わたし達はいろいろなことを、忘れやすい。だから手帳やカレンダー、日誌、記録などをみて、記憶の地層から掘り起こすようにする。

特に最初は、昨年の「3大ラッキー」を思い出すことをお勧めする。いろいろなことがあった。でも、ラッキーだったこともあるはずだ。たとえ小さな事でもいいから、自分の身に降りかかった幸運な出来事を考える。そうすると、気持ちが穏やかになるはずだ。気持ちを穏やかに、新年を迎える方がいい。

もちろん、中には忘れたいこともあるだろう。不運なできごと、イタい結果を招いた自分の決断(ないし不決断)、あるいは悔やまれるミス、などなど。そうしたことから無縁でいられる人は少ない。

それでも、そうした経験から何が学べるか、教訓(Lessons Learned)を考えてみる。仮に不運は避けえぬとしても、予兆はなかったか。早く気づけば、傷は浅く済んだかもしれない。失敗や本ミスなどの場合は、自分の間違いがすぐさま外に出ないよう、ダブルチェックやフェイルセーフを考えるべきかもしれない。

え? うじうじと考えて過去を振り返るのは自分の趣味じゃない? なるほど。そういう方には、「KPTフレームワーク」をご紹介しよう。これは仕事で使うツールである。KPTは、Keep, Problem, Tryの頭文字で、文字通り、この三種類についてふりかえりを行い、文章にまとめる。もちろん箇条書きで良い。

K(Keep):振り返ってみてよかったこと、これからも続けたいこと
P(Problem):問題だと思うこと、解決すべきテーマ
T(Try):次の回にはチャレンジしてみたいことがら

KPTフレームワークはチームで行う定期的なふりかえりに用いられ、アジャイル開発のミーティングなどでも、よく使われているようだ。

ここで、T(Try)の中には、目標設定の萌芽がある。つまり、次の計画のタネである。

わたしは、2000年に出した最初の単著『革新的生産スケジューリング入門』で、計画という仕事を、次の式で表した:

 計画=予測+意思決定

計画という仕事は、単なる予測とは違う。予測計算だけだったら、今後はきっとAIが人間よりずっと上手に行っていくだろう。しかし、そこには意思決定がなければならない。何に関する意思決定か? 1つには、不確実な外部環境に関する仮説である。もう一つは目標設定に関することだ。自分の目標設定は、機械に任せるわけにはいかない。

ところが、この「目標」あるいは「目標設定」と言う概念が、残念ながらわたし達の社会では、あまりよく理解されていないように思える。その証拠に、非常に漠然とした目標設定が、プロジェクトの出発にあたって設定されたりすることを、しばしば見かける。

わたしはプロジェクト・マネジメントの授業で、学生に対して、目標設定の演習として、自分の卒業論文作成プロジェクトの目標を書かせたりする。すると、
「研究活動に慣れ、装置の使い方をマスターする。分析には○○を用いるので取り扱いを慎重にして事故を起こすことなく、必要なデータを取る」
などと答える学生がいる。まことに優等生的な文言だが、これは目標だろうか? やり方、プロセスを答えてるだけではないか。

あるいは、就活プロジェクトの目標を書かせると、「会社に入社し働く」などという答えがかえってくる。これではどんな会社であれ、入社できればOKということになってしまう。どのような会社にESを出し、何を狙うかといった方向性が、目標からさっぱり出てこない。

この事情は学生に限らない。社会人相手に研修をしてみても、プロジェクトの目標設定で、例えば「納期と予算を守ること」などと答える人が少なくない。もちろん普通たいていのプロジェクトは、予算・納期・品質・Scope・法令等の制約条件を課されるものだ。だが、制約を満たすことは「必要条件」であって、目標ではない。

目標とは、成功・失敗を測る基準=Success criteriaである。それはゴールや目的とは異なる。陸上競技に出て100mを走る時、ゴール地点まで走ることは、誰だってできる。目標とは、「12秒台で走る」「自己記録を更新する」などでなければならない。これだったら、ゴールインした時に、目標を達成できたか明確に、すぐ分かる。

ふりかえりの効かない目標を設定してはいけない。終わってみて、結果をふりかえり、良かった点を伸ばし、まずかった点は改善する。こうして、人も組織も成長していく。曖昧な目標、例えば「精一杯頑張る」「事業の進展を図る」などという目標を設定すると、ゴールインした時に、達成したのかしなかったのか、議論が分かれて誰も分からなくなる。こうなると、ふりかえって考えるべきポイントを見失ってしまう。

これを避けるために、目標設定では、『SMART基準』というやり方を知っておくべきである。SMART基準とは、以下の5条件の頭文字をとったものだ。

  • Specific=具体的である
  • Measurable=計量可能である
  • Achievable=達成可能である
  • Relevant=目的に関連している
  • Time-bound=期限がある

目標は、具体的でなければならない。抽象的な「事業の進展を図る」では、何がどう進展すれば成功なのか、判然としない。また、目標は計量可能でなければならない。「精一杯頑張る」は本人の主観で、客観的に測りようがない。

さらに、目標は達成可能でなければならない。「100mを5秒台で走る」という目標を立てて、達成できる人間がいるだろうか? 不可能すぎる目標は、やる人のモチベーションを削いでしまう。また目標は、その仕事の目的に関連していなければならない。100m競走の目標を、「優勝して女の子にモテたい」にするのは、何か別の目的が混入しているだろう。

そして、目標設定は、一応の期限をつけた方がいい。まあ1年の抱負なら、必ず期限がくるはずだが。

e0058447_22274606.jpg
このSMART基準は、英国における公共サービスや公共事業において、政策評価チェックシステムであるPSA (Public Service Agreements: 公共サービス協定)で用いられる基準である。公的な資金を投入して、なんらかのサービス開発や事業を行う場合、必ず「政策評価」というチェックを実施するのが、英国のやり方である。その際の「チェック=ふりかえり」において、最初に立てた目標を検証する。だから、目標をSMARTに立てることが要求されるのだ。これがまあ、成熟した民主主義社会というものの姿なのだろう。

一年のはじまりは、望みや抱負をいだく季節である。希望とは、自分にとってより良い未来を、自分が関わって創りだしうる、という感情だ。自分の努力が関わらないこと、例えば「今年は宝くじに当たります」を、自分の目標にする人はいない。「宝くじが当たったら」という夢を見るのは、いい。ただ、その夢を見ているだけでは成長はできないのだ。

わたし達の社会で、SMART基準といった目標設定の考え方が普及していないのは、なぜなのか。これは想像だが、かつての昭和時代、多くの人にとって、目標とは抽象的な数値や基準ではなく、「ああなりたい人」の背中だった。いつかは、あの人に追いつきたい、あんな風になりたい、が目標だった。少しは近づいたかどうか、節目ごとにふりかえりも可能だった。

今の時代は、若い人(特に男子)にとって、追いかけたい「背中」が見えない。だから、ふりかえりが難しくなったのだ。

いや、社会全体で見ても、高度成長期には、欧米先進国が「追いかけたい背中」だった。それがバブル期になると「もう欧米に学ぶものなし」の有頂天になり、その後のバブル崩壊で向かう方向も見失ったのだろう。目標は、「売上の前年度維持」みたいなものになってしまった。自分の背中を、自分で追いかけているのだ。ただ、既存の市場を守ることだけが、自己目的化した。

出来上がってしまって、蟻の這い出る隙もないような業界構造、一方的で不公正な組織や慣行、そして身分制度のように固定され、公正さが望み得ない社会では、誰が希望を持ちうるだろうか。今、わたし達の社会で足りないのは、将来の人口数ではない。将来の望み、ビジョンが足りないのだ。

たとえ経済的に豊かでも、希望を持ち得ないコミュニティの中では、人間は孤独になる。自分しか信じるものがなくなってしまうからだ。そうした殺伐とした社会は、この地球を見渡すと、確かに存在する。わたし達の社会がそんな状態に陥るのを防ぐためには、人は変わりうるし、組織も成長しうることを、やはり示さなければならない。

つい大げさなことを書いたが、わたし自身も、今年はまた、少し技術的なスキルを学び直そうと思っている。ま、なんとかの手習いだが(笑)。それは昨年末に発表した、勤務先の長期的なビジョンとも関わっている。

海図は引いた。だが船出はこれからだ。年明けの今こそ、望みを自分の中に持ち直すときである。


<関連エントリ>
 →「今年の抱負はこう作ろう」 https://brevis.exblog.jp/21527608/ (2014-01-03)
 →「“仕事が面白くない”症候群とたたかう三つの方法」 https://brevis.exblog.jp/23726856/ (2015-09-30)


by Tomoichi_Sato | 2019-01-07 22:36 | ビジネス | Comments(0)

講演(計装制御技術会議・11月1日)と論文記事執筆(経営システム誌)のお知らせ

(1) 講演のお知らせ

いつもながら直前のお知らせで恐縮ですが、来る11月1日に、日本能率協会主催の「計装制御技術会議 2018」で、日本の化学産業とプロセスプラントの変貌について、講演します。

これは3日間にわたる計装制御系の会議で、三日目の「スマート化で実現するプラントの未来像」の午後一番にお話しします。かなり専門的な技術分野の会議でもあり、また申込期限まで日数がありませんが、この話題に興味をお持ちの方はぜひご来聴下さい。

<記>

題目:「ディスクリート・ケミカル工場の設計論と 中央管制システムの姿

講師:佐藤 知一 (日揮株式会社 データインテリジェンス本部 DIプランニング部 部長)
日時:2018年11月1日(木) 13:00-13:40
場所:品川フロントビル (港南2丁目3-13, 東京都)

・参加申込み・会場アクセスは下記ホームページをご参照下さい。


(2) 論文記事執筆のお知らせ

日本経営工学会の「経営システム」誌・第28巻1号に、下記の論文記事を書きました。

佐藤知一:「生産システム,そのパラダイム・シフト
 経営システム, Vol. 28, No. 1, pp. 70-75 (2018) 

紙の学会誌は7月に発行されましたが、おそらく購読されている方は少ないと思います。同誌は一応、学会のWebでも公開されています(ただし閲覧には会員登録とパスワードが必要です)。

ただし、学会誌には「別刷り」という古き良き習慣があり、読みたい人には論文のコピーを配布することができます。わたしの手元にも多少の部数がありますので、講演を聴きに来ていただいた方には、希望があれば別刷りを進呈いたします。

ちなみに 元々この記事は、拙サイトに掲載した同名の記事である、
 『生産システム、そのパラダイム・シフト』 https://brevis.exblog.jp/27223637/ (2018-04-28)
を読まれた編集委員のリクエストで、論文記事の形式にしたものです。そして下の図も、載せています。学会誌ですから内容はもっと敷衍していますが、主旨は同じですので、興味がある方は上記のエントリもご覧下さい。

e0058447_22243364.jpg

(1)と(2)のいずれも、近年わたしがずっと主張している、「工場とは生産のための仕組み(システム)であり、その設計と操業には、システム工学の視点が重要である」という事柄を論じた点では共通しています。今年の経産省『ものづくり白書』でも触れられていましたが、「システム思考」の弱さが、今日の日本の製造業の苦境をもたらした原因の一つであると、わたしは考えています。それを脱却するにはどうしたらいいかが、目下のわたしの主要なテーマです。



by Tomoichi_Sato | 2018-10-23 22:32 | ビジネス | Comments(0)