PR

デジタル変革の波に乗り、アジャイル開発の導入が増えてきた。一方で、ウォータフォール型の価値観を引きずったまま無理に導入する現場も目立つ。回り道のようでも、まずはアジャイル開発の価値観を押さえたい。

 2018年7月19日に東京・有明で大規模なアジャイル関連の年次イベント「Agile Japan」が開催されました。10回目となる同イベントで驚いたのは新規来場者の数が常連組を圧倒的に上回っていた点です。事例発表も多く、今までにない盛況ぶりでした。

 デジタルトランスフォーメーションにアジャイル開発が欠かせないという認識が広まったからでしょうか。アジャイル開発は「興味はあるが様子見」という対象から、実際に取り組む対象になったのだと感じました。

思考停止のアジャイルが目立つ

 ただ筆者には強い懸念があります。アジャイル開発で実践する各種の項目(プラクティス)を取り入れているものの、実践するメンバーの考え方がウォータフォール(WF)型の思考から全く変わっていない現場が多いのです。アジャイル開発の導入や開発プロセスの全体最適化といったテーマで組織改革を進めたものの、様々な理由で行き詰まり、私が途中から支援するケースは必ずこの点が共通します。

 WF型開発の現場の考え方を端的に言えば「思考停止」です。大量生産の考え方なので、統率型マネジメントを徹底して指示命令に従わせるだけ。

 これに対し、アジャイル開発は自ら考えて創意工夫して行動に移すという自律型マネジメントが主流です。アイデアが湧いてくるチームでなければ成功できません。

 アジャイル開発が米国で生まれた2000年代当初からいち早く日本でアジャイル開発にチャレンジしていた技術者にとっては毎日が創意工夫の日々でした。WF型一辺倒の現場でアジャイル開発を推し進めるため、向かい風に倒されないように手を尽くし、倒されてもすぐに立ち上がってきました。

 筆者も及ばずながらアジャイル開発、特に「Scrum(スクラム)」の手法に注目し、工夫を重ねてきました。注目した訳はスクラムの源がトヨタ自動車の主査(チーフエンジニア)の振る舞いにあるからです。

 Scrumを学ぶと同時に、筆者はトヨタ生産方式(TPS)を学んで研究し、様々なTPSのノウハウを知りました。具体的には、注文に応じて1つひとつ作って売るという「一個流し」や、自分の工程で不良を作らず、かつ次の工程に不良を渡さないという「自工程完結」、自律したチームの育成方法などです。ビジネス戦略を起点として、案件の掘り起こしから営業、契約の締結、開発、リリース、運用保守までの一連の工程が、水が流れるかのようにさらさらと進められるような仕組みである「流水化」の考え方もその1つです。

 その後、これらのノウハウをソフト開発の現場の組織改革やホワイトカラーの働き方改革、アジャイル開発、DevOpsなどに適応させるよう取り組んできたわけです。試行錯誤で実践するなかで、特に一個流しと流水化を推し進めるには、仕事を一定時間に区切る「タイムボックス」が必須であるとの考えにも至りました(タイムボックスという概念はTPSでは明確に言及されていません)。今も多くの現場を支援していますが、正解はなく、日々が試行錯誤の連続です。

思考停止がはびこる理由

 ともあれ、20年近い時をへて、アジャイル開発が多くの現場で実践されるようになり、事例も増え、新しいプラクティスも増えてきました。そうすると、アジャイル開発で困った事態に直面すると、まず自らで工夫するのではなく、「何かアイデアになりそう」「参考になるかも」という安直な考えで新しいプラクティスに飛びつく人も増えてきました。

 事実、様々な支援活動をしていると、「うまくいく方法を知りたい」「正解を教えてほしい」「他社の成功事例を導入したい」と話す人が多くいます。前述した通り、技術者であれば開発現場がWF型開発に長く漬かっていたので答えを知りたがる気持ちも分かります。ただ、開発現場以外にもこうした思考停止状態の人が多くいます。

 なぜこうにも多いのでしょうか。筆者は日本人がIQ重視で与えられた課題を効率良く説く方法に偏った教育を受け、MBA(経営学修士)取得者などによる目先の成果を追う欧米式経営が広まった結果と考えています。

 現場支援では「小さな失敗をして改善しながら成長しましょう」と呼びかけます。しかしほとんどの人が行動しません。おかしな表現ですが「失敗の仕方」が分からないからです。

 メンバーは「行動しなければ失敗も成功もない」と頭では分かっているのです。しかし、行動する前にどこかに正解があるのではないかと考え、探してしまう。探す行為は否定しませんが、何でも便利な時代だからこそ、知恵を養うには自ら買ってでも苦労をしなければいけないと思います。

