(レポート)[JAWS Festa 2016] いまさらきけない、なんでアジャイル?なんでクラウド? #jawsug #jawsfesta

(レポート)[JAWS Festa 2016] いまさらきけない、なんでアジャイル?なんでクラウド? #jawsug #jawsfesta

Clock Icon2016.10.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本レポートは2016年10月22日(土)に開催されたJAWS Festa 2016のセッション「いまさらきけない、なんでアジャイル?なんでクラウド?」のレポートです。

本セッションのスピーカーはアトラシアン(株)の長澤 智治さん。

nagasawa_at

レポート

現在の状況

・以前はデベロッパー戦国時代。現在はビジネスの戦国時代。
・ビジネス戦国時代において、デベロッパーは武将。武器はテクノロジー。
・90年代、ITは確立したビジネスモデルにおける便利なツールだった。
・00年代、EコマースやWebの時代には、ITは有効的なツールだった。
・現在、テクノロジーありきでビジネスが作られるようになった。
 ・ビジネスにおいてテクノロジーは不可欠。
 ・意思決定者がIT部門からマーケット、コンシューマーに変化。
 ・CIOの予算がCMOに移ってきている。
・その変化の中で、アジャイル、クラウド、リーンスタートアップがキーワードとして出てきた。
 ・私たちが考えなければいけないのは、今自分たちの状況がどこなのか、お客様の状況がどこなのか。
 ・お客様の状況によって提供できるビジネスが変わる。
 ・テクノロジーだけではなく社会的な最新動向もチェックしなくてはいけない。
・ビジネスを変えるテクノロジー。
 ・デバイス。インターフェース。
  ・ガラケー時代、キャリアが動向を握っていた。
  ・スマホ時代はアプリによってビジネスの逆転が可能。
 ・クラウド。つながる仕組み。
  ・ビジネスを支える基盤。
 ・IoT。
  ・データ活用に繋がっていく。
・ビジネスを作り、広げる力がテクノロジーにある。
 ・テクノロジーによってお客様に直接タッチし、学ぶことができる。
 ・これまでのビジネスよりスピードが速く、競争が厳しい。

アジャイル

・これまでは、ゴールがあったので要件定義が明確、途中の経過も決まっていた。
・ビジネスモデルが速く変わる今の時代、遠いゴールが立てづらい。
 ・道のりがわからないなら、まずは簡易的に、徐々に組み立てて高機能に。
 ・仮説を検証し組み立てていく。それがアジャイル。
・お客様にマッチしているのがアジャイルなのか、これまでの方式なのか、よく考えて適用する。
・アジャイルの拠り所。アジャイルソフトウェア開発宣言
 ・できたのが2001年。
 ・経営者にとっては現場主義に見える、分かりづらい。
 ・最近はモダンアジャイル(今の時代にあったもの)を作ろうという動きがある。
・2005年、経営者にアジャイルを伝えるものが「相互依存宣言」。
 ・経営者にも分かりやすい言葉で書いている。
・アジャイルの代表例。
 ・スクラム。
  ・要件(プロダクトバックログ)に対して見積(プランニングポーカー)を立てる。
  ・優先順位を動向によって組み替える。
  ・チームで対応できるターゲットを決め、プランを立てて、バーンダウンで処理。
  ・非常に短いスパン(スプリント)でターゲットを開発。
  ・デモを見せることができなければそのスプリントは失敗。
 ・カンバン。
  ・詳しくは著書を。

FURPS+

・機能性、使い勝手、信頼性、性能、保守性、制約、の頭文字を取ったもの。
・アジャイルで効果が出るもの。機能性。
 ・お客様にマッチした機能をレビューしながら組み立てられる。
 ・その結果、使い勝手と保守性も改善される。
 ・それ以外は?クラウドの強みが活きてくる。

アジャイルの限界とクラウドとの出会い

・アジャイルの限界。調達がネック。
 ・機能を作ってもサーバを調達しないと動かない。
・クラウドによって調達が簡単になった。
 ・開発側からすると調達を言い訳には使えなくなった。
・アジャイルにおけるフィードバック。実際に使う人に使ってもらうのが一番簡単。
 ・クラウドのスケール力とコネクティビティによってアーリーアダプタに開放できるようになった。
 ・できた機能は限定公開して使ってみてもらう。
 ・フィードバックで評価の低かった機能を取り除くことが出来る。
・品質。これまではリリース時にある程度の品質を担保する必要があった。
 ・継続的デプロイによって、とりあえず出す、ダメならロールバック、が出来るようになった。
 ・運用時のテストが注目されるようになった。
・Infrastructure as a codeによって、非機能要件のコード化が出来るようになった。
・今後は、より制約とできることが明確になる。

まとめ

・昔はコードレベルで問題を考えていた。
・テクノロジーの抽象度が深まってきている。
・テクノロジーの力だけでなく、ビジネスや社会まで考えたエンジニアになってほしい。
・技術者の行く道はビジネスアーキテクト、グロースハッカーになる。

さいごに

アジャイルとクラウドの相性によって簡潔にまとまっており、すごく分かりやすかったです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.