2019-02-15

• Developer Summit 2019
• 発表資料 PDF
• 2019-03-12 文字起こしをスライドの合間に貼り付けました

佐伯：皆さんおはようございます。翔泳社のコードジン編集部の佐伯と申します。テクノパーツサミット2019にご来場いただき誠にありがとうございました。今回の2日間で延べ4000人以上の方に登録いただきまして過去最大級の開催となります。ありがとうございます。今回のテーマなのですが「SHARE YOUR FUN」とさせていただきました。昨今の技術的な編成ですとか社会のニーズが激しい中で、エンジニアの皆さんは日々学び続ける事の重要性を感じていらっしゃるかと思います。その中で学び続けるモチベーションとして○○しないといけないというよりかは、○○をしたいといったご自身の中から秀でる楽しさですね。楽しさをそこから駆動して学ぶ事が多いのではないかと考えました。今回のイベントでも多彩な登壇者の皆さんにそういったソフトウェア開発の楽しさっていうのは何だろうかというあたりで色々講演いただきますので皆さんもそこから是非気づきを得て明日からの開発に是非活かしていただければと考えております。もう1点ですね。今回から運営サイドでも長年の懸案事項であった会場のWi-Fiを設置させていただきました。是非Wi-Fiを使って皆さんが感じられたFUNもSNSやブログで共有いただけると幸いです。ご登壇者の皆さんもそういったフィードバックが励みになると思いますので是非よろしくお願いいたします。冒頭のセッションはサイボウズラボの西尾泰和様より「エンジニアの知的生産術」をお題でご登壇いただきます。ちょうど昨年弊社ではないのですけれども技術評論社さんから、同名の書籍を出されまして昨日開催されたエンジニア本大賞でもノミネートされるほどの良い書籍の1冊だと思っております。今回はその中で語られているエンジニアとしてどう学び、それをアウトプットするかという辺りのエッセンスをご登壇頂きたいと思っております。では皆さん拍手でお出迎え下さい。西尾様よろしくお願いいたします。 会場：拍手 西尾：はい。よろしくお願いいたします。マイク大丈夫ですね。「エンジニアの知的生産術」この本は技術評論社から出たのですけど翔泳社さんのイベントでこんな話をさせていただいて翔泳社さんはとても懐が広いなぁと思っている次第です。早速ですけどエンジニアの知的生産術ビフォー・アフターと称しまして何の話をするかというと、この本が出るまでどういう事があってこの本が出たのかっていう話とこの本が出た後、どんな事が起きてきたか、そしてこの後に何を狙っているかという前と後ろの話。そういう話をしていきたいなと思っています。というのは何故かといいますと、この本に書いている内容って皆さん本を買って読んだらここに書いてあるから分かるのですけど、どうしてその本を書こうと思ったのかとか、そういうふうな話ってあんまり聞く機会ってないですよね。なのでそういう所にフォーカスしていった方が面白いのではないかなと思って今回こういうふうな内容で話させていただこうと思います。よろしくお願いします。

• エンジニアの知的生産術 著者公式ページ
• エンジニアの知的生産術 早速なのですがさっきもちょろっと紹介にありました、この本は技術評論社から出た本なのですけど、エンジニアの知的生産術という本でして去年の8月に発売されました。発売の10日前からAmazon上でベストセラーに入る〓00:10:40〓の高い本だったのですけど。皆さんここでちょっと余談なのですけど、面白い話をしたいのですけど、この本の表紙を見た時に大事な部分ってどこだと思います？「エンジニアの知的生産術」って1番上に書いてあって、その下には「効率的に学び整理しアウトプットする」って書いてありますね。その後に「自分の環境に合わせて適用し創造性を高める」っていうのが真ん中の黒い所に書いてあって、1番下に「10年後も役立つ考え方を身に付ける」と書いてある。これ実はタイトルとかサブタイトルじゃなくて、下の帯に書いてある事が僕、個人的にはすごくグッとくるポイントなのです。なぜかというとタイトルとかサブタイトルって色々な制約で影響を受けるのですが、ここの所はほぼ自由に決める事が出来るので1番言いたい事が実はここに入るのです。というような感じの事を、1つ手前の方の話をする時に〓00:11:28〓

話を戻しますとこのエンジニアの知的生産術は去年の8月に出しましてジュンク堂の池袋本店で技術書に限らない一般書全体も含めたランキングで10位になるというぐらい皆さんから評価していただきまして。特に技術者じゃない人がこれを本屋の店頭で手に取ってみて自分はエンジニアじゃないけれどもすごく学びになったという感想をあげて下さっている方がたくさんいらっしゃって僕としてはこれが嬉しかったところです。実際に〓00:12:00〓ライティングの中でも書店員さんからの自分は書店員でこれを手にとって読んでみてすごく面白かったみたいなコメントが2件ほどついて。タイトルにはエンジニアの知的生産術と入っているのですけれどもエンジニアに限らず物事を生産していく知的な情報を生産していく人にとってはとても有益な本が書けたのではないかなというふうに思っております。

さてさてビフォー・アフターの話ですね。話を戻します。今回の発表っていうのはこの本を書くに至るまで「ビフォー」手前に何があったか。どのようにしてこの本が生まれてきたかっていうこの手前の話と、発売後の「アフター」この本が発売された後、何が起きてどうなっていったか。そしてこの後、どうなっていく事を狙っているのかみたいな話をしていきたいと思います。

