アジャイル開発についての本を書いてみての感想

私がアジャイル開発なるものを知ったのはいつだろうか、はっきりとは覚えていませんが、2004年だったと思います。その頃は私はまだアメリカから帰ってきたばかりで日本で情報システム系の専門学校で教師として働いていた頃でした。プログラミングからシステム設計、ハードウェアを含むコンピューターシステム全般を授業で教えていました。当時の私はまだアジャイルというキーワードの意味を大して理解していませんでしたが、XPという手法について、かなり先鋭的で挑発的な取り組みに思えただけで、特に深入りしませんでした。ただ、ウォーターフォールモデルは破綻しているとは感じていました。卒業生が就職した先で疲弊している話や、システムインテグレーションにまつわる業界の話の中で、すでにウォーターフォールモデルは悲劇の元凶とされていましたから。私が担任として受け持った生徒を卒業させると同時に私もソフトウェア会社に就職しました。2006年のことです。そこはERPパッケージソフトウェアを自社開発する、かなり攻撃的でカオスな会社でした。配属された部署は一癖も二癖もある猛者たちで、開発エンジニアたちが自ら要件を定義しコードを書きテストを行っていました。そして一定の間隔でリリースし、機能追加をしていました。創業して5年で上場を果たして、国内の大企業向け人事給与システムの市場でトップシェアを取るほどの高い評価を受けていた一見固そうな事業ドメインの印象とは違い、高速に開発することを求められつつも、開発者それぞれに大きな裁量権がありました。私も配属されてすぐに要件を書き、それをもとにコードに書き、テストに流し、戻され、コードを修正し、を何回か繰り返したのち、製品はリリースされていきました。ユーザーは大企業の人事部。1000社を越える企業に使われるパッケージソフトウェアの開発は、非常に高いプレッシャーが襲ってくるはずなのに、開発エンジニアの誰もがユーザーと直接やり取りし、ユーザーを恐れていませんでした。継続的に製品はインクリメンタルにリリースされていく、まさしくその姿はアジャイルでした。しかし当時はアジャイルという言葉を用いていませんでした。無償でバージョンアップを行なっていくという当時としては画期的なビジネスモデルゆえに、いかに早く価値の高い機能をリリースするかがビジネスの成否を分ける状況だったため、そのなかで試行錯誤した結果、自ずと開発プロセスはアジャイル化されていったのです。リリースサイクルも常に一定というわけではありませんでしたし、統合されたバックログもありませんでした。形式化されたミーティングもなく、しかし開発エンジニアはフロアのあらゆるところで議論を行い、会話も多く、まさしく大きなチームでした。

600人いる社員の平均年齢が28歳という急拡大中の組織は、人事制度も細部は貧弱で、ルールの多くは社員の善意に委ねられていました。就業時間もフルフレックスで、何時に来て何時に帰っても会社は基本的には干渉してきませんでした。社長は「開発者の天国を作る」と公言し、今思うとまさに『興奮するフィールド』でした。DBのテーブル数も桁違いで、簡単なクエリですら下手をするとすぐに返ってこない、そんな巨大なシステムでありながらちゃんとした設計書もない。ひらすらソースコードを読み解きながらコードを書いていく。10万行を越えるプログラムコードを夜中の静かな時間を見計らって必死に読み解く、そんな日々でした。開発エンジニアの誰もが優秀で、法制度にも詳しく、人事給与業務のニーズも完全に把握していました。大企業の給与制度は複雑で、とても多くの特殊なパターンがあり、それをシステムでどのように処理すればいいのか、を考えながら実装していきました。「ブレークスルーを起こせ」。そのようにイノベーションを起こすことを求められていました。そして挑戦による失敗は許容されていました。

私は途中で、社長直下の採用部門に異動になります。海外採用を社長に提案し、予算を与えてもらい、海外のエンジニアを採用する裁量を与えられたことで、何年もの間、インド、中国の現地の超優秀な学生たちと接する機会を得ることができました。私がいまだにソフトウェア産業が最高の場だと言い張っているのは、このとき見て感じた世界が根底にあります。私は野球というものでアメリカに渡ることができ、そしてソフトウェア開発によってインド、中国、シンガポールに行くことができました。

