GitHubで始める、場所に依存しないグローバルチーム開発

2022年12月06日 火曜日


【この記事を書いた人】
栗原 貴憲

IaaSサービスの仮想化レイヤで設計・開発や構築・管理の自動化をしています。新しいテクノロジーに釣られてあっちへふらふら、こっちへふらふら。

「GitHubで始める、場所に依存しないグローバルチーム開発」のイメージ

IIJ 2022 TECHアドベントカレンダー 12/6(火)の記事です】

はじめに

こんにちは、IIJでクラウドサービスの提供に携わっております、栗原です。

私たちのチームでは現在、IaaSを提供するうえでお客様にリソースを提供する基盤となるサーバ・ネットワーク仮想化について、技術や製品のキャッチアップ・検証、これらを活用したサービスのリファレンスとなることを目指した設計・開発を行っています。

従来の組織では基盤運用にリソースの多くが割かれており、継続的な新規開発を行うのが難しい状況でした。
そこで開発能力を強化し、また対応範囲を拡大していくためにこの1年で始動した私たちチームですが、大きな特徴としてベトナム法人である IIJ Global Solutions Vietnam との共同開発チームとなっています。

春~夏にかけては対面でのコミュニケーション・チームビルディングのために本社メンバーがホーチミン市のオフィスに出張しましたが、その後は GitHub を中心としたスクラムベースのコラボレーションを行っています。
時差2時間、飛行機でおよそ6時間の距離に隔てられた我々チームの活動をご紹介します。

チームについて

私たちチームは、サーバ・ネットワーク仮想化製品を中心にその周辺も含めた技術・製品に関わるプロアクティブな調査・検証・開発と、他チームがそれらの技術を活用・習得するための支援を主な役割としています。
様々な製品の新バージョンを評価する、新機能を検証しガイドラインとなる設計に落とし込む、運用管理におけるナレッジを蓄積する、といった活動を通じてサービスを運営するチームをサポートし、結果として魅力あるサービスをタイムリーにお客様にお届けすることを目指しています。

先述の通り、従来は人的リソース不足などが原因で新規開発が思うように進められていませんでした。
加えて社内・国内での人材確保が難しい状況や、将来的なさらなる開発規模拡大も念頭に、ベトナムでのチーム立ち上げに至りました。

メンバーのほとんどはベトナム・ホーチミン勤務のエンジニアで、やり取りは英語が基本となっています。
互いにネイティブというわけではなく、意図をスムーズに伝えられない、間違って伝わるといったことも多いですが、毎朝のミーティングをはじめ密にコミュニケーションをとることで随時軌道修正を図っています。

なお、アプリケーション開発の現場で行われるそれとは毛色が違った部分もあるかと思いますが、大筋でスクラムをベースとするタスク管理に取り組んでいます。
またスクラムマスターにはアプリケーションにおけるスクラム開発の経験者をベトナム現地で採用し、インフラ技術については他メンバーがフォローする形を取っています。

GitHub Enterprise Cloudによるコラボレーション

IIJでは、有志により運営されており、社内からのみアクセス可能なGitHub Enterprise Server(社内GitHub)環境が様々なプロジェクトで活用されています。
しかし我々のチームではベトナム現地メンバーの参加が不可欠であることから、パブリック版である GitHub Enterprise Cloud を採用することにしました。

Server-Cloud間でライセンスを共有可能であるため、以前から社内GitHubを利用しているメンバーはライセンスコストを重複させることなく利用できるのも理由の一つです。
また本プロジェクトの成果は将来的に日本・ベトナム以外でのサービス展開にも活用したいと考えており、その際には各国メンバーへの情報共有をスムーズに行うことができるでしょう。

GitHub Enterprise Cloud を利用するうえで、情報の公開範囲などには十分に気を使う必要があります。
意図せず情報を公開するリスクなどを減らすため、一般的なユーザは各種リソース作成の際、Private 設定のものしか作成できないような制御を行っています。
細やかな制御ができることが Enterprise ライセンスの強みの一つではないでしょうか。

一方 SaaS であるため、意図した通りの制御ができているかといった設定の見直しは必須です。
制御できる項目が増えるなど日々改善されている、ということでもありますのでアカウント等の管理と合わせて定期的な見直しを行っています。

なお私達の場合、契約単位である “Enterprise” の管理下にプロジェクト向けの”Organization” を作成し、適宜メンバー・外部コラボレータを招待してこの中で開発を行っています。
以下に記載している機能・設定などについて、認可やセキュリティ周りを中心にEnterpriseライセンス・Organization でのみ利用可能なものも多いことをご承知おきください。

GitHub Projectsによるタスク管理

