読者です 読者をやめる 読者になる 読者になる

kzk-casino.com

一人前のITエンジニアを目指して

書評 アジャイル開発とスクラム

書評 DevOps

アジャイル開発とスクラム」を読みました。

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

最近インフラ環境をアジャイル的に開発していくプロジェクトにアサインされたものの、
アジャイル・・?」
スクラム・・?」
状態だったので、これらの開発手法の概要を掴むにはいい本だったのでは、と思います。

簡単な感想

この本は大きく分けて以下の3部構成となっています。

  1. アジャイル開発、中でもスクラムの概略
  2. アジャイル開発・スクラムの実践例
  3. アジャイル開発・スクラムについての考察


第一部では、変化の早い時代において、短いサイクルでリリースを繰り返すアジャイルという手法の必然性、また具体的な開発手法について記載されています。
いまソフトウェア開発に求められているのは「スピード感」である、というのはすでに共通認識となっていると言っても過言ではないと思います。
スピード感ある開発には従来のウォーターフォール型は向きません。要件定義〜リリースまで半年〜数年かかるようでは、リリース時にはニーズが変わってしまっている可能性が高いからです。
そこで、スタートアップから最初のリリースまでを、最低限の機能に絞って3ヶ月程度で行い、市場に投入して反応を見、そして改良を加えていく、という非常にスピード感をもった開発手法であるアジャイルが注目されているんだ、ということが理解できました。


第二部では、アジャイルの実践例として、リクルート楽天富士通の事例を記載しています。
中でも、リクルートの事例の中で書かれていた、「アジャイルを推進するにあたってもっとも苦労したのは、関係部署の橋梁を得ることである」という主旨の話が印象に残っております。
アジャイルでは「ワンチーム・マインド」といって、製品開発に関連する様々な部署が一つになって開発を推進する必要がありますが、大きな組織ともなってくると部署間の距離を詰めるのが難しかったり、責任の所在を明らかにしにくい開発手法は受け入れられにくかったり、という壁があるのだろう、ということは容易に想像できました。
しかし、新しいことを始めるにはこう言った壁はつきもので、その壁をいかに壊していくかが重要なんだな、と思いました。


第三部では、「スクラム」という開発手法について、生みの親でもあるジェフ・サザーランド氏のインタビューや、80年代の日本の製造業に「スクラム」的な開発手法を提言した野中郁次郎氏の言葉などが記載されています。
アジャイル開発を現場に投入する上で、知っておいて損はない背景の話などを垣間見ることができます。


自分の立場で見る

さて、この本を一通り読んで、アジャイルは基本的にソフトウェア開発の手法として捉えられることが一般的なんだな、と思いました。
これは当たり前ですが、実際に市場に投入する商品のほとんどはソフトウェアなので、開発〜リリースのサイクルを非常に早く回す必要があるのもソフトウェアの世界なんだろう、ということには違和感はありません。


ただ、アジャイルはソフトウェアにしか適用できないんだ、と思い込んでしまうと非常にもったいないな、と思いました。
インフラの世界であっても、ビジネスのスピードに適応することや、DevOps的な考えでインフラもアプリも共同で一つの製品を作るという場合を考えると、スピード感を持ってインフラ環境の提供をすることが大事になってくると思います。
そういった際に、「必要最低限の機能だけ最初にリリースを行い、観察して、求められている機能を順次追加していく」というアジャイル的な考えでインフラ環境を提供することが重要となる時代も、もう来ているんだろうな、と思います。
(初期投資コストも抑えられますしね・・)


現場や時代にあった開発手法は何か、今一度考え直す時なのかな、と思いました。