【読書】岩田さん ー岩田聡はこんな事を話していた。ー【感想】

「判断とは、情報を集めて分析して、優先度をつけることだ」ということがわかったんです。
「そこで出た優先度に従って物事を決めて進めていけばいい」と思うようになりました。
そうやって判断を重ねていったら、物事がだんだんうまく回りだしますから、それはきっと色んな事に適応できる真実なんだろうというふうに感じて、それが社長としての自信につながっていくんですね。

多くのタスクをこなす時、いつも優先度との闘いです。
全部「なるはやで」と言われたとしても、些細な優先度の違いは出てくるものです。
優先度「高」の中でも、またその中で「高」「中」「低」はつけられずはすです。
そうやって優先度をつけてタスクをこなす事が重要だと自分も思いますね。

HAL研究所の社長だったときの面談は、半年に1回、社員全員と話していました。
最初に社員全員と話をしたとき「面談してはじめてわかったこと」がものすごく多かったんです。
それまでも、ふつうにコミュニケーションできていたと思っていた人でも、一対一で面談するとはじめて語ってくれることがある。
変な言い方になりますが
「人は逆さにして振らないと、こんなにも、ものを語ってくれないのか」とあらためて思いました。

自分は「面談」「ヒアリング」
こういったものは「人」と仕事をする上では避けては通れないと思っています。
世の中には色んな人がいますし、肩を突き合わせて話してみないと本音が出ない人もいます。
一対一でお話する事はすごく大切な事だなって思います。

コンピュータの進歩が速いのは、トライアンドエラーの回数が圧倒的に多いからです。
例えば、ハードウェアを製造するときの金型を直すとかいうことになると、何種類かを試すだけでもすごく時間がかかります。
でも、ソフトウェアなら「マリオがどのぐらいの高さでジャンプすればプレイヤーが気持ちよく遊べるか」を1日何度でも試せる。
現実には、パーフェクトというのはまずなくて、トライアンドエラーの繰り返しです。
「あ、ちょっとましになった」「あ、ちょっとましになった」と繰り返しながら、すこしづつよくなっていくわけです。

そういう意味で「調整」「ブラッシュアップ」というのはすごく大事で、こういった事を行う期間が、しっかりスケジューリングされているかどうかで
成果物の面白さ、クオリティというのは大きく変わってくると思っています。

ボトルネックになっているところを直さない限りは、そうじゃないところをいくらなおしても意味がないんですね。
ところが、人は、とにかく手を動かしていた方が安心するので、ボトルネックの部分を見つける前に、目の前のことに取り組んで汗をかいしてしまいがちです。
そうではなく、一番問題になっていることはなにかとか、自分しかできないうことはなにかと
いうことがちゃんとわかってから行動していくべきです。

プログラマーをしていると身に染みる言葉ですね。
バグを例に出すと「根本解決」しないと、目先のバグをとっても意味ないですから。

世の中の面接って、どうして答えにくい事から訊くのかなって思うんですよ。
なぜ答えやすいことから訊かないのかなと。
わたしの経験からいうと、面接官には2通りのタイプがあるんです。
相手をほぐしてから、その人の本性を引き出して、その上で選びたいと思っている人と「ほぐれていないから話せない」というのもその人の社交性だったり、力だったりするから、そのまま評価してしまうという人と。
わたしは、前者です。後者の面接官って可能性を一部しかみてないと思うんですよ。
まずは、ほんとうの自分を表現してもらわない事には、何も始められませんからね。

自分も前者ですね。
面接というよりも、人間関係を構築していく上で、相手の得意分野の話を振ったりする事はよくある事です。
そうして「本性」を出してくれた所で、ようやく本当の人間関係が構築できるような気がしています。

仕事はやっぱり大変だし、嫌なことはいっぱいあります。きっと我慢もしなきゃいけません。
ですけど、おそらく、その人にとって「仕事が面白いかどうか」というのは「自分が何を楽しめるか」
という枠の広さによってすごく左右されると思うんです。
考えようによっては、仕事って、面白くない事だらけなんですけど、面白さを見つける事の面白さに目覚めると、ほとんどなんでも面白いんです。

「面白さを見つける事の面白さ」か。
凄いなぁ、自分は、まだその域には達していない気がします、精進ですね。

どういう時に企画がうまくいくかというと、最初の計画では決まってなかった事を「これ、僕がやっておきましょうか？」というような感じで誰かが処理してくれる時。
そういう人がたくさん現れるプロジェクトは、だいたいうまくいくんです。

逆にそういう現象が起きないときは、例え完成したとしても、どこかに不協和音のようなものがあって、あんまりよくないんですよね。
「こうなりたい」というイメージをチームの全員が共有したうえで、現実的な問題が起こった時、あるいは起こりそうな時に誰かが発見して、自然と解決していく。それが理想の形なのかもしれません。

最終目標というか、チームとして「到達するべき場所」が共有されている事は大事だと思います。
それが共通認識できていれば、おのずと、プロジェクトは良い方向に進む。そう思います。

誰かとつながりながら、何事かを成し遂げようとする時、自分以外の人たち、別の意思と価値観を持って動いている人たちに「敬意を持てるかどうか」っていうのが、ものすごく大事になってくると、わたしは思ってるんです。

