移転プロジェクトをGitLab管理してみた(前編)

i.M.D. Staff

2016.04.20

スクリーンショット 2016-04-20 12.57.01

以前社内へGitを落としこむ為社内のデザイナ、フロントエンドエンジニア、エンジニアを抱き込み勉強会を行いました。
IMDGit勉強会を開いてみた
Gitにも慣れてきたし移転プロジェクトをGit（Lab）で管理してみてはどうかと考え、IMDが移転する際にプロジェクト扱いとしてGit（Lab）でプロジェクトの進み方と運用管理した手順を紹介

移転で実際にメンバーがどう動いたのかっていうのはコラムにあがっているのでよければそちらをみてもらえればおもしろいです
前編、中編、後編
このブログ（前編、中編、後編）は、移転することをどのように意思決定されたのかとか、どうやって進めていったのかってのを語ります

GitLabとはなんなの

Gitと連携できたり、課題を設定して議論・報告できるISSUE機能があったり、情報をまとめておくことができるプロジェクト内WikiがあったりするCloseなRails制のWebサービス
Githubとは自分のサーバに立ち上げ利用することができる
UIは違いますが、Githubと機能かなり似ているサービス
詳細は”さくらのナレッジ”をみてもらうのがベターですね

Git（Lab）の利用状況

エンジニア　日々Gitで作業管理してる
フロントエンドエンジニア　日々Gitで作業管理してる
デザイナ　HTML管理はGitで登録、PSDはGit対象外でGitには少し触れる
営業　GitLabはチェックしてるかもしれない

引っ越しプロジェクト手順

１．プロジェクト立ち上げ
２．移転先をリサーチ・プレゼンするチームを作成
３．移転先決定プレゼン
４．移転準備チーム３チーム＋進行管理アサイン
５．チーム決定事項の全体への最適化
（４，５は何度も繰り返しタスクが生まれていく）
６．決定事項のタスクをつぶし
７．移転準備作業
８．移転作業
９. プロジェクト完了

プロジェクト手順詳細

スクリーンショット 2016-04-20 13.06.12

1.プロジェクト立ち上げ

スタッフがもっと交通の便の良い市内へ移動したいという希望を社長にぶつけつづけ、ようやく引っ越しの決意表明が出た
そして移転するなら、メンバー全員で予算を縮小してやっていこうと方針がでる

プロジェクト条件

メンバーみんなでやっていこうというざっくりコンセプト

そこで移転成功を達成するため、社内メンバー全員アサインされた引っ越しプロジェクトを立ち上げてGitLabで管理することを書記役の私は考えました。

GitLab　オペレーション

基本ポリシーを書いたREADMEを登録
プロジェクト名を”imd_transfer”としてGitLabへ新規登録
社内メンバー全員をアサイン
プロジェクト管理兼進行管理者をT氏として登録
書記としてプロジェクト情報のまとめ役に私はアサイン

スクリーンショット_2016-04-20_13_11_09

2.移転先をリサーチするためのプレゼンチームを作成

移転するとなったらいろいろ意見でますよね
そしてまとまらない。。
そんなときはやっぱ進行管理の手腕が問われます
でも、意見多すぎるし、スルーされるし声が大きい人の声が通りやすいってどこにでもある問題を縮小すべくチーム制をしきます
３チームの担当エリアをざっくりをキタ、ミナミ、本町エリアにわけた

リサーチチーム役割コンセプト

移転先候補エリアリサーチして予算、場所をチーム内で決める
移転先候補を選抜しメンバーへプレゼン

GitLab　オペレーション

様々な意見をとりとめておく雑談ISSUE板の立ち上げ
チームISSUEを作成して、問い合わせ情報、資料をISSUEで議論
議論のまとめ板を作成

3.移転先決定プレゼン

プレゼン勝者は移転先が自分で決めれるという権利があたえられ、
序盤で一番の盛り上がりどころでした
でも、ここの後日談というかオチをさきにいってしまうと、社長の決定権は絶大であったということも一言付け加えておきます。。。

GitLabで情報を共有できるようにしていたのでプレゼン期日を設けて、各チームが不動産屋さんに問合せ、候補の議論・ファイルのアップロードの進捗が共有され見えているのは、単純にながめていておもしろい！
チームによって方針がそれぞれで、チームメンバーが一丸となっていたり、チーム内でチームを細かくしたりと書記役の自分は外から見るとう特権を発動して楽しんでました。。。すいません