あなたは、どう考えるの？

「佐藤さん、すみません、ちょっとご相談があるんですが・・」

若手社員が机の前にやってきて、顔を上げたわたしに、いいにくそうな声でぼそっときり出した。わたしが、ITリッチなプロジェクトをやっていた時代のことだ。

－－なあに？　何か、いい話かな？

「いえ、あの・・。例の中間在庫ロットなんですが、どうしようかと悩んでいまして。」

－－そこは新しいコード体系を使おうって、先週の打合せで決めたじゃないか。

「そうなんですが、注文書のシステムで、ちょっと困ったことが見つかりまして。あのままでは、番号がかち合ってしまう可能性があると分かったんです。」

彼は仕様書の該当箇所をわたしに見せて、問題を詳しく説明する。なるほど、先週の打合せでは、この点を見落としていたらしい。

－－つまり、このまま進めば、ユーザに運用を変えてもらって、少しだけ手間が増えるのを我慢してもらうか、さもなければシステムの設計変更をするか、二つに一つです、という訳かな。大勢のユーザに文句を言われるか、開発会社から追加費用を請求されるか、どっちかしかありません、と。

「・・まあ、そういうことです。どうしたらいいでしょうか？」

そこでわたしは、いつものセリフをぶつけた。

－－あなたは、どう考えるの？

その場で部下が、自分の考えを言ってくれれば、もちろん、それでよし。内容について議論できる。部下の考えがまとまっていない場合は、「少し考えてから持ってきてごらん」と、いったん突き放すことにする。

しばらくすると、「佐藤さん、こう思うんですが。」といってくるので、そこからは議論に付き合い、一緒に考えることにする。たとえ、途中こちらがヒントをだし、リードをしても、「一緒に考える」雰囲気が大切だ。そうすれば相手は、打合せ結果を「自分が考えたこと」として、モチベーションをもって働いてくれる。

わたしはこのようなやり方を、自分自身が駆け出しの頃の、上司から学んだ。わたしが同様に、問題を抱えて、こまって上司のところに行くと、彼は決まってためいきを一つついてから、こう言う。

「それで、オタクはどうしたいんだよ？」

（その人は有名私学の出身で、そのころはまだ珍しい『オタク』という二人称を使う人だった）

わたしが、何も自分でアイデアをもっていないと、「考えてからもってこいよ。」といわれて、対話は終わってしまう。なにか解決策や提案を持っていけば、（もちろんたいていは技術的にケチョンケチョンに叩かれるのだが）とにかく前には進める。

だから、問題が生じても、まずは自分で答えを考えてから、相談に行く姿勢がいつの間にか身についた。それは、そのあと、自分が直接、顧客と接して動かなければいけないキーパーソン・レベルになってからも、とても役に立った。だからわたしも、人を使う立場になると、自然とその真似をするようになってきたのだ。

ただし、ときおり、まったくこちらの指示に依存する姿勢の若手も現れる。「少し考えてから持ってきてごらん」と突き放しても、こういうケースではたいてい、すぐにギブアップしてくる。自分で考えて突破しようという思考体力というか、基本的なスタンスが足りないのだ。おまけに、わたしは冷たい上司だと思われてしまう。そうなると、今度は問題が発生しても、わたしに報告せずに自分一人で抱え込むようになる。そして火が噴くまで、こちらが気づかない危険性が増す。

そういうときは、しかたないので、論点を整理しつつ、もう少し踏み込んで、最初から一緒に考えてやることにしている。その若手社員も、そのタイプだった。一緒に問題構造を図解したホワイトボードの前で、彼は言い出す。

「佐藤さん、従来の品番コードの頭に、取引先の略号を3桁つける、という手はどうでしょうか？」

－－そりゃダメだ。そんな抜け道を造ったら、工場内のロットを物流システムで統一的に管理するという、全体の設計思想が歪んでしまう。それに、3桁なんて、どうせすぐパンクするよ。

「それじゃ、どうしたらいいでしょうか？」

