Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。Experience)やアジャイル開発と並び注目されている開発生産性。Keys)を測定する手法が一般的だ。この講演では、DMM.com合同会社でプラットフォーム事業本部・メンバーシップサービス部部長を務める石垣雅人氏が、同社における生産性向上の手法や意識、仕組みなどを紹介した。石垣氏の講演は、開発生産性に関する主要なレポートの紹介から始まった。Engineering(DPE)」を挙げ、メトリクスや時流については「この2つを抑えておけば大丈夫」としている。メトリクスのサービスの発展は目覚ましく、ログ収集やCI/CDにおいてはGithubでソースコード管理を行うことで、プルリクエストまでの時間やデプロイ回数の計測が可能になった。コード品質やチームパフォーマンスに貢献するツールも増えており、生産性に関するさまざまな要素が数字として可視化されている。した状況を背景に、"推測するな、計測せよ"というワードは現実的な位置まで来た。「開発以外の部分も含めたソフトウェアライフサイクルの計測が現実的なラインが出てきている」と石垣氏は実感を語る。パイプラインも充実し、現在ではDMMに所属するエンジニア約1200名の生産性データが集積されたリポジトリと連携することで、組織全体の生産性を向上させている。メトリクスツールが生産性を押し上げるここでいう開発生産性の範囲は、(1)組み込みやミドルウェアを含まないソフトウェアであること、(2)DevOps周辺の生産性であること、の2点だ。Keysについての議論はDevOpsがその中心となるが、歴史をたどると2001年ごろにアジャイルや後を追うようにクラウドの概念が出てきて以降、「小さいチームでオーナーシップを持ちながら適切なプロダクトサイズで改善サイクルを回していく」という流れが起きたことが、今日まで続く大きな技術革新の源泉だという。Developersという1つのチームで設計からオペレーションまでを実行する流れができました。Engineering(DPE)に繋がってきます。技術革新によって開発者体験・サイズが変化このように歴史を振り返ったうえで、石垣氏は開発生産性にまつわる議論を順に確認する。Keysの指標を「改善」したことによる悪影響、(3)DevOpsの生産性=組織の生産性「ではない」ために生じる、「何をもって生産性とするか」という議論だ。(1)生産性の測りづらさについて、たとえば以前では、ソースコードの行数をもとに開発生産性を測るような時代もあった。この手法には言語の違いやソースコードの効率といった要素が含まれておらず、適切な指標といえないのは周知の事実だ。Keysの指標を「改善」したことによる悪影響については、一例として、デプロイ回数を増やしてインターフェースを頻繁に変更するようなケースが挙げられる。このような取り組みを続けていると、ユーザーの使い心地は損なわれ、コミュニケーションコストが上がってしまう。クリティカルな議論は、(3)「何をもって生産性とするか」だ。開発生産性を語るにあたり、DevOpsの生産性と組織全体の生産性は同一視されがちだ。実際には、デプロイ開発のサイクルタイムと組織が仮説を立ててそれをリリースするまでのリードタイムは一致しないことも多く、「何を、誰のために計測すべきかを見極めなければ無意味な指標になってしまう」と石垣氏は警鐘を鳴らす。「生産性」が何を指すのか立ち止まって考えることも重要こうした議論のもと、石垣氏は「何を計測するべきかについては、デプロイ回数などのアウトプット量ではなく、時間単位でのプロセスの推移を見るべき」と語る。誰のために計測するかという部分では、「『プルリクからマージまでを高速化したい』といったチーム内部での課題なのか、『開発組織のかける予算が適切か』『意図したタイミングでリリースされないことへの疑問による生産性への問い』といったチーム外への働きかけなのか、目的意識の明確化が不可欠だ」とする。Keysをはじめとする開発生産性の計測に注力しすぎないことも重要なポイントだという。データ化はあくまで課題解決のための手段に過ぎないため、「メトリクスを取るのにリソースをかけすぎず、手を動かして改善するという課題解決に時間をかけるべき」というのが、上記の議論に対する石垣氏の答えだ。DevOpsの生産性と組織の生産性について、DMMではこれらが一致しているかを判断するため、プロダクト開発時に現状把握と将来像の明確化を目的としたプロセス図「バリューストリーム」を作成することが多い。石垣氏はさらに、「変更承認の合理化」について話を進める。諸々の議論があるとはいえ、ソフトウェア開発においてスピード感を持った開発が競争優位性を高めることは一定の合意を得ている。実際の現場においては、経営層や事業責任者の承認を得るまでに時間がかかり、「開発は2日で終わったのに、リリースまでに2週間かかる」ような状況もざらだ。原因として考えられるのは社内での「承認」に関する課題が多く存在する。した状況を改善しなければ、いくらDevOpsが生産性を高めようとも組織に与えるインパクトは限定的になる。そこで改善の指針となるのが、「変更承認の合理化」4か条だ。「手動による変更承認なしで実稼働環境にプロモートできるか」「運用上の変更は、展開または実装前に外部機関の承認を受ける必要があるか」......これらのポイントを先ほどのバリューストリームと突き合わせながら自己点検することで、DevOpsと組織の生産性をイコールに近づけていくのだ。その後テクニカルライターを経て、2021年にフリーランスライターとして独立。Webメディアを中心に活動しており、広くビジネス領域での取材記事やニュース記事、SEO記事の作成などを行う。シン)インタビュー、ポートレート、商品撮影写真をWeb雑誌中心に活動。※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容ですこの著者の最近の執筆記事CodeZine編集部(コードジンヘンシュウブ)CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。