• コーディングを支える技術 著者公式ページ この本が出るキッカケになった本がこの僕が5年前に書いた本なのですが「コーディングを支える技術」という本なのですけども。2013年の4月に出まして5年経った今でも売れ続けているロングセラーなのですけど、この本はどういう本かと言いますと複数のプログラミング言語、それを比較する事によって、どのようにしてそれぞれのプログラミング言語の文法というのが生まれてきたのかっていうのを考えていこうという本です。やっぱり特定のプログラミング言語だけを学んでいるとその言語特有の、その言語のローカルルールでそうなっている事っていうと必然性があって、そういう風な仕組みでないと上手くいかない理由があって出来ている文法ってそういうのがゴッチャになってしまうのですけれども。複数の言語を比較しながら、そのそれぞれの言語がどうしてその文法であるとか言語の機能であるとか、そういうふうな仕様を持つ必要があると考えたのか。プログラミング言語って人間が作ったわけなので作った人間が何らかの理由があってこの機能が必要だと思ったからその機能があるわけなのですね。そういうどうやって作られてきたのか、つまり「ビフォー」なのです。プログラミング言語が生まれるビフォーの部分にフォーカスした本です。 この本を書いている最中に僕が思った疑問があるのですね。なんでそもそも学ぶ必要があるのか。こんな本を自分が書いているのだけどプログラミング言語を比較して学んだら楽しいと自分が思ったから、それをこんな風になっていて面白いのだよって伝える本を書いている最中に「いや、待てよ。これ僕が楽しくてこの本を書いているけど、これ読者にとってみてこれを学ぶ必要性って一体何なのか。なんで学ぶのかっていう説明がないよな。」というふうに書いている最中に気づいたのですね。これってびっくりなのですけど。本を書いている最中にその本の存在意義を自分で否定してしまう。「あれ待てよ。これをしっかり説明する必要があるな。」って考えた時になぜ学ぶ必要があるかって、それはしっかり理解する必要がある。なぜ理解する必要がある。そもそも理解って一体何なんだみたいな感じでドンドンと考え始めたわけですね。僕が考えた中で1つのたどり着いた答えっていうのは

• 学びの加速 将来の学びの加速のためだと。プログラミング言語を比較して特定の言語に拘らない一般的な複数の言語に共通して持っている共通のパターン、共通の構造、必然性そういったものを把握する事によって将来新しいプログラミング言語が生まれてきた時にそれを学ぶ〓00:14:59〓このコーディングを支える技術の中でも紹介しているのですけど、Flashという物が一時期生まれてそれがだいぶ衰退したとか、APLというのが一時期すごく盛り上がっていたけど今ではもう見る影もないとか。そういうような話を歴史の流れを書いているのですけど、それは今後も繰り返される話で今流行っている言語は当然衰退するし新しい言語が出てくるわけなのですね。プログラミングという業界自体がこのまま大きくなるのか小さくなるのかも誰も予想できないわけなのですけれども。新しい物が生まれてきた時にそれを学ぶ事を加速していく必要があるというように僕は思ったわけなのです。

よく学ぶ事は大事だって皆さん耳にタコができるぐらい聞かされていると思うのですね。学ぶ人と学ばない人では学ばない人は全然成長しないけど学ぶ人は成長するのだ。時間が経ったら大きく差があくみたいなこんな感じの事を皆さんもうタコが出来るぐらい聞いていて、当然こうだよなと思っていると思うのですけど

• 学びを加速させる人 学びが加速するかどうかを比較すると学びが加速していっている人に比べれば学ぶ人・学ばない人はそんなに〓00:15:52〓であってどうすれば自分の学びを効率良くしていく事が出来るかというところをフォーカスしないと長期的に見た時に、何十年経った時に大きな差に繋がってしまうのではないかなと僕は思っているわけです。

• 詳しい話は なぜ知的生産術に投資するのか で書いた
• 生産性の向上 この学びは加速する。生産性を向上するという話は例えて言うならば経済学で言うところの、昔靴下って手編みしていたのですね。職人が家で家庭内手工業を使って靴下を編んでいたのですけど靴下を編む機械というのが発明されて、そうすると工場に靴下を編む機械を導入してそこでがーッと作る事によって大量の靴下が作れるようになる。これって靴下の生産能力の向上なわけなのです。その結果どうなったかというと家庭内手工業でやっていた靴下というのはごく一部のプレミアム物とかそういう物だけになってしまって一般的に今皆さんが履いている靴下のほとんどっていうのは工場で作られているわけですよね。ユニクロとかで大量生産されたりとかしているわけですよね。そういう靴下を皆さんが履いているというわけです。同じようにプログラミング言語の〓00:16:53〓っていうのはプログラムの生産能力を高めたのです。昔、プログラミング言語のなかった時代に機械語で書いていた時代と比べてFORTRANが生まれているし〓00:17:02〓が生まれている。プログラミングの生産性というのがすごくアップしてきたわけです。そのFORTRANという古臭い言語〓00:17:08〓と思うのですけどそれらの言語が地軸になって今皆さんがモダンだと思っているような例えばスクリプト言語であったりとかブラウザ上で動くであるとか、そういうふうな新しい言語の像っていうのは過去の言語が生産性を高めた上でその上に積み上げる事が出来て生まれてきたという言語なわけなのです。当然のように今流行っている言語も10年後20年後には同じように、より生産性の高い言語に変わっていくっていうのがあるでしょうね。多分ここにいる皆さんだと分かりやすいと思うのですけど、コンパイルする言語とコンパイルしない言語でどちらの方が皆さん好きです？コンパイルする言語の方が好きな人？コンパイルしない言語の方が好きな人？かなり半々というか、しない方が6割する方が3割ぐらいの割合でパカっと別れているのですけどこの比率って今後変わっていくと思いません？ちょっとすみません。例の挙げ方が悪かった。コンパイルするばっかりの時代があって、コンパイルしない言語の時代があって、やっぱりコンパイルする言語の方が語れる事が増えて良いよねみたいな〓00:18:21〓戻しの時期に今あるわけですよね。すみません。話がちょっと混乱してしまいましたけど、言いたかった事に戻しますと言語って変わっていくのです。その新しい言語・新しい概念が必ず生まれていって5年後10年後には変わっていくので、それを習得していく必要があると。それを習得していく上で学びを加速する事が必要であると。

新しい情報って必ず生まれてくるので将来の自分はそれにキャッチアップしなければいけない。ならばその新しい情報にキャッチアップする学びの生産性を高める事が必要になる。この学びの生産性を高める事が長期的に見ると大きな差になる。それはどういうような差かというと、今皆さんが手編みの靴下ではなくて機械生産の靴下を履いているのと同じような事が起こるわけです。

