人気ブログランキング |

<   2019年 01月 ( 3 )   > この月の画像一覧

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)

プロジェクトのオーナーシップとは何か

オーナー(Ower)とは、所有者であり、オーナーシップ(Ownership)とは所有権を意味する。ただ英語の語尾 -shipは、名詞について、それを持つ人の志や、性質や「らしさ」をも示す(例えばリーダーとリーダーシップのように)。だから、オーナーシップとは、所有者らしいふるまい、ということにもなる。

有形のもの、車とか家などのオーナーシップの意味は、誰にも明らかだ。そのものを所有して、自分の意のままにすることができる。無形のもの、例えばライセンスといったものにも、オーナーシップを考えることができる。自分がお金を払い、そこから得られる便益を自分の自由にすることができる。何であれ、それを維持する労力や費用負担し、そこから主たる価値を得るものは、それに対するオーナーシップを持つと言えるだろう。

それでは、プロジェクトのオーナーシップとは、何なのか?

X社のプロマネP氏は、困惑していた。大型プロジェクトを受注して数ヶ月。このままでは、かなりの赤字になることが明白だ。現時点での詳細設計から、全体コストを見積もり直してみると、当初想定していた金額を大幅に上回ってしまう。

顧客のA社に窮状を訴えて、追加費用を出してもらうことも考え、実際内々に打診してみた。だが顧客の反応は冷たかった。そもそも基本設計も、X社が有償で行なったのではないか。その基本設計書の内容をもとに、両者が合意して一括請負契約を結んだのだから、その通り実行してもらいたい。それが向こう側の言い分だった。

確かにその通りだ。要件定義は前任者のプロマネが行い、P氏はそれを引き継いだまでだ。ただ、顧客の業務要件は思ったよりはるかに複雑で、例外が多く、新しく入ったメンバーが理解するまでの時間も、かなり必要だった。

おまけにもっとまずい事に、プロジェクトで中心的に使うつもりでいた自社製の新型装置を、隣のチームが並行して開発中だったのだが、予定された期日からかなり遅れていた。基本設計レベルに問題があったらしく、期待したパフォーマンスがさっぱり出ないのだ。そのおかげで、上司の命令により、自分のチームから優秀なメンバーを数名、隣に回さなければいけなくなった。

仕様は思ったより膨らんでいる。優秀なメンバーもとられてしまった。あてにしていた中核装置も出来上がってこない。顧客は頑固な態度である。このままでは赤字は必至だ。一体どうしたらいいのか?

世の中ではしばしば、大赤字を生みデスマーチが見えているプロジェクトが、延々と続けられている。なぜだろうか。受注したからには完成させるのが受注者の義務? だが、たとえ違約金を払ってでも、プロジェクトから降りてしまう方が、ビジネス的には傷が小さく済む場合だってあるではないか。

だが、一般にプロジェクト・マネージャーには、プロジェクトを中止・撤退する権限はないのである。プロマネとは、プロジェクトを遂行するように命じられた存在である。遂行の義務と責任を負っている。仕事のパフォーマンスがまずくて、プロマネの職を解かれることはある。だが、プロジェクトの価値が下がったからといって、自分からプロジェクトの遂行をやめる権利は無い(会社自体を辞めてしまうなら別だが)。

そこで改めて考えてみよう。プロマネを任命するのは、一体誰か。プロマネの成果を認定し、評価するのは誰なのか?

それが、「プロジェクト・オーナー」なのである(オーナーは、業界によっては「スポンサー」と呼ばれる場合もある)。プロジェクトの価値を考え、プロジェクトを発進させ、プロマネを任命し、予算を与えるのがオーナーの仕事である。なお、プロジェクトが上位の「プログラム」の一部である場合は、プログラム・マネージャーがオーナーシップをとる。だが、日本ではプログラム・マネジメントをまともに実施している企業がほとんど無いため、そのケースは無視していい。

さて、苦境に陥ったP氏は、上司である事業部長K氏に、状況を正直に報告し、対策を相談した。事業部長が、このプロジェクトのオーナーだったからだ。そこでK事業部長も、自ら顧客に追加交渉にいってみた。だが、相変わらず相手の態度は硬い。このまま続ければ、この開発プロジェクトと、自社の新型装置開発の、二つのプロジェクトがともに道連れで沈没しかねない。

K氏はさらに上の役員と相談の上、苦渋の決断を下した。顧客A社に対し、違約金を払って、このプロジェクトから降りると宣言したのだ。

発注者A社側のプロジェクト責任者は、X社の撤退に驚き、大いに怒った。たとえ違約金をもらったからといって、費やした時間も労力もかなり無駄になったからだ。しかしA社の担当役員は、X社の決断に舌を巻き、内心、敬意を評したという。X社が受注者としてのスポンサーシップを発揮し、痛みは伴うが適切な決断を下したからだ。「確かにウチは迷惑した。だが、あの決断は大したものだ。なかなかできる決断ではない。」