昔のプラクティスで十分

 正解を探す行為を最優先すると、安易に新しいプラクティスに飛びついてしまいます。2000年代初頭から存在するようなプラクティスよりも後発のプラクティスのほうが「良いもの」に違いないと思い込んでいるのです。

 筆者はScrumとXP(エクストリームプログラミング)が初期から掲げるプラクティスだけでアジャイル開発を十分成功に導けると考えています。むしろ後発のプラクティスは「型崩れ」を起こしているとさえ考えています。

 なぜScrumとXPの初期のプラクティスだけで十分なのか。それはプラクティス通りに進めれば、秒単位から月単位まで何重ものサイクルでフィードバックを受けられるからです。

 例えば秒単位や分単位のフィードバックは2人一組でプログラミングする「ペアプログラミング」というプラクティスによって実現できます。コーディングを担当する「ドライバー」に対して、隣に座る「ナビゲーター」は「仕様通りのコーディングか」「誤ったコンポーネントを呼び出していないか」「コーディング規約に沿っているか」といった観点で随時チェックし、ドライバーに適宜フィードバックします。

図 ScrumとXP(エクストリームプログラミング)のフィードバックループ
図 ScrumとXP(エクストリームプログラミング)のフィードバックループ
連続するフィードバックを守るのが第一
[画像のクリックで拡大表示]

 日の単位でみると、単体テストが終わればすぐに結合テストを実施して最低でも1日1回は結合テストをする「CI(継続的インテグレーション)」があります。さらにプロジェクトの繰り返し期間を1~2週間単位の「イテレーション(スクラムではスプリントと呼ぶ)」で設定し、数週間~1カ月でリリースできるようにします。

 初期から存在するこれらの代表的なプラクティスをしっかりと実践できていれば、1日の作業の終わりには品質が担保されたオブジェクトが出来上がっているはずです。さて、実態はどうでしょうか。「ソフトウエアにはバグがつきものだから」と言い訳して、バグが残った状態を容認するという怠慢な姿勢に陥ってはいないでしょうか。

 XPのペアプログラミングやCI、そしてテストコードを先に実装してからそれをパスするプログラムを書くという「TDD(テスト駆動開発)」の各プラクティスは自工程完結を実現するために必須のプラクティスです。また、作業タスクを1時間の粒度で洗い出すことも自工程完結に欠かせません。

 こうしたアジャイル開発における各プラクティスの進め方や品質については、以前の連載「現場を元気にするチーム運営術」の第7回や第8回、「現場を元気にするDevOps 2.0」の第5回で詳しく解説しています。

 ここで言いたいのは、安易に正解を求め、プラクティスに飛び付く「プラクティス信奉者」は結局表面的な事柄しか捉えていないということです。上っ面しか理解していないと何が起こるのか。経験上、そうした現場はすぐ壁にぶつかります。すると次の2つのどちらかの行動を選びます。

 1つは自分たちの未熟さを棚に上げてプラティクスそのものを「使えない」と批判する行為。ひどい場合はアジャイル開発そのものを否定し、取り組みそのものもやめてしまいます。

 もう1つは新たに登場したプラクティスや他社事例に考えなしに飛びつく行為です。これまたうのみにしているだけですので、飛びついてもまた壁にぶつかる。そうすると、また他社事例に飛びつくか、「使えない」と批判するかです。こうなるとプロジェクトに残された道は「迷走」だけです。