　設計思想を大事にしろ、というのも、上で述べた昔の上司から学んだことだった。ただし彼は、設計思想という言葉の代わりに、『設計のスタンス』という呼び方をしていた。その方が、顧客に対してスムーズで、通りやすいからだろう。設計のスタンスを曲げると、あとで追加修正が難しくなり、いきおい全体が温泉旅館の建て増し的な、ゴチャゴチャしたものになっていってしまう。そうなれば結局、運用しづらく保守もコストがかかる。そういう理由をつけて、その上司は顧客の要求を押し戻したりしていた。

　どうしたらいいかたずねてきた若手社員に、わたしは、再びくりかえした。

－－あなたは、どう考えるの？

さっきと同じ文句だが、問うていることは、じつは違う。今度は、どれを選ぶかたずねているのだ。目の前のホワイトボードには、結局とるべき方策は三つしかないことが、明らかになっている。

・今までの設計方針を押し通し、運用側で一手間かけてもらう
・システムを一部、変更する
・彼の言う、一種の変則的な抜け道をつかう

三番目は、コスト追加もユーザの不興を買うこともないが、設計思想が歪むので、わたしが賛成しなかった。選ぶなら、一番か二番目しかない。

『考える』という行為には、一般に二つのフェーズがある。問題の答えを探すことは、その主要な部分である。しかし、答えを見つけたあとにもう一つ、問題が生じる。それは複数の答えの中から、良いものを決めることである。

われわれ技術者が直面する問題は、数学のようにたった一つの正解がでてくる場合は少ない。ふつうは複数の解決案があり、しばしば、どれも帯に短したすきに長しと見える状態になる。その中から、どれかを決めなくてはいけない。よく、迷っている人が、「考え中です」と言ったりするように、考えるという行為の第2フェーズは、じつは決めることなのだ。だから、二番目の「あなたは、どう考えるの？」は、

－－あなたは、どれを選ぶべきだと思うのか？

と言いかえてもいい。

そして、この問いに答えるためには、『価値観』が重要になるのである。どのような価値観を持って、それを選ぶのか。たとえば、コストと顧客満足が両立しない場合、どちらをより重視するのか。どのような状況のときには、コストを犠牲にしても顧客満足を確保すべきなのか。逆に、どのようなときは、顧客の不興を買っても、コストを選ぶべきなのか。そして、そもそも、“顧客の満足”とは、ほんとうは何をさしているのか。

そして、わたし達は、価値観をしっかり立てて、それに従って何かを決める態度が、しばしばとても弱い。とくに受注ビジネスではその傾向が強いように感じられる。多くは、“ご無理ごもっとも”で顧客要望をなんでも聞き入れてしまって、結局自分のコストと時間で帳尻を合わせている。そのような要望を受け入れることが、相対する顧客のミクロな局所最適にはつながっても、顧客組織のマクロな便益には反してしまう場合、ほんとうに顧客満足優先の価値観に立脚するならば、あえて反論し説得しなければならないはずだ。だが、そう振る舞える技術者は少ない。へたをすると、顧客の些末な要望を聞き入れて、曲芸のような設計を実現することに、自分の職人的プライドをかけたりするような逆立ちが、まかり通る。

まあ、もっと敷衍すれば、わたし達自身、それこそ学校を選ぶときも、就職先を選ぶときも、自分の価値観というより、世間的な評価や周囲のすすめなどにしたがって、何となく選んでしまう。まわりと合わせることが最大の美徳であるこの社会に育って、何か独自の価値観を樹立せよ、という方が無理があるのかもしれない。だが、われわれがビジネス社会で成長するためには、その無理をなんとか通す必要があるのだ。

ところで、ここまで読んだ読者の中には、そんなことを部下にたずねるのはおかしい、決めるのは上司の責任だ、と思う方もいらっしゃるかもしれない。たしかにその通りだ。部下が○○がいいと思います、と言ってきても、わたしは××を選ぶかもしれない。かりに○○を選んだとしても、その結果おきる事は、もちろんわたしの責任であり、まちがっても「部下がそうしろと言ったので」などという言い訳は通用しない。

