ちょっと話題の記事

DevOps導入支援のヒアリングシートを作ってみた

2018.07.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、DevOps導入支援担当の藤村です。

前回、 DevOps導入支援サービスのご紹介 という記事でご紹介させて頂いた弊社のDevOps導入支援サービスですが、おかげさまで少しずつ問い合わせが増えてきている状況です。その中で、DevOpsという言葉の定義が非常に曖昧なこともあり、お客様によってDevOpsのイメージやDevOpsに期待することなどが異なっていることも多いと感じてました。そこで、支援を希望するお客様との期待のすり合わせ用にヒアリングシートを作ってみたので、その内容をご紹介します。

ヒアリングシート

まず始めにDevOpsを導入する目的に関する質問です。

1. DevOpsで解決したい明確なビジネス目標はありますか?

○ある ○ない

2. 「ある」と答えた方は、解決したいビジネス目標についてお聞かせください。

________________________________

DevOpsを導入する際には、DevOpsで解決したい明確なビジネス目標が不可欠です。これが無いままDevOpsの導入を試みてしまうと、目的がDevOpsを導入することになってしまい、いわゆる手段の目的化に陥ってしまいます。この質問に即答できない場合は一度立ち止まり、今の組織の本当の課題は何か、その課題に対してDevOpsは有効か、などの観点からお客様との対話を始めます。

次に、具体的に改善したい項目についての質問です。

3.改善したい具体的なメトリクスはありますか?

○ある ○ない

4.「ある」と答えた方は、改善したいメトリクスを教えてください。

□リードタイム

□メインブランチへのコミット頻度

□1日あたりのビルド回数

□回帰テストに要する時間

□プロダクションへのデプロイ頻度

□本番デプロイ成功率

□サービスを復元するまでの時間

□開発ベロシティ(速度)

□その他

ここで確認したいのは以下の二点です。

  • 具体的に改善したいメトリクスが定義されているか
  • メトリクスが質問2の解決したいビジネス目標とマッチしているか

DevOpsに限らず、何か新しい行動を起こす際には、その行動が有効だったのかを検証するために以下の流れで進めることが重要です。

  1. 目標を立てる
  2. 目標に関連するメトリクスを定義する
  3. 定義したメトリクスの現在の値を計測する
  4. 行動を起こす
  5. 定義したメトリクスの行動の後の値を計測する
  6. メトリクスが改善したかどうかを検査し、次の行動計画に適応させる
  7. 4に戻る

そのため、具体的に改善したいメトリクスが定義されているかを質問しています。もし定義されていない場合は、ビジネス目標に対してマッチしているメトリクスは何か、そのメトリクスの現在の値はどうやって計測するかなどの観点から支援を検討します。なお、羅列しているメトリクスは書籍からの引用や、思いついたものをざっと書き出しているだけなので、今後もアップデートしていく予定です。

続いて、開発チーム外(ステークホルダーなど)から見た課題感についての質問です。

5. 開発チーム外(ステークホルダーなど)から見た開発チームの課題はありますか?

○ある ○ない

6. 「ある」と答えた方は、開発チームの課題を教えてください。

□開発スピードが遅い

□費用対効果が悪い

□品質が悪い

□期日を守れない

□イメージした通りの物ができあがってこない

□その他

ここでは事実を知りたいわけではなく、開発チームと経営陣含むステークホルダーとの関係性を知りたいという意図があります。DevOpsは開発チームからのボトムアップだけで進めることが非常に難しく、導入には経営層の理解が不可欠です。その中で、経営層が自社の開発チームのQCDなどに不満を持っていたり、逆に開発チームが経営層の意思決定などに不満を持っているような文化の組織ではDevOps導入の前に、まずはお互いを尊重して理解しあうところから始める必要があると考えています。

この後は、現状の開発プロセスや開発基盤に関する質問を用意しています。

※回答の選択肢は、○はい、○どちらともいえない、○いいえ、の三択です

7. 開発する機能の多くは会社、プロダクトのビジョンに沿っていますか?

8. 信頼できる開発スケジュールがありますか?

9. 開発スケジュールは変化を受け入れることができますか?

10. 仮説を持って開発する機能を決めていますか?

11. 開発チーム外(ステークホルダーなど)から開発チームの状況を簡単に把握することができますか?

12. 開発チームは短い期間で定期的に価値ある機能を完成することができますか?

13. 完成した機能の多くは発注者がイメージした通りですか?

14. デグレードは頻繁に発生していますか?

15. リリース後にバグが見つかることが多いですか?

16. リリース後にバグが見つかったら、すぐに以前のバージョンに戻すことができますか?

17. リリース後、開発した機能が想定した価値を発揮しているか確認できますか?

18. チームに新しく入った開発者は、初日から開発に貢献できますか?

19. チームに新しく入った開発者は、初日からデプロイ作業ができますか?

20. 開発者、開発チームは疲弊していますか?

これらの質問に対する回答を見ることで、現状の開発プロセスや開発基盤の成熟度がある程度見えてくるため、お客様に有効な開発プロセスや開発基盤を検討する際の参考になります。

おわりに

いかがでしたでしょうか。このヒアリングシートもお客様からのフィードバックを元にどんどん更新していきたいと考えておりますので、こんな質問もあった方が良いのでは!とか、こんな質問したところで意味ないのでは!など、色々とフィードバックを頂けると大変ありがたいです。

それでは。