GitLabを選んだ理由(昔話)

プロジェクト管理ツールは世の中にたくさんあります。その中からGitLabを選んだ理由を紹介します。それなりに昔のお話で、2015年頃にとある組織に導入したときのお話です。

背景と方針

当時、インターネットではGitHub + Circle CIでの開発が流行りだしていました。自分もこれらを利用していましたが、使いたいときにすぐに使い始められるのにとても魅力を感じていました。

イントラネット内で閉じたこれらのサービスが使えない開発現場では、環境を用意するところから始めないといけません。特にCI/CDをやろうとしている開発現場では、開発効率の差が大きく開いていくと感じていました。

この格差の解消を目指して、組織のイントラネットへのプロジェクト管理ツールとCI/CDの導入を目指しました。

自分の開発チーム用であれば、いままで利用していたTracやJenkinsを導入するだけで済みます。組織への導入となると「みんな使って!」だけでは済みません。

さてどうしようということで思い出したのが「イノベーション普及学」で紹介されている「ロジャースのベルカーブ」です。

この分類をヒントにターゲットを分類しました。

• (a) すでにプロジェクト管理ツールを導入・活用していて満足している開発チーム。
• (b) 自身で様々なプロジェクト管理ツールをインストールしていろいろ試すタイプの人。
• (c) 道具があればそれを試行錯誤して覚えるタイプの人。
• (d) 詳しいドキュメントや導入事例がないとなびかない開発チーム。

(a)は現状で現場が問題を感じていないので対象外としました。

(b)も対象外です。自分たちが使いやすいものを自分たちで導入する傾向があります。

(d)が一番人数が多く、当然この層に導入するのがゴールです。しかし、この層に導入して活用してもらうには、良質のドキュメントと導入事例が必要で、それには膨大なコストと時間がかかりますので対象外としました。

というわけで目をつけたのが(c)で、アーリーアダプターと呼んでいました。(d)と比べると人数は少ないのですが、使い方がわからなくても試行錯誤をしたり英語のドキュメントを調べたりしてくれます。こんなことができるよと軽くアピールするだけでいろいろと活用してくれるわけです。中には開発チームを引っ張ったり、広告塔になってくれる人もいます。

最終的には(d)の層にもどんどん広めていきたいのですが、まずは(c)のアーリーアダプターをターゲットにし、プロジェクト管理ツールの選定基準は、機能よりも試行錯誤がやりやすいかを重要視することにしました。

プロジェクト管理ツールの選定

試行錯誤のやりやすさとは何だろうと要件を考えました。

• 試行錯誤の中での操作ミスで他の環境を壊さないこと。他の人に迷惑をかけるかも?と考えると試行錯誤をためらうようになります。
• 好きなタイミングですぐに環境を作れること。例えば、環境の作成で申請が必要だと、申請が必要ならあとでやるかとなって、忘れてしまうことが多いです。

前者に関しては、プロジェクト管理ツールはプロジェクトという単位で環境が分離されるので問題のあるツールはありません。試行錯誤用にプロジェクトを作成すれば、そのプロジェクトで操作している限り他人のプロジェクトが壊れたりはしません。

後者の要件を満たすためには利用者が自由にプロジェクトを作れる必要がありますが、多くのプロジェクト管理ツールはこれができませんでした。プロジェクトごとにインスタンスをセットアップする必要があったり、プロジェクトの作成にシステム管理権限を必要としたりしました。(もちろん、システム管理権限は利用者に与えられません)

また、利用料金を取ると後者の要件を満たせなくなりがちです。無料で使えるというのも条件にしました。

GitLab以外にも要件を満たすプロジェクト管理ツールはいくつかありました。最終的にGitLabを選択したのは、CI/CD機能がGitLab本体に統合され、それが手軽に利用できるようになったからです。

GitLabは一般の利用者がグループやプロジェクトを好きなタイミングで自由に作ることができます。作成したグループやプロジェクトの設定は作成者が自由にいじることができ、好きなように試行錯誤ができます。さらに、CI/CDも .gitlab-ci.ymlファイルを作成するだけで使い始められます。運用側の作業は特に必要ありません。利用者がちょっと試してみたいと思ったら、すぐに環境を作って試行錯誤ができるわけです。

機能的にはGitLabより優れているプロジェクト管理ツールはありました。しかし、プロジェクトの作成に運用側の作業が必要だったり、CI/CDが別ツールとなり連携させる作業が追加で必要だったりしました。欲しい機能のいくつかをGitLabは持っていませんでしたが、試行錯誤のやりやすさを優先しました。

結果

このGitLabはマジョリティにあたる層にも思ったより広まっていました。おそらく次のような理由があったと考えられます。

• 自分たちで構築運用するより楽だから
• Excelよりはましだから
• 申請などの準備が不要だから
• 新たなメンバーに、ツールの操作練習をやってもらいやすいから

試行錯誤のために使い始める敷居を下げた副次的な効果です。また、マジョリティ層の中には、潜在的にはアーリーアダプターだけど試行錯誤する暇がないからやれない人もいますが、彼らにとってすぐに試せるというのは魅力的だったのだと思います。この点については成功したと思います。

ただし、CI/CDの導入はあまりうまくいきませんでした。CI/CDを積極的に利用されるとサーバーリソースを急激に消費し障害に繋がりますので、リソース監視はこまめに行っていましたが、残念ながらリソース消費量が急激に上昇することはありませんでした。次のような理由があると考えています。

• CI/CDはある程度使えば良さがわかるけど、使ったことがない人のその良さを伝えるのが難しい
• 開発を統合開発環境で行っている開発現場は、CLIでのやり方がわからないので、CLI中心となるGitLab CIでは敷居が高い
• そもそも自動テストすら採用していない開発現場がほとんどで、CIを使う理由がない

最後に

当時と今ではかなり状況が異なります。SaaSでの開発への抵抗も薄くなってきています。プロジェクト管理ツールもそれぞれ機能強化されています。今やるとしたら、オンプレミスは選ばないと思います。

しかし、ツールの機能の優劣だけでなく、試行錯誤のやりやすさも重要視したほうがいいのはいつの時代でも同じです。

もちろん、何でもかんでも利用者の好きにさせるわけにはいかないので、そのあたりが腕の見せ所だです。