• 知識と資本論とテクノロジストの条件 というような感じの経済学とかそういうような感じの話を絡めた章を第0章として書いたのです。このコーディングを支える技術という本に。そしたらこれがボツになりまして。なぜかというと、本屋に並ぶわけですね。だいたい皆開いてみて冒頭から読み始めるのですね。冒頭のとこに経済学の話が書いてある技術書なわけなのです。「これはちょっとどうかと思います。」って編集者さんに言われてしまって。知識とは何かっていう話を掘り下げていくと哲学になってしまうし、生産性って何だっていう話を掘り下げていくと経済学になってしまうのですね。そういうような白書が〓00:19:34〓という事でこれ削る事になったのですけど。これ幸いというか僕が2017年に発掘してネット上に置いたので「知識と資本論とテクノロジストの条件」で検索すると読めるのですが、この講義資料とか翔泳社さんのサイトとかで見られるのかな。あとで辿り着く方法はネットでググれば分かるようにしてありますので興味のある方は是非読んでいただけたらと思います。

で、話を戻しますとそのボツになった文章がもったいないという事でコラムとして入れたのですね。「組版してみたらページ半分空いているページがいくつかあるのでここにコラムを入れられませんか？」というのを終了の2週間前ぐらいに言われるわけで。「じゃああのボツにした原稿からピックしましょう」って言っていくつか切り出してコラムとして入れたのですね。

• 何をどう学ぶか？
• 何をどう学ぶか？２：三大入力方法
• この辺りの話は なぜ学び方に興味を持ったか？ で詳しく情報収集した あとやっぱり話足りないなと思った所をスライドの形でやってそのまま紹介スライドを書籍の公式ページに載せたら良いのではないかと言って載せたのです。この2つの「何をどう学ぶか？」とそれの続編である「三大入力方法」というこの2つを書いたのですね。これそれぞれスライドシェアで公開していたのですけれども、5.3万ページビューと2.5万ページビューでそれぞれ結構読まれて面白い〓00:20:44〓がいっぱいでという感じの発表資料になりました。この公開資料を公開していたら次に何が起こったかというと、「コラムが面白いな」とか「この発表資料が面白い」とかのフィードバックがガンガンきたので
• 特集 エンジニアの学び方 技術評論社の編集さんがこの内容でWEB+DBの特集記事を書かないかという話になったわけなのですね。それで書いたのがちょうど1年後の2014年4月に出たWEB+DB PRESS Vol.80の特集:エンジニアの学び方というやつです。これ効率的に知識を得て、成果に結びつけるというさっき話していたような内容がチョロってサブタイトルに入っているのです。これを書きました。この記事はネット上でも見られるので興味のある方は検索してみれば良いと思います。でもこの本にほぼ入っているのでこの本を読んでいただければそっちで良いと思いますけれども。この特集で書いた重要なポイントって何かというと

• アウトプット 本を読むという勉強スタイルと手を動かすという勉強スタイルの2つあるよねと。どちらか片方ではだめだよねという話で。学ぶという言葉を聞いた時に皆さん頑張って本を読んで、一生懸命に本を読んでインプットして、インプットして、インプットしてみたいなイメージを持ってしまう方が多いと思うのですけれども。なぜかというと小学校の教育とかでそういう事をされたケースが多いと思うのですけれども、でも実際に自分がプログラミング言語をどうやって学んできたかといったらキーボードを叩かないでずっと本だけを読んで勉強したかと言ったらそんな事ないわけですよね。 だいたい皆さんがプログラミングを書いて実行してみて、そしたら自分がこう動くだろうと思った結果と違う結果が出てきて、「あ！何か期待していたのと違うぞ。何が違うのだ？」みたいなサイクルを何度も何度も繰り返してプログラミング言語が書けるようになってきたと思うのですね、皆さん。「手を動かす」＝「アウトプットする」という事なのですね。なんでなのかというと、

• 理解は仮説 本を読んだりして自分は理解したと思った、この理解した気持ちって仮説なのです。あなたが本当に理解しているかどうかっていうのは、理解した気持ちになっているという事とは無関係なので。なので理解したと思っても、その理解に基づいたプログラミングを書いてみてそれを実行してみると。正しく理解しているなら〓00:22:40〓回るのですけど、正しく理解していなかった場合にはプログラミングが期待と違う挙動をするわけですね。期待したのと違う挙動を自分が書いたプログラムがした時っていうのは、これは自分の理解が間違っていた。理解を改善していくというチャンスが出来たのです。学びのチャンスが出たわけです。これって仮説に基づいてプログラムを書いて、そのプログラムを見て動作を見てそして自分の仮説が理解が間違っていたというのを確認して改善していくという作業って完全に

• 知識の行動による証明 実験科学の仮説検証とそっくりなのですね。実験科学でも仮説を立てます。その仮説を検証するために実験をします。実験結果を観察して、その検証される仮説が正しいのか仮説に反する結果が出てくるのかそれを観察します。この比較を繰り返す事によって科学が発展してきたわけです。なので、皆さんの脳内に科学を組み立てるみたいなイメージで思っていただけたら良いですけれども。知識をコードによって検証する。何が正しい知識なのか、自分の理解が正しいのかどうかっていうのを行動する事によって検証していくというのをそのサイクルを回して学んでいくわけです。これ今回のイベントのテーマがFUN楽しさというところで楽しさの話をスライドに入れ忘れたのですけど今ちょっとここで話しますと動くかなと思って書いたのが実際期待した通り動いた瞬間はめっちゃ楽しいのですよ。「あれ？動かないぞ。なんでだろう。なんでだろう。」って考えて「あ！そうか。こうだったからこうすれば良かったんだ。」と分かる瞬間これも楽しいですよね。このサイクルをガンガン回すのが楽しいです。〓00:24:14報酬？〓のサイクルなのです。そのモチベーション高い状態で楽しいおもしろいと思いながら学んでいく事が、嫌々教科書を読みながら勉強する事に比べて圧倒的に生産性が高いのです。なので、如何にこのサイクルを回していくか。楽しい状態で学んでいくかってすごく皆さんの長期的な生産性、長期的な学びの効率に影響してくると思っています。

• リーン・スタートアップ

