献本をいただいてからしばらく経ってしまいましたが、読了しました。

https://www.amazon.co.jp/dp/B08GSQ4BL3

広木大地さんが「読むインターンシップ」と書いてて、とても納得したので、VOYAGEさんにインターンしてる気分で読みました。


ピクシブの2019年度の新卒研修で発表した内容です。

文脈としては、新卒全員(ビジネス職も含む)に社内の色んな職種について話すパートでエンジニアの職種について話してくれとのことだったのですが、「今こういう仕事があります」だと深みがないので、「なぜこういう仕事があるのか」を重点的に話すことにしました。

エンジニアリングとは

エンジニアリング:課題解決のためにシステムを作ること

システム:複数の要素が相互作用しながら動く仕組みのこと

ソフトウェアエンジニアリング:課題解決のためにソフトウェアというシステムを作ること

ソフトウェアも、複数の要素が相互作用しながら動く仕組みですね。

Q: ソフトウェアではない「システム」は何がありますか?

例えば、「風が吹けば桶屋が儲かる」。

人と人との関係も、システムといえます。

ソフトウェアエンジニアリングの歴史

元々は、こういう機械を作るのがエンジニアリングでした。「エンジン」ですね。


# 2019/03/16 Week 1 Lesson 1: Introduction to Clouds

## 1.1: Why Clouds?

Operation cost, saves development time.

## 1.2: What is a Cloud?

Cloud = Lots of storage + compute cycles nearby

## 1.3: Introduction to Clouds: History

## 1.4: Introduction to Clouds: What’s New in Today’s Clouds

4 distinctive features of today’s clouds:

  • Massive scale
  • On-demand access
  • Data-intensive Nature
  • New Cloud Programming Paradigm


下のようなお話をピクシブ株式会社で講演して、メンバーとカジュアルにディスカッションしていただける方を探しています。

依頼内容

「過去20年のトレンドを目を細めて見てると次の10年がなんとなくわかる」というテーマで、講演者さんの視点からお話をしていただきます。

例えば「情報通信技術」とか「評価経済社会」というふうにある程度対象を絞ってもらうことを考えています。

過去10年〜20年ぐらいのトレンドをかいつまんで紹介していただき、さらに今後の10年で起こりそうなことを話してください。

「現在」の話にフォーカスしすぎることなく、過去と未来を俯瞰してください。

発表内容は他の場所で自由に使いまわしていただいて構いません。

参加者は(基本的に)弊社メンバーのみで、10〜30人程度を想定しています。

目的

目的は、弊社メンバーの一人一人が自分の頭でこのテーマについて考えるようになることです。

(ですので、「予想の正しさ」はあまり重要視していません)

さらには、日本全体でたくさんの人が10年後の世界を予想するようになれば、もっと良い社会になると思っています。

時間と報酬

平日(できれば金曜)の19時ぐらいから質疑応答多めで60分ぐらい+懇親会と考えています。

報酬は5万円ほどで考えていますが、相談可能です。

お断り

弊社メンバーからの紹介を優先させていただきます。

ご興味のある方はTwitterで@edvakfにDMください。


「仕事はスピードがすべて」みたいな考え方を見て、思うところがあったので書いてみました。

結論から

  • 「速さ」のためには「正確さ」も必要
  • 速さだけが重要な仕事は機械化されていくはず
  • 「正確さ」を磨いていこう

スタートアップの成功の要因の8割は市場選び

という考え方を聞いたことがあるでしょうか?

どれだけ速く物を作っても、市場選びの時点で間違ってたら、残念ながら成功には結びつかないのですよね。

逆に市場選びさえ良ければ、他のことはまあなんとかなるみたいです。

「手の速い優秀なエンジニア」vs「残念な設計」

Supership取締役CTOの山崎さん曰く、

手の速い優秀なエンジニアをせっかく集めても、設計が残念だと設計が残念なシステムが高速に実装されるだけなのよね。当たり前ですが。
https://twitter.com/yamaz/status/1090294549744738304

設計の正確さってとても大事、というお話です。

「速さ」を支える「正確さ」

スピードを上げられるための設計というものがあります。

図の左側の「正確さが価値」の部分は「スタートアップの成功の要因の8割は市場選び」みたいなやつです。

図の下側の「上手く設計しないと並列化できない」の部分についても、正確さが価値な部分です。

  • 仮説検証をどう並列化するか?(ユーザーインタビューする人、データマイニングする人、ABテストを回す人、みたいな)
  • 並列化できるシステム境界をどう作るか?(適切にシステム分解されていれば、それぞれのシステムで考えることが減ってスピードが出せる)
  • 並列化できる仕事とできない仕事をどう分解するか?(例えばABテストの仕組みを作るのは並列化しにくいが、その上で動くABテストの一つ一つは並列化しやすい)

などなど。「設計」(プログラミングに限らず業務設計や組織設計やビジネス設計も)が正確であれば、結果的に速さに繋がることっていっぱいあるのですよね。

「速さ」←→「正確さ」という軸

とにかく高速にPDCAすることに価値のある領域と、より正確さが求められる領域というのがあります。


