こんにちは、mofmofでCTOをしている橘です。 この記事では、最近盛り上がりを見せている「開発生産性」や「DevOps」を紹介し、アジャイルプロジェクトへ適用していく方法について書きました。

目次

1. ソフトウェア開発における「開発生産性」とは? 測定の難しさ
2. 「DevOps」とは?
3. 「開発生産性」を改善するための「DevOps」
4. アジャイルプロジェクトの開発生産性を上げるための3ステップ
5. まとめ

ソフトウェア開発における「開発生産性」とは? 測定の難しさ

開発生産性とは簡単に言えば、少ない資源で高い価値を届けられるソフトウェアを生み出せるかどうかです。

資源となるものは

• 人的リソース
• 稼働時間
• 人件費
• その他コスト

などがあります。

対して、高い価値を届けられるソフトウェアを定義するのは難しいです。 高い価値の評価には段階があり、段階を経るほどに評価に時間がかかります。

1段階目 結果を見ず、作業量（PRやストーリーポイントなど）を評価する。定量化や改善がし易い。

2段階目 個々の施策がどの程度プロダクトにとって価値があったかを評価する。

3段階目 売上やKPIなど実際のサービスに対しての貢献度を評価する。

3段階目を測定しようとすると売上など遅効性の指標が多い。 逆に1段階目は、ソースコードの量を測定するのか?ストーリーポイントを測定するのか? という具合に、測定すること自体が難しいのです。

「DevOps」とは?

DevOpsはPatrick Debois氏が提唱した概念です。

DevOpsは、開発と運用が一体となり迅速にビジネスを前進させていくための活動全般を指す言葉として使われています。

当時自動化が遅れていたインフラや運用監視などにも、アジャイル開発を適用し、迅速にフィードバックループを回せるようにする活動が始まりのようです。

https://blogs.oracle.com/oracle4engineer/post/how-dev-versus-ops-became-devops-ja

「開発生産性」を改善するための「DevOps」

開発生産性の測定に、開発に関連する指標を用いることができることを「DORA」という研究プロジェクトが示しました。

DORAは収益性などが高い（=開発生産性が高い）企業が持つ特徴を統計的に分析し、以下の指標が高くなるほどに開発生産性が高いことを示しています。

LeanとDevOpsの科学という書籍に研究結果について記述があるので、気になる方はそちらを参照ください。

これらの指標が良いスコアのチームは、仕事への熱量や満足度も高く、良い結果を出す。すなわち開発生産性が高いことも示されています。 売上やKPIなどを計測しなくていいということにはなりませんが、経過を追う上で有力な指標となりえます。

これらの指標を改善していくためには、本番リリースを行う回数を増やしていく必要があります。

本番リリースを素早く行えない要因（ボトルネック）として「インフラ変更の本番反映」や「リリースまでの承認、レビューフロー」などが上がってきます。

こういったボトルネックを解消するためにDevOpsを推進していきます。

アジャイルプロジェクトの開発生産性を上げるための3ステップ

OKわかった。けど、具体的に何から始めたらいいんだ?

そんな声が聞こえてきます。

一例として以下の3ステップを最初にやるといいでしょう。

1. 現在のプロジェクトの状態を可視化する
2. フィードバック速度を改善する
3. 継続して改善するための文化や仕組みづくり

それぞれのステップについてみていきます

1. 現在のプロジェクトの状態を可視化する

まずは現在の状況をみることが重要です。

現在の開発生産性を可視化するのはもちろん、どのようなフローでリリースが実行されているのか、どのようなスケジュールでプロダクトが成長していくのか、といったことを知るところから始めましょう。

プロジェクトの状況をみるために以下を確認しましょう

• バリューストリーム
• プロジェクトの現在の開発生産性

バリューストリームを確認する

「ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要なプロセス」をバリューストリームと言います。

例えば

• ユーザーからのフィードバックはどう処理されるのか
• 新しい機能を開発する際にどんな人が関わっているのか
• どういう流れで機能設計を行うのか
• 開発体制、開発の流れはどうなっているのか
• どんな確認、承認フローがあるのか
• デプロイの手順は自動化されているのか
• 手動で実行する手順はなにか
• 本番反映後には誰がどのように動作を検証するのか

