開発と導入サポートでのトラブルと対策
続く第2章は、2012年春から秋にかけての時期。「開発と導入サポート」がテーマとなる。この時期、開発チームは9名に増員された。この時期に行われたことは、大きく分けて4つ。次々に更新されるupstreamに合わせたサービスのアップデートと、顧客のアプリをPaaSに載せるためのサポート、バグフィックスと機能追加に応じたパッチの送付、だんだん陳腐化していく開発のやり方の検査と見直しになる。
このupstreamへの追随で、トラブルが発生した。最新のupstreamを取り込み、Hello Worldは動いたのだが、なぜか数時間たつとMySQLのインスタンスが消えてしまう。そこでソースコードをチェックすると、不要なインスタンスを処理するはずが、常に全部選択して消すようになっていた。「OSSできちんとCIが回っているので大丈夫だと思っていたが、それが入っていたとしても正しく動くとは限らないことが身にしみて分かった」（川口氏）。
そこで行われた対策は3つ。stagingに上げた後、しばらく状況を見る。きちんとソースコードを読む。問題が起きたら追加でテストを書き、2回目は起こさないようにする。
続いて顧客へのPaaS導入サポートだが、今まで作っていた環境をそのまま乗せても動かないことが結構ある。その場合は、プラットフォームで対策するか、アプリで対策するかの選択になる。
例えばある顧客では、分散メモリキャッシュサーバのmemcachedが必要だったのだが、当時はサポートされていなかったので追加した。他の事例では、JavaベースのWebアプリケーションサーバResinをサポートした。ただこちらは現状、非公開となっている。そもそも需要があるかが分からないし、必要なライブラリ変更を英語で説得するのが大変だからだ。
経験を積み、開発が分かってくると、「Core Compatibleでありつつ、国内の顧客の要望にも応えられる」というのが、Cloudn PaaSの価値だということが、チーム内で分かってきた。そしてOSS化は、社内手続きなどいろいろあるのだが、それらもやる気次第でできることも分かってきた。
ただ、同時に問題も出てきた。例えば、テストが増えたのはいいが、時間がかかる。そこでJenkinsのSlaveを使い、並列実行することにした。ここで大活躍するのが自社で持つIaaSで、fogやknife-cloudstackで操作することで、割と簡単に自動化できている。
また、作業が属人化してきたため、ペア作業の時間を週に2時間行うことにした。その内容を1チーム5分でライトニングトークし、Wikiに書いて情報を共有している。さらにコードレビューを強化するため、Githubのpull requestを使う体制に移行して、必ずオーサー以外がマージするようにした。
飽きが出てきた振り返りへの対策では、やり方を変えてKPT以外のことを試している。また、毎週金曜日は定例ミーティングを実施し、チーム全体で振り返りを行うことにした。
商用サービスの開始は2012年12月3日であったが、リリース目標をしっかり守ることができた。2012年冬からの第3章は、成果の出たやり方を組織に広げていくことがテーマだ。現在行っているのは、隣のプロジェクトとの連携であり、隣の人に火を点けることだ。
川口氏は、モチベーションを高め、ネットワーク事業だけでなく、クラウド事業でも価値を創出するために行動することにした。そこで始めたのが社内勉強会。隣のプロジェクトの人と仲良くなったりと、少しずつ前進している。
最後に川口氏は2つのアクションを求めた。まず、「いいな！ と思ったら、ぜひやってみる」。そして「もっと良い方法があれば教えて欲しい」というものだ。