# 2019/02/17

## 1.1: What is Cluster Analysis

Cluster: a set of data objects which are similar (or related) to one another within the same group, and dissimilar (or unrelated) to the objects in other groups.

Cluster analysis, clustering, data segmentation: partition points into a set of groups which are as similar as possible

Cluster analysis is unsupervised learning

## 1.2: Applications of Cluster Analysis

  • A key intermediate step for other data mining tasks (summarize data for classification, pattern discovery, etc., or detect outliers)
  • Data summarization, compression and reduction (vector quantization)
  • Collaborative filtering, recommendation systems, or customer segmentation
  • Dynamic trend detection (clustering stream data)
  • Multimedia data analysis, biological data analysis and social network analysis

## 1.3: Requirements and Challenges


VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。

「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪

妥協ない挑戦

元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか?」というのをキーワードにやってました。

解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。

そんなこと言っても普段は妥協ばっかりですって?いえいえ、相反する選択肢の中で、何を考えて「現状ベスト」を選んだかも妥協ない挑戦と考えています。

ただ、「何に対して妥協ない挑戦をすればいいのか?」という疑問の声が多かったので、次のような言語化をしてみました。

4つの挑戦

この図の説明はこちら

①チームの課題を最短経路で解決できる

毎週仮説検証できるチームを作ることには、とてつもない価値があります。

チームをコンパクトに保てる力(複数の環境を使いこなせるとか)や、最短経路で課題解決できる判断力や、「顧客が本当に必要だったもの」を作ることができる力や、将来に渡って課題解決のスピードを保てる力などが求められます。

②チームの手作業をフレームワーク化して減らし続けられる

世の中のテクノロジーは、人間の手作業を減らす方向に進んでいます。資本主義最高ですね。

そういう「フレームワーク」をうまく使ってチームの仕事の効率を上げて、チームが本質的な課題解決に注力できるようにすることには大きな価値があります。

品質やセキュリティ等を「意識しなくても」高められるように環境整備していくのも、フレームワーク化の一部です。

(ここでいうフレームワークとは、ライブラリ、ツール、ミドルウェア、SaaS等、幅広い意味で使っています)

③まだフレームワークが整っていない分野を切り開く突破力がある

まだ会社にはノウハウが少ないけど、世の中的には「めっちゃ頑張れば手が届く」ところまで来ている技術を、すぐに自分の物にして動くものを作っちゃう力です。

こういう人のおかげで会社のオプションが広がり、「この分野を攻めよう」というときに真っ先に声がかかることになるでしょう。

④技術、組織、ビジネス等の状況から長期的視野でバランスの良い判断ができる

ビジネスの視点で技術の判断をするとか、技術の視点で組織の判断をするとか、社内外の状況を長期的に把握して設計に落とし込めるような力です。この役割を務められれば、どんなスタートアップの創業CTOにもなれるでしょう。

ちなみにこれはCTOとしての自分がやってる仕事です。

最も大事なこと

以上4つのうち2つぐらいで価値発揮することを目指してくれるといいかなと思います。

しかし、テクノロジーはどんどん進化し続けています。今日ある仕事は、3年後にはフレームワーク化されて無くなってる可能性もあります。

現状に満足せず常に役割を変化させ続けることができるエンジニアが「良いエンジニア」なのは間違いありません。

やっぱり妥協ない挑戦に戻ってきちゃいましたね。


いくら議論しても平行線で全然噛み合わないときは、もしかしたらお互いの前提条件がずれているからなのかもしれません。まずは落ち着いて前提条件を列挙するところから始めてみてはいかがでしょうか?

https://unsplash.com/photos/3V8xo5Gbusk

何か将来の方針を考える時、人は知らず知らずのうちに自分で前提条件を定義しちゃっていることがあります。自分と相手の前提条件が揃っていないと、堂々巡りに陥ってしまいます。

ビジネスにおいては、もちろん選択肢が無限にあるなんてことはありえませんね。予算、メンバー、自社のブランド、既存システム、採用計画、パートナー企業、法律などなど。前提条件は実は大量にあるものなのです。

他にもあります。人は身近なことを考えるのは得意ですが、遠い将来のことを考えるのは苦手です。世の中の長期トレンド、その中で自社はどのポジションを取っていくか、会社の将来のプロダクトビジョンなど、現在だけでなく将来のほうからの前提条件を置いてみるのも大事です。

長期トレンドというのは恐ろしいものです。地理的な面では少子化や都市への人口集中のトレンドなど。テクノロジー面では、一貫して人間がやる仕事を効率化していく資本主義的に合理的な方向に世の中は向かっています。

長期トレンドにはGoogleや中国でさえも逆らえません。

このようにして、現在の前提条件や未来の前提条件を並べてみると、取れる選択肢は実はそんなに多くないということに気付き、お互いに納得する妥当な選択に落ち着くのです。

合わせて読みたい


CTOというのは会社全体のシステムを設計するお仕事なのですが、そんな大きな設計にバグがあったりすると、会社の未来を数年単位で苦しめるような、大損害になってしまいます。