撤退の判断は、つねに難しい。特に受注型プロジェクトの場合は、なおさらだ。お金も労力も失われるが、自分のメンツや顧客からの評判は丸潰れになる。業績評定にだって、大いに影響が出るだろう。

プロジェクトが完遂できないのは、明らかにプロジェクト・マネジメントの失敗である。だが、失敗したプロジェクトから、適切なタイミングで撤退する事は、正しいオーナーシップの発揮なのだ。この点を世間の人は誤解しがちなので、あえて繰り返し強調しておく。失敗したプロジェクトから思い切りよく撤退する事は、オーナーシップの失敗ではない。

オーナーシップの失敗とは、価値のなくなったプロジェクトを、延々と続ける事なのだ。プロジェクトにおいて最も恐ろしい事とは、プロジェクト自体が自己目的化してしまう事だ。ゴールに到達したが、結果は無価値で、労力と金と時間の無駄だった、という事ほど、人心を荒廃させる事はない。それはオーナーシップの不在を意味する。

わたしは授業でよく、公共事業のケースを例にあげる。有名な公共事業の中には、すでに半世紀以上にわたって遂行中で、予算規模も千億円クラスのものがある。だが、終戦直後に計画されたその事業の完成を、もはや誰も待ち望んでいない。それでも続いているのはなぜか。役人という人種が、いったん始めた事は絶対に失敗を認めないし、撤回もしないからだ。だが、繰り返す。失敗を認めず、意味のなくなった事業を続けることこそ、より大いなる失敗なのだ。

もちろん、オーナーの仕事はプロジェクトを中止し撤退することだけではない。むしろそれは最後の選択肢だ。オーナーは、プロマネを助けて、プロジェクトが意味ある仕事として完遂することを支援するのが、本来の仕事である。

以前、米国のPMコンサルタントであるNeal Whittenの主張を紹介した(「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/)。彼によると、米国におけるプロジェクトの問題の1/3は、オーナーシップの不全にある、という(彼は「スポンサー」という用語を使っている)。

それでは、プロジェクト・オーナーの仕事とは何か。それは、

  • プロジェクトを起動し
  • プロマネを任命し
  • Project Charterを承認し
  • 予算枠と期限を与え
  • プロジェクトの状態と価値を定期的にウォッチし、
  • プロマネの相談に乗り、助ける
  • プロジェクトの終結を承認し
  • あるいは、無価値となったプロジェクトを中止する

こうした、プロマネに対する「上からの支援」が、プロジェクトの成功のためには、非常に重要なのである。だからあえて、以前も掲げた図をここに再掲しておこう。
e0058447_23034860.jpg
プロジェクト・オーナー(スポンサー)は、プロマネの相談相手として機能しなければならない。そして、プロマネの悩みはたいてい決まっている。それは、お金が足りません、か、人が足りません、なのだ。オーナーというのは上級職の仕事で、普通はプロジェクトにフルタイムで関わることはない。だが、プロマネに対しては、いつでも悩みを聞いてあげる存在でなければならない。

ところが、わたし達の社会では、これが弱いのだ。あるいは、オーナーという役割が存在しない場合も多い。その必要性さえ、認識されていない。だが、プロマネを助けないプロマネの上司とは、一体何のためにいるのか?

とはいえ、多くの読者諸賢の職場では、実際問題、オーナーというポジションは存在しないかもしれない。だったら、どうすべきか。居ないものは居ないとして、それでもプロジェクトが倒れないようにするための、現実解を考えなければならない。

わたしがお勧めする方法は、三つである。

第一に、きちんとProject Charterを作ることだ。Charterというのは、日本では「憲章」と誤訳されているが、「趣意書・許可書」のことだ。もともと英国で、国王が特に出す勅許状のことを、Charterと呼んだ。特別仕立ての飛行機のことをチャーター便と呼ぶのは、その名残だ。また英国では、公式に認定された技術者をChartered Engineerと呼ぶ。

Project Charterという文書は、組織が、そのプロジェクトを公式に認めて、その発進を許す書状である。そこにはプロジェクトの目的や目標などを書く。そして本来は、このCharterはプロジェクト・オーナー(スポンサー)が作って、プロマネに与える、という建前になっている。少なくとも、PMPの試験では、そう書かないと正解にならない、と教わったはずだ。

だが現実には、プロマネがCharterを作っている企業が大半である(だってオーナーはいないのだから)。そこでCharterを作ったら、それをしかるべき上司に、承認してもらおう。表紙にハンコの承認欄を作るのもいい。判子をもらってしまえば、それは上司が公式に認めたことになる。そして上司にも責任(命令責任)が生じる。