だとすると、なぜ、若手社員に「あなたは、どう考えるの？」などと聞くのか。理由ははっきりしている。彼に、上司の視点でものを考える訓練をしてもらいたいからだ。上司の視点で考えるとは、必然的に、自分の狭い責任範囲をこえて、全体感を（あるいはせめて多少は広い範囲を）考えた上で、『価値評価』する作業を求めている訳だ。そのような思考訓練は、他者の立場・価値観を推測するスキルにつながり、やがては顧客に対する説得力・交渉力につながっていく。少なくとも、かつての上司がわたしに求めたのは、そうした能力だったにちがいない。

ホワイトボードの前で、まだ迷っている若手社員に対して、ともあれ助け船を出すことにした。

－－とりうる選択肢に対してさ、それぞれProsとConsをあげて表にしてみな。

ProsとConsとは、「賛成すべき点」「反対すべき点」の意味で、つまり長所と短所である。彼をうながして、ホワイトボードに簡単な表を作らせた。そして、それぞれの項目に、◎○△×を記入してもらった。

「ええと、こうなりました。」



－－どれがいい？

「記号を足し算してみますと、えー、１が一番良さそうですか・・？」

このようなPros/Consの表は、非常に単純に見えるだろうが、フェーズ２の「考える」＝「決断する」行為では、案外有効である。頭の外側に見える化することで、見ている全員が、なんとなく納得感をもつからだ。

－－うん。少し頭が整理できただろ？　ただし本当は、こういう表を作った場合はね、どこかに×がある選択肢は、もうその時点で原則的には不採用なんだ。ノックアウト条項というんだけどね。

「・・じゃあ、２も３も失格ですか。」

－－そう言いたいところだけれどね。でも、いまは感覚的に○×をつけているわけで、あまり厳密じゃない。ところで、２の選択肢についてだけれど、納期も遅れる可能性があるのかな？

「はい。追加変更のボリュームによると思いますが。」

－－そうだな。じゃ、いつまでに決めなくてはいけないかのな？　開発会社に聞いてみてくれないか？

「それは聞きました。半月以内に決めてくれ、というんです。でも、この議題は、来週のお客さんとの会議で、もうアジェンダにあがっていまして・・」

－－だったら、わたしがお客に電話して、来週のアジェンダを組み替えてもらおう。再来週まで時間を作るから、もう少しだけ考え直して見なよ。今、決めるのはやめることにする。コード重複がどれくらいの頻度で起きそうか、まず調べること。」

「はい。わかりました。」

彼は席に帰っていった。わたしの中のカンでは、（根拠も何もないのだが）この問題は何か、技術的な逃げ道があるような気がしたのだ。でも、それを考えるのには時間がいる。

わたしの職場には、

　「決めないリスクより、決めるリスクをとる」

という格言がある。決断を先延ばしにしても、普通あまりいいことはないのだ。だが、担当者の彼に、考える時間を作ってやることが、現時点では優先度が高いと、わたしは考えた。それは、カンであり、賭けである。だが、考えるために一番大事なリソースは、「考える時間」なのだ。わたしが自著『時間管理術 (日経文庫)』でも強調したように、タイム・マネジメントの最大の目標は、集中して考える時間を確保することなのだ。

わたしの賭けの結果が、どうなったかは、あえて書くまい。わたしが、かつての上司ほど、カッコいいマネージャーではないことは正直に認めよう。だが、わたしの中には、かつて教わったいくつもの原則が生きている。それを、もっと後ろの世代にも伝えることが、少なくともわたしの使命であろう。

だから、今もこんな文章を書いているのである（笑）。


＜関連エントリ＞
　→「わたしが新入社員の時に学んだこと」 （2010-05-01）
　→「設計思想（Design Philosophy）とは何か」 （2012-03-26）