概要
基本自分の仕事ではお客さま先常駐で作業することが多いのだけど、場所ないし人いないしリモートワーク必須だよねー、と言う圧がひしひしとかかっていた。だけど、お客さんもうちもパートナーさんもノウハウがない。
そんな人々が、Web屋さんが当然のようにホスティング使ってわいわい楽しそうにやっているのを横目に、SIer風の運用やってみた記録でございます。
前提
- ガチなウォーターフォール開発
- 契約は一括請負前提（泣きで一部準委任）
契約形態
ユーザー企業のシステム子会社が元請。弊社が開発ベンダで、一部機能を再委託している。ガチな多重下請け構造ですね。よくあります。
元請～弊社間の契約は以下の通り
- 基本設計：準委任
- 詳細設計～製造・単体～内部結合：一括請負
弊社～再委託先の契約は以下の通り
- 詳細設計～製造・単体～内部結合：一括請負
構成
弊社はお客さま先に常駐して作業。再委託先は持ち帰りで自社開発です。あるある。
やりたいこと
ドキュメント共有
設計書はお客さま先の共有フォルダがマスタになる。これをリモート開発側とストレスなくセキュアにやり取りしたかった。リビジョン管理とバックアップがついているとなおよし。
コードホスティング
プロダクトコードはホスティング先をマスタとする。オンサイト側も持ち帰り側も同じリポジトリを参照、更新する。両者で共有するコードがあり、分散リポジトリ開発がしたかった。
プルリクエスト
内部レビュー、受入レビューをコードホスティング上で参照する。git-flowを活用し並列開発可能とし、かつプルリクエストなしでは開発本線への合流を抑止したかった。
チケット管理
タスク、不具合などのイシューは統一的にチケットとして管理する。オンサイト側も持ち帰り側もタスクの進捗状況を同じように管理したかった。
CI
単体テスト時点から継続的インテグレーションを行い、カバレッジや静的解析を自動実行したかった。
環境
縁あってOracle Developer Cloud Service（以下ODCと略す）を使用した。ドキュメント共有にはOracle beehiveを使用した。似たようなサービスは他のホスティング会社も提供しているし、OSSの組み合わせで自作することも容易だと思う。ただしサービスの運用というインフラなところで悩まなかったのはありがたかった。
実施のみちのり
基本設計
要件定義があいまいだったので基本設計は準委任だった。SIerあるある。ともあれ、基本設計フェーズはチームビルディングの貴重かつ重要なタイミングである。ここが準委任で取れたので、のちに持ち帰り開発することになる再委託先の主要メンバー、オンサイト側で開発を継続するメンバー、PMである自分が一堂に会した状態でお客さま先に常駐することができた。
チケット駆動（パイロット実施）
ODCのIssueを利用したチケット駆動を開始した。チケットはタスクの割り当てとレビューの依頼としてのみ使用している。お客さま先常駐だから設計書のマスタにはアクセス可能なのでドキュメント共有などは使用していない。
管理
ちなみに、計画のクリティカルパス分析にはMSProjectを使っているし、進捗確認にはExcelベースのWBSによるEVMを使用している。ガチなSIerですから。ここが二重管理になりがちなので、シンプルなワークフローになるようにした。
- PMが計画作成する。MSPおよびWBSまで
- PMがWBSをインプットにチケットを登録する
- メンバーがチケットを更新する
- PMはチケットに基づき毎日WBSを更新する
あんまりシンプルじゃねえな。でも日々のワークとしては3．と4．だけだし、責務がメンバーとPMに分かれているのでボリューム的にも全然回すことができた。
朝会
このタイミングでスタンディングな朝会を開始した。朝会はチームビルディングのために行うもので、ただの進捗状況確認の場ではないことを常に意識した。「困っていることありますか？」は魔法の言葉でしたねえ。
詳細設計
詳細設計からはオンサイト側と持ち帰り側で作業場所が分かれる。クラウドホスティング使うからと言ってコミュニケーションコストは下がりません。立ち上げのときには濃密にコミュニケーションとらないと苦労しますよ。
と、言うわけで詳細設計方針とかは事前にパワポでまとめて現地に説明しに行ったりした。
ドキュメント共有
beehiveを利用して詳細設計書およびレビュー票を共有した。ちなみに詳細設計書もレビュー票もExcelである。
設計書のマスタがお客さま先のドキュメントサーバなのは基本設計時と変わらないので、ドキュメント共有サービス側と同期がとれているかは人間系で常に気を付ける必要があった。ドキドキ。
チケット駆動
ODCのIssueを使ったチケット活用は基本設計執筆フェーズと同様に、タスクの割り当てとレビューの依頼にのみ使用した。
製造・単体
チケット駆動（レビュー票が＋）
チケットはタスクの割り当てとレビュー依頼に使用していたが、製造工程ではレビュー票の添付を行うようになった。
製造工程以降でもレビュー票はExcelで運用する。指摘数、指摘内容の分類、レビュー時間などの指標がほしいのである。ガチのSIerですから。ODCは残念ながらプルリクエストにコメントしたとしてもエクスポートできない（できるホスティングサービス知らない）し、前述のような指標は取れないのであるよ。
コードホスティング
ODCのリポジトリはGitであり、Githubライクにブラウザ参照もできる。しかし大事なのはそこではなく、git-flowのような運用が可能かどうかである。一つの資源にロックされない平行開発や、developにマージラインをそろえることで資源の取り込み漏れを避けたいのだ。
Mavenリポジトリ
今回のPJでは、元請のシステム子会社独自のArtifactが存在した。これは公開リポジトリには存在しないため、持ち帰り側の開発環境からはアクセスできない。
ODCの場合プロジェクト専用のMavenリポジトリの運用が可能なので、CIなどからも参照可能だった。このような環境がない場合は.m2ディレクトリを固めて配布するとかの手当てが必要になるだろう。
CI
Jenkinsではありません。Hudsonです！ 大人の事情についてはGoogle先生に聞いてください。
テストの実施記録くらいはとってくれるけど、それ以上のプラグインはないのでMavenのビルドでカバレッジ取得とCheckstyle、Findbugsで静的解析を実行した。
内部結合テスト
チケット駆動（試験項目表にエビデンスが＋）
チケットはタスクの割り当てとレビュー依頼に加え、試験項目表、レビュー票、エビデンス添付を行うようになった。
また不具合とその横展開管理にチケットを使用した。ただし詳細な内容や対応方針、横展開状況管理などにはExcel併用である。これにはガチのSIerであることは関係ない（後述）。
エビデンスは徹底的にスリム化した。納品物としてのエビデンスのフォーマットはExcelである。動かせない。ガチのSIerですから。しかしBeehiveでやり取りするのも若干ストレスだし、重たいファイルは存在が許せない。テキストベースで生ログとIn/Outデータを取得してもらい、Excelに画面ダンプを張り付けるのはやめてもらった。
画面がないシステムだったのでできたのだが、これはできるPJできないPJあるだろう。
課題
設計書の版管理
単純に版管理する/しないの話しではなく、管理されたドキュメントにしかアクセスできない仕組みがほしい。かつそれがオンサイトもリモート側も同じだとなおよい。
承認のワークフロー
請負側レビューと元請側レビューをシーケンシャルにおこなうことにしたのだけど、製造時はブランチ単位でレビューを行うことになると思う。ただそれだとブランチの生存期間が長くなりすぎる気がした。もっと短いスパンでブランチは吸収されてほしい。でもブランチがないとレビューしづらい。
かしこいチケット運用
ODCのチケットはRedmineほどのカスタマイズ性はないので、不具合の傾向分析とかには使えない。が、それはあまり不満には思わない。限定的なツールと言うのはシンプルで好きだ。
そこではなく、やはり運用側の問題だ。もう少しわかりやすく言うと、チケットをメールのように使うのやめてほしい。
ODCのIssueはSummary、Description、Commentsの要素からなる。それぞれタイトル、本文、履歴に該当する。
なぜか本文に「何々様お疲れ様です、○○のレビューお願いします」と書いてくる。やめてほしい。そのチケットはタスクの割り当てにもレビュー依頼にも使うつもりなんだ。と言いたい。
下記のように運用できればよかったな。
- Summary：よい要約
- Description：「リソース」と「終了条件」
- Comments：相手への依頼や回答など
git-flow教育
「Gitできますか」と質問する。みな「できます」と答える。これを信じてはならない。彼らは「SVNの代わりとして使うことはできる」と答えているのであり、開発のフローが変わるなどとは微塵も考えていない。git-flowはよく考えられた仕組みだが、人によってはそれまでの考え方に致命的な影響及ぼす場合が多い。導入時の教育を省略してはいけない。
その他
ブランチの命名方針とかコミット内容で書くべきこととかもっと整備してあげればよかった。みんな思った以上に文化を知らないし、知ろうとしない。実例やサンプルをもっと豊富に提供する必要はありました。