あるいは、もう少しモダンなやり方としては、皆で集まってチームビルディングを行う。そして、最後に皆で「コミットメント・シート」を作る。そこにサインを寄せ書きする。無論、上司には中央にサインをしてもらおう。そのシートは、プロジェクト・ルームの壁に掲げて、いつでも見えるようにしておく。こうして、オーナーたるべき人物を、責任と面子のループに取り込んでおくことが重要である。わたし達の社会は、面子とコンセンサスの社会なのだから。

第二に、プロジェクトのJournalを頻繁に発信することである。Journalというのがまた、適切な訳語がない言葉なのだが、元々は日誌のことで、転じて定期刊行物や雑誌を意味するようになった。プロマネにとって、日誌をつけるのは非常に良い習慣である。それはいざという時の法的根拠にさえなる。だが、もっとソフトな意味で、定期的な情報発信のことを、ここでは言っている。

つまり「プロジェクト週報」だとか「プロジェクト新聞」といった簡単なニュースメールを発信し、関係者皆に送りつけるのである。関係者の中には、もちろん「オーナーたるべき人」も、さらにその上司をも、送付先に含めておく。

こうして、プロジェクトの状況を、定期的に、かつできる限り頻繁に、皆に知らせておき、上層部にも関心を持ってもらう。「そんなの多分、メルーボックスの肥やしになるだけだ」などと、最初から悲観してはいけない。捨てる神あれば拾う神ありで、世の中にはたまに、ちゃんと見ている人もいるのだ。プロマネはなるべく、いろんな人に味方になってもらう必要がある。

三番目の方法は、ちょっと大技だが、プロジェクトのために「ステアリング・コミッティー」を設置してしまう(設置してもらう)やり方だ。これは、拙著『世界を動かすプロジェクトマネジメントの教科書』 (最近増刷が決まった)に書いた方法でもある。

この本では、製造業の若手エンジニア・小川君が突然、海外企業とのジョイント・プロジェクトに巻き込まれるのだが、このプロジェクトたるや、誰がプロマネなのかも判然としない。そんな中、大学の先輩だった広田氏のアドバイスをもらいながら奮闘していく物語だ。その際、プロマネもオーナーも不明ながら、なんとか仕事を前に進めるために、あえて複数部門の管理職の層でステアリング・コミッティーを設置してもらうよう、小川君が上に提案する(広田氏がそう勧めたのだ)。

その顛末は本を読んでいただくとして、いったんコミッティーを作ると、なにせ面子とコンセンサスの国だから、なんとかサポートは得られる。そして、プロジェクト・ガバナンスの点からいうと、これはこれで立派な方策なのである。

もちろん、上記の三つの方法が、いつも功を奏するとは限らない。忙しい中、権限もないのに、実行するのはかなり大変だろう。でも、本当にプロジェクトが傾いてきたら、一番こまるのはプロマネの自分なのだ。だとしたら、少しでも会社にオーナーシップを自覚してもらうべきである。

それにしても、研究会などで多くのプロジェクト事例を聞くにつけ、感じることがある。日本の多くの組織で見られる、現場リーダークラスの共通の悩み、共通の問題があるのだ。

それは、ビジョンの不在や戦略の失敗を、戦術レベルでなんとかカバーしようと努力して苦労している、という事実だ。これが、中堅若手のプロマネや、サブリーダー・クラスの疲弊感を生んでいる。たとえば、営業部門が売上目標のために無理な価格、納期で受注してきた案件を、技術部門が苦心惨憺、遂行する。そして、プロジェクトをなんとか黒字にできないか、悩んでいる。あるいは、ヘンテコな製品戦略のために、新製品開発プロジェクトが迷走し、BOMや基準情報までが混乱する。こうした例は、枚挙にいとまがない。

なぜ、そんなことに努力を費やすのか。それは、現場リーダーに与えられた権限範囲と、リーダーの責任(評価・賞罰)とが、あっていないからだ。プロマネ自身ではどうしようもない環境条件において、結果だけを評価される。ここでプロジェクトの「環境」とは、プロマネが短期的な努力では左右し得ない条件をいう。

プロジェクトのオーナーシップは、プロマネを任命する権限を持つ者にある。したがって、プロジェクトの最終的な損益やアウトカムに対する最終的責任・評価もオーナー側にあるのだ。プロマネは与えられた条件下で、どこまで良くやったか(計画し遂行したか)を評価されるべきである。プロマネは、自分では途中でやめられないのだ。プロマネには実行責任がある。だが、命令責任は、オーナーは負うべきなのである。


<関連エントリ>
 →「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/ (2015-07-08)
 →「アカウンタビリティとは『命令責任』である」 https://brevis.exblog.jp/24837740/ (2016-11-05)


by Tomoichi_Sato | 2019-01-17 23:12 | プロジェクト・マネジメント | 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)