次の話なのですがこのサイクルを小さくする事が重要なのですね。1年かけて実験して1年後に結果が分かりますだと学びがなかなか進まない。この件に関してソフトウェアエンジニアの皆さんというのはとても恵まれていて、すぐ実験出来るじゃないですか。プログラムを書いて実行してみて、「あ！間違っていた。」じゃあここを直してみてもう1回実行して今度は上手くいった。これが1日のうちに出来るわけです。もし、皆さんが木工職人だったとするじゃないですか。木工の技術を磨こうとして勉強しているとするじゃないですか。作っていて切る所を間違って長さ間違っていた、木材を書き間違っていて椅子にならなかったとなった時に切る所からやり直しなのです。木材の在庫がなかったら木材を買ってくる所からやり直しなのです。これに比べるとソフトウェアエンジニアがいかに恵まれているか。この小さいサイクルをガンガン回して学んでいくという、この楽しい学びをする事が出来る。とても恵まれた立場にいるわけなのですよね。なぜかというとそれがデジタルメタだからです。プログラミングというのは。今後〓00:25:32〓みたなそういう物が生まれてくる事によって物理的な物作りも、そういうサイクルが回しやすくはなってくるとは思うのですけれども皆さんは1歩先んじて、人類の中でも恵まれた職種に就いているというわけです。さてさてこんな感じの特集を書いたのですけど。

この特集記事が人気だったので、この特集記事を元に書籍化をしましょうという話になります。これが2017年5月～11月ぐらいで3週間で1章のペースで執筆をします。これなぜかというと〓00:26:00〓回してどうのこうのみたいな話を読んで、なるほど！これをやってみたい。と思ったのですね、僕が。3週間で1〓00:26:07デリューション？〓でやろうと思って結構大変でした。そんな感じの事を3週間で執筆したのがこちらです。なんかこれ文章がちょっと切れていますね。「コーディングを支える技術」これの執筆の時に使った、僕がどうやって執筆していったかという知的財産の技術自身をこの本に書くという、それもまたちょっとメタなチャレンジなのですけれども。自分がどのようにしてこの本を書いていったかというプロセスを執筆している自分を観察〓00:26:37〓観察していると自分はこうやって執筆しているのだなという観察した結果をこっちにフィードバック先の人が書いているという、そういうような構造の本なわけなのです。5章6章辺りに如何にして執筆してきたかの話が。この本を執筆している最中にこの本を執筆でどういう事をしたかみたいな話がこの本に入っている。メタな感じの本なのですけど。この本を書く事自体も先ほど出てきた行動によって検証する1つの事例なわけです。

知識を行動によって検証するっていうのは学びに重要だという話をしました。コーディングを支える技術を書いた時の本は、この本が5年も売れ続けているという事によって、ある種有益な知的生産をする上で有益な手法だったに違いないというふうに思っている。ならばその方法を別の本、もう1冊の方に使った上でその内容について執筆したらどうだという事を考えた。それはこの本の規格なわけなのです。なので、コラム記事を書籍化したみたいな話をするとコラム記事の内容がそのままコピーされてここに入っているとか、それが薄められて本に入っているんじゃないかとイメージされる方が多いと思うのですけど実質的にはコラム記事の内容が第1章のところに入って残りの所は新しくガーっとこの場で生産された、この実験によって生産された知識がここにギュウギュウと詰まっているという状況になっています。 やっぱり書籍の特集記事書きますといった時に、「じゃあ12ページで書いて下さい。」みたいな話になるのですね。12ページで書けるわけがないのです。この本は250ページあるのですけど、この250ページでも足りないと思っているぐらいのを、なんとかして1冊の本として発行できる形になんとかして圧縮しようとして頑張って詰め込んだという感じの本ですね。さてさてあと25分ぐらいありますがスライドは半分ぐらいですね。

タイトルがちょっと変わりました。「エンジニアの学び方」という特集だったのが「エンジニアの知的生産術」というタイトルに変わりました。これなぜなのか。この学びという言葉はやっぱり学ぶと言ったら本とかを読んでこうやってインプットする場所なのだ、インプットする物なのだみたいな勘違いを生み出しやすいなというのがひしひしと感じていまして。でも先ほど説明したようにアウトプットをしてその結果を見て検証するというのが学びのすごく重要なキーポイントだと僕は思っている。そのアウトプットが大事なのでアウトプットありき。アウトプットして結果を見る事によって学んだ。学んでから発表しようとか学んでからアウトプットしようと思う方多いじゃないですか。例えば勉強会とかで発表するのにも自分が十分勉強して発表出来るぐらいの自身がついたら発表しようみたいな気持ちを持たれる方が多いですけど、そうではなくてアウトプットしてフィードバックを受ける事によって、より加速するのですね、学びが。十分学んでからやろうと思っていたら、いつまでたってもやらないです。なので、そういうアウトプットを強調した。そのアウトプット大事だよという言葉も皆さん耳にタコが出来るほど聞いた言葉だと思うのですけど、では具体的にアウトプットってどうするのだと。というのはあまり聞いた事ないですよね。例えばIT系の勉強会のライトニングトークで5分間話します。これって比較的イージーなアウトプットだと僕は思っているのですけど。やり足りない、心にハードルを抱えている事に関すると、それですらハードルが高く感じてしまうのですね。ならばもっと小さい単位のアウトプット、もっともっとハードルの低い物からチャレンジして徐々に回していって大きくしていって、アウトプット出来るようになっていく。そういうふうな形の事をやっていく必要がある。そのアウトプットのハードルを下げる必要があるという所に関して、この本では丸々1章かけて書いています。どんな事を書いているかというと、まず付箋に。これくらいの小さい付箋に書けるくらいの文章ってたかだか20文字もないくらいですけど、まずそれを書いてみよう。それが書けるか書けないのかで自分の中にアウトプットする知識があるのか、知識がないのかが分かる。ある程度書けたその書いた付箋を見てそれを脳内で考えるのではなくて、まず付箋に書き出してみた、その付箋が並んでいる状態を見ると考えている最中に情報が消えなくなるので安心して断片の情報を組み合わせるという所に自分の脳のCPUのリソースを100％使えます。脳内だけで考えようとしていると材料に使う情報の断片というのは脳内で記憶して保持しておくという方にCPUのリソースが取られるので実際考えるところに使える脳のリソースが減るわけなのです。それを一旦書き出してそれを見ながら考える事によって覚えておくという〓00:30:57〓減らす事によって皆さんの脳をより一層断片の情報を組み立てて構造を作っていくという所に〓00:31:07〓投資する事が出来る。これ技術によって皆さんの知能を向上させる手法なわけなのですけど。そういうふうな感じの事をやっていけば良いという話は書いてあります。

