「エンジニアのための図解思考 再入門講座」を読んで、今すぐシステムを自分で作り上げろ
花粉症の薬だけではもたない世界線の日本、しょっさんです。
コロナ騒ぎで、わたしの周りからはライブが一掃されてしまっていて、楽しみが失われた状況下にあります。ただ、それ以外は面倒な予定ごとが減ったり、なぜか仕事が忙しかったりで、思った以上に変化のない世の中だったりします。たまたまライブのない時期だと思えば、余計なことのない過ごしやすい日々だとも。
さて、そんな連休の間の読書で、良い本があったので紹介です。
10年前の本です。9年前に購入しました。ある程度読んでいたのですが、最近、図表の作り方がわからなくなっていたので、あらためて読み直しました。
読んでみたら驚きの一言です。2011年の頃は、コレを読んでいながらぴーんとこないことがほとんどだったのに、2020年になったら心に染み渡ることがたくさんです。この本のポイントと、私が感銘を受けたポイントについて紹介します。
文章のラベリング
最近のわたしの流行りごとは「キャッチコピー」です。いわゆる「結局、それを一言でいうと？」という、その場でまとめたいなんとなく意識高い系の人が、急に思いつきで発する最悪のオブジェクションに対する返しです。
大抵、ほとんどのケースに置いて、この言葉が出てくるまでにさんざんと説明しています。聞いてる方は聞いてるだけでメモを残していかなかったり、他人事で特に興味がない場合に「で？」という感じで出てくるナンセンスな質問です。が、これは重要なポイントでもあります。ここで、ぴしっと一言で言い切れると「ほー」となります。ほーってなるだけで、理解できなかったり、それが相手の心に刺さらなかったら、ただの一言です。はっきり言って、こんなのほとんど成功しません。相手のことをいくら理解したからと言って、その時の一番のポイントに刺さるかどうかについては、こちらの持っているプロダクトががっちりマッチしなければなりません。がっちりマッチしてれば「一言で」なんてこともないです。「それいいじゃん」で終わりです。
というわけなので、そんなキレイにマッチすることも少ないので、そんなときに、ある意味力技で合わせていかざるを得ません。しかし、それはエンジニアとしての良心の呵責も含んで、ほとんど不可能なものです。「正しいことを伝えなければならない」と「商談クローズしなければならない」ことを鑑み、そして「お客様の心に刺さるキャッチコピー」をその場で紬ぐ必要があるわけです。しんどい。まぁいいです。お仕事です。がんばります。
そして、この鍛錬に必要なものが「ラベリング」です。長ったらしい様々な文章を書いてしまう自分ですが、それにうまく「ラベル」をつける。 = 「おいしいキャッチコピーをつける」ことでもあります。抽象化されたラベルは、新しい思考回路を広げるためにも必要不可欠です。日本人は細かいことを掘り下げて、どんどん細かい話をさせることは得意です。ディスカッションさせると、目的とあっていようとなかろうと、自分の興味ある分野をどんどんと掘り下げていくことは得意です。だから、会議の時間がいくらあっても足りないんです。そこで、この「ラベリング」です。ものごとをある程度抽象化して、余計な空中戦をさけ、全体をうまく可視化するための最強のツールです。ほんと、うまいこと言いたい。
0次情報と読解力
0次情報とは「自分自身の体験して得た情報」と理解しました。
1次情報とは、他人がなんらかの経験・体験、実験から得た結果の情報のことです。本書の中では、「あるラーメン屋で、知人が食べたら美味しかった」という情報ということになっています。知人にも様々な知人がいるでしょうが、その親近度合いによって、この情報の確かさも変わってくるでしょうが、かなり信頼できる情報源です。2次情報は「どこの誰かは知らないラーメン屋の情報」です。ふと、どっかの得点サイトとか思い浮かべながら「信用ならねぇな」と思うアレです。2ch(5ch)などでいう、「ソース」は1次情報であり、信頼の置ける人間・機関などの情報源が提供する情報、2次情報は特に関係のない人間がSNSなどに雑に乗せている不確かな情報ということとも言えるでしょう。
では、あらためて0次情報とは。自分が実際にそれを体験、実験することで、その確からしさや体験しないと得られないものを理解した情報です。本書の中では、「水は100度で沸騰する」という情報に対して、実際に水を沸騰させて得た知見を含めたものを、0次情報としています。実際には、水は1気圧化の1リットルの水が沸騰するときの水温を100度として定義していますが、実際に沸騰する条件によって、コレは96度になったり100度を超えるケースもでてくるでしょう。また20度の水を100度まで上げていくその段階で、どのような現象が起きるのか。こういったものは、実際にそれを体験することによってはじめて得ることができます。
私の個人的エンジニア感は、この0次情報をどれだけ持っているか、がそのエンジニアの強さ(スキルレベル)を表すものと考えています。スペックしか知らないで良いと説いたアーキテクトの発言は、未だに反対の意見を持つわたしですが、1次または2次情報しか持てないエンジニアは、最終的に実現不可能な、または可能だけれども茨の道であるようなアーキテクチャを平気で作ってしまいます。実際に開発を行ったことのある人、実際にハードウェアに触れて障害を体験したことのある人、実際に設定を行って、その容易さ・難しさを体験したことのある人。このように0次情報を持っているエンジニアは、とにかく「強い」です。そして、この0次情報を持ったエンジニアでなければ、信用たり得ないと考えています。
本書の終わりの方に「エンジニアに必要な能力とは」の項で「表象」と「メンタルモデル」のつながりと「メンタルモデルの自覚的操作能力」の重要性が示唆されています。
「表象」とは、現実のものを「言葉」に置き換えたものです。
この写真を見て「りんご」となるのが、「表象」された結果ということです。現実を記号化した情報そのものですね。言語とは限らないかもしれません。
そして「メンタルモデル」とは、この標章から得られるもので、脳内にイメージできることを「メンタルモデル」と言います。記号たる「表象」から、この「メンタルモデル」をいかに正確に導き出せるか、逆に「メンタルモデル」からいかに正確な記号化・符号化を行って「表象」できるかがエンジニアにとって重要です。
しかし、次項の「表象とメンタルモデルのリンクが切れている？」というところでは「表象からメンタルモデルを導くことができず、言葉の意味が理解できない」といった内容を読んだときに、これまでの様々な事象が走馬灯のように蘇ったわけです。もう死にそう。
わたしのスペシャリストとしての立場として、エンジニアと話す機会は多く、ほとんど大抵のエンジニアとは開発・設計の話が通じ合えます。しかし、なんちゃってエンジニアとは、記号や図解をしてもつながっていかない人がいるわけです。とんちんかんな質問をしてきたり、信じられない構成パターンを編み出したりしてきます。世界がさまざまな情報で溢れているとして、これらを組み合わせて、新たなアイディアが出ることは多様にありますが、平気でアンチパターンをこれみよがしに出してくるエンジニアがいます。いや、それ流石に不可能ですから。
知識として知らないということはあり得るので、それは補えばよいだけの話です。なので、知らない部分の知識を補っていけば、これまたある程度のエンジニアは理解できます。それでも、理解のできないエンジニアはまだ数多、存在します。これは、自分の中に経験がなく、メンタルモデルが出来上がっていない所為で、「表象」がただの言葉・記号としての意味でしか覚えていないからでしょう。どおりで、どれだけ伝えても、どうやっても理解できない人がいるもんだと、腹落ちしました。
結局、知識ベースだけでなにか立派なエンジニアが誕生することはなく、さまざまな経験を経て、地道に作り上げていくしかないのだろうということを心に刻みました。今後のエンジニアの育成に関して、自分がどのようにすべきかを考えるよい機会になりました。
まとめ
エンジニアの重要なポイントは次の2つ。
1. 抽象化能力
2. 知識を自分のものにする
ラベリングにより抽象化能力を高めていくこと。これはアウトプットを行うときに重要な能力となります。
そして、知識は記憶に留めるでなく、実際に経験・検証を行うことで、自分のメンタルモデルを増やしていくこと。メンタルモデルを鍛えることが、まさにインプットに必要な能力です。読むだけの知識は、メンタルモデルが備わって、初めて生かされることです。
エンジニアのみなさまにおいては、実際に手を動かしながら知識を自分の能力に変え、ラベリングしながらアウトプットを効果的に行っていきましょう。わたしのように、駄文生成能力を高めても、時間をつぶすだけです。みなさまに期待してます☆(・ω<
いいなと思ったら応援しよう！
