「佐藤さん、すみません、ちょっとご相談があるんですが・・」
若手社員が机の前にやってきて、顔を上げたわたしに、いいにくそうな声でぼそっときり出した。わたしが、ITリッチなプロジェクトをやっていた時代のことだ。 --なあに? 何か、いい話かな? 「いえ、あの・・。例の中間在庫ロットなんですが、どうしようかと悩んでいまして。」 --そこは新しいコード体系を使おうって、先週の打合せで決めたじゃないか。 「そうなんですが、注文書のシステムで、ちょっと困ったことが見つかりまして。あのままでは、番号がかち合ってしまう可能性があると分かったんです。」 彼は仕様書の該当箇所をわたしに見せて、問題を詳しく説明する。なるほど、先週の打合せでは、この点を見落としていたらしい。 --つまり、このまま進めば、ユーザに運用を変えてもらって、少しだけ手間が増えるのを我慢してもらうか、さもなければシステムの設計変更をするか、二つに一つです、という訳かな。大勢のユーザに文句を言われるか、開発会社から追加費用を請求されるか、どっちかしかありません、と。 「・・まあ、そういうことです。どうしたらいいでしょうか?」 そこでわたしは、いつものセリフをぶつけた。 --あなたは、どう考えるの? その場で部下が、自分の考えを言ってくれれば、もちろん、それでよし。内容について議論できる。部下の考えがまとまっていない場合は、「少し考えてから持ってきてごらん」と、いったん突き放すことにする。 しばらくすると、「佐藤さん、こう思うんですが。」といってくるので、そこからは議論に付き合い、一緒に考えることにする。たとえ、途中こちらがヒントをだし、リードをしても、「一緒に考える」雰囲気が大切だ。そうすれば相手は、打合せ結果を「自分が考えたこと」として、モチベーションをもって働いてくれる。 わたしはこのようなやり方を、自分自身が駆け出しの頃の、上司から学んだ。わたしが同様に、問題を抱えて、こまって上司のところに行くと、彼は決まってためいきを一つついてから、こう言う。 「それで、オタクはどうしたいんだよ?」 (その人は有名私学の出身で、そのころはまだ珍しい『オタク』という二人称を使う人だった) わたしが、何も自分でアイデアをもっていないと、「考えてからもってこいよ。」といわれて、対話は終わってしまう。なにか解決策や提案を持っていけば、(もちろんたいていは技術的にケチョンケチョンに叩かれるのだが)とにかく前には進める。 だから、問題が生じても、まずは自分で答えを考えてから、相談に行く姿勢がいつの間にか身についた。それは、そのあと、自分が直接、顧客と接して動かなければいけないキーパーソン・レベルになってからも、とても役に立った。だからわたしも、人を使う立場になると、自然とその真似をするようになってきたのだ。 ただし、ときおり、まったくこちらの指示に依存する姿勢の若手も現れる。「少し考えてから持ってきてごらん」と突き放しても、こういうケースではたいてい、すぐにギブアップしてくる。自分で考えて突破しようという思考体力というか、基本的なスタンスが足りないのだ。おまけに、わたしは冷たい上司だと思われてしまう。そうなると、今度は問題が発生しても、わたしに報告せずに自分一人で抱え込むようになる。そして火が噴くまで、こちらが気づかない危険性が増す。 そういうときは、しかたないので、論点を整理しつつ、もう少し踏み込んで、最初から一緒に考えてやることにしている。その若手社員も、そのタイプだった。一緒に問題構造を図解したホワイトボードの前で、彼は言い出す。 「佐藤さん、従来の品番コードの頭に、取引先の略号を3桁つける、という手はどうでしょうか?」 --そりゃダメだ。そんな抜け道を造ったら、工場内のロットを物流システムで統一的に管理するという、全体の設計思想が歪んでしまう。それに、3桁なんて、どうせすぐパンクするよ。 「それじゃ、どうしたらいいでしょうか?」 設計思想を大事にしろ、というのも、上で述べた昔の上司から学んだことだった。ただし彼は、設計思想という言葉の代わりに、『設計のスタンス』という呼び方をしていた。その方が、顧客に対してスムーズで、通りやすいからだろう。設計のスタンスを曲げると、あとで追加修正が難しくなり、いきおい全体が温泉旅館の建て増し的な、ゴチャゴチャしたものになっていってしまう。そうなれば結局、運用しづらく保守もコストがかかる。そういう理由をつけて、その上司は顧客の要求を押し戻したりしていた。 どうしたらいいかたずねてきた若手社員に、わたしは、再びくりかえした。 --あなたは、どう考えるの? さっきと同じ文句だが、問うていることは、じつは違う。今度は、どれを選ぶかたずねているのだ。目の前のホワイトボードには、結局とるべき方策は三つしかないことが、明らかになっている。 ・今までの設計方針を押し通し、運用側で一手間かけてもらう ・システムを一部、変更する ・彼の言う、一種の変則的な抜け道をつかう 三番目は、コスト追加もユーザの不興を買うこともないが、設計思想が歪むので、わたしが賛成しなかった。選ぶなら、一番か二番目しかない。 『考える』という行為には、一般に二つのフェーズがある。問題の答えを探すことは、その主要な部分である。しかし、答えを見つけたあとにもう一つ、問題が生じる。それは複数の答えの中から、良いものを決めることである。 われわれ技術者が直面する問題は、数学のようにたった一つの正解がでてくる場合は少ない。ふつうは複数の解決案があり、しばしば、どれも帯に短したすきに長しと見える状態になる。その中から、どれかを決めなくてはいけない。よく、迷っている人が、「考え中です」と言ったりするように、考えるという行為の第2フェーズは、じつは決めることなのだ。だから、二番目の「あなたは、どう考えるの?」は、 --あなたは、どれを選ぶべきだと思うのか? と言いかえてもいい。 そして、この問いに答えるためには、『価値観』が重要になるのである。どのような価値観を持って、それを選ぶのか。たとえば、コストと顧客満足が両立しない場合、どちらをより重視するのか。どのような状況のときには、コストを犠牲にしても顧客満足を確保すべきなのか。逆に、どのようなときは、顧客の不興を買っても、コストを選ぶべきなのか。そして、そもそも、“顧客の満足”とは、ほんとうは何をさしているのか。 そして、わたし達は、価値観をしっかり立てて、それに従って何かを決める態度が、しばしばとても弱い。とくに受注ビジネスではその傾向が強いように感じられる。多くは、“ご無理ごもっとも”で顧客要望をなんでも聞き入れてしまって、結局自分のコストと時間で帳尻を合わせている。そのような要望を受け入れることが、相対する顧客のミクロな局所最適にはつながっても、顧客組織のマクロな便益には反してしまう場合、ほんとうに顧客満足優先の価値観に立脚するならば、あえて反論し説得しなければならないはずだ。だが、そう振る舞える技術者は少ない。へたをすると、顧客の些末な要望を聞き入れて、曲芸のような設計を実現することに、自分の職人的プライドをかけたりするような逆立ちが、まかり通る。 まあ、もっと敷衍すれば、わたし達自身、それこそ学校を選ぶときも、就職先を選ぶときも、自分の価値観というより、世間的な評価や周囲のすすめなどにしたがって、何となく選んでしまう。まわりと合わせることが最大の美徳であるこの社会に育って、何か独自の価値観を樹立せよ、という方が無理があるのかもしれない。だが、われわれがビジネス社会で成長するためには、その無理をなんとか通す必要があるのだ。 ところで、ここまで読んだ読者の中には、そんなことを部下にたずねるのはおかしい、決めるのは上司の責任だ、と思う方もいらっしゃるかもしれない。たしかにその通りだ。部下が○○がいいと思います、と言ってきても、わたしは××を選ぶかもしれない。かりに○○を選んだとしても、その結果おきる事は、もちろんわたしの責任であり、まちがっても「部下がそうしろと言ったので」などという言い訳は通用しない。 だとすると、なぜ、若手社員に「あなたは、どう考えるの?」などと聞くのか。理由ははっきりしている。彼に、上司の視点でものを考える訓練をしてもらいたいからだ。上司の視点で考えるとは、必然的に、自分の狭い責任範囲をこえて、全体感を(あるいはせめて多少は広い範囲を)考えた上で、『価値評価』する作業を求めている訳だ。そのような思考訓練は、他者の立場・価値観を推測するスキルにつながり、やがては顧客に対する説得力・交渉力につながっていく。少なくとも、かつての上司がわたしに求めたのは、そうした能力だったにちがいない。 ホワイトボードの前で、まだ迷っている若手社員に対して、ともあれ助け船を出すことにした。 --とりうる選択肢に対してさ、それぞれProsとConsをあげて表にしてみな。 ProsとConsとは、「賛成すべき点」「反対すべき点」の意味で、つまり長所と短所である。彼をうながして、ホワイトボードに簡単な表を作らせた。そして、それぞれの項目に、◎○△×を記入してもらった。 「ええと、こうなりました。」 ![]() --どれがいい? 「記号を足し算してみますと、えー、1が一番良さそうですか・・?」 このようなPros/Consの表は、非常に単純に見えるだろうが、フェーズ2の「考える」=「決断する」行為では、案外有効である。頭の外側に見える化することで、見ている全員が、なんとなく納得感をもつからだ。 --うん。少し頭が整理できただろ? ただし本当は、こういう表を作った場合はね、どこかに×がある選択肢は、もうその時点で原則的には不採用なんだ。ノックアウト条項というんだけどね。 「・・じゃあ、2も3も失格ですか。」 --そう言いたいところだけれどね。でも、いまは感覚的に○×をつけているわけで、あまり厳密じゃない。ところで、2の選択肢についてだけれど、納期も遅れる可能性があるのかな? 「はい。追加変更のボリュームによると思いますが。」 --そうだな。じゃ、いつまでに決めなくてはいけないかのな? 開発会社に聞いてみてくれないか? 「それは聞きました。半月以内に決めてくれ、というんです。でも、この議題は、来週のお客さんとの会議で、もうアジェンダにあがっていまして・・」 --だったら、わたしがお客に電話して、来週のアジェンダを組み替えてもらおう。再来週まで時間を作るから、もう少しだけ考え直して見なよ。今、決めるのはやめることにする。コード重複がどれくらいの頻度で起きそうか、まず調べること。」 「はい。わかりました。」 彼は席に帰っていった。わたしの中のカンでは、(根拠も何もないのだが)この問題は何か、技術的な逃げ道があるような気がしたのだ。でも、それを考えるのには時間がいる。 わたしの職場には、 「決めないリスクより、決めるリスクをとる」 という格言がある。決断を先延ばしにしても、普通あまりいいことはないのだ。だが、担当者の彼に、考える時間を作ってやることが、現時点では優先度が高いと、わたしは考えた。それは、カンであり、賭けである。だが、考えるために一番大事なリソースは、「考える時間」なのだ。わたしが自著『時間管理術 (日経文庫) わたしの賭けの結果が、どうなったかは、あえて書くまい。わたしが、かつての上司ほど、カッコいいマネージャーではないことは正直に認めよう。だが、わたしの中には、かつて教わったいくつもの原則が生きている。それを、もっと後ろの世代にも伝えることが、少なくともわたしの使命であろう。 だから、今もこんな文章を書いているのである(笑)。 <関連エントリ> →「わたしが新入社員の時に学んだこと」 (2010-05-01) →「設計思想(Design Philosophy)とは何か」 (2012-03-26)
by Tomoichi_Sato
| 2014-09-28 19:40
| 考えるヒント
|
Comments(0)
|
検索
カテゴリ
著書・姉妹サイト
私のプロフィル My Profile
【著書】 「世界を動かすプロジェクトマネジメントの教科書 「時間管理術 「BOM/部品表入門 (図解でわかる生産の実務) 「リスク確率に基づくプロジェクト・マネジメントの研究 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
最新のコメント
最新のトラックバック
フォロー中のブログ
ブログパーツ
ファン
記事ランキング
ブログジャンル
画像一覧
|
ファン申請 |
||