もう1点、本を出してからこれある種の実験だったのですけど、予想以上にこの「の」っていう所が気になられた方がいて。「エンジニアの知的財産術」というタイトルを見て「エンジニアのための知的生産術」でエンジニアでない人は読んではいけないと解釈をする人が思った以上に多かった。そんなに多いと思わなかった。なぜかというと東大生の〓00:31:40〓が東大生だけのものだとは思わないし外資系コンサルタントの資料作成術は外資系コンサルタントしか使っちゃいけないとは思わないだろうと思うのですけれども。なぜか以外とエンジニアの知能生産術といった時にエンジニアのためのなんだというふうに考えられた方が多くて、Twitterとかで反響を見てみると、それは前半部分が東大生とか外資系コンサルタントは特殊な感じがするけどエンジニアって特殊じゃない感じがするから「エンジニアの知的生産術」って「エンジニアのための知的生産術」なのだと思ったみたいな話がありました。なのですけれども、実際の所エンジニアって割と特殊で、ここでいうエンジニアってソフトウェアエンジニアなのですけど、ソフトエンジニアって割りと特殊なのです。

• 長い間、言葉を使って作られるのが概念、物質を使って作られるのが道具だった。
• プログラミング言語の誕生によって、人類は「言葉によって道具を作る」という選択肢を手に入れた 知的生産に関して人類の歴史上とても特殊な存在なのですね。どういう存在かというと、〓00:32:23〓や言葉を使って作られる物っていうのは思考とか思想とか概念とか〓00:32:29議論？〓とか、そういうふうな考えなのです。一方物を作って、物質を使って作られるのがハンガーであるとか自転車であるとか、工場の機械であるとか、そういう風な道具だったわけです。でもプログラミング言語が誕生した事によって人類というのは言葉によって道具を作るという手段を手に入れた。そういう選択肢を手に入れた。これ、たかだか70年前の話なのです。50年代にプログラミング言語が生まれたわけです。プログラミング言語という道具が生まれた事によってソフトウェアを生産する能力が上がった。

プログラミング言語それ自体がソフトウェアなのです。という事は道具を作る能力を向上したと同時に道具がさらに作られるようになったわけなのですね。効率の良い言語を使ってさらに効率の良い言語が作られていくという、こういう〓00:33:10フェードアップ？〓なサイクルが発生しているわけなのです。まさに加速のサイクルなのですね。たかだか80年前にはプログラミング言語はなかったのです。プログラミング言語がない時代を皆さんイメージしてみて下さい。プログラムをどうやって書いていたか。コンピューターがあった。コンピューターに特定の目的の処理を実行させるという事はやっていた。じゃあどうやってそれを実現したのか。ゲーブルの配線を繋ぎ変えるのですね。この目的をこのコンピューターで計算するためにはこの配線とこの配線を繋ぐ必要があるっていう、そういうチャートを作りまして、ケーブルいっぱい持って、こことここを差して、こことここに差してっていって繋いでいく。そういう事をしていたわけなのです。物理だったのです。物理の〓00:33:53道？〓があったのです。それがデジタルデータでプログラムを書く事が出来るようになった。ソフトウェアというものはデジタルデータで作られるようになった。

これによって如何に大きな人類の歴史に対する影響があったか。歴史上例えば300年前とか500年前に偉い哲学者とか偉い学者の先生とかいっぱいいるのですよ。賢かった人が世の中にいっぱいいたのですけど彼ら誰もプログラミングを経験していないのです。これって面白いポイントで、このプログラミングの登場というものが人類に大きな影響を与えた。ほぼほぼ間違いないのに、それを経験している人っていうのはこの後の時代。この70年前以降、だから1950年以降の時代にしか人類の中で登場していないのです。そういう状況に皆さんあるのですね。それってすごく特殊な状況なのです。

• 「バージョン管理システム」という発明の話
  • それ以前に言葉で表現されたものを複数ブランチ並列で開発することは困難だった

言葉によって記述された物が人間でない物によって実行される。これって特殊なのです。コンピューター以前は言葉によって書かれた文字が人間が読んで人間が実行する物だったのです。それが人間ではない物が言葉によって記述された物を実行するようになった。そうすると何が出来るようになってきたか。その後、コンピューターとかが発展してきていて何が起きるようになったかというと人間では把握出来ないような膨大な量の情報から言葉によって記述された物の中から検索して見つけてくるという事が出来るようになった。皆さんソースコードに〓00:35:16〓検索したりするじゃないですか。書籍のデータとかが入っている検索データエンジンがあったら、そこで検索キーワードを入れるとその場所とかがバーっと出てくるじゃないですか。皆さんGoogleで検索したりするじゃないですか。ほぼ日常的に。あれによって何が起きているかというと、生身の人間あなた1人の脳の中に絶対に収まりきらない大量の情報の中から見つけだしてくるという能力がコンピューターによって知見されているのです。その知的能力増加状態。すごい装備をつけている状態だと思います。すごく強化されている状態。この強化されている状態を経験をした哲学者といのはここにいないのです。これすごく面白い状況ですね。しかも皆さんデジタルデータを扱っているエンジニアなので物理的な物作りのエンジニアと違って。どこが1番大きく違うかというと、これ作っている物が言葉によって作られている物なので編集過程が記録出来て、しかも見るたびに巻き戻せる。これ〓00:36:17〓とかそういうイメージで説明しているのですけど、これが出来る。今まで人類が例えば哲学者が哲学の色んな考えを本を書いてみたいな作業を回していた時に現状つまり出来なかったブランチを切っておこうとか、この考え方はAの考え方、Bの考え方があるからとりあえず両方ブランチ切っておこうとか出来なかったわけですね。共同編集も出来なかったわけなのです。それがソフトウェアという物は何が出来ているかというと共同編集出来ているしブランチ切って複数のパートが一度に走っているし、間違った〓00:36:48〓出来るし分岐した事があったらマージー出来るわけです。こんな〓00:36:53〓発生というのは人類史上いかに面白い事をしているのかという話です。こんな感じの事を話していると時間がドンドンなくなっていくのですが。でもまぁ十分ある。あと17分ある。というふうな感じの事を、如何に僕が面白がってこの本を書いているかもうすでにたいぶ伝わっていると思うのですけど、すごく面白いのですよ。皆さん面白い時代に生きているし面白いチャンスに恵まれている状態なわけなのですね。

