アジャイル開発の原点『アジャイルサムライ-達人開発者への道-』

 

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

  • 作者:Jonathan Rasmusson
  • 発売日: 2011/07/16
  • メディア: 単行本(ソフトカバー)
 

 

IT系の開発をしたことがある人なら1度は耳にしたことがある言葉、「アジャイル開発」。アジャイル開発はもはやweb業界の開発手法としてはデファクトスタンダードとなりつつある。しかし、一方で「アジャイル開発」とは名ばかり、ただただ無計画に開発をしているような現場もありなん。

実際、アジャイル開発がまさしく「アジャイル」に回っている現場を見たことはほとんどない。アジャイルソフトウェア開発宣言が出たのが2001年ということで、本書「アジャイルサムライ」を読みつつ、アジャイル開発の原点について振り返ってみた。

アジャイルとは何か

「アジャイルな開発現場」とはどのような現場だろうか。「ユーザストーリー」や「インセプションデッキ」、「スクラム」と言ったプラクティスを実施している現場だろうか。そんな疑問にジョナサンは以下のような明確な答えを出している。

・毎週、価値ある成果を届けられているか?

・たゆまぬ改善のために努力を惜しまず続けているか?

この二つの問いへの答えが「イエス」なら君はアジャイルだ

極めてシンプルかつ根源的だ。この二つの問いに自信を持ってイエスと言える現場どの程度存在するだろうか。

実際、二つの問いの一つ目に「イエス」と答える企業は多い(一部のSier業界の企業はイエスとは言えないだろう)。ここ10年ほどの大きな技術トレンドは、「一つ目の問いをどのように達成するか」だったといっても良い。その過程で、継続的インテグレーション、テスト、デプロイ自動化は当たり前となり、さらにはdevOpsエンジニアなる職種まで誕生した。

二つ目の問いにイエスと答えられるチームはどれほどだろうか。僕が思うに、この二つ目の問いこそがアジャイル開発を成功させるための前提条件だろう。故に自社サービス企業ほどアジャイル開発を実施するのが容易であり、受託開発企業は難しいのだ。

アジャイル開発は、依頼者と開発者が共に「より良いソフトウェアを作りたい」と思わない限り決して成功しない。アジャイル開発では常に依頼者と開発者は共に良いソフトウェアを作り上げる仲間でなければならない。

実際のところ多くの受注開発企業では、依頼者と開発者は対立関係におかれる。開発者は仕様で定められた機能のみを実装すれば良いと考え、仕様変更を容易には認めない。逆に依頼者は仕様変更を納期やスコープを変えずに主張し続ける。日本の開発現場の御家芸である。

本書は、アジャイル開発のプラクティスを説明しながらも決してプラクティスに踊らされてはいけないと忠告してくれる。

継続的なリリース

アジャイル開発で最も重要なプラクティスは、短い期間でソフトウェアのリリースを繰り返すことである。なぜなら、動かないソフトウェアに価値はないからだ。毎週の進捗報告のための素晴らしいドキュメントよりも動くソフトウェアを提供し続ける方が遥かに価値が高い。

CI/CDのための技術スタックは、今日では非常に重要な要素となっている。近年のソフトウェア技術の根底にはアジャイル開発があるんじゃないかと思わされる。

CI/CDはフトウェア開発に限らず重要である。特に近年、重要視されているグロースハックは、CI/CDなしには成立し得ない。アジャイル開発はソフトウェア開発の枠組みを超えて影響を及ぼしている。

 

アジャイルなプログラミング

アジャイルとは開発手法であり、プログラミング技術ではないが、本書ではアジャイルプログラミングのプラクティスが紹介されている。

  • ユニットテスト
  • リファクタリング
  • TDD
  • 継続的インテグレーション

アジャイルにTDDやリファクタリングのプラクティスがあるのは結構意外だった。これらはアジャイルに関係なく存在すると思っていたが、安定したソフトウェアを継続的にリリースするためにはテストが書かれている必要があるし、最初の方に書いたコードは後からリファクタリングされることが多い。(最初は予期しない機能が追加されるため)そして、日常的なリファクタリングのためにはユニットテストやTDDが良いプラクティスとなる。

感想

ソフトウェア開発技法の歴史はソフトウェアの複雑さとの戦いの歴史である。そして、アジャイル開発が示すのは、我々は事前に全ての要件を明文化する能力はなく、正しく作業工数を見積もる能力もない、ということである。そのため、ソフトウェア開発者がやることは、トライ&エラーであり、複雑な要件を小さく分割し、小さな要件ごとに成果物を出す。

面白いのはアジャイル開発の実践は、伝統的なエンジニアリングとは全く違うということだ。伝統的なエンジニアリングとは自動車工場を思い浮かべるとわかりやすい。そこには、最初からあらゆる部品の設計図があり、その通りに自動車が作成される。

我々にはいかにも馴染みのある開発方式であるが、実はこのような伝統的エンジニアリングの手法は人類にとってはごく最近になった用いられた手法だ。文化人類学者のレヴィ・ストロースによれば、元々人類が行ってきた開発方式はブリコラージュと呼ばれる。ブリコラージュとはwiki先生によると以下のように説明される

ブリコラージュは、理論設計図に基づいて物を作る「設計」とは対照的なもので、その場で手に入るものを寄せ集め、それらを部品として何が作れるか試行錯誤しながら、最終的に新しい物を作ることである。

なんだかんだ、複雑すぎるものの設計なんか人類には元々合ってないんじゃないか...