スクラムの起点となるプロダクトバックログ、スプリントバックログとして、先日正式版となったGitHub Projects (V2) を活用しています。
Issueベースのタスク管理をする上で高度化・効率化に活用できるサードパーティ製品などもありますが、チームが始動するころには Projects (当時はBeta版) の機能も充実しつつあったことから我々のチームではネイティブな GitHub 機能を最大限活用する方針としました。

プロダクトバックログアイテム(PBI)、スプリントバックログアイテム(SBI)はそれぞれ Issue Template をもとに作成し、対応する Project =バックログに投入していきます。
様々な製品や機能ごとにリポジトリを分けて開発を同時並行で進めていますが、各リポジトリに紐付くバックログアイテムを1つの Project にまとめることで平行する開発の状況を一画面で管理することができます。

またこれらのバックログのほか、他チームからのリクエストや質問などを取り込むための Project、逆にベンダーへの問い合わせなどを管理するための Project もあわせて活用しています。
GitHub一箇所に情報がまとまることで一貫した方法でタスク管理ができるほか、必要に応じてフィルタやアイテムの並べ方を調整した “View” を作成することで会議体や場面に応じて適切な視点で状況を把握することができています。

バックログの一例

バックログの一例

なお、チャット・会議ツールとしてはIIJグループで採用している Microsoft Teams を利用。
GitHub Issue のやり取りではどうしても限界がありますので、口頭でのディスカッションやホワイトボードツールも随時活用しています。

GitHub Pagesでの内部向けドキュメント公開

チーム内外向けのドキュメントも主要な成果物の一つですので、レビューやバージョン管理、ブランチの仕組みを活かせる Git で管理し、公開場所として GitHub Pages を活用しています。

広く社外に公開することを意図したものではありませんので、Pages は Private 設定としてあります。
これにより GitHub にログイン済みであり、権限を持っているユーザのみが閲覧可能となります。

なお通常 Private Pages はランダムに選ばれる複数単語からなるURLでホストされますが、利便性と事故防止のために開発用に割り当てた独自ドメインを利用しています。
またこの際リポジトリごとに個別のURLが必要であるため、管理が容易なマネージドDNSサービスを活用しています。

ドキュメントのビルドにはプロジェクト内で知見のあった Sphinx を採用しました。
執筆に際しては、内容に応じて Markdown と reStructuredText を併用しています。
ローカル環境でのプレビューや各種図の作成についてはエディタのプラグインを活用し、一貫したドキュメント作成フローを実現しています。

ドキュメント作成のイメージ

ドキュメント作成のイメージ

GitHub Actionsの活用

上記のようなワークフローを効率的に回すため、可能なタスクは自動化してしまいたいところです。
私たちチームでは、タスク管理における Project 操作について GitHub Actions を利用した自動化を進めています。
Issue 作成で利用するテンプレートにはラベルが付与してあり、ラベル付きの Issue が作成されると対応する Project が自動割り当てされるようにActions Workflowが組んであります。
GitHub の UI 上で Issue に Project を割り当てるのはひと手間になりますし、これを忘れるとタスクが宙に浮いてしまいますので真っ先に自動化したいポイントです。

Projects (V2) についてはリリースされたばかりということもあり、API が未実装の機能が多いのが悩みどころです。
もっとも日々新たなAPIが増えていっていますので、次第に手動で実施しなければいけないタスクは減らしていけるでしょう。

そのほか、プルリクエストに対する機械的なコードチェック、ドキュメントのビルド・公開やAnsibleなどを利用したデプロイ・構成管理についても自動化を推進しています。
今後も引き続きバージョン・リリース管理の自動化などを進め、ナレッジの獲得に取り組んでいく予定です。

Actions Workflowの例

Actions Workflowの例

おわりに

各項目については触りだけになってしまいましたが、雰囲気程度でもイメージいただけましたでしょうか。
まだまだこれから様々なことにチャレンジしていく段階ですので、いずれ成果がある程度形になったタイミングで続報をお伝えできればと思います。

また本稿では触れていませんが、道にあふれるバイク、南国らしい空気やスコール、ゼロからの都市開発が今まさに進められている風景など、ベトナムについてもいつか機会がありましたら。

IIJ Engineers blog読者プレゼントキャンペーン

Twitterフォロー&条件付きツイートで、「IoT米」と「バリーくんストラップ」と「バリーくんシール」のセットを抽選でプレゼント!
応募期間は2022/12/01~2022/12/31まで。詳細はこちらをご覧ください。
今すぐツイートするならこちら→ フォローもお忘れなく!

栗原 貴憲

2022年12月06日 火曜日

IaaSサービスの仮想化レイヤで設計・開発や構築・管理の自動化をしています。新しいテクノロジーに釣られてあっちへふらふら、こっちへふらふら。

Related
関連記事