TechTrend #1：DevOpsにつながるソフトウェア開発プロセス再考に参加した。その時のメモ。
とても有益だった。

Countir

ファイナンスの未来に、答えを。
ブロックチェーンに取り組んでいるらしい。

DevOpsにつながるソフトウェア開発プロセス再考 – 長沢智治氏

・DevOpsの定義はないため、スコープは人によってさまざま
・「現場の解は現場にしかない」
　今日学んだことを実践するというよりは、自分たちのビジネスの立ち位置を考えて
　どう動くかチームでコンセンサスしていくことが重要

時代の流れとIT

・確立したビジネスがあり便利な道具としてITを使うモデルから、ITありきのビジネスモデルに変化してきた
　時代は変わる、つまりソフトウェア開発手法も変えるべきなのかもしれない
・ユーザがダイレクトに伝えられる時代になってきている
　そのため意思決定はユーザや競合他社の状況も含めて判断しなければならないため
　CMO(Chief Marketing Officer)の重要性が上がっている
・つまり意思決定権は市場が主導となっている
・より顧客にリーチするにはどうすればよいか？といった攻めるプロダクトも必要
・品質について、コード品質からシステム品質に重要性が移り
　現在はビジネスとして品質が担保されているかどうか？がポイントに
　コードの品質が悪くとも、ビジネスの品質が高いということもある
・ステイシーマトリックスでいうと90年代は単純であったが、現在は無秩序

アイアントライアングルと開発手法

・Quality(品質)はある程度守るという前提で
　Scope(要件)、Cost(費用)、Delivery(納期)の全ては固定できない
　どれを守るか？が重要
・ウォーターフォールとアジャイルで固定するものは違う
　ウォーターフォール：要件(S)を固定して、工夫してコスト(C)と納期(D)を検討する
　アジャイル：一定の期間(D)で、一定のチーム(C)で、できる範囲(S)を実施していく
・アジャイルではその時々で優先順位の高いもの、できるものから処理していく
　つまりスプリントごとに価値を見直すため、結果として従来型よりも価値を高めやすい
・アジャイルでは、このチームでこの期間で、どれくらいのことができるか？が明確となり、予測できるようになる

チームと集団

・集団でなく、チームであるべき
　・共通の目的と成果
　・やり方を共有
　・フォロー関係
・ビジネスする場合は集団も必ずある(開発班と企画班)が、DevOpsのためにはチームになる必要がある
　そのためには共通の目的を持つこと

知らなかったサービス

質問を匿名で受け付けるツール
https://www.menti.com/