• ハンドル: 液体が容器に入っているメタファー
• 付箋は本体ではない 概念のハンドル 水面下の「まだ言語化されていないもの」を引っ張り出すためのフック

この本を書いて、少なくとも日本中の何千、何万のエンジニアというのが自分の中で知的サイクルが回っているのだという事を自覚する。そのサイクルを加速していくという事が技術によって可能である。加速していくという事は自分の人生にとって有益である。そういうふうな感じの〓00:37:40〓を皆さんが受け取るわけですね。しかも今までこの本を読んだ感想を色々見ている中にはいっぱいあったのですけど、今まで無意識にやっていたというか言葉にせずにやっていた事がここに説明されている。こういう流れで生まれていくのだ。こういう概念が過去にあったのだ。自分と似ている所もあるし、ちょっと違う所もあるみたいな感じのより自分の知的生産を観察して記述してそれについて考えてとやっていくためのハンドルになる言葉が増えたわけです。この本によって。 ここに書いている図はクジラを釣り上げている図なのですけれども。この水面は言語化されている物とされていない物の境目なのですね。皆さん色々な経験をしてきて自分がプログラムを書くという知的生産の過程であるとか、文章を書くという知的生産の過程であるとか、今までの人生の色々な経験を皆さんの水面にはドッサリあるわけなのですけれども、それを言葉にして引きずり出すという事が上手く出来ていない状態にある。でもこれに自分のしたあの経験というのはこの言葉だよ。こういう言葉で説明されているのだ。みたいなフックが掛かると、そのフックを引っ張る事によって自分の経験を言語化していく事が出来るようになるのですね。このハンドルというか本の中ではハンドルと呼んでいますけど、魚の例えで言うならばフックを引っ掛けて釣り上げるよりも釣り針で引っ掛けて釣り上げる方がもっとイメージが沸きやすいかなと。そのフックとかハンドルになる言葉というのを是非入れる事によって皆さんの思考がより一層やりやすくなるのですね。これソフトウェア業界で言うならばデザインパターンとかと同じなわけで、デザインパターンもメディエーターパターンという言葉がなかった時代、中心にメディエーターが存在してそれぞれの〓00:39:17〓ごとにやり取りを一括集中する事によってそれぞれが作用するというより効率の良い管理しやすいコミュニケーションの形態をもたらすみたいな感じの事をすごく今言葉をいっぱいたくさん使って説明しないといけなかったのですけど、デザインパターンをお互い知っている同士だと、「このパターンはメディエーターパターンだね？」「うん。そうだね。メディエーターパターンで実装するのが良いよね。」みたいな感じの会話が出来るわけなのですね。思考の経済性、思考の効率、コミュニケーションと思考とか議論とかそういう物の諸々の効率を言葉というのは底上げするわけなのです。こういう言葉、そういう本を作る事が出来た。となると、当然必然的に次に何が起こるかと言うと、この本に書いてあった○○というのはあれの機能を使ったら良いのではないかとか、今までこういう悩みなのだけどそれって、この本の何ページに書いてあったあの手法を使ったら解決するんじゃないのみたいな話になるのです。実際にTwitterを見たら、そういうのがパラパラと散見されるのです。つまりこの本の読者の人達の皆さんの知的生産というのがこの本に書かれた言葉によって生産性が向上するという。プログラミング言語が発明されてプログラムの生産性が向上したのと同じように、皆さんの知的生産性を向上する言語なのです。これが。そんな感じの事が現在観測されている〓00:40:35〓です。

• エンジニアの知的生産術 反響まとめ 行動によって検証するっていうのはちょっと先走って話ましたけれども、この本に書いた内容って僕が「コーディングを支える技術」を書く時に使った、僕が使って僕が有益だと思った方法を書いた本なのですけど、これが自分にとって有益なだけなのか、それとも自分以外の人にとっても有益なのかというのは、これは分からなかった。これは仮説だったので、他の人にも有益なのではないかと思ってこの本を書きはじめたのですけれども、これは仮説だったわけです。これを出版する事によって検証するっていうのをやりまして、これを発売から週に数回はこの本のタイトルで検索してTwitter上の反応を全部見ています。そうすると、自分のスクラップボックスにどんどん転載していくとブログ記事を除いても5万字ある状態になっていて。皆さん色んな方が色んなブログ記事を書いていただいて、とてもありがたいし本職が執筆業の人がプログラマーじゃないけど読みましたみたいな人が書いてくれたブログの記事が本当に良い文章でさすがプロだなと思ったのですが。そういうふうな色々な分野の色々なバックグラウンドの人がこの本について色々言ってくれている、ブログを書いていただいて、そういう状況になっている。それがすごく面白いと思っていて、ある種これは皆さんにとって有益である事が検証されたんだろうなというふうに思っています。

今ちょっとスクラップボックスっていう話が出ましたけど、スクラップボックスの話が何故出たかと言うと、記録しているのがスクラップボックスという話もそうですけど知的生産性を支援するソフトウェアっていうのは今後よりどんどん良くなっていくだろう。改善していく加速していくサイクルが発生するであろうという話なのですけど、スクラップボックスっていうサービスは僕が今、1番グッときているサービス、1番FUNを感じているサービスですね。このイベント的に言う。