私は過去に1度だけ社長を激昂させたことがあります。それは、私の不手際でミスしたことを報告しなかったのです。社長に怒られたのは、ミスをしたことではありませんでした。ミスしたことを報告しなかったこと、保身に走ったことを強く怒られたのです。失敗を許容する文化というのは、謝罪をベースとする文化です。許可をベースとする文化ではありません。とりあえずやってみてダメだったら謝ろう、とする姿勢が基本姿勢です。

とにかく忙しかったですし、誰もがハードワークでした。そして利益率は高く、給与も高かったです。やりがいも実利もありました。そして私は次第に自分自身でも事業を興したくなってきました。社長が作ったこの会社のように自分も何か形のあるものを作り上げたいと思うようになりました。そして独立しました。

事業サービスもソフトウェア製品もすべて自分たちで作り上げました。開発も最初に立ち上げたWEBアプリケーションは私1人で作り上げました。ERPパッケージを大きなチームで開発していた際に学んだことを生かして、今度は大きなチームではなく小さなチームで戦うことを選択しました。その後9つのプロダクトをアジャイルプラクティスで開発し、スタートアップならではのエクイティでの資金調達や、メディア露出なども積極的に行いました。スタートアップというものはアジャイルそのものです。規律と変化を同時に生み出さなければならず、沈んでいく船の修理をしながら航海を続ける冒険の旅なのです。生きて帰ってこれるかもわからないその旅の行く先を、目をこらし疑いながらも、根拠もなく自らを信じ込み、進んでいくしかないのです。

その後は、日本を代表する世界的大企業に対して、アジャイルを教える機会を得ることができました。アジャイル化を果たすためのコンサルティングとコーチングでプロジェクトを支援をする仕事をスタートしました。会社が町一帯というほどの巨大企業。超大企業というものの実態に触れることができ、その中で様々なことを学びました。アジャイルを経験したことも見たこともない人に、アジャイルの本質を理解してもらうのがどれほど難しいのか、を痛感しました。そして、どのようにすれば実践しやすくなるだろうか、アジャイルを削ぎ落としていくなら何を削って何を残せばいいだろうか。毎日そんなことを考えながら複数のプロジェクトを渡り歩いていきました。時には力及ばずで、うまくアジャイル化を果たせなかったプロジェクトもありました。私自身も実践の中で多くの気付きと反省を繰り返してながら、成長していきました。

今思うと私の人生がアジャイルそのものかもしれません。
価値ある人生を送りたいと願って日々を過ごしていますが、このアジャイルという哲学を本に書き起こし世に出すことが私の提供できる価値である、と思い立ち、本書を書き上げました。なるべく特定の技術に偏った内容にならないように心がけ、また、プログラミングに詳しくない人でも読み進められるように、できるだけ汎用的な表現を用いることにしました。ソフトウェアの世界の変化は速く、本書を手に取った皆さんの時代背景と常に一致させることは不可能ですが、それでも不朽の本質なるものを伝え、そしていつの時代でも使えるようにとの思いを込めました。

何度失敗してもいい、そこから学んで次に進み、ついに成果を実らせましょう。
限りある人生の時間の中で、リスクを取り、変化に適応し、圧倒的な速さによって価値を届けましょう。

本書が皆様のプロジェクトの助けになることを祈っております。

関連記事

  1. なぜいまだに日本では ウォーターフォールモデルが採用され続けるのか

  2. 【有料記事】スタートアップが生き残るためには『ゲリラ戦』を理解せよ

  3. 計画駆動とアジャイルの違い -成功するアジャイル開発(1)-

  4. 書籍「成功するアジャイル開発」を出版いたしました

  5. アジャイル桃太郎

  6. 失敗するプロジェクトは現実逃避から始まる -アジャイル開発を成功させよ…

  7. なぜスクラムマスターが必要なのか

  8. 個人かチームか 〜開発者が”1人”と”2人以上”の違い〜

最近の記事