Slide 1

Slide 1 text

コー ドを書かない エンジニアリング feat. のステマ Factorio

Slide 2

Slide 2 text

最近取り組んでいる課題 web サー ビスのテクノロジー よりの側面全体のケア 「 プロダクトの技術的品質に責任を持つ」 「 開発プロセスの継続的改善に責任を持つ」 「 ナレッジの展開及びメンバ育成、 その他」

Slide 3

Slide 3 text

だが、 コー ド書いていない感 GitHubEnterprise の緑色(Contribution) が 薄くなってきている図

Slide 4

Slide 4 text

コー ド書かずに何やっているのか MTG して人とだべって概ね一日が終わる リリー スや障害で燃えると追加稼働

Slide 5

Slide 5 text

主に MTG したりだべってる事柄 設計レビュー 実装レビュー 設計の指針策定 レビュー 基準策定 リリー ス基準策定 リリー ス可否判定 設計破綻・ 障害対応の状況把握・ 対応方針ぎめ

Slide 6

Slide 6 text

ところで、(WEB サー ビスにおける) エンジニアリングとは ( 私見) 何らかの課題を、 仕組みを構築することで解決すること 例えば Not: 面倒な作業を... ひたすら手作業で頑張る Better: 面倒な作業を... 自動で片付くようにする Not: 保守運用を... 悪い意味でファジー に適当にこなす Better: 保守運用を... インシデントのpush 通知, バグ・ 抜け漏れの自動チェック etc. で確実に回るようにする

Slide 7

Slide 7 text

Factorio とある惑星から脱出する宇宙船を組み立てるゲー ム 鉱石の採掘から宇宙船までの膨大な工程 手動でも理論上可だが、 自動化された工作ラインが必要 ラインが詰まる、 電力が足りない、 天然資源が枯渇す る、 輸送力が限界に達する、 異星人が攻撃してくる... 等

Slide 8

Slide 8 text

プログラミングのもたらすもの プログラムのやっていることは( 理論上) 手動でも可能 ( 人間はチュー リング完全) だが 自動化しないとやってられん ( 時間, 労力, ストレス) ものによっては計算量的に非現実的 そして、 自動化プロセスの構築・ 運用における諸問題を 解決することがエンジニアリング冥利でもある ( 私見) Factorio とよく似ている

Slide 9

Slide 9 text

Factorio における自動化の例 鉄鉱石を電気採掘機で採掘しベルトコンベアに載せる 下流の組立機に投入 得られた歯車をベルトコンベアに載せて下流の組立機 に投入し ( 以下略 発生する問題の例 鉱石枯渇時に随時採掘ラインを増やす必要がある 環境汚染するため異星人に攻撃される原因になる ラインの配置を工夫しておかないと搬送ラインの拡張 が困難になる 自動化プロセスの問題を片付ける プロセス自体どうにかできないか

Slide 10

Slide 10 text

Factorio における自動化の 問題解決アプロー チ 1. 自力対応する : 可能だがプレイヤー がボトルネックになる 2. 問題解決のためのロボットを製造する : ロボで出来ることの限界が 3. マルチプレイで捌く : 互いに足引っ張らずに協力できる人がいれば...

Slide 11

Slide 11 text

プログラミング における自動化の 問題の解決アプロー チ これって、 プログラミングにおける... 1. 自力対応する : ひたすら手を動かしてコー ド書く・ バグ対応する 2. 問題解決のためのロボットを製造する : コンパイラ, Build Bot/CI, 機械学習, AI 研究 などなど... 3. マルチプレイで捌く : エンジニアの育成、 組織づくり、 快適に仕事が回って くれるようその他雑用 このマルチプレイ部分を頑張るのが今やっていること

Slide 12

Slide 12 text

再帰的エンジニアリング エンジニアリング: 何らかの課題を、 仕組みを構築することで解決すること ( 私見) エンジニアリングする上で発生する課題の 解決の仕組み作りもまたエンジニアリングでは? 話をする相手が CPU でなく媒体がテキストエディタでも ないが、 エンジニアを調停する仕立てをすることも またエンジニアリングなのではなかろうか

Slide 13

Slide 13 text

( 再掲) MTG したりだべってる事柄 設計レビュー 実装レビュー 設計の指針策定 レビュー 基準策定 リリー ス基準策定 リリー ス可否判定 設計破綻・ 障害対応の状況把握・ 対応方針ぎめ エンジニアリング上の課題の解決をしようとしている

Slide 14

Slide 14 text

FAQ: 自分で設計したほうが/ コー ド書いたほうが早いのでは? 個別の事案についてはそう感じうる局面もある。 だがしかし...

Slide 15

Slide 15 text

スケー ラビリティ サー バー1 台前提のシステムを作らないのと同様に... ステー クホルダー や案件需要に対しスケー ルするか ある日事故にあって死んだ時にプロジェクトが止まら ないか (c.f. バス係数) 有給を取りたい時に取れるか また、 色々 な種類のサー バー/NW 機器があるように... 不得意 or やりたくない分野を( 好き好んで) やってくれ る存在がいるか, やりたいことが変わった時に代わっ てくれる存在がいるか やらかした時に検知・ リカバってくれる存在がいるか といったことを考えると、 組織の意味がある

Slide 16

Slide 16 text

いろいろなエンジニア 実装力で需要に片っ端から対応するスター エンジニア Bot/AI に課題を解かせるサイエンティスト エンジニア サー ビス仕様を改善するグロー スハッカー エンジニア エンジニアリングを調停するアー キテクト エンジニア ( 他にもあると思う ) どの種類も世の中には必要なエンジニアではなかろうか それぞれ異なるスペシャリティ 世の中に何らかの価値貢献する点さえ押さえていれば、 おのおのの好きなスタイルで良いのでは

Slide 17

Slide 17 text

未完 この果てしないエンジニアリング坂を のぼりはじめたばかりなので、 引き続き精進したい