• Scrapbox
  • 連想のストック 残念ながらこのスクラップボックスが本格的に使われだしたのは17年の8月とかそういう辺りで、つまりこの本の執筆をスタートした後だったのですね。執筆後だったのでこの本の中で全然スクラップボックスの「ス」の字も出てこないのですけれども、もしこの本の執筆が1年後だったら間違いなくスクラップボックスのページがだいぶ増えていたと思います。そんな感じのツールがこのスクラップボックス。このスクラップボックスは一体何なのかというと、簡単に言うと情報の繋がりをリンクという形で表現する〓00:42:47〓使っていない人にとってイメージ沸きにくいと思うので1番皆さんがしっくりきやすい、似ている物って言ったらWikipediaかなと思うのですね。Wikipediaって皆さんイメージするとページがありますよね。ページの中の文章にリンクがついている、そのリンクを押すとそのページに飛びますよね。これ情報の間にリンクが繋がりなく作られているこの状態。このWikipediaみたいなウィキを、Wikipediaは不特定多数の人が書いているわけなのです。なので、主観的な情報は全部取り除いて、客観的な事実だけ集積しようとか、独自現況を書くなとかそういうローカルルールなのですね。一方で皆さん個人がスクラップボックスを使う場合とか僕が自分の書いた物をスクラップボックスに載せる場合というのは、すみません。話の順番をちょっと飛ばしました。一旦今のを忘れて頂いて、

• 著者の数とフォーマット 一方で電子書籍というものは電子って言っても本の形、本のフォーマットを引きづっていますよね。一次元的に。だいたい頭から開いて順番に読んでいって、僕のこの本、実は以外とリンク情報があってこの話は第4章の○○で書いていますとか、この本は○○ページのコラムに書いていますみたいなリンクがいっぱい書いてあるのですけれども、なかなかそれを辿らないで皆、一次元的にこれに書かれている順番で読むのではありません？これは紙の本ですけれども、紙の本はそう読むのに適したデバイスだったので皆さんそのフォーマット。一次元で読むというインプットのパターンに慣れてしまっている。一方で皆さんWikipedia読んだ事ありますよね？Wikipedia読んでみた楽しいと思いませんでした？自分が読んでいる最中に興味があったキーワードをポチっとするとそのキーワードの説明が出てきて、そのキーワードの説明の中にあった知らない単語をポチっと押すとまたそれの説明が出てきてってグルグルと辿っていく。これ何だろうな？と思った自分の好奇心、疑問に思った事の答えはスッと出てくるという、このサイクルを回していく学びっていうのはすごく楽しいと思いません？なので僕は思ったのです。書籍っていうのは特定少数の著者が書いているのですね。Wikipediaと違って。特定少数の著者が書いているネットワーク的な情報表現、知識表現のフォーマットがあったらそれってすごく面白いのではないかと僕は今思っているわけなのです。これは割りとTRUEかFALSEか怪しい仮説なのです。そんな新しいフォーマットのコンテンツがあったとしても読みづらいよとか紙の形の方が良いよという読者の方が多いという評判の方が今、多数派で、実は。僕は〓00:45:21〓仮説なのですけれども。そういうふうな物があったら面白いのではないかと思うわけです。

というわけで考えたのがエンジニアの知的生産術をスクラップボックスのプロジェクトにしてしまおうという事を考えていましてこれは実はログの上では既に存在しているのですけど、残念ながら出版社が売り上げが減少するのではと難色を示していて議論中なのですけど最悪発売から1年ぐらい経ったらエイヤ！って公開してしまおうかなと勝手に思っているぐらいの状況なのですけど、そういうわけなので文章にも書いちゃっているので言いますと、現状そこの所の議論も折り合っていないのでまだ出版契約結んでいないのですね。発売から何カ月〓00:45:58〓そういう状況なのですけれども、「これの英語版を作るのは良いですよね？」という事で「それはさすがに良いですね。」という話になったので英語版を作っていくと。

これは実際今、作りつつある英語版のこの本のスクラップボックスです。これ面白いのは図とかがこれに表示されるのは面白いですね。

それはさて置き何故英語版を作ろうと思ったかという話をしますと。発売から4ヶ月とかTwitterを〓00:46:22慣行？〓をしていて多くの日本人にとってこの本のコンテンツが有益だという事が分かったと。それは実験によって検証されたと。この中に日本人特有の日本人だから出来るような事ってほぼないのですよ。まぁ写経っていう言葉とか、KJ法とか日本っぽいのはいくつかあるのですけど、この内容は…写経はちょっと追加で英語版には説明は書いたのですけど。そういう〓00:46:47〓日本に限らず世界中の人にとって有益なコンテンツであるはずだというふうな事を思っているので。でもこれは仮説なわけなのです。英語圏の人から見ると「ふ～ん。そんなのは別に面白い話じゃない。新しい話じゃない。日本人それ今まで知らなかったの。遅れている！」みたいな事をもしかしたら英語圏から言われるかもしれないのだけど、それは分からないから仮説なのですね。僕は有益だと思っているのです。なのでこの仮説を検証をするためには何をする必要があるかというと、このコンテンツが英語である必要があった。英語であると、単に翻訳という訳ではなくて英語圏の〓00:47:17〓色々補足の説明を足さないといけないという事もあって自分で翻訳している状態なのですね。

これは現在進行中の実験でして2つ目の実験は1冊の書籍がスクラップボックスの形になったら面白いのではないか。作って実験しようというのが1つ目の実験。このコンテンツの英語版が出来たらそれは面白いのではないかというのがもう1つの実験。これを同時にやったら良いよねという事で英語版もスクラップボックスで今翻訳を進めていっている最中でこれがある程度まとまったら一応本の体裁の方が受け入れやすい人がいるような雰囲気なので電子書籍版を作って英語圏で発売しようというふうに思っています。

• 英語版
  • /intellitech-en
• 英語版の電子書籍
  • https://leanpub.com/intellitech-howtoboostyourcreativity/c/NF89WYOM4fLm