自分にはないものをその人が持っていて、自分にはできない事をやっているということに対して、敬意を持つこと。
この敬意が持てるかどうかで、働くことに事に対する楽しさや面白みが、大きく変わってくるような気がするんです。

自分と別の意見を持っているからといって「あの人嫌い」となるのではなく「でも、あの人、自分にできないあんな事ができる」といった所を「見つけて」敬意を払う事が大事だと思います。
自分は過去に「尊敬できる所がない」と、ある人に言われましたが「尊敬できる所を見つけられない」そんな方が可哀そうでした。

余談ですが、わたし、いまよりずっと若いころ、自分がものすごく忙しく感じていた頃に
「自分のコピーがあと3人いればいいのに」って思ったことがあるんです。
でも、いま振り返ると、なんて傲慢で、なんて視野の狭い発想だったんだろうって思うんですよ。
だって、人はひとりひとり違うから価値があるし、存在する意味があるのに、どうしてそんな事考えちゃったのかなって恥ずかしく思うんです。

「自分のコピーがいれば」
誰しもそんな事を考えた事がある気がしますが
お互いがお互いをカバーしあう事に目を向ける事が大事ですね。

本当は得意になる才能を持ってるんだけど「オレは苦手だ、わたしは苦手だ」って本人が勝手に思ってることってあるんですよ。

マネジメントなんか大嫌いで「ものづくり一筋の職人としてやっていきたい」と言ってたような人が
「ひとにものを教えるのは、面白いなぁ」って変わっていくのをわたしは何度も見てきました。

その人自身が気付いてなかった部分を誰かが探すことができた時、人は思いがけない方向に伸びていくとこができるんです。

「得意な事が好きな事とは限らない」とはよくいったもので
特段頑張ってないのにできちゃう事が、その人の「得意分野」だと、何かの本で読んだ気がします。
自分の得意分野は「マネジメント」かな？って思ってます。

あらためてわたしが思うのは、やはり目標を定めるのが大切だという事です。例え、それが前例のない目標だとしても。
単純に、仕様を積み上げていくことを繰り返していくだけだと、どうしてもマージンが重なって大きくなるだけでしょう。
それよりも、やりたいことが明確にあるのであれば「こうしたいんですよ」っていうところから
逆算して目標に向かっていくほうが正しいと思うんです。

> 逆算して目標に向かっていくほうが正しいと思うんです。
「逆算」って大事だと思います。
特にスケジューリングする際、迷うような場面があったら、目標から逆算する事でより精度の高いスケジューリングができるかなと思います。

大きな組織になるほど「今回はこれにこだわると決めた！」みたいなことが必要になってくるんですよ。
だって会社にとって、やった方がいいことなんて無限にありますから。

誰かが方針を決めないとパワーがどんどん分散していくわけです。
だから、宮本さんなり、わたしなりが「これをやりましょう」ってきちんと選ばないといけない。

僕はマネジメントにおいて「放任主義」って好きじゃありません。
それが活きる場面もあるのかなとは思うのですが、組織やチームを率いる状況の際の「放任主義」は無責任かなと思います。
リーダーに値するような人は、チームや組織をあるべき方向に引っ張っていく。間違った方向に向かっていたら軌道修正する。
そういった役割があると思います。そういった中で「自主性」に任せるのは、丸投げでは？

プログラムの経験が会社の経営にいきていることはたくさんあります。
例えば何層にも重なった複雑な問題を単純化してほぐしていく時には、プログラマーとしての経験がものすごく役立っています。

問題を分析するというのは、物事を要素に分けて分解して、その中で「こうすればこれは説明がつくよね」という仮説を立ててくいく事です。
プログラマーは何か問題がある時、それに対して、いくつもの仮説を立てては頭の中で比べるということを日常に繰り返しています。

ですから、複雑な問題に立ち向かう時に、足腰があらかじめ鍛えられているんですね。
経験してきたトライアンドエラーの回数が多いですから、それについては毎日筋トレをしているぞ、という程度の自負はあるんです。

プログラマーには「問題解決能力」が必要ですからね、あと論理的思考力も。
これは、プログラミングに限った話ではなく、幅広い場面で応用できます。

ひとつ思いついたことによって、これがうまくいく、あれもうまくいく……。
それが「いいアイディア」であって、そういうものを見つけることこそが、全体を前進させ、ゴールへ近づけていく。
ディレクターと呼ばれる人の仕事は、それを見つけることなんだって宮本さんは考えているんですね。

自分も「いいアイディア」をポンポン思いつけるようになりたいものです……。

宮本さんの発想の仕方として、すごく面白い事のひとつは「機能から始まっている」という事ですね。
例えば、物語的にこういう人を登場させたいという事ではなく、ここに誰かがいないとつまらない。
という機能としての理由から発想がスタートしている。
その辺りはインダストリアルデザインをやっていた人の発想だなと感じますね。

これは任天堂イズムでもありますよね。
でもこれ、アクションゲームを作るのであれば、一つの最適解かなって思います。
どういうキャラで、どういうストーリーで、というのは後回し。

ユーザーに何を体験させたいのか、どういった遊びを届けたいのか。そこから考える事が大事だと思います。
なので、任天堂のゲームはキャラクター等のネーミングが結構適当だったりしますよね。
それは「機能先行」だからかなと思います。