TechTrend #1:DevOpsにつながるソフトウェア開発プロセス再考 に参加した

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/

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください