id:naoya さん講演『技術と問題解決』講演記録パート

work

「rebuild.fmの人」やTwitterの@記法の名前もそうなんですがヘビーはてなユーザーの私としてはやっぱりid記法で呼びたい id:naoya さん（伊藤直也さん）の新卒向け講演が社内で行われたのでまずは講演記録パートです。本名と所属は以前から「がんばればわかる」ようになってますし*1、出して困るような厄介な人は幸い身近にいないので身バレとか知らない。

以下長いので続きを読む記法で。感想パートは1日以内に別記事で更新します。

「技術と問題解決」

Agenda

Q. uptimeコマンド・topコマンドで見える「ロードアベレージ」って何ですか？

  • 無限ループ -> 上がる
  • 巨大なファイル読み込み -> 上がる
  • STDINからの読み取り -> 上がらない

よく起こるトラブル：「重い！」「遅い！」「反応がない！」→そうやって反応したい気持ちはわかるのだけど…それってどういうこと？ load average / CPU使用率はどうやって算定されてる数字なの？

→OSのカーネルを見てみよう。でもカーネルのコードリーディングをここで始めると帰っちゃうので…

  • OSのスケジューラはカーネルモード契機（割り込み）ごとに次にどのプロセスを実行すべきかを決定。
  • 超高速で切り替えているので並列に動いてるかのように見える
  • load averageはタイマ割り込み(4ms)ごとに計算される
  • static inline void calc_load(unsigned long ticks) { ... }
  • count_active_tasks() -> ロードアベレージとして計算すべきかそうでないかを判断
    • unsigned long nr_active(void) { ... }

カーネルの実装を読んだ結果：ロードアベレージとは、タイマ割り込みごとにプロセスを全部なめて特定の状態のプロセスの数を数えている。数える対象はTASK_RUNNINGとTASK_UNINTERRUPTIBLE

  • TASK_INTERRUPTIBLE - 割り込み可能。長時間の待ち、完了時間が不確定な待ち、sleep、キーボードやNWのIO
  • TASK_UNINTERRUPTIBLE - 割り込み不可能。短時間の待ち、ディスクIO

負荷とは？→実行中・実行待ちのプロセス数。実行を継続したいけどできないプロセスの数。

Q. Apache と Nginx どっちが速い？

だめなA: 「雑な比較だとNginxのほうが速い」

A: 「全然違うものなので比較にならん」

例：（厳密にはどっちも「Apache→Nginxにする」が解ではない）

  • 大量の画像ファイルを配信するのにスループットが出ない : Nginxにする価値はある（かもしれない）
  • Railsが動いてるサーバーが重くてスループットが出ない : Webサーバー変えても変わらん

並行処理のアーキテクチャ

  • Apache : マルチプロセスモデル。forkを使う。子プロセス分しか処理をできない。メモリに対して生めるプロセスに限界。ただし子プロセス間に相互作用はないので子プロセスが詰まっても他に影響は少ない。
  • Nginx : イベント駆動モデル。select / epollを使う。メモリが少ないシステムでもたくさんのリクエストをさばける。しかしシングルスレッドなので止まったら影響が出る。

どっちが速いという話ではなく、ユーズケースに合わせた適材適所。

技術とは何か？

技術を知っているとは原理を知っていること。方法ではなく原理。 原理が第一、方法は第二。

この定義に基づくと、こう書いたらこう動く、このライブラリを使うとこんなことができる、のような帰納的知識は技術ではない。

どう知識を身につけたのか？

  1. Linuxカーネルのソースコードを読んだ。

きっかけ：Linuxカーネル本を積読→1pも読んでないのに改訂が出た→もったいないので読もう…

学生時代からスーパーハカーだったわけではなくシステムの会社に入るにあたって勉強し始めた。

読んでみたら：知りたいことがいっぱい書いてあった！

そもそもなんでプロセスの話を知りたかったのか？→システムが落ちまくっていた。数百台のサーバー、エンジニア数人、落ちまくる。それに対して対症療法を繰り返していた。やっていた対応に対して根拠がわからなかった。

障害が起こってユーザーさんに怒られる・夜中に叩き起こされる・同僚も疲弊…（「フリーザ様の圧倒的戦闘力を前に震えるベジータさんの気持ち」）

→たまたま読んだ「詳解Linuxカーネル」に答えが！これだ！

OSの動作原理を学ぶことが負荷の対策になるとは思わなかった。

ここから新卒社員への説教

基礎は大事だよ、本を読みましょう、コツコツ努力、本質的な技術ガー

ではなく。

『アイデアのつくり方』という本にあるアイデアが生まれる過程：資料集め -> 心の消化過程 -> { あえて心の外に置く -> 常にそれを考える } -> Eureka!

ひらめきは必然。偶然ではなく必然。そのもとになるデータ量・思考量があり、緊張が解かれ、リラックスしているときにひらめく。

「負荷分散困ったなあ」と毎日途方に暮れていたからこそ、カーネル本をチラ見して「これだ！」と思う瞬間が来た。目の前に立ちふさがる大きな壁が、実はひらめきを与える土台になっていた。

Appleのデザイン。どうやってあんなにかっこいいデザインを作ってるの？→Appleではデザイナーが神。デザイナーが作った設計図をエンジニアは必ず実現しなければならない。「エンジニアとデザイナーが手と手をとりあって…」ではない。「できるわけねえだろ、だけどやんなきゃクビになる」から出てくる。高いハードルがあって、そのハードルを越えようとして工夫をし始めてひらめきが起こって生まれる。エンジニアが集まって「こういうことできそう」ではない。

MAZDA RX-8の開発。MAZDAのフラグシップモデルとして開発された。開発したタイミングは経営的にかなりヤバい状態。フォードに資本を注入してもらってた状態。もともとはエンジニアが「俺が作りたいものを作る」だったが経営的にこんなこと言ってられない。RX-7の後継として作ろうとしたがRX-7は2人乗り。しかし経営的には4人乗りにしたかった。エンジニアの常識的には4人乗りの構造じゃ厳しい。→ドアを観音開きで開くようにしたのは構造上の問題を解決するため。＋ロータリーエンジンによってエンジンの位置を変えられる。→4人乗りのスポーツカーが誕生。家族持ちにすごく売れた。

無理難題を突きつけられてがんばった結果ひらめきが生まれて、という経緯。技術的に重要なブレークスルーが起きるときは外から力がかかる。エンジニアだけががんばってブレークスルーしたわけではない。

日常継続思考の法則。人は特別な力が働かない限り同じ思考を継続する（慣性）。

  • 技術者としてスキルが伸びたとき = 割と課題が目の前があった
  • どうしても作りたいものがあった
  • 負荷分散しなければいけなかった
  • 50人の組織を束ねなければいけなかった
  • →自分の慣性から脱出するにはきっかけが必要だった

技術を身につけるには：（純粋な好奇心でももちろん良いが…）作りたいもの、作らなければならないもの、解かなければならない問題を探す。漠然と技術を学ぶのではなく。問題を解決するために身につけるほうがずっと早く身につく

解の質 x イシュー度の両方を満たすもの = バリューのある仕事

技術顧問をしていると「他のところはいい感じの開発をしてるのに我々にはできない、モダンな開発がしたいです」っていうのがよく来る。しかし優先度付けを間違えている、組織がマネージされてない、みたいな問題のほうが多い。ほんとにやらなきゃいけないのはダメな上司を取り替えるとかレポートラインを整備するとかそういうことのほうが多い。

技術は人の役にたってはじめて価値を帯びる。技術そのものに価値があるわけではない。価値を届けるためのハードルを越えようとするたびにスキルが上がる。

プログラミングを覚えようと思ってもなかなかダメ。＊＊を作るために覚える、だとうまくいく。Rubyの入門書を手に取ると1p目からオブジェクト指向が出てくる、C言語の本を手にとってみたらわけわからん、続いてLispの本を手に取ったら括弧のお化け！で最後にPerlで掲示板を作るところからPerlが一番はまった。中には純粋な興味で覚えられる人もいるけど例外。

世の中の石ころ

「〜すべき、〜しなければならない、この本を読め」→大概は発言者がドヤ顏するために発せられた言葉。あなたのことを真剣に考えているわけではない。あまり参考にしないほうがいい。

自分自身の問題、課題に向き合おう。

質疑応答

Q. ストレスによって成長する、というのは非常に納得するところがある。 -> 日本国内のエンジニアの賃金について。すごいものを生み出すにはストレスを与える必要がある、生みの苦しみを味わせ続ける必要があるという側面がある一方、ペイがあっていないのではないか？Google/Appleとかはペイもいいけど…

  1. 「新卒向けには答えにくい質問ですねw」

話したいことは2つあって、

  1. Web開発の賃金はすごく上がってる。買い叩かれる仕事のように見られがちだけど上がり続けている。ソフトウェア開発の仕事はペイが悪いとは思わない。別の分野はどうかはわからないが心配は必要ないと思う。
  2. もう１つ別の話としてモチベーションと金銭的報酬の関係として、もらってるお金が少ないほうが仕事の達成感が大きい。もらってるお金が少ないとなぜ仕事するかを必死に考えてこの仕事が好きだからだ、という結論を導く（心理学的な事実、実験がある）。内発的動機vs外発的動機。外部から動機を与えられると品質が下がる。目標を高く設定しないといけないがモチベーションを感じてもらわなければならない、というのはマネジメント的に難しいところ。

Q. 就職するまでプログラミングはしてなかったという話ですがコンピュータへの興味は？

  1. 家庭環境からコンピュータに触る機会はあって、興味はあった。

Q. 今趣味でコード書いてますか？

  1. 「家帰ったらプレステの電源入れてます」

根性を出すことよりも自分のペースで長く続けることのほうが大事。

Q. ずっとやっていくために必要なことは？

  1. コミュニティとつながっていくこと。エンジニア仲間を作る。仲間は会社の外にもいる。そういうの見てるとみんな楽しそうにしてる→自分もやってみよう、みたいになる。

自分の作りたいものと会社の作りたいものが一致しない -> ソフトウェアだったらオープンソースでその願いを叶える。

Q. 専門分野を一般にもっていったらうまくいくみたいなイノベーションの事例をご存知ですか

  1. 1990年代はネットでできることがほとんどできていない。それができるようにすることがビジネスになった。一通り揃うようになるとWeb2.0と言われて(2005-2010)ソフトウェアで解決できることはソフトウェアで解決しよう、という既存のビジネスとは関係ないけどネット上だけで完結するビジネスが増えた。しかし生活の問題は何も解決しなかった。世の中で起こっていることはインターネットと既存のビジネスをクロスさせてよくする、という原点回帰。わかりやすいのがUberとかAirbnbとか。

Q. 問題を見つけるための方法とかは？

  1. 問題を持っている人からフィードバックをもらう。困っている人を観察する。ユーザーを観察する。

勘違いしてはいけないのはユーザーは自分の問題を正しく理解しているとは限らない。観察対象がいないところで仮説を立てると大抵外す。自分の問題を解決するようなソフトを作るのがよいのでは。全然関心のない問題を解くのは苦手。

（ここまで新人によるQ&A）

Q. 技術負債をどのようにとらえるか

  1. リファクタリング・コードレビューをプロセスの中に組み込んでしまう。見える化はやろうとすると難しい。日常の中で自然に修復されていく。

Q. 技術負債にもメリットはあってスピード感だと思うのだが、そういう現場があったらどうやって叱りつけるか

  1. 叱りつけることはしないですw

事業が伸びてるときは負債を溜め込むことはよい。一方、技術的負債を返したいというときにこの先に事業が伸びなさそうなら意味がない。

クソコードを書き直すことはある。しかしそのコードにも理由はあって、事業が伸びていくフェーズには許されることはある。なんとなく負債が溜まっててやだから、という理由で技術的負債の解消は行わない。

Q. 失敗するようなプロジェクトを止める判断・事業の見極めのコツは？

  1. 「これをズバッと答えられたら本一冊書いたらそれだけで生きていけそうw」…ないですね。

どうやってもうまくいかないプロジェクトを放置しているのはマネジメントが悪いのでは…。その人たちの責任を追及する。マネジメント側の立場なのでそういうプロジェクトを出さないようには気をつけているが…

事業を数値で進捗管理してもうまくいかない、問題を解決している実感が重要、ニーズをとらえている実感が重要。

数値目標を立てると数字を伸ばす手法はいろいろあってその手法に走ってしまう。広告の数値をいじるために誤クリックを誘発するようなことはあった。

Q. 最近Immutable Infrastructureの講演や記事が多いがそれに至った問題意識は？

  1. 対象の会社がクラウド上でビジネスを行っている会社が多く、try and errorのループを早くしよう、と思ったらこれだった。

特にインフラ屋というわけではない。たまたまそういう文脈での話をお願いされることが多いだけ。

今気にしている問題はどちらかというとお客さんによって決まることが多い。

Q. 技術の人たちと話をできるよう勉強しているが、営業と技術を一つのチームにするためにはどうしたらいいか？実現可能なのか？

  1. 実現できます。

商談にエンジニアが連れて行かれすぎて開発する時間がない…というのはマネジメントが悪い。一緒にしたことによるデメリットはどうしても出てくるのでマネジメントが適切に介入する必要がある。チーム構造を一つにしたときに重要なのはミッションを明確にすること。それはマネジメントの仕事。単純にone locationにすればいいというわけではない。介入をさぼればありきたりな大企業になってしまうが…

Q. チームとしてのモチベーションの上げ方。あまりうまくいってないプロジェクトで会社としてやると決めた場合。チームリーダーはモチベーションを上げなければいけないが…

  1. ゴールが適切に設定するとか、ダメな中から小さな目標を探すとか、小さい単位でコミュニケーションをとるとかしないと難しい。

Q. 技術戦略について。技術の方向性を決めることについて。今までは問題解決のためにはなんでもやるとやってたら分散してしまった。技術の教育・蓄積の目標をどうしたらいいか？

  1. それって根本的に技術をやってる会社かどうかによって決まるのでは？技術そのものによって競争力を持っている会社だったら意味を持つけれど（例：Googleだったら検索の技術・クラウド開発）、「技術を売っている会社」にいたことがないのでそういうところにいると技術は二の次になる。

新しいプロジェクトに対してレビュー会をやったりして技術の分散を防ぐということはするけれど、それは「悪いことが起きないようにするため」という問題から起こるもので、一生懸命戦略的なディスカッションをしてするものではない。

Q. マネジメントを学ぶためには？

  1. 部下を作る、後輩ができる、しかないのでは。否が応でも学ばざるを得なくなる。

Q. マネジメントをする楽しさはどうやってつく？

  1. マネジメントは好きではないけど得意。人間好きなことを仕事にしたいと思うけれど得意なことと好きなことを混同しがち。得意なことを見つけるには：自分では大したことないと思っているけど周りがすごく感謝されることをやればいい。モチベーションは周りの人に依存している。

「マネジメントって揉め事の解決だからそれが好きってことは相当性格悪いですよw」

Q. 関連して、「マネジメントっぽいことやってみない？」と言われることがあるが

  1. 自分はやらざるを得ない状況になった。がんばって技術がクロスするところを探した。

関連し、GREEにいたときに優秀だと思った人の話。すごくコードが書けるのだけど前の会社でオフショア開発のマネジメントやってた。その人は1から10まで文脈をわかってくれた。本人が嫌だったけどマネジメントをやったということに起因している。でも難しい。仕事の幅は広がるけど、上司として押し付けると辞められてしまう。

Q. 対症療法に明け暮れるのはプロジェクトも同様だと思っていて、やってる本人たちは視野狭窄に陥って対症療法で満足してしまっている。どうやって対処した？

  1. チームの中にビジネスの責任を持つ人・コードの責任を持つ人を明確にした。役割的に技術的問題に視野狭窄になるのは仕方ないことで、そうでない人を作った。

セールスとエンジニアの真ん中の人がいないケースが多い。PMに属人的になりやすくて失敗すると崩壊する。

エンジニアを紹介してください、という話をよく受けるけど、それエンジニアじゃなくてPMじゃね？というのは多い。

Q. 技術者からマネジメントにキャリアパスを変えた理由は？

  1. 選べなかった。人を連れてこないと解決できない、みたいになって、マネージせざるを得なくなった。プロジェクトの人がマネジメントができなかった（せっかく連れてきたバイトにLANケーブル作らせてた）。そのあとも続けてたらキャリアパスがついてきた。いきなりマネジメントをやれと言われたわけでなかったのは幸運で、必要に応じてシフトしたというのがよかった。 マネジメントしてると技術の話についていけなくてプライドが傷つくこととか会社に最適化しすぎてしまっているのではというような悩みがつきない。人が増えると全てをコントロールできない。全てを知ることをあきらめなければならない。なんで全てを知りたいか？→エゴ。自分の安心感はチームのためによいことでは必ずしもない。エゴを捨てなければならない。人に言われてできることではない。

Q. IT版SHIROBAKO期待しています

（一同爆笑）

（筆者注：ゼノブレイドクロスの話が出たのは多分ここのタイミングですが筆者がよくわからなかったため聞き逃した）

*1:去年の講演の時点とかで割と明らかだしQiitaが本名名義からsylph01さんになった時点でも割と明らか