プロジェクト引き継ぎのベストプラクティス、そしてアンチパターン

あじさいがきれいですね。そんなことを可愛い女の子に言ってみたい。

どうも！アプリ基盤チームの@yokotasoです。

唐突ですが、プロジェクトの引き継ぎはうまく行っていますか？

プロジェクトの引き継ぎを経験すると、「あのとき聞いておけばよかった…」経験あると思います。

社内でためた引き継ぎの知見を公開します！どうぞ！

開発のハードルを下げるための引き継ぎ

開発環境をコンテナ化する

人の移動が多くないプロジェクトでは、開発環境構築のドキュメントが長い間メンテナンスされないことがあります。 この手のプロジェクトを引き継ぐことになったら、最初に検討すべきは開発環境のコンテナ化です。

コンテナの内部でできるだけ作業が完結するように、依存するライブラリやパッケージはすべてコンテナの中に収めましょう。 動作確認もWebサービスであればコンテナ内にWebブラウザーをインストールし作業がコンテナ内で完結することを目指します。

コンテナ化すると嬉しいこと

• 他の開発メンバーも参加しやすくなる
• コンテナ化すれば、環境をコードで表すことができ、利用者がパッチを投げてくれる
• 既存の開発環境を汚染しない

利用ライブラリのバックアップを忘れずに

開発時に必要なものはダウンロード可能な状態を維持するために、バックアップをしておきましょう。 本家のレポジトリが突然消えたりなど、なんらかのアクシデントでアーカイブがダウンロード不能になったりすることがあります。

CIシステムの引き継ぎ

CIシステムに関する引き継ぎもしましょう。スムーズにリリースできる仕組みを維持していく必要があります。

CIシステムが、突然動かなくなる可能性はあります。

• CIシステムが不安定になるときの特徴、対処方法などを引き継ぎましょう。
• 時間があるときに根本的な原因の究明を行うようにしましょう。

「いつか成功する」は圧倒的アンチパターンなので、撲滅していきましょう

問題の解決が難しい場合、監視など問題の発生に早く気付けるような仕組みを構築するのもよいでしょう。 CIシステム自体の問題に早く気付けるようになることで、問題の切り分けが容易になり調査のストレスを減らせます。

できるだけCI環境を停止するのはやめましょう。CIを復旧するのにそれ相応のストレスが伴います。

外部サービス連携の引き継ぎ

外部サービスの認証情報の切り替え

開発で利用している外部サービスの認証情報は、前任者がいるうちに利用しているアクセストークンの入れ替えなどを行っておきます。 前任者の退職に伴いアクセストークンの有効期限切れになり、連携している外部サービスがうまく動かなくなることがよくあります

引き継ぎ失敗あるある

• 引き継ぎ完了後、JenkinsからGitHubのCommit StatusのAPIの実行に失敗する
• テストは成功するが、Git Hubのステータス更新がされない
• Git Hubのアクセストークンの更新を忘れていた

アクセストークンが有効なうちはPull Requestからアクセストークンの発行主を確認することができるので確認しておきましょう

APNs の証明書の発行フローを確認する

Push通知を利用している場合、証明書の更新が1年に1回程度は必要になります(JWTを用いた認証方式を除く)。 証明書の更新が要求される外部サービスはかならず引き継ぐようにしましょう。

証明書管理のベストプラクティス

• プロジェクトメンバーが複数人、証明書にアクセスできる状態を作る
• 証明書の期限切れを3ヶ月ほど前にチームに対してリマインドする
• 証明書の更新を優先度の高いタスクとして登録する

弊社ではグループウェアのスケジュール上にリマインド予定を登録しています

開発者用アカウントの整備

Facebook,Twitterなど外部サービスと連携する場合は開発者用アカウントを整備しましょう。動作確認用に必要なアカウントを用意しましょう。 外部連携サービスの動作確認のハードルを下げることができます。

チームで共通アカウントを利用する場合は、どこかで一元管理すると良いでしょう。

共通アカウント管理のルールの例

• 開発者用アカウントにアクセスできるのは、アクセス権をもつチームメンバーのみ
• 情報システム部にパスワードを定期的に変更するリマインドをしてもらうルールを作る

外部連携APIのメンテナンス

「Facebookでログイン」など外部サービスのAPIと連携している場合、APIの期限切れに警戒しましょう。期限切れの半年前などにリマインドを設定しておくと安心です。 特にFacebookAPIは、APIの賞味期限が短いです。新しいversionが頻繁にリリースされていきます。

外部連携APIについてドキュメント化する

• 利用APIを明記する
• 動作確認方法を明記
• 利用APIの期限切れをチームに対してリマインドする

バッチ処理などでFacebook APIを使うと、動作確認ミスが起きやすくなります。このあたりは注意が必要です

version無指定のAPI利用はアンチパターン

Facebook APIではversionを指定しない利用方法もあります。この場合、利用可能なAPIのうち一番古いversionのAPIが利用されることになります。 一見、便利な機能です。Facebookからも警告が届きます。ですが、version無指定が常態化するとFacebookの警告は、無視するようになるでしょう。 Facebook APIの仕様変更に気付けずログインができないなどの致命的なバグに繋がります。

version指定をしてAPIを利用しましょう

ライブラリへの独自パッチの適用を引き継ぎ

レガシーなプログラムほど、既存のライブラリでは要求を満たすことができず、独自パッチが適用されていることが多いです。 ハックはビジネス的な価値を提供する一方で、メンテナンス性を悪化させます。

引き継ぎの担当者は独自改修の存在に気付けるようになっているでしょうか？レガシー・ブラウザ対応のための独自パッチは未だに必要でしょうか？

• 独自パッチを適用するときは、適用した理由と箇所、ビジネス的な価値を必ずドキュメント化する
• 止むを得ず独自パッチを適用しているときは、ライブラリのアップデート時にハックが外せないかを調査する
• ビジネス的な価値を失った不要な独自パッチはは積極的にもとに戻す

サービス運用にまつわる引き継ぎ

メトリクスの共有

サービスに障害が発生している時にいつも見ているメトリクスは共有しておきましょう。 メトリクスがなければ、障害が発生しても何がおきているのか、わかりません。

メトリクスにあわせて、障害が発生するときの特徴的な負荷状況を共有しておきましょう。

いつも見るメトリクスに加えて、過去の障害のときの原因となったメトリクスも確認できるように、ダッシュボードをカスタマイズしていきましょう

無視しているアラートの共有

開発に注力するあまり運用やメンテナンスに力を避けていないプロダクトの場合、監視システムからのアラートを無視している可能性があります。 無視する正当な理由があることもあるので、無視しているアラートと理由、(わかっていれば)原因の共有を必ずしましょう。

新年度の切り替わり時などに発生する定期的な警告で無視しているアラートは必ず共有してください。 この引き継ぎをしないと新しい担当者が定期的な障害が発生した時に運用チームから問い合わせを受けても右往左往するしかありません。

稟議が要求されるタスクは作業手順書を作成する

運用チームが顧客情報を見せないなどのためににログ閲覧に制限を設けている場合があります。 ログを取得するために稟議を申請する必要があるときは、作業手順書を用意して後々の作業の負担を減らしましょう。

探求はつづく

プロジェクトの引き継ぎに関するベストプラクティスとアンチパターンを紹介しました。

未発掘のよいプラクティスがあると思うので、要探求です！「こんなのあるよ！」という方はコメントでぜひ教えてください！

プログラムが生み出してくれた価値に感謝することを常に忘れず、プログラムを愛でたいものですね。チャオ！