こういったことを明らかにしておきます。

また、障害があったときの流れも同じように考えておくと良いでしょう。

プロジェクトの現在の開発生産性を確認する

DORAのサイトでにDevOps Quickチェックを実施することができます。

まずはここで現在のプロジェクトの健康診断をしましょう。

開発生産性が改善されているかを確認するためには、最低限デプロイの頻度と変更のリードタイムは追えるようにしておくと良いです。

これを行うためのツールとして以下のようなものがあります。プロジェクトにあったものを選択して継続的にウォッチできる状態にしましょう。

• https://github.com/dora-team/fourkeys
• https://findy-team.io/
• その他プロジェクト管理ツールなど

2. フィードバック速度を改善する

価値のあるソフトウェアを作り上げるために重要なこととして、試行回数を増やすこと。があります。

リーンとDevOpsの科学にこんな一節があります。

「テクノロジーやビジネスをめぐる状況は絶えず変化するもの」という前提に基づいて、組織が継続的な改善を行って進歩していくことが必要

変化する状況に対応できるアジャイル開発と親和性が高く、アジャイル開発を実践しているだけで一定のフィードバック速度を得ることができているはずです。

ここではアジャイル開発を実践していることを前提として、更に開発生産性を上げていく方法の一例を紹介します。

【変更のリードタイムのボトルネックを改善していく方法】

1. 前節「現在のプロジェクトの状態を可視化する」で、変更のリードタイムを可視化
2. リードタイムの長い変更（デプロイ）を見つける
3. デプロイされた作業が実際どのような流れで行われていたのかを追っていく
4. 時間がかかっている箇所を特定
5. 特定できたら、ふりかえりなどを用いて案を出し改善していく

速度を上げるために無茶なリリースを増やすのではなく、安心してリリースできる状態を維持することが大事です。

以下のような改善が効果が高いです。

• コミュニケーションの方法を改善する
• CI/CD周りを改善する
• 自動化を進める、マニュアルを用意する
• など

信頼性の高いリリースをしながら速度を上げていくための即効性のあるソリューションはなく、日々の改善が必要になります。

3. 継続して改善するための文化や仕組みづくり

開発生産性はすぐに改善できるものではありませんし、改善の終わりもありません。

継続的な改善活動を根付かせる必要があり、そのために実践できそうなことを上げてみます。

【問題の原因を人のせいにしない】

ヒューマンエラーによって障害が発生したとして、障害を起こしたくて起こす人はいません。

何かプロセスや仕組みに課題が隠れているはずです。

非難をしてしまうと、障害の要因や、早期発見をした場合に共有しづらい空気が形成されてしまいます。

非難を取り除き、組織的な学習の価値を認めると、「組織は自己診断、自己改善能力を高め、問題の発見と解決の力をつけていく」そうです。

【改善を制度化する】

たとえば

「次の1ヶ月でリードタイムを10%短縮する」

このような目標を立て、仮説を立ててアクションすることを促します。

システムは、手を入れなければ同じ状態でいられるというものではありません。

オープンソースライブラリや外部システム、そして世界は日々改善されており、手を入れないでいることは劣化していくということです。

日常に改善を溶け込ませやすい環境を整えることが大事です。

5. まとめ

開発生産性とDevOps、その改善方法について書きました。

改善は一朝一夕でうまくいくものではなく、小さなところから日常的にやっていくことが重要です。

日常的に改善を回すためにコツコツと取り組んでいきましょう。

mofmofでは月額制の開発サービス「開発チームレンタル」で高品質なプロダクトを素早く開発できるよう、日々改善を続けております。気になりましたらどうぞお気軽にお問い合わせください。

参考文献

• LeanとDevOpsの科学
• The DevOps ハンドブック
• https://cloud.google.com/devops?hl=ja
• https://qiita.com/hirokidaichi/items/53f0865398829bdebef1

など

あなたのビジネスの構造がわかる 一枚のテンプレート【無料】

ダウンロード　→

インセプションデッキの要点を解説 テンプレート付き実践ガイド【無料】

ダウンロード　→