CircleCI新入社員 ここに悩んだ

Transcript

1. 1 CircleCI 新⼊社員、 ここに悩んだ 後に発表される⽅のハードルを下げるために ⾈⽊ 将彦 (@mfunaki) Developer Advocate, CircleCI
2. 2 ⾃⼰紹介 (@mfunaki) • 2020年6⽉15⽇にCircleCIにJoin Developer Advocate(開発者応援⼈)として 活躍準備中 • 元々は⾃然⾔語処理が専⾨ (上はメインフレーム上のマクロアセンブラ、 下は組み込みボード上のT-EngineでC++) • 2000年に Dejima社(後のSiri) に転職 →2004年にSybase(DB,モバイル)により買収 →2010年にSAP(ERP)により買収 • 2018年にMicrosoftに転職 Digital Advisorとして新しい技術や開発⼿法、 ビジネスモデルなどをコンサル 製 品 プ ロ ト
3. 3 時間とは是、就く銭⾦、効率とは是、就く⽣命なり
4. 4 ⼊社前 (1/3) • New Normal な採⽤プロセス、⾯接は Zoom のみ (⽇本 x 3, US x 1) • 技術担当の⽅との⾯接前に、課題を提出し、提出した内容に沿って質疑応答 ◦ Docker x 4 (イメージ作成、既存イメージの問題解決) ◦ CircleCI x 2 (ウェブサービスを任意の⾔語で実装、テスト、デプロイ)
5. 5 ⼊社前 (2/3) ー ここに悩んだ • New Normal な採⽤プロセスだったため、⾯接は Zoom のみ (⽇本 x 3, US x 1) • 技術担当の⽅との⾯接前に、課題を提出し、提出した内容に沿って質疑応答 ◦ Docker x 4 (イメージ作成、既存イメージの 問題解決) → Docker⾃体は「バージョン違いで動作 しない」問題回避のため常⽤していた →製品を Dockerイメージ でリリースする のが当たり前な時代に⽴ち会えた幸運 ◦ CircleCI x 2 (ウェブサービスを任意の⾔語で実装、テスト、デプロイ) Hello Worldチュートリアルがイケてない - run: echo ‘Hello World’ # の目的・意味の説明が不十分 (Hello Worldが出力されることより、終了ステータスが重要) - AndroidとMacOSの例はそもそもHello Worldになっていない →config.ymlに慣れ親しんでもらうのがゴールなのでしょう
6. 7 ⼊社前 (3/3) • New Normal な採⽤プロセスだったため、⾯接は Zoom のみ (⽇本 x 3, US x 1) • 技術担当の⽅との⾯接前に、課題を提出し、提出した内容に沿って質疑応答 ◦ Docker x 4 (イメージ作成、既存イメージの問題解決) ◦ CircleCI x 2 (ウェブサービスを任意の⾔語で実装、テスト、デプロイ) →最初は(当時Microsoft社員だったので)、TypeScript/Node.jsで 簡単なサービス書いて、JESTでテスト、(無料の)herokuにデプロイ →なんか分からんけど動かないのでJavaScriptで書き直す→動いた！ CircleCIのコンフィグ(config.yml)は言語ごとに文法があるかと勘違い(「言語ガイド」ページあるし) docker: - image: circleci/openjdk11.0.2-jdk-stretch - image: circleci/postgres: 12-alpine ⼤事なのはココだけ
7. 8 開発の現場で常に効率、品質を追い求めていたこともあり、 (製造業、とりわけ自動車会社との仕事が多かった) 製品リリースを管理する立場で苦しんだ経験もあり、 Azure DevOpsをコンサルしていた経験もあってか、めでたく入社
8. 9 そして、⼊社 (1/2) 英語版より日本語版にある ミッションステートメントが誇らしい。
9. 10 そして、⼊社 (2/2) • (ウェブ上の)チュートリアル、イケてないな とずっと思っていた • エンジニアリングマネージャーとの1on1の 際に「チュートリアル整備させてください！」 と直訴 • Koan(公案)あるよ →禅的で良かった！ • みんな Koan やろうぜ！ • とはいえ、瞳を閉じて、これまでのエンジニア ⼈⽣で出会ってきたお客さまに CircleCI の価値を 今あるものでどこまでお届けできるのだろうか？
10. 11 これからやっていきたい事 ー 全ての開発者のために なぜ企業はERPにSAPを導入するのか？ →プロ経営者が道具の使い方・データの 見方を学習しなくても、即時実力発揮可能 「私の周り」を最適化するのではなく、 「全体」を最適化する事で、 エンジニアはやりたいプロジェクトに 意欲的にアサイン・立候補可能 JRのみどりの窓口の駅員さんが 物凄い勢いで端末操作しています ソフトウェア開発もそんなやり方ですか？ config.yml, API呼び出し等、 操作でなく、コードを共有＋繰り返し処理は 子供の漢字練習のような繰り返しではなく コピペ＋修正で賢く解決すべき そもそも我が社が顧客に価値提供できる ようになるためには何が必要？ どう準備・整備していけばいい？ なぜ今のままでは生き残れないのか？ （「日本はホワイトカラーの生産性は低いが 製造現場の生産性は高い」は 既に20年前の昔話) Dockerイメージの当てはめではなく、 開発・ビルド・デプロイ環境の 構築→共有→維持管理 顧客ニーズ寄り添うデプロイが求められる 時代、単数／複数プロジェクトにどう アサインすると効率的かではなく、 コンテクスト切り替えながらの仕事が前提 既 存 の 製 品 ・ サ ! ビ ス 未 来 の 製 品 ・ サ ! ビ ス 開発・ビルド・リリースを自動化済み 開発・ビルド・リリースが人依存
11. 12 Q&A