そんな大きな話が、自転車置き場の議論に陥ったせいで十分に議論されないまま決まってしまったりしたらと思うと、心底ゾッとします。

自転車置き場の議論(bikeshedding):例えば原発の開発計画について議論するべき場で、自転車置き場の素材をどうするかのような「議論しやすいけれど本質的ではないこと」に多くの時間を費やしてしまうこと

本質的ではない議論に時間が費やされ、本質的な課題は解決されないまま「じゃあ続きは来週で」なんてことになってしまうフラストレーションは、誰しも経験があると思います。

意識していること

そんなわけで意識しているのが、次の図です。

https://www.liquidweb.com/kb/what-is-a-progressive-jpeg/

時間は有限です。左側からスタートしても、絶対に右側までは到達しません。

  • 上:目につくものからいきなり詳細な話をしてしまうものの、本質的なことに到達するまでに時間オーバーになる
  • 下:ぼんやりでも良いので全体像から徐々に形を描いていって、細部は決められなくても気にしない

冒頭の設計の例においては、10年後絶対に起こっているであろう未来を列挙した後に、それを元に3年先はまあこんな感じだよねって話をして、だいたい合意が取れればOKとします。

そこさえ握っておけば、あとの細部はチームに任せてしまっても、まあなんとかなるもんです。

応用例

考えてみると、この図を意識したほうが良いことって、けっこういっぱいありますね。

マネジメント

  • 上:やたら細かい指示を出す割にどこに向かってるか不明
  • 下:大きな方向性を示して細部は任せる

セキュリティ

  • 上:目についたところを片っ端から潰していくが、いつまで経っても肝心なところは防げない
  • 下:全体に効くことから徐々にやっていく

チューニング

  • 上:片っ端から(略)
  • 下:全体像を把握

他にも色々あると思います。ぜひこの画像を会議室の壁に貼っておきたいですね。

合わせて読みたい


「エンジニアリング組織論への招待」という本がありますが、この「エンジニアリング組織」とは「技術を使って課題解決をする組織」のことです。

決して「エンジニア」と「エンジニア以外」で組織論を分けて語るべきではありません。

サービス開発技術の進化

10〜20年前は、30人とか50人とかのチームで一つのウェブサービスを開発していました。大規模開発という言葉がぴったり当てはまる時代でした。

そういう開発スタイルだと、課題解決のためにはまず課題を定義し、エンジニアチームに依頼して、開発されて完成品が出てくる、というやり方でやらざるを得ませんでした。

その反動が2001年のアジャイルソフトウェア開発宣言です。アジャイル開発では、チームで必ず毎週(毎イテレーション)仮説検証をすることを義務としています。

毎週仮説検証をするためには、チーム間のやりとりなどは無駄でしかありません。自分のチームで1日でできることでも、隣のチームに頼むだけで1週間待たされてしまいます。チームの人数をどんどん小さくして、1言えば10伝わるチームで最速で課題解決に向かうほうがよっぽど仮説検証サイクルが速く回ります。

今では3人のスタートアップが毎週仮説検証を繰り返すことができるぐらいにウェブサービス開発のフレームワークやツールが充実しています。

課題解決できるチーム

そんな現代のソフトウェア開発においては、「エンジニアを何人揃えるか」などよりも、「本質的な課題解決ができる組織作り」のほうがよっぽど大事なことです。

例えばCSとエンジニアを別々のチームにしてしまうと、CSの課題はエンジニアからは他人ごとになってしまい、なかなか解決されず、CSの手間がどんどん増えることになります。そうなるとCSを増やすことになり、より一層他人ごとになっていきます。

では少人数チームを作れば良いかというと、それだけではまだ不十分です。単に同じチームになっただけで、一緒に課題解決をするチームだと思っていなければ意味がありません。CSがエンジニアリングを覚えてエンジニアがCSの手伝いをしたほうが課題解決に繋がることもあります。

課題解決に向かうチームに「あちらさん」の関係を作ってはいけないのです。

組織全体で最も本質的な課題解決をする

そもそも今はGoogle Apps Scriptなど、(いままでの)エンジニアからすればオモチャみたいなツールが出てきていて、CSの課題解決はそういうものでも十分だったりするかもしれません。もっというなら、遅かれ早かれGUIでポチポチしながらウェブサービスを作る時代も来るはずです。

そんな時代にエンジニアだけがコードを書いて、エンジニア以外はコードを書かないなどという考え方は通用しません。全員でこのテクノロジー時代を進んでいるのです。

会社というのは、テクノロジーなどの社会基盤の上にサービスを作り、全員で市場の課題を解決するのがミッションの組織です。

会社の「形」の概念図

この図のどこにどういうチームを作れば最速で課題が解決できるか、それこそが「エンジニアリング組織」の設計なのです。

「エンジニア」と「エンジニア以外」に分けて「エンジニア」だけの組織を設計することはもう時代遅れになっています。

合わせて読みたい

Atsushi Takayama

2020年からNewsPicksでCTOをしています。その前はピクシブでCTOをしていました。Courseraでイリノイ大学の大学院をやっています。

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store