1 縁の下をどう支えるか 〜 の伝え方 CircleCI Developer Advocate 舟木 将彦 (@mfunaki) #JTF2021w_C

自己紹介 HIC Researcher Dejima Developer Sybase Eng Mgr SAP Design Thinker 転 Microsoft Digital Adviser 買 転 買 CircleCI Developer Advocate 転

最初に質問です

ソフトウェアエンジニアの生産性を高めるのは何？ 速いCPU、リッチなメモリ、広い画面？ 肩こりや腰痛と無縁になれる椅子？

どれも正しいと思います。 けど、それって「もの」ですよね。

日本はホワイトカラーの生産性は低いが、 製造業(ものづくり)の生産性は他国より優れている → 過去(2000年)までの常識 ただし、日本の生産性が下がっていたわけではない →ほぼ横ばい「何も変わってこなかった」 日本以外の各国は人力ではなく、デジタル・ ITを 活用することで生産性を高めてきた (ただし、アイルランドのように低税率の法人税で 多国籍企業を誘致し、ものづくりは他国で、売り上げは 自国でという現実には留意が必要 ) 6 日本の ものづくり生産性 出典: 日本生産性本部「労働生産性の国際比較 2019」 労働生産性水準 : 就業者1人あたり付加価値

作っているのは 「もの」じゃないんだ

質問２

この２枚の「一日乗車券」、何が違う？ その日の終電まで有効 使い始めから24時間有効 人手ゆえの制約

10 きっぷなら ● 一日の定義が変えられる ● 終電まで有効は変えないまま、 使い始め時刻により価格を変える デジタル情報＋ 自動化で タイムカードなら ● ８時間労働が非連続でもよい ● 働いた時刻(人手の需給)に応じて 時給を変える これまで「手動」でやってきたことが、「自動化」可能に 無理だったアイデアを 実装して「変化」できる

No content

人手でやってません？ ビルド、テスト、リリース、デプロイ

13 継続するビジネスと開発・運用の継続をつなげる プラン コード ビルド テスト リリース デプ ロイ 運用 監視 継続的インテグレーション (CI) 継続的 デプロイ (CD) 自動化できない 完全自動化できない プルリクエスト(コードの追加・修正 )起点で 自動化 ビジネスが継続する限り、プロジェクトは続く 共有 リポジトリ上 で 常に作業 コード追加・修正時は 常にビルド・テスト (最後にまとめてやらな い→早く失敗すれば 早く品質が安定する) サービス停止せず常時 リリース/デプロイ (失敗時にはクイックに 修正 ／ 前バージョンに 戻せる)しくみ 運用・監視しやすい 品質をコードに反映 (必要なデータの取得、 スケーラビリティの 確保) 継続的： ● お願いドリブンでな いこと ● 遠慮なしに依頼可 能な状態 ● 依頼しなくても 左から右に カンバンが 流れる状態 継続的ではない： 「それ、手元の 　コードでは 　もう直したんです 　けど」

の重要さは 既に理解している ≒共感・理解をヨコのメンバーに広げられる ≠お金を出す人(タテ)を説得できる 頭で理解してもらうだけでなく(ROI, 機 能比較などなど) 腹に落としてもらって 行動してもらわないと 開発・運用プロセスは変わらない

15 早くFAIL(失敗)すれば、 もっと早く成功できる！

16 は「最初のフェーズ」からやるべし マシュマロ・チャレンジ 18分間で 乾燥パスタ20本＋タコ糸90cm＋ テープ90cm＋はさみ でタワーを作り、一番高いチームが 勝ち。 ただし、タワーの頂上には マシュマロを刺しておくこと。

17 大人と幼稚園児の アプローチの違い 大人 18分間のほとんどを ● 計画(Plan) ● 構築(Build) で使い、最後の最後になって頂上にマシュマロを突き刺す →あえなく倒れてしまい、 　(どんなに一生懸命頑張っていたとしても )結果は0cm。 幼稚園児 18分間を通じて、 ● 低いタワーを作る ● マシュマロを刺す: MVP - Minimum Viable Product ● タワーの高さを少し高くする を繰り返す。 タワーが倒れてしまったら、直前まで立っていたタワーの高さに戻す。 →DevOpsな皆様なら、聞いたことある話 この「マシュマロチャレンジ」を 私(舟木)は2013年以来、 日本企業や海外日本企業拠点を 中心に150社以上で実施 →業界や会社ごとの 「個性」見てきています！

テスト・ビルド・ リリース・デプロイ 後でもできる、簡単だと思って、 舐めんなよ 500円玉と同じ程度には 重いって分かってたら もっと早く 取り掛かっていたのでは？ 大して中身も なくて スカスカに 見える 私ですが

の考える生産性 「もの」以外で生産性を高める

20 実データから見る自動化(CI/CD) 調査期間 　2020/08/01~30 　(2019年版は90日間) 調査対象 　44,000組織 　160,000プロジェクト 　200万ジョブ/日

21 ユーザーの 中央値(2020/08) ベンチマーク目標値 スループット ワークフローの平均実行数 0.7回/日 プルリクエストのマージごと いつでも(遠慮せずに)ビルド可能 実行時間 ワークフローの平均実行時間 4分以内 5~10分 自動化可能なことは全て任せる 平均復旧時間 ワークフローの失敗～成功の平均時 間 56分以内 60分以内 大きな失敗を最後にではなく、すぐ に復旧できる失敗を早期に 成功率 ワークフローの成功数／実行数 デフォルトブランチで 80% デフォルトブランチで 90%以上 自動化における４つの評価ポイント ここの数値を「近い目標」として ここの数値をベンチマーク対象にする

なぜCircleCIを選ぶべきなのか を知りたい

CI/CDマーケットにおけるCircleCIの位置づけ CircleCI https://www.g2.com/categories/continuous-integration?segment=mid-market#grid

CI/CDを簡単に定義するためのパーツ(Orbs)が充実 パートナー様製 Orbs CircleCI 製 Orbs

数多くのお客様のビジネスをCI/CDの面から支えている実績

日本語のウェブサイト・技術情報・情報発信

コミュニティ起点での豊富な情報とエンジニアの成長支援 CircleCI (335) GitHub Actions (237) GitLab (134) Jenkins (59)

CircleCI Advent Calendar 2020

教育やPoCレベル以上のリアルユースケース

30

雑誌・書籍・技術系同人誌が充実

皆さんが選ばれて輝く存在である ように、CircleCIも選ばれて輝く存在でありたい 情報を発信・共有することで 自ら輝く 発信された情報を「まとめる・再発信する」 ことで、反射して輝く

33 #CircleCI書き初め大会 開催中！ 開発プロセス、テスト、リリース、 デプロイ、自動化、品質、生産性 などなど、みなさまの思うところを #CircleCI書き初め で共有ください！

Thank you. 34