イノベーションと開発プロセス

RCO アドテク部 社内勉強会(2014/11/05)での発表資料です

Transcript

1. + イノベーションと開発プロセス RCO アドテク部 コアテクG　阿部 直之 2014/11/05
2. + ターゲットとゴール n ターゲット n  サービス / システム開発においてプロセス改善を行う人 n  プランナーとエンジニア、でも主にエンジニア n ゴール n  新しい開発プロセス / 手法が求められる背景を概観 n  最近取り上げられている各プロセス / 手法をざざっと紹介 最後はだいぶ駆け足になりますデス…(*´～｀*)｡o◦ 2
3. + ここ最近の流行りワード（一部） n  継続的デリバリー n  CI n  テスト自動化 n  DevOps n  Git Flow n  Pull Request開発 n  TDD n  ビルド自動化 n  E2Eテスト n  TiDD n  情報の共有 n  ChatOps n  コードレビュー n  デプロイ自動化 このあたりのトピックが求められる背景をまとめてイキマス…(*´～｀*)｡o◦ 3
4. + 今日の内容 n まず目指すべきイノベーション n サービス開発で目指すもの n システム開発が実現すべきこと 4 だいぶ風呂敷広げすぎてマス…(*´～｀*)｡o◦
5. +まず目指すべきイノベーション
6. + イノベーション n  イノベーション（innovation）とは、物事の「新結合」「新機 軸」「新しい切り口」「新しい捉え方」「新しい活用法」（を 創造する行為）のこと。一般には新しい技術の発明と誤解され ているが、それだけでなく新しいアイデアから社会的意義のあ る新たな価値を創造し、社会的に大きな変化をもたらす自発的 な人・組織・社会の幅広い変革を意味する。つまり、それまで のモノ・仕組みなどに対して全く新しい技術や考え方を取り入 れて新たな価値を生み出して社会的に大きな変化を起こすこと を指す。 出典： http://ja.wikipedia.org/wiki/イノベーション 6 Wikipediaまるまる抜き出し…(*´～｀*)｡o◦
7. + 2つのイノベーション n 破壊的イノベーション n  破壊的技術とは、従来の価値基準のもとではむしろ性能を低下させ るが、新しい価値基準の下では従来製品よりも優れた特長を持つ新 技術のことである。また、破壊的技術がもたらす変化を破壊的イノ ベーションという。 n 持続的イノベーション n  持続的技術とは主流市場の主要顧客が評価する性能指標（すなわち、 従来の価値基準）のもとで性能を向上させる新技術のことである。 持続的技術がもたらす変化を、持続的イノベーションという。 出典： http://ja.wikipedia.org/wiki/破壊的技術 7 日本では破壊的イノベーションが求められがちデスガ…(*´～｀*)｡o◦ 今回目指すのはこっち 市場のルールを変えてしまう系
8. + 持続的イノベーションは視点の転換 PDSやPDCAとか呼ばれる ループの横からの視点 実はスパイラルに上昇してる 8 未来へのスパイラル。。。…(*´～｀*)｡o◦
9. + イノベーションイメージ この縦の変化がイノベーションのはず ここを最大化できれば勝つる！ 9 オレ理論な上に雑なイメージですみません…(*´～｀*)｡o◦
10. + 負のスパイラルもありえるわけで 10 まずは正のスパイラルを目指すサービス開発を考えます…(*´～｀*)｡o◦ こうならないための開発プロセスを考えます n 頑張るほど赤字になっていくサービス n やればやるほど泥沼にはまっていく現場 n そして疲弊していくメンバー
11. +サービス開発で目指すもの
12. + サービスを開発すること n 実現すべき未来を予測し開発 / 発展させていく n  ユーザに新しい価値を提供 n  新しい市場を開拓していく 12 サービスを開発するのは新たな世界を作ることカモ…(*´～｀*)｡o◦ n ビジネスとして目指す基準を達成する n  課金価値を高めることで利益を上げる n  （他サービスのための）集客の入り口として人を集めていく n  時期サービスの布石としてコミュニティを作る。。。等 当然会社組織としての活動なので
13. 13 でも完全な予測なんて無理だよね…(*´～｀*)｡o◦
14. + 見えない未来をつくるために n サービスの評価はユーザ（市場）が行うものである n ユーザの行動を100%予測することなんてできない 14 検証なので取り下げることも念頭に入れてるわけデス…(*´～｀*)｡o◦ コンフリクトした無限ループ 実際にユーザにぶつけて確かめてみるしかないじゃん ⇛ 必要なのは市場に対する仮説と検証
15. + 仮説検証 vs いきあたりばったり 1.  何を実現すべきで実現したらどうなるか？を仮説立てる 2.  立てた仮説が正しいかどうかを実際に検証する 3.  検証結果を受けて新たな仮説を立てていく 15 行き当たりばったりをAgileとよぶ人がいるトカ…(*´～｀*)｡o◦ 仮説検証ループ いきあたりばったりループ 1.  何か思いつく 2.  とりあえず試す 明らかに違うよね
16. + 仮説検証を高速に繰り返す n サービスリリースの速度はどんどん高速化 n  インターネットの発展とか、市場の動きの活発化とか n  時間をかけて準備してリリースして、では遅すぎる n 検証すべき仮説の粒度を小さくし、そのぶん手数を増やす n  何を確かめるのかを明確化し、仮説内の変数を極小化 n  粒度を小さくすることでリリース速度を早くする n  仮説をシンプルにすることでシステムがなくても検証可能 16 仮説検証を高速に回すためには。。。 細かく手数を増やしてフィードバックをたくさん得る的な…(*´～｀*)｡o◦
17. + 粒度ざっくりの予測 粒度の小さい仮説と検証の例 n サービスへのSNS連携機能が必要であろう n  SNSが流行ってるから連携すればユーザ数が増えるはず n  既存ユーザもSNSと連携することで満足度があがるはず n SNSに投稿機能を追加すると新規ユーザが増える的な仮説 n  SNSへの投稿からサイトへのユーザ流入が投稿数の◦%発生する仮説 n  全アクティブユーザのうち△%がSNSへの投稿を行うはず仮説 n  結果的に新規ユーザ数の増加が▪%になるはず仮説 17 仮説の達成基準は明確にするのが大切そうな予感…(*´～｀*)｡o◦ 粒度小さめの仮説検証に分解 何確かめる？ どう確かめる？ 何作る？ これはシステム無くても 確かめられそう
18. + サービスを発展させるために n 何を作る？よりはどんな仮説を検証する？ n 小さな仮説検証を高速に繰り返していく n 次々と新たな機能をリリースし続けていく 18 ようやっとシステム開発の話に入るよ…(*´～｀*)｡o◦ これらを実現するシステム開発プロセスを考えます
19. +システム開発が実現すべきこと
20. + サービス開発からシステム開発へ n 共有すべきものは機能の仕様だけではなく仮説 n  エンジニアも仮説からの機能の洗い出しにコミットする姿勢 n  仮説検証にコミットできるエンジニア → グロースハッカー n 検証を含めたリリース計画 n  リリースしたら終了、ではない意識 n  機能（仮説）の達成基準に対してコミットする姿勢 n とにかく高速な開発 / リリースが必要 n  高速仮説検証サイクルのボトルネックになってはいけない n  コンパクトで高速な本番リリースの実現 20 エンジニアがサービスにコミットすることが求められてマス…(*´～｀*)｡o◦ エンジニアが 最も注力すべき なのはきっとここ
21. + システム開発プロセス n 継続的なサービス開発/リリースが求められている n  ビジネスプランがどのくらい良いものなのかをより素早く評価したい n  素早いリリースにより継続的なフィードバックを得る n  継続的なフィードバックによりビジネス価値の向上とムダの削減 n  市場の変化に対応し、競争優位性を築き上げる n 実現すべきなのは継続的デリバリー n  ユーザー（市場）への持続的かつ高速なソフトウェアの提供 21 一旦ここを起点にしますネ…(*´～｀*)｡o◦
22. + 継続的デリバリー n 概要 n  ビジネスや市場の環境に対応するために、継続的にソフト ウェアを改修・機能追加し、迅速に提供していくという概念 n  継続的なフィードバックにより競争優位性を築き上げる n ターゲット n  高速なサービス開発 / リリース n  持続的なサービス開発 / リリース n ベースになるトピック n  CI、DevOpsなど 22 各トピックはこの程度で納めるので続きはWeb(検索)で…(*´～｀*)｡o◦ 出典: 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 (2012/3/14) David Farley (著), Jez Humble (著), 和智 右桂 (翻訳), 高木 正弘
23. + 継続的デリバリーの2つの要素 持続的かつ高速なサービス開発 / リリース n 高速なサービス開発 / リリース →　開発サイクルの高速化 n 持続的なサービス開発 / リリース →　技術的負債の軽減 23 もうちょっと分解してイキマス…(*´～｀*)｡o◦
24. + 開発サイクルの高速化 それでは阻害要因となるものは？ n  開発速度がそもそも遅い n  右往左往するような複雑なワークフロー n  大量の手作業 n  あやふやな仕様による手戻りの発生 n  状況の変化により発生する空きリソース 24 。。。が大事なのはわかっているの･ﾟ･(つД｀)･ﾟ･ ｳｪ―ﾝ あくまで一部ですが結構ままならないものたちデス…(*´～｀*)｡o◦
25. + エンジニアが頑張らなくていい部分 プロセスを改善することで解決でき そうな。。。ε=＼＿◦ﾉ ｲﾔｯﾎｰｩ！ 現場のエンジニアは もうだいぶ頑張ってるよね･ﾟ･(つД｀)･ﾟ･ 開発サイクルを高速化する要素 n 開発自体の高速化 n 冗長な工程を短縮 n 手作業の省力化 n 変更サイズの極小化 n 手戻りの削減 n リソース活用の最適化 25 ここらへんでだいぶ高速化は実現できるハズ…(*´～｀*)｡o◦
26. + 技術的負債の軽減 n  ソフトウェアに賞味期限がある n  時間が経てば立つほど複雑になるコード n  ちょっとの変更から大量のバグ発生 26 参考: https://www.slideshare.net/sifue/developers-summit-2014-play2scalaweb 大規模サービスの動きが遅くなる原因デスネ…(*´～｀*)｡o◦ n THE 技術的負債 n  サービスが大きくなるにつれて動けなくなる現場 n  しかも時間の経過とともに負の利子が増えていく n  技術の陳腐化、チープなコード、情報の散逸・属人化などが原因 時間 技術的負債 によって身動きがとれなくなるイメージ
27. + 技術的負債の軽減するための要素 n 利用技術の陳腐化 n ソフトウェア複雑度の軽減 n 情報の集約 n 知識の属人化の防止 n リファクタリングの簡易化 27 先人の知恵に学べ！は大事デスネ…(*´～｀*)｡o◦ ココは防ぎようはないよね･ﾟ･(つД｀)･ﾟ･ 様々なチャレンジがされている領域 各種ツールやメソッドを取り入れる ことで改善できそうな。。。 ε=＼＿◦ﾉ ｲﾔｯﾎｰｩ！
28. + 高速化と技術的負債への挑戦 これらの要素に各種メソッドでアプローチします n  冗長な工程を短縮 n  手作業の省力化 n  変更サイズの極小化 n  手戻りの削減 n  リソース活用の最適化 28 n  ソフトウェア複雑度の軽減 n  情報の集約 n  知識の属人化の防止 n  リファクタリングの簡易化 解決すべき課題群はこちらですね…(*´～｀*)｡o◦
29. + 【再掲】ここ最近の流行りワード n  継続的デリバリー n  CI n  テスト自動化 n  DevOps n  Git Flow n  Pull Request開発 n  TDD n  ビルド自動化 n  E2Eテスト n  TiDD n  情報の共有 n  ChatOps n  コードレビュー n  デプロイ自動化 それじゃ配置してみます…(*´～｀*)｡o◦ 29
30. 30 さあ、こっからスーパーオレオレ理論タイムです
31. + 各技術要素の分布 高速な開発の実現 技術的負債の軽減 継続的デリバリー CI テスト自動化 DevOps Git Flow Pull Request開発 TDD E2Eテスト TiDD 情報共有化 デプロイ自動化 コードレビュー ビルド自動化 スクラム開発 31 ChatOps 実行トリガ 下から順に 導入してくのが オススメ
32. 32 各トピックを見ていきますが、概観なので詳しくはWeb（Google）で
33. + DevOps 33 n 概要 n  「Development）」と「Operation（運用）」を組み合わせた言葉 n  開発と運用と評価を短いサイクルで繰り返し仮説検証を高速化 n  デプロイや運用の自動化などにより高速のリリースを実現 n ターゲット n  冗長な工程の簡略化 n ベースになるトピック n  デプロイ自動化、CIなど インフラと開発のコラボレーション…(*´～｀*)｡o◦
34. + ChatOps 34 n 概要 n  Chatからのコマンドによる各種プロセスを実行 n  専門知識がなくても各種オペレーションが可能 n  自動化（スクリプト化）の過程によりフローが明確化 n  様々なコマンドの組み合わせで複雑な処理も可能に n ターゲット n  冗長な工程の簡略化、手作業の軽減、知識の属人化の防止 n ベースになるトピック n  デプロイ自動化、ビルド自動化、テスト自動化など 動きが未来っぽいってだけで自分は好きです…(*´～｀*)｡o◦
35. + ChatOpsの例 35 botとbotが入り交じる…(*´～｀*)｡o◦
36. + CI（継続的インテグレーション） 36 n 概要 n  ソフトウェア開発時の品質改善や納期の短縮のための習慣 n  狭義にはビルドやテストなどを継続的に実行していくこと n  頻繁なビルド・テストにより各種問題の早期発見 n ターゲット n  手作業の軽減、ソフトウェア複雑度の軽減、手戻りの削減 n ベースになるトピック n  ビルド自動化、テスト自動化など 何かのトリガーを検知して頻繁にプロセスを回すアイツです…(*´～｀*)｡o◦
37. + デプロイ自動化 37 n 概要 n  自動化することで細かく高速なリリースが可能 n  ヒューマンエラーの防止 n  コード化に寄るインフラ作業等の可視化 n ターゲット n  冗長な工程を短縮、手作業の軽減、知識の属人化の防止 n ベースになるトピック n  サーバ構成管理ツールなど インフラもプログラマブルに管理する時代デス…(*´～｀*)｡o◦
38. + ビルド自動化 38 n 概要 n  自動化することで細かく高速なビルドが可能 n  ビルド手順の明確化による人依存の防止 n  ヒューマンエラーの防止 n ターゲット n  冗長な工程を短縮、手作業の軽減、知識の属人化の防止 n ベースになるトピック n  各種ビルドツールなど（手作りのスクリプトでもいけるはず） 同じような作業は自動化デスね…(*´～｀*)｡o◦
39. + テスト自動化 39 n 概要 n  テスト支援ツール等を使うことでソフトウェアテストを自動化 n  小さな変更でも繰り返しテストを行うことで問題を早期発見 n  カバレッジの計測などによるテスト状況の分析 n ターゲット n  冗長な工程を短縮、手作業の軽減、手戻りの削減 n ベースになるトピック n  各種テストツール、TDDなど 開発初期からテストを作っているとここで楽できマス…(*´～｀*)｡o◦
40. + E2Eテスト 40 n 概要 n  システム全体が正しく動くことを確かめるテスト n  Webシステムではブラウザからのテストも含める n  最近ではフロントエンドからの通しテスト、というのが多いような n  ユーザ影響の一番大きい領域で早期の問題発見 n ターゲット n  冗長な工程の省略、手作業の軽減、リファクタリングの軽減 n ベースになるトピック n  フロントエンドのクロスブラウザテストなど かなり人的コストのかかる領域の自動化だったりしマス…(*´～｀*)｡o◦
41. + スクラム開発 41 n 概要 n  開発チーム一体で目的を追い求める柔軟なプロダクト開発方略 n  スプリントを基準としてチーム開発を進める n  スクラムマスター・プロダクトオーナー等の役割を基にチーム運営 n  メンバー間のコミュニケーションを重視して効率を最大化 n ターゲット n  手戻りの削減、リソース活用の最適化、情報の集約 n ベースになるトピック n  TDD、TiDDなど スクラムは本来もっと広い領域を指すので↑は意訳デス…(*´～｀*)｡o◦ 出典: SCRUM BOOT CAMP THE BOOK (2013/2/13) 西村 直人 (著), 永瀬 美穂 (著), 吉羽 龍太郎 (著)
42. + 情報共有化 42 n 概要 n  情報や知識の一元集約、透明性の向上 n  全てを記録・言語化することで暗黙知を形式知に n  幅広い共有と適切なアクセス管理がキモのような。。。 n ターゲット n  知識の属人化の防止、情報の集約 n ベースになるトピック n  情報集約など 情報は全ての下地になりますナ…(*´～｀*)｡o◦
43. + Pull Request開発 43 n 概要 n  Pull Requestをベースにしたコードコミュニケーション n  コードレビューの開発フローへの組み込み n  Pull Requestを起点に各種自動化につなげる流れも有り n ターゲット n  知識の属人化の防止、ソフトウェア複雑度の軽減 n ベースになるトピック n  Git Flow、コードレビューなど GitHubが生み出したコードベースコミュニケーション…(*´～｀*)｡o◦
44. + Git Flow 44 n 概要 n  Gitブランチを利用した開発フロー n  各機能の開発が他の変更に依存せずに進められる n  ブランチのカテゴライズとマージプロセスの指針を提示 n ターゲット n  変更サイズの極小化 n ベースになるトピック n  TiDD、Gitなど Gitのブランチングはマジ必須…(*´～｀*)｡o◦
45. + コードレビュー 45 n 概要 n  ソースコードの体系的な検査 n  コードの内容をチームが共有できるきっかけになる n  誤りの発見だけでなく学習・教育の場としても機能する。。。はず n  発展形としてペアプロなどが存在するような n ターゲット n  知識の属人化の防止 n ベースになるトピック n  ソフトウェアインスペクションなど 昔からあるトピックですが、やはり大事なものは大事です…(*´～｀*)｡o◦
46. + TDD 46 n 概要 n  プログラムの必要な機能についてまずテストを書く n  書いたテストを満たす最低限の実装を行い、洗練させていく n  テストに書き出すことで仕様を明確化できる n  テストサイズによって仕様の膨張を検知できる。。。はず n ターゲット n  変更サイズの極小化、手戻りの削減、リファクタリングの軽減 n ベースになるトピック n  ユニットテストなど 開発初期からテストを作るきっかけになりマス…(*´～｀*)｡o◦
47. + TiDD 47 n 概要 n  作業をタスクに分割しBTSのチケットに割り当てて管理を行う n  チケットなしのコミットを禁止することで、タスクを可視化 n  成果物の更新が必ずチケットと関連するので情報が集約しやすい n  チケットサイズによって仕様の膨張を検知できる。。。はず n ターゲット n  変更サイズの極小化、リソース活用の最適化、情報の集約 n ベースになるトピック n  BTSなど 各メンバーの作業量も把握しやすくなりマス…(*´～｀*)｡o◦
48. 48 それではまとめますヽ(ﾟДﾟ )ﾉ
49. + そしてイノベーションへ イノベーション = 　リリース価値 − コスト − 技術的負債 49 適切な仮説検証で 最大化 高速開発で最小化 様々な施策で最小化 あくまでオレオレ理論ですが…(*´～｀*)｡o◦
50. + まとめ n サービス開発の目的は高速な仮説検証サイクル n  システムにより検証すべき仮説を明確に n 持続的かつ高速な開発 / リリースによる仮説検証の実現 n  エンジニアがサービスにコミットする意味 n 上記を実現するための様々なトピックがたくさん n  使えるものは何でも使う総力戦の時代へ n  ちょっとでも琴線に触れたモノがあれば使ってみてください n  プロジェクトへの適用もまた仮説検証ですすめる感じで 50
51. + 参考 n  リリースの高速化はWebサービス企業にとって最重要である - delirious thoughts http://blog.kentarok.org/entry/2014/05/29/024953 n  「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた - delirious thoughts http://blog.kentarok.org/entry/2014/03/15/224227 n  Slack x Hubot 勉強会で発表した資料 http://ja.ngs.io/2014/10/25/hubot-lt/ n  エンジニア×デザイナー GitHubで変わるコミュニケーション http://www.slideshare.net/HiroyukiYamaoka/phpcon2014-p4d-yamaoka n  アトラシアン製品ではじめるスクラム運営 (1) JIRA Agile と Confluence でのバックログ http://re-workstyle.com/articles/value-of-atlassian-toolchain-01/ n  社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアッ プ導入)について http://www.slideshare.net/i2key/ss-38266796 n  Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションの スクラム開発の勘所」 http://www.slideshare.net/sifue/developers-summit-2014-play2scalaweb n  KAIZEN platform Inc. の開発マネジメント https://speakerdeck.com/naoya/kaizen-platform-inc-falsekai-fa-manezimento 51