【レポート】GitHub Constellation Conference： DevOps For Business #githubconstellation
はじめに
本記事はGitHub Constellation Conferenceのセッション「DevOps For Business」のレポートです。
レポート
スピーカーは株式会社アトラクタの吉羽 龍太郎さん。
スライドはこちら。
現状
時価総額ランキング2006年と2016年の違い。
2016年はトップ5位が全てIT会社。
ITの会社は利益が出やすい。
現在のビジネス。ビジネスの変化が早くなっている。
GitHubを始め多くのサービスがここ10年で登場。働き方や休日の過ごし方に影響を与えている。
IT自体がビジネス上の成果達成に対し、重要な要素となっている。
ビジネスサイドが何を考えているか。
プロダクトを当てたい。もっと柔軟に対応したい。もっと製品を投入したい...
従来のやり方
要求を全部集めてドキュメント作成。
スケジュールやコストを見積もり。
人をたくさん集めてまとめて作る。
作ったものをまとめて確認。
要求の問題
質問。ウォーターフォール型の開発している人は？→会場には少ない。
顧客が本当に必要だったものは、顧客が説明した要件と違う、というのはよくある。
システムのたくさんある機能のうち、使っているものは？という統計。
2/3がほとんどもしくは全く使われない。
なぜそうなるか？最初に要求を全部集めちゃうから。使わない機能まで集まっちゃう。
使わないもの→無駄。作りすぎてしまったもの。
最初に要求を全部集めてもあってる保証はない。
要求のタイミングが一度しかないと、必要「かもしれない」ものを全部入れ込んじゃう。
ソフトウェアは規模が大きくなればなるほど保守が大変になり開発が遅くなる。
見積の問題
費用とスケジュールの見積は難しい。
不確実性コーン。初期の見積と結果には4倍程度の差がある。
作る人と見積もる人が違うともっと当たらない。
チームが優秀だと早く終わるし、そうじゃなければ時間がかかる。
まとめて作る時の問題
設計、開発、テスト、運用、など、フェーズによってチームが違う。
チーム間で受け渡しが発生する。
受け渡しがあると途中で変更が加えにくい。
まとめて確認する時の問題
頼んだものと違う。バグだらけ。期日に間に合わない。
結果的にビジネスチャンスを逃す...
すなわち
従来のやり方は、一度に扱うサイズ(バッチサイズ)が大きすぎる。
フィードバックサイクルが長すぎる、そもそも回ってない。
リスクが後半になってから顕在化する。
顧客に見せたら頼んだものと違うと言われる。
変化に対応できない。
変化がない領域ではこういうやり方でも構わない。
新規ビジネスに当てはめると、一発勝負。
リリースする期間が長い。
開発にかかるお金が大きい。
かけたコストが回収できるかわからない。
大きな会社だと製品を開発するのに2年以上かかって後手に回るケースもある。
どうしたらいいか
ビジネスとして素早いフィードバックサイクルを回す。
要求、開発、リリース、フィードバック、のサイクル。
要求をマーケットに出してフィードバックを得るサイクルを短期でガンガン回す。
受け渡しのバッチサイズが大きくなればなるほどどんどん遅れが大きくなる。
受け渡しで情報が欠落することもある。
頼んだものと違うものが出来てしまう。
簡単に試す方法。コイン渡しゲーム。
バッチサイズを小さくすることが大事。
まとめて全部やらない。
製造業によくある「一個流し」をする。
短いサイクルでフィードバックを得る。
一度に作れる量は少ないので、大事な要求から順番に実装する。
今何が大事で、何をやるべきなのか、ビジネス側が優先判断をし続ける。
優先判断をまとめてやるのはビジネス側の責任をこなしてない。
頻繁にサイクルを回す→アジャイル開発。
頻繁にサイクルを回すリリースの方法→CI/CD。
CI/CDの前にやらなくてはいけないこと。
漏れがあるまま早いサイクルで回すと問題も早いサイクルで発生する。
大事なのは漏れがあるまま急がない。
ビジネスサイドが練られていない要求を開発に渡してもゴミになる。
ダメな要求を開発側が常に確認し続けて時間が無駄になる。
品質が悪いと後で修正するリソースが必要になる。
ビジネス側は開発チームの能力を超えるプレッシャーをかけてはいけない。
品質の確保が重要
プロダクトやシステムによって求められる品質は異なる。
大事なのは不良を次のプロセスに渡さない。
自分にとって十分ではなく、相手にとって十分なものを引き渡す。
プロセスの逆流が発生すればするほど遅くなる。逆流を防ぐ。
一気に変更すると混乱する。段階を踏む。
逆流率が高ければ高いほど、いつ終わるのか予測がし辛くなる。
ビジネスサイドでは予測ができないのが一番辛い。
直行率を上げる。
不良率の高い工程があると、全体の速度に影響を与える。ボトルネックになる。
不良率の高い箇所を修正する。
それがどこなのかはプロジェクトによって違う、まずはそれを明らかにする。
開発チームだけが問題だとは限らない。
ビジネス側に問題がある場合もある。
ビジネス側の不完全な要求、プレッシャー、割り込み...
問題のある箇所の発見方法
見えないものは改善できない。
バリューストリームマッピング。
色んな現場で試しているが、思っている以上に人によってプロセスに対する理解が違う。
利益を得るための流れや他の部門が何をしているのかがわかる。
データの活用。
データで共通理解を持つ。
大事なのはいきなり全部データをとるのではなく、仮説を検証するためのメトリクスを取ること。
不要な項目のデータをとるのは無駄。
データは全員が見えるようにしないといけない。
データがあると議論の空中戦を避けられる。
事実としての問題を掴み、仮説を立てて、対策の仮説を立てて、ソリューションを適用し、また検証する。
事実を起点に考える。
心理的安全性を確保。
定量的なデータだけでなく定性的な事実も改善のネタになる。
ビジネス側と開発側が一緒になって継続的に改善を進める。
自分たちの仕事を安全に、簡単にする。
安全に簡単になっていないものは改善とは言わない。
忙しすぎると改善できない。
改善や学習の時間の余裕が必要。
強制的に余裕を持たせるための仕組みを作ることもある。
安全に・簡単に、がとても大事。
実現するためのツールはたくさんある。
ツールの重要性を理解する。
安全で簡単なツールを作って、手戻りや無駄を減らす。
そのためには適切な投資が必要。
エンジニアがデファクトスタンダードなツールを使うためにROIなんか不要。
ただし、ツールが全ての問題を解決するわけではない。
短い周期で止まって振り返る。
仕事をしない時間を作る。
自分たちの問題を考える。
短いサイクルほど改善を進めやすい。
ウォーターフォールの場合、プロジェクトが終わってから振り返りをしても次に活かされない。
2週間のような短い周期であれば、問題と解決策を覚えてるし、次に活かすことが出来る。
漏れがなくなったら流れを早くする。
リードタイムを縮める。
待ち時間を減らす。
クロスファンクショナルチームで受け渡し自体を無くす。
自動化、効率化を進める。
プロセスタイムも縮める。
不要な工程を無くす。
一緒にやったほうが効率的な工程を統合する。
逆流がある工程の順番を変える。
工程を単純化する。
流れる量を増やす活動もする。
スループットが増えてキャパシティが空いても、そのキャパシティを全部投入しない。
だいたいのことはアジャイルソフトウェア開発宣言に書いてある。
DevOpsとは結局何なのか
変化するビジネス環境に対応するために、関係者全てが関わる活動。
プロセスやツールではなく、全員で、より早く結果を出すための活動全て。
開発側だけでなくビジネス側も関わりが必要。
さいごに
アジャイルやDevOpsの必要性をビジネスサイドにわかりやすく伝える素晴らしいセッションでした。
