ITツールでビジネスや組織を方向づけ、ビジネスや組織にあわせてツールを変化させる - ツールとビジネスの関係性に着目すると CI ツールと しての CircleCI の長所が見えてきます。
はじめに - ソフトウェア開発のツールチェーンに求めるべき要件
CircleCI のようなソフトウェア開発ツールチェーンを選定するとき、どのような要素を検討しますか? 特定の言語・フレームワークをサポートしているか、十分な速度・性能が出るか、セキュリティ ポリシーに適合するか、といった技術的要件の充足はすぐに思い当たるポイントだと思います。特に筆者はエンジニア一筋でやってきたので、ツールの選定においては技術的要件や自身が実際に使う際の使い勝手がすぐに気になります。 しかし、そもそものツール導入検討の動機を考えてみると、最終的な目標は業務効率改善やワークスタイルの革新といったオペレーションの見直しや、ビジネスそのものの成功にあって、技術的要件などはそれら最終目標を満たすための個別具体な例にすぎないことが多いのではないでしょうか。では、オペレーションの見直しやビジネスそのものの成功のために、ツールが備えているべき要件とはなんでしょうか。それは、ビジネスや組織を理想的に方向づけられることと、ビジネスや組織の細かい特徴に併せて柔軟にカスタマイズできること、その両面の性質をバランスよく備えていることです。
この答えの背景には、二つの特筆すべき現実があります。第一に、ビジネスの成功には、本質的な部分の付加価値創造に集中するべく、既知の有効なやり方の踏襲がそうでない部分では不可欠だということです。任意のビジネスにおいて、独創性や独自性の追求や製品の差別化は必要不可欠で、これなくしてビジネスは成り立ちません。ところが、顧客提供価値に直接関係ない部分でも独創性や独自性を追求するようになると、そちらに必要なリソースが無視できなくなってゆき、かえって本質的な付加価値の向上に割けるリソースが減り、最終的には競争力低下を引き起こします。 つまり、顧客に提供される製品・サービスの付加価値を最大化するためには、確立されたうまくいくことが知られているやり方を可能な限り踏襲することが望ましいのです。このことはスタートアップ向けのアドバイスでも触れられています。 そして第二に、人の思考や行動は外部環境、特に直接手にする装置やシステムの影響を非常に強く受けるということです。これは実験心理学やサイバネティクスの世界で基本原則として捉えられているだけでなく、私はとある著名なマーケターが組織改革におけるシステムの重要性に言及するのを耳にしたことがあります。 つまり、日頃使用するツール次第で、人や組織の行動、さらにはビジネスのあり方や進み方そのものが決定づけられてしまう可能性があるのです。 この二点を踏まえると、自ずと、人や組織を踏襲するべき既知の理想的なやり方にマクロに方向づけつつ、独創性・独自性の追求や差別化にどうしても必要なミクロなカスタマイズを許容することが、ツールに求められる要件であると導かれます。以下のような図にしてみると、イメージしやすいかもしれません。
では、 CircleCI は、この要件をどのように満たすのでしょうか? 以下では、 CircleCI により作り出されるビジネスやオペレーションの方向性と、独創性・独自性の追求を支援する CircleCI のカスタマイズ性のそれぞれを見ていきます。
CircleCI が作り出すビジネスやオペレーションの方向性
CircleCI についてよく挙げられることのひとつに、 CircleCI が CI/CD 専門ベンダーとして、世界中のソフトウェア開発のベスト プラクティスを分析し、その知見を製品に反映しているというポイントがあります。つまり、 CircleCI というツールは、世界中のベスト プラクティスを踏まえた開発スタイルを、各ユーザーの手元足元でもより強力に実践できるように開発されているのです。 CircleCI での分析を踏まえると、理想的なソフトウェア開発には以下のような特徴があります。
- 漸進的な開発。マイルストーンを細かく設定し、細かい PDCA サイクルを何回も繰り返す、いわばアジャイル型の開発スタイル。継続的に提供するサービスに限らず、特定の納品期日があるような製品においても、テストを一度にまとめて行おうとせず、開発スケジュール全体を通じてこまめにテストを何度も実行する。これにより、不具合発生時のいわゆる “出戻り” の発生リスクを大幅に減らす。
- Git 上のすべてのコミットに対するテストの実行。これにより、リグレッションの発生ポイントを素早く見つけ出せるようにする。
- テストやデプロイの実行結果の共有。これにより、万が一の問題発生時に誰でも調査・検証を実施できるようにし、製品やコンポーネント・部品の属人化を防ぐ。
- テストやデプロイの高速化。これにより、ソフトウェア開発に従事するエンジニアのアイドリング タイムを最小化する。
- データ・メトリクスに基づいたオペレーションの改善。開発サイクルの回転速度 (スループット)、ジョブ実行時間、平均復旧時間 (MTTR)、テスト成功率やテストの安定性といったデータに基づいた根拠のある施策の導入により、チーム生産性の最大化を目指す。 そして、CircleCI は、標準的な使い方をすれば自ずとこのようなアプローチを踏襲することになるようデザインされています。たとえば、
- 宣言的で静的なジョブ定義。 CircleCI では CircleCI 上で実行するタスクをYAMLファイルで宣言的 (declarative) かつ静的 (static) に定義します。したがって、安定し “枯れた” 処理 (たとえばコードのテストや検証) を何度も繰り返し実行するのに秀でており、あらかじめ決定した KPI の達成率が少しずつ上昇する、もしくは劣化しないことをこまめにチェックするような用途に特化しています。
- Webhookを活用した Git のコミット・プッシュをトリガーとしたジョブの実行。 VCS 上に存在するすべてのコミット・プッシュに対してテストが実行されることを徹底します。
- Webhook により実行されたジョブの実行結果は、権限のあるユーザーであれば瞬時に CircleCI 上から確認することができます。実行結果は VCS 上でも確認でき、ソースコードにアクセスできるユーザーであれば誰でもジョブの成否を一目で判断できます。
- 並列化 (parallelism、fan-out/fan-in ワークフロー) やキャッシュ (依存関係キャッシュ、Docker Layer Caching)、リソース クラスの指定により、コストパフォーマンスにも配慮しながらテストやデプロイを高速化しエンジニアの稼働率向上に寄与します。
- Insights ダッシュボードによる、スループット、ジョブ実行時間、 MTTR、テスト成功率、不安定なテストの有無といったメトリクスの可視化。生産性向上にむけた改善ポイントを ”見える化” します。 また、 CircleCI のプレミアム サポートに付属するサービス メニューを活用することで、単なる機能の存在だけでは不十分な部分 - たとえば、定例ミーティングでのメトリクスに関する情報共有や、全社内向けセミナーや開発者向けトレーニングの実施 - の支援を受けることもできます。 このように、 CircleCI により、 CI/CD の専業ベンダーが蓄積してきた世界中のベスト プラクティスや知見の踏襲・実践を推進し、より本質的なことに割けるリソースを増やすせるよう、日常のオペレーションや組織のあり方、ビジネス全体の進め方を方向づけることができます。
独創性・独自性の追求を支援する CircleCI のカスタマイズ性
CircleCI をカスタマイズする方法はたくさんありますが、ここでは特に強力なものを 3 つ紹介します。
1. Private Orb
CircleCI 上で実行するコマンドをライブラリ化する機能であるOrbですが、Private Orbを使えば各組織特有の Orb を組織内だけで共有することができるようになります。 Private Orb の利点は 2 つあります。まず第一に、そもそもカスタマイズされた Orb を非公開のまま作成できるということ。そして第二に、それを組織内で広く共有できるということです。つまり、組織特有のどうしても変えられない社外秘のオペレーションがあるような状況 (アプリケーションのデプロイがわかりやすいでしょう) において、そのオペレーションの手続き一切を外部から見えないライブラリとして作成し、組織内の誰でも再利用できるのです。 Private Orb の活用により、組織全体が独自性を維持しつつ、ライブラリ化されたオペレーションの先にあるもっと本質的で独創性に富んだことに集中することができます。
2. ランナーRunner
ランナーは、 CircleCI 上で実行されるジョブをセルフ ホステッドな持ち込み機材上で実行できるようにする機能で、以下のような独自のカスタマイズを必要とするユースケースで役立ちます。
- 他のクラウド リソースと密な連携をしたい場合。例えば、 IAM ロール/サービス アカウント/マネージド ID を使用したパスワードレスなデプロイの実行や、 HSM などのサービスを組み合わせて利用したい場合。
- 特殊なハードウェアを活用したい場合。例えば、組織内で保有しているマルチ CPU サーバーや強力な GPU を活用したい場合や、 USB/RS-232 などで接続された外部ハードウェア (特にスマートフォン) を使ったテストを実行したい場合。
- ジョブ実行環境がおかれている物理的地域・リージョンに制約がある場合。例えば、日本のサーバーへの大量のデータ転送が必要なためアメリカにある CircleCI のジョブ実行環境ではスピードが十分でない場合や、輸出規制のあるリソースと組み合わせてジョブを実行したい場合。
3. CircleCI server
GitHub Enterprise Server と組み合わせて使用したい、ソースコードを外部に持ち出せない、といった制約がある場合、 CircleCI を組織内にセットアップしてしまうということも可能で、それを実現するのが CircleCI のオンプレミス ソリューションであるCircleCI serverです。CircleCI server の場合、 GHES との連携や組織内ネットワークでの CI/CD 実行環境立ち上げといったごく一般にあるニーズに応えるだけでなく、サポート範囲に限界があるものの CI/CD プラットフォームのカスタマイズ (たとえば、あらかじめ IAM ロール/サービス アカウント/マネージド ID を割り当てた実行環境を組織内で横断的に共用できるようにし、各チームでの runner 管理の必要性をなくす、など) も可能 で、様々な独自環境に柔軟に対応させることができます。
おわりに
この記事では、ITツールがビジネスや組織を方向づけ、ビジネスや組織にあわせてITツールを変化させる、という、ITツールとビジネス・組織・オペレーションの関係性に着目し、 CircleCI の長所を見てきました。ツールがビジネスや組織を方向づける側面においては、世界中の事例から導かれたソフトウェア開発のベスト プラクティスの実践を念頭に、 CircleCI の機能やサービスが設計されていることがおわかりいただけたかと思います。また、ビジネスや組織に合わせてツールを変化させる側面では、独創性・独自性の追求を支援する CircleCI の強力な機能をご紹介しました。この記事が、読者の皆様が日常のオペレーション、組織やビジネスの経営・運営の視点から最適な CI/CD ツールを選択する際の一助になりましたら幸いです。
