システムエンジニア Advent Calendar 2016 - Qiita 2日目の記事です。
SI 業界人なら構成管理の現場で一度くらいは遭遇したことがあるかもしれない Excel 入出庫台帳との思い出と付き合い方について書きます。
書くこと
- Excel 入出庫台帳とは
- 付き合いの歴史
- オススメの付き合い方
- まとめ
こういうやつです。
この Excel に、これから編集するファイルのパス・バージョン・編集種別 (追加・修正・削除) といった管理情報を記入します。それを申請書として構成管理担当者に提出すると、記入したとおりのパス・バージョンのファイルが送られてきます *1
これは「構成管理物を担当者に払い出す」ので「出庫 (申請書)」と呼ばれます。反対に、担当者が作成・修正したファイルを構成管理に戻す (入れる) ときは「入庫 (申請書)」と呼ばれます。しかし、入庫も出庫も単に「入出庫台帳」と呼ばれることも多いです。
Git しか使ったことがない人にはまったく意味不明だと思いますが、使っていた人もほとんどが「なんでこんなの使うんだ？」という代物です。
そんな Excel 入出庫台帳について、あるプロジェクトで付き合った思い出と付き合い方を書きます。
付き合い前 - 最初期
構成管理のためにバージョン管理システム (以下 VCS) を利用することが多いと思いますが、最初期は VCS を使っていませんでした。
どうやっていたかというと、共有ディレクトリに置かれたファイルを担当者が直接修正 + 日付ディレクトリで運用していました。また、共有ディレクトリのファイルを直接編集するのではなく、ローカルにコピーして編集したあとにディレクトリ全体を戻す、といったことも行われていました。
当然のように、いろいろな問題が頻発しました。
- 修正したファイルが他の担当者に上書きされる
- 削除したファイルが復活する
自分がジョインしたのはちょうどそんな頃でしたが、VCS を使わないのはあまりにも無謀です。そこで、すぐに VCS の導入を提案しました。
付き合い前 - 前夜
チームとしても「このままではまずい！」という危機感を持っていて、すぐに VCS を導入することになりました。自分は Git か Mercurial を推したのですが、最終的には標準ソフトウェアという理由で CVS が導入されました。なお、この時点ではまだ Excel 入出庫台帳による管理は行われていませんでした。
運用の実際
この頃から頻繁にステージング環境にデプロイするようになり、以下のような手順でデプロイしていました。
一直線に進むだけの開発においては CVS + ブランチなし運用でもなんとかやっていけていました。一応。
ふりかえって気が付いたこと
当時は Git や Mercurial ではなく CVS を採用する理由が分かりませんでした。しかし、
- 自分以外のメンバーは Git, Mercurial の経験がなかった
- 一方、CVS の経験はあった
- デスマーチ一歩手前で学習コストが払いづらい
- 不慣れな Git, Mercurial を使った場合の事故が怖い
- 自分はジョインしたばかりだった = 実績がない = 信頼がない
これだけネガティブな環境的要因が揃っているなかで、実績も知名度もないメンバーの意見を積極的に採用するほうが難しいでしょう。
「信頼を得るのに弁舌でなく実績をもってすべき」とか言われても不思議ではないと思います。
付き合い初期 - すべて人力
プロジェクト全体で構成管理プロセスの品質向上が図られることになり、Excel 入出庫台帳 (以下、台帳) が導入されました。また、この頃からプロジェクトが完全にデスマーチ化しました。
運用の実際
台帳を導入したもののファイル自体は CVS で管理されているので、台帳が入出庫フローに直接組み込まれることはありませんでした。その代わり、ファイルを追加したり修正した場合はその実態に合うように台帳に記入し、デプロイの際には台帳の記録履歴からファイルを集めてビルド・デプロイすることになりました。
困ったこと
台帳を導入してすぐに問題が発生しました。問題は大小様々でしたが、一番大きな問題はコンパイルができない *2 ことでした。原因は様々ですが、大雑把にリストすると、
- 台帳に記入されたパスが間違っていて update できない
- 台帳に記入されたパスが間違っていて別のファイルが update された
- 台帳に記入されたリビジョンが存在しない
- 台帳の記入順に update するとリビジョンが巻き戻る。これが正しいのか？
- 台帳はコミットごとに別ファイルとして作られる *3
- そもそも台帳への記入漏れがあった
こういった原因のためにコンパイルできなかったり、コンパイルできても論理的な矛盾 (バグ) があるなどに悩まされました。「昔はブランチをマージする前に禊 (みそぎ) をしたものだ」なんて聞いたことがありますが、この頃はマージどころか単にビルドするだけで何時間もかかるのが当たり前で、通常業務への影響は到底無視できるものではありませんでした。
ビルドは持ち回りでやっていたのですが、1度でもやった人は2度とやりたがらず、自分も1度やってみてすぐに改善を決めました。
台帳による管理を続ける理由はまったくありませんが、台帳は品質向上プロセスの一環として導入されたため、取りやめるためには政治的な壁が高く立ちはだかっていました。そこで、入出庫フローそのものは変更せず、作業の実体だけを変えることにしました。つまり、プロセスのリファクタリングです。
ビルド持ち回り2巡目からはほぼ自分1人がビルドしていたので、チームリーダーの合意だけもらってリファクタリングを進めました。
- ビルドにかかる時間が20分になった
- 誰でもビルドをしてくれるようになった
- 台帳に記入する時間を開発に充てられるようになった
- 「台帳いらないよね」気運が高まった
やったこと
台帳への記入と台帳からファイルを集めるのを自動化しました。具体的には、
- CVS クライアントを導入
- commit のログから自動で台帳に記入するラップコマンドを作成 *4
- 一連の台帳の記入内容からファイルを集めるスクリプトを自動生成
- 記入内容をチェックして誤りや矛盾がある場合にはレポート生成 *5
- 定間隔で記入内容をチェック
行った変更はすべて台帳に記入・台帳の記入内容からファイルを集めてビルド…という入出庫フローはそのままですが、作業の実体としてはまったく別物になりました。定間隔でのチェックは Windows のタスクスケジューラを使ったのですが、誤りを早期発見できるようになったおかげで無駄な調査時間を一掃することができました *6 *7
どうやったか
できるだけ段階的な自動化を心掛けました。というのは、
- 単純に変化を嫌う人もいる
- 変化よりは苦労のほうがマシとさえ言う人もいる
- CLI しか用意しなかったが、CLI に苦手意識を持つ人もいる
こういったありがちなことを避けるためです。
また、自動化後の運用フローも1人ずつ段階的に導入してもらいました。というのは、
- 一気にチーム全体にお願いすると "上意下達" と受け取る人もいる
- 反発したり、言われたから仕方なくやる、になってしまいがち
- 事実上、いきなり全員をフォローするのは無理ゲー
- 相談という形で1人ずつお願いすると自分事と捉えてくれる
- 先行して導入した人が後続する人のメンターになってくれる
目的は構成管理にかかる時間の最小化と余計な作業を減らすことで、自動化された手順を使ってもらうのは手段にすぎないので。
とはいっても、このあたりはプロジェクトや組織の文化次第でいくらでも変わるので、いけるなら一気に導入したと思います。
付き合い末期 - 別れ
自動化を導入してから数ヶ月後、家庭内別居状態だった台帳と別れるときがやってきました。
きっかけ
プロダクトが無事にリリースし、それと同時に複数バージョンのメンテナンスが必要になりました。台帳と家庭内別居したあたりから構成管理周りのことは最初に相談してもらえるようになっていたのですが、この時は「好きにやっていいよ」と言ってもらえたので好きにやることにしました。
やったこと
いろいろやりましたが、キモは台帳が不要であることをマネージャーに納得してもらうことでした。
マネージャーは台帳そのものが必須だと考えているわけではありません。マネージャーにとって台帳はあくまで手段でしかなく、目的は構成管理プロセスから生み出されるプロダクトの品質が担保されることです。しかし、「台帳という手段があるからこそ目的が達成される」「台帳という手段がなくなったら目的が達成できなくなる」とも考えています。
そこで、台帳が無くても新しい構成管理のやり方 (= 手段) で目的を達成できることを、チームリーダーと2人でマネージャーに説明しました。自分一人では納得してもらえないか、あるいは相当に時間がかかりそうでしたが、チームリーダーが粘り強く説得してくれたおかげでかなり早期に GO サインがでました。この一件にとどまりませんが、チームリーダーに対するマネージャーの信頼の高さに救われました。信頼は大事です。つくづく思います。
その後
台帳と別れたあとはユニットテストを充実させたり、CI を導入したり、DSL で機能テストを書けるようにしたり、と変化の速度はあがりましたが、台帳とは関係ない話なので以下略。
オススメの付き合い方
誰がなんといおうと付き合わない、間違いなくこれが最善策です。
それでも付き合わなければならなくなったとしたら、家庭内別居状態→離婚のコンボを狙う、これが次善策でしょうか。
実効性がないプロセスは政治的・文化的な理由から存在するのがほとんどなので、最初から拒否するのは難しいことも珍しくありません。そこで絶対に拒否！と頑張るのもいいのですが、非常に疲れますし最終的に受け入れざるを得なくなることも多いです。ある程度まで頑張っても駄目なら、悪化した状況、つまりリスクが発現するのを前提に考えてみるのも1つのやり方だと思います。
まとめ
ながくなってしまいましたが、Excel 入出庫台帳の思い出と付き合い方でした。
最後に、Excel 入出庫台帳に限らないのですが、プロジェクトのルールや文化を変えていくにあたって心がけていることを書きます。
- 知名度がなければ実績で信頼を得る
- 変化は少しずつ
- 変化は自分から
- 自分自身を変えるのも簡単ではない
- 自分が他人を変えるのはほぼ不可能
- しかし、他人が自身を変えることはできる
- 仲間をつくる・増やす
- メリットを体験してもらう
- トップダウン・ボトムアップに絶対はない
- 技術的正論が通らない (= リスク) ことは当たり前にある、を前提に考える
- 建前を変えられないときは実体から変えていく
- そのときがきたら建前も変える
- 変化は手段であって目的ではない
- しかし、変化がない≒リスクである
いろいろ書きましたが、変化を楽しみながら仕事ができる、そんなシステムエンジニアでいたいと思います。
