アジャイル

一言でいうと

短い反復を重ね、変化に合わせて計画を見直していく開発の考え方です。手順の名前ではないため、同じ語で呼ばれる現場の実態は大きく違います。

提唱者と登場年

2001年に公開されたアジャイルソフトウェア開発宣言が起点です。Kent Beck、Ken Schwaber、Jeff Sutherland、Martin Fowlerら17名が署名しました。宣言は四つの価値を示しています。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を重んじる、というものです。

宣言は左側に価値がないと述べているわけではありません。左記のことがらに価値があることを認めながらも、右記により価値をおく、と書かれています。この但し書きは実務でしばしば落ちて伝わります。

何を解決するか

要件を最初に固めきる前提が崩れる領域に対応するための考え方です。作っている途中で市場が動く、使ってみて初めて要らない機能だとわかる、といった状況では、計画どおりに完遂すること自体が価値を生みません。

反復を短く区切り、動くものを早く出し、そこで得た情報で次を決める。この循環を回すことで、間違った方向に進む距離を短くします。

実際の進み方

考え方であるため、具体的な進め方はスクラムやカンバンといった手法を選んで実装します。共通するのは、期間を区切ること、区切りごとに動くものを確認すること、そこで得た情報を次の計画に反映することです。

チームの外との関係も設計に含まれます。何を作るかを決める人が反復のたびに関与しないと、方向を修正する情報が入ってきません。

導入でよくある失敗

• 会議体と用語だけを取り入れる。計画を見直す権限が現場になければ反復の意味がありません
• 短い反復に長い工程をそのまま詰め込む。期間だけ短くなり、負荷が上がります
• ドキュメントを一律に減らす。宣言はドキュメントに価値がないとは述べていません

求人票にこの語がある場合に読み取れること

この語だけでは実態がわかりません。日次の進捗確認をしているだけの組織から、リリース判断まで現場が持つ組織まで、同じ語で表現されます。

媒体の職種カテゴリにも資格にも翻訳できないため、この語で候補者を引くことはできません。求人票に書く場合も、語単体ではなく、直近で計画を変えた具体例を添えてください。

自社側で先に押さえておきたいのは、反復の期間と、計画を変える権限が現場にあるかどうかです。候補者には、前職で計画が変わった場面とそのときの決め方を聞きます。「毎日朝会をしています」だけが返る場合、会議体の導入にとどまっている可能性があります。

隣接手法との違い

関連キーワード

スクラム / カンバン / DevOps / AI駆動開発