この本の全体像を簡単に説明しますと、第0章というのが短い導入になっていて、サイクルを回していく事が大事だよね的な事がチョロっと書いています。第1章というのが先ほど紹介しました技術評論社のエンジニアの学び方っていうコラムで紹介した内容に近い内容。それに由来する部分です。それはどういう事が書いてあるかと言うとさっきもチョロっと説明しましたがサイクルを回して学んでいく事が大事だという話を書いていたのです。第2章は何を書いているかというと、この辺からまるっきり追加コンテンツなのですけれども。「やる気のマネジメント」このサイクルを回していくっていうのをサイクルを回す気が起こらなくなってヤル気が萎えてしまうとサイクル回らないですよね。楽しいって言いながらガンガンサイクルを回す心理状態をどうやってキープしていけるかとか。これが世の中に色々なライフハックとか生産性向上Tipsとかあるじゃないですか。でもやる気がある状態を保つの保たないのって、やる気がある状態を保っている時間の差が3倍あったとしたら多少のTipsでは変わらないのですよね。1番重要なのは自分が楽しく学べている。行動出来ている状態をどうすれば延ばす事が出来るのかというところで。これはもう100％正解というのは無いのですけれども例えばこういう状況は〓00:48:58〓だからこういう状況だったら…例えばタスクが大きすぎて終わりの時間が見えないでやる気がなくなるよねとなったらタスクを小さく刻む必要がある。刻む方法はどんな方法があるだとうか。時間で刻む方法もあるし量で刻む方法もあるとか、緊急のタスクがどんどん飛び込んでくる時はどうやったら解決できるよとか、そういうような感じの事を書いているのが第2章です。

第3章以降が先ほどのサイクルをグッと引き伸ばしてそのサイクルの細々したところをより深くフォーカスしている話でして。3章は記憶の話。どうやって記憶を蓄積していくかという話でして、ここを今英語版の翻訳中です。次の4章はどうやって本を読んでいくのかという話。これに関しての話。この3章と4章をザックリ言うならばインプットをどうやってやるかという話です。 その次の5章、6章。考えをまとめるにはどうするかという事で新しいアイデア・新しい考えというのはどうやったら作る事が出来るか。5章、6章というのはアウトプットに関する、アウトプットをどうすれば底上げできるかという話になる。 最後の7章が何を学ぶか。これが幻の0章なのですね。1番最初の「コーディングを支える技術」で0章で書いたのだけどボツになって削った章が5年も経っているのでだいぶ内容も色々さし変わってアップデートされたりしているのですけど要はコンセプトとして哲学と経営学の話が入っている章っていうのがこの第7章という感じになっております。 さてさてこんな感じの本を今まさに発売した後も実験をしている。発売自体が実験だったけれども、その後も発売して終わりじゃないという事なのですね。ゴールじゃないのです。そもそも実はこの本の1番最後のページに何て書いているかというと、「この実験もそろそろ終わろうとしています。私が価値のある知識を創造出来ていてこの本を通じてあなたに伝わりあなたの中に根付いてあなたの知的生産の助けになる事を祈っています。私にとってこれはゴールではなく新たなスタートです。スタートでありこの本の初版から5年10年経った時に何が起こるのかをワクワク楽しみにしています。」今この本を書いた種が皆さんという土壌の中に根付いてそこから育っていった時に5年後10年後に何が起こるかというとこまで、すごく〓00:51:10〓そういうチャレンジが現在進行形で進んでいるという状況なのです。

というわけでそんな感じの本を書きましたという話でして、読みたい人に関してはまずこの会場でこれ翔泳社さんのイベントなのに技術評論社の本が結構な冊数入荷されているらしくて。なんか50冊と聞きましたよ。すごい技術評論社さん〓00:51:30〓という話をしていまして会場でも恐らく帰ると思います。売り切れていなければ。あとやっぱり電子書籍版が欲しいよという方がいらっしゃると思っていて、これ技術評論社の電子書籍ストアからPDFとEPUBの形式でダウンロードする事が出来るというのと買う事が出来るというのとあとAmazon Kindleでももう買えるようになっているはずだと思います。自分でやっていないのでちょっと自信がないです。大事なポイントとしては僕の中で今1番ホットなのは英語版を作っているというところで英語版は僕の英語力の問題とかもあるかとは思うのですけどボチボチと進めていって今3章の半ばまでは訳している所なのですけど、これを見るというのも1つの手です。英語であるというデメリットがある反面、〓00:52:10〓というメリットがあってスクラップボックス形式になっていうという謎のポジティブなのかネガティブなのか分からない実験というのがそこにあるわけですね。

ここまで話てくると色々な英語版のとことか、そういうふうなのにどうやって辿り着けるのかと考える方が多いと思いますので紹介しますと、まず「西尾のScrapbox」で検索していただく。これをまず覚えていただければだいたい大丈夫かと思います。そうするとスクラップボックスのページにたどり着きます。そこに僕が色々言っていた今回発表の断片とかそういう物が全部ウィキの状態でバーっとあるわけなのですね。エンジニアの知的生産術のビフォー・アフターという、この発表のタイトルです。この発表のタイトルで検索していただくとこの発表のために作ったページがあって、そこから色々な断片へのリンクが全部そこから貼ってある。なのでこれを辿っていただければ、良いと思います。以上で発表は終了なのですが残りが1分という微妙な感じで余っているので、質疑応答の時間に入らせて頂いて良いですかね。質問のある方？ない。ないですか。じゃあ早めに切り上げますか。では、早めに切り上げさせていただきたいと思います。何か疑問に思った事、ここでこう質問ありますか？と聞かれた時にとっさに質問を出しにくいという心のハードルがあるわけですね、皆さん。アウトプットをする事に対する心のハードルがある状態なのですけど、これがどうやって下げていくかっていった時に例えばTwitterでハッシュタグとかがあるのですね、このイベントのための。あとでそれは見ておくので後から思った事とかをそちらに書いていただければ反応するかもしれません。Twitterで僕にメンションしていただいてももちろん構わないです。それからあまりこういう所で質問する事に気を追わないでアウトプットのハードルを下げていく事がとても大事だと思いますという事を言わせていただいて、発表を終了させていただきたいと思います。ご清聴ありがとうございました。

• エンジニアの知的生産術と体育型授業
• 当初30分発表15分質疑だと思い込んでいたので、体育型授業の質問タイムスライドを入れていたが、45分発表の想定だと聞いてアドリブでコンテンツを増やしたら発表が終わったタイミングで残り1分だったから使わなかった。

2019-02-12

• 知識と資本論とテクノロジストの条件
• なぜ知的生産術に投資するのか
• 知識という資本#知識資本

2019-01-23

• なぜ知的生産術に投資するのか
• 知識という資本#知識資本
• エンジニアの知的生産術と体育型授業