まずはできるところから!ウォーターフォール派も試してみたくなるアジャイル開発の新しい試みとは <前編>

まずはできるところから!ウォーターフォール派も試してみたくなるアジャイル開発の新しい試みとは <前編>

こちらは、メンバーズエッジカンパニー主催で開催したウェビナー「まずはできるところから!ウォーターフォール派も試してみたくなるアジャイル開発の新しい試みとは」の書き起こし記事です。(2回に分けて掲載します)

あの世界的に有名なアメリカの自動車メーカー、フォード・モーターの一部門「フォードラボ」のプロダクトマネージャーRenee Liken氏Jonathon Bezak氏をお招きし、アジャイル開発の実践例、筋のいいアイデアを出す方法やコミュニケーション術など、明日からの業務ですぐにお試しいただける戦略や取り組みについてお話いただきました。

登壇者紹介

Renee Liken氏(フォード・モーターFordLabs プロダクトマネージャー
フォード・モーターの顧客体験の最適化を担う研究所、「FordLabs」のプロダクトマネージャー。過去にアジャイル開発環境や中小企業の経営、クリエイティブエージェンシーにおけるデザイン業務のキャリアを持つ。
FordLabsでは、UXデザイナーやプロジェクトマネージャーを経験し、ビジネス要件、プロダクトビジョン、そしてユーザの目的到達に何が必要かを見極めることに長けている。現在はプロジェクトリソースの状況を踏まえたうえでリリースに向け、開発チームを支えている。

Jonathon Bezak氏(フォード・モーターFordLabs プロダクトマネージャー
フォード自動車にてソフトウェアエンジニアとして活躍。入社後、自動車組み立て工場の車両スケジューリングシステムの改善に従事。それからは同社の車両エンジニアやデータサイエンティストにアナリティクスソリューションを提供。以前はウォーターフォール派であったが、現在はリーンスタートアップと人間中心設計を専門とするプロダクトマネージャーとして革新的なソリューションをアジャイルに検証し、新たなビジネスチャンスを模索するのに貢献している。

はじめに

Renee Liken(以下、Renee みなさんこんにちは。私はRenee Likenです。今日はJon Bezakも一緒にお話します。私たちはFordLabsのプロダクトマネージャーです。まずは自己紹介をさせてください。

Jon Bezak(以下、Jon みなさんこんにちは、私はJon Bezakです。
まずなにより私はアジャイル開発が大好きで、これまで何年も取り組んできました。現在はFordLabsのプロダクトマネージャーで、ビジネスアイデアをコンセプトから現実へ落とし込む部分を担当しています。

私が最も好きな仕事は、従来的なウォーターフォールのメソッドにずっと取り組んできたチームにリーンやアジャイルのコンセプトを紹介し、新しく、よりよい方向へ変革していくことです。お気に入りの格言は、「自分が入れると感じる水深よりも、少しだけ深いところへ進みなさい」です。いつも自分自身を前へ向かせ、新しいことに挑戦するようにしています。

Renee では私の番です。Renee Likenです。元々のバックグラウンドはUXデザインでした。少しずつプロダクトの方へ移行し、2~3年前にプロダクトマネージャーになりました。ユーザーが求めるものとビジネスが求めるものの交差点を見つけ出すことや、チームが求めるビジョン、つまり「実現したい結果」を見つけることに大きな喜びを感じます。

アジャイルには、ソフトウェアとマーケティングの領域で10年ほど取り組んでおりますが、フォードー・モーター・カンパニーのFordLabsには半年ほど前に参画したばかりです。

Fordlabsとは何か。フォードー・モーター・カンパニーはご存知ですよね。自動車を製造・販売しており、近年はより大きなモビリティ空間へと事業を広げています。FordLabsはそんなフォードー・モーター・カンパニー内にある特別なチームで、リーンと人間中心設計を取り入れたプロダクト開発に特化しています。

通常はソフトウェア・プロダクトに従事していますが、たまにFord全体と共同でリサーチプロジェクトに取り組むこともあります。彼らは、特定の事業課題がある時に、FordLabsに相談することが多く、その課題において最も注力すべき点が何かを発見することを期待しています。以上がFordLabsの概要です。

アジャイルの基本をおさらい

Renee では、アジャイルの基本を少しだけおさらいしましょう。皆さんの中には何年も前からアジャイルに取り組んでいる方と、まったく初めての方がいらっしゃると聞いています。この講演の目的は、現在ウォーターフォールに取り組んでいるステークホルダーをどのようにしてアジャイルに変えていくかをお伝えすることで、私たちがアジャイルの何を大事に考えているかを共有したいと思います。

アジャイルソフトウェア開発宣言

さて、アジャイルはどのようにして始まったのでしょうか。
昔々、2011年のことですが、従来のソフトウェア開発とは異なる開発スタイルを模索する17人がいました。ドキュメント駆動のソフトウェアに嫌気が差し、顧客に実際に使ってもらえるソフトウェアを開発したいと考えました。彼らはこれを「アジャイルソフトウェア開発宣言」と名づけました。

プロセスやツールよりも個人と対話を

いくつかの項目をピックアップして、左側と右側の価値について比較していきましょう。まず1つめは「プロセスやツールよりも個人と対話を」これは、「個人と対話」が大事で「プロセスやツール」がどうでもいい、ということではありません。ここで意味することは、何がチームにとって有効かを見つけることが、「誰かがやっていたから」や「誰かに言われたから」行動するより重要だということです。

何が有効なのかを見つけたら「チームの約束」にまとめることをおすすめします。スタンドアップミーティング、振り返り、スプリントプランニングといった集まりには、必ずコミュニケーションゴールがあります。「個人と対話」に常に集中するよう心がけてください。同じ場所で働くチームは関係性構築の機会が多く、コミュニケーションがうまくいきやすいです。個人的には、近くで取り組むほうが格段のやりやすさを感じますが、メンバーが違う場所にいても実現不可能ではありません。

さらに、チームの目的によって最適なツールは変わります。なので、使いなさいと言われたからといって盲目的にツールを受け入れるのではなく、なぜそのツールを使わなければいけないのか、どのようにチームを支援してくれるツールなのかを理解するよう努力しましょう。

最後に、全てのチームメンバーが持つ視点のバランスを探りましょう。全員を全ての会話に含めるのです。たとえば、デザイナー、ソフトウェアエンジニア、もしいればプロダクトマネージャー、スクラムマスター、プロジェクトマネージャーなど。誰もが同じテーブル上で平等に声をあげられる環境が必要です。忘れてはならないのが、アジャイルというのは単なる開発手法ではなく、社内文化を変革するマインドセットだということです。これらは、「個人と対話」により価値をおかなければ達成できません。

包括的なドキュメントよりも動くソフトウェアを

「アジャイルソフトウェア開発宣言」に書かれている2つ目の価値は「包括的なドキュメントよりも動くソフトウェアを」です。先ほども申し上げた通り、全てを完璧に文書化してから構築するという従来のやり方では、実際に動くソフトウェアが構築されて、目にされるまで価値を生むことはできません。アジャイルでは、後で戻ってコードを修正する必要があったとしても、とにかく動くソフトウェアを得ることに大きな価値をおきます。それでいいのです。とにかくまず動かし、正しいコードになっているか、もっと効率的な運用ができないか、もっと早くできないかは後から考えればいいのです。

小さなユーザーストーリーというのは動くソフトウェアで大きな価値を発揮します。なぜなら、コードベースへの変更が小さければ、ひとつひとつの機能やストーリー、改善を行なった後の動作検証を継続的に行なえるからです。検証して、「うん、ちゃんと動くね」と言えますね。これはつまり、顧客が求める軌道からはずれることなく開発し続けることも可能にします。これが「包括的なドキュメントよりも動くソフトウェアを」ということです。

「契約交渉よりも顧客との協調」により価値を

そして「契約交渉よりも顧客との協調」により価値をおきます。「顧客は敵ではない」と頭に留めておくことは重要です。同じように、大企業の中でプロダクト開発を行なっている場合もビジネス側の部署の人々は敵ではありません。価値あるものを届けるために、彼らとの協調が必要です。協調する方法のひとつは、頻繁に進捗を見せること。構築中のソフトウェアのデモを見せましょう。間をあけて大きな変更を見せるよりも小さな変更を頻繁に見せることのほうが効果的です。イテレーションを繰り返す中で、必要に応じてストーリーを追加することで、応えていく方がよいでしょう。もうひとつ大事なことは人間中心設計です。顧客のこと、また顧客への提供価値を考え続けましょう。顧客との協調は、そのための方法のひとつです。

計画に従うことよりも変化への対応を

そして「計画に従うことよりも変化への対応を」です。計画を持つべきではないとは言いません。計画は必要ですし、どのような計画も大事です。しかし、より大事なのは計画に対する変化を受け入れることです。なぜなら、計画通りに物事が進むことはないからです。バグが見つかるかもしれません。でもいいのです。バクは発生します。しかし、バグが発生したらストーリーを作成し、バグ修正を行なうたびに計画を修正すると共に、ジョンが先ほどお話したデモから得た顧客のフィードバックや、「私はこんなもの求めていない」といったようなエンドユーザーからのフィードバックがあれば、それも計画に反映します。これからの予定が書かれていたロードマップのほうを修正するのです。「計画に沿っているかどうか」だけを常に気にしているようでは、顧客やエンドユーザーが本当に求めるものが何かを学ぶことはできません。状況に応じて柔軟に対応できるようにならなければいけません。

ケーススタディ

どのようにしてアジャイルを地道に学んできたか

本日は、ウォーターフォールのマインドセットを持つ人々に新しい考え方を導入する方法をお伝えしたいと思います。まずは、私がどのようにしてアジャイルを地道に学んできたかについてお話しましょう。

「アジャイルを学習中だった数年前、私はFordの製造ソフトウェアの開発に取り組んでいました。その頃、Fordは彼らがいうアジャイル変革の真っ只中でした。ウォーターフォールのマインドセットで取り組んでいた従来的なチーム全てを、アジャイルのプラクティスに移行させようとしていたのです。

Fordはまず、私達に使って欲しいプロセスやツールの導入を進めました。「イテレーションやスプリントといったプラクティスを実行し、ユーザーストーリーにポイントをつけなさい」と言いました。しかし私は、これらがいったい何なのかも取り組む理由も、まったく理解していませんでした。私も私のチームもソフトウェアが動き続け、組み立て業務が停止しないことを最重要視していました。私達が理解しているかどうかに関わらず、これらの変更への適応を強制的に求められたのです。誰かが何かをしなさいといったときには、なぜそれが求められているのかを理解することが大切です。もし「バックログを管理するために、あるツールを使いなさい」と命じられたら、なぜなのかを理解することからはじめましょう。誰かに言われたからツールを使うのではなく、あなたの目的のためにツールを使うようにしてください。

アジャイルプロセスに挑戦する中で、何がうまくいっていて、何が障害になっているかを理解するのは大切ですが、難しくもあります。状況を理解する手助けになるのが、指標をもつことです。シンプルで追いかけやすい目標に注力するといいでしょう。例えば、製造ラインに取り組んでいるとしたら、ラインの稼働時間、工場でどれだけ効果的に機能しているか、バグの有無などです。これらは注力すべき重点指標です。先ほど申し上げたとおり、当時「なぜこれが行なわれているか」についての説明が一切ありませんでした。私達は、デイリースタンドアップがなぜ効果的であるかを理解することができませんでした。他のやり方が存在することも知りませんでした。言われたから、ただやっていただけだったのです。「アジャイルの『セレモニー』を全てやったチームでもアジャイルになれないことがある」というのを知っておくのは非常に重要です。一方で、「セレモニー」を一つもやらないチームが非常にアジャイルになることもできます。これらのアジャイルのセレモニーを通じて実現したいのは、円滑なチーム間コミュニケーションなのです。

もう一つできることとしては、小さな1歩から始めることです。私の経験上、アジャイルを取り入れていく上でもっとも難しいことは、メンバーが理由もろくに理解しないまま大きな変更を行なっても、彼らはやらないし、導入成果もでない、ということです。それを防ぐための一つが、小さな一歩を積み重ねることです。どうしたらチームが改善できるかを常に考え、そのために小さな変化を起こします。また、変化に取り組む期間が短いと効果的であるかどうかの検証もすぐに実施することができます。例えば、「この変更を1週間だけやってみよう」としましょう。1週間後に成果が出ていなければ単純にやめてしまえばよいのです。もし成果が出れば、次の週はそこからまた少しだけ新たな変更を加えます。改善を繰り返し、チームが今より少しだけよくなるために何をすべきか考えます。そして、小さな変更に集中しましょう。

アジャイルのセレモニーを取り入れる際、気をつけることがあります。スタンドアップに取り組む場合、チーム間のコミュニケーションに集中しましょう。単に「今日は一日中打ち合わせだ」といった報告は行なわないように。あなたの仕事で、チームのメンバーが知っておくべきだけどもまだ伝えていないことを話しましょう。イテレーションやスプリントプランニングを行なう場合、週の予定をたてることよりも、各カードやユーザーストーリーを完了させるために何をすべきかについて考えましょう。どう適用するか、どのようなアーキテクチャを設計するかなど情報共有を行ないましょう。振り返りを行なう場合、前週がどうだったかを振り返り、改善のための小さな一歩を進めましょう。「地道にアジャイルを学ぶ」から得たいくつかの学びです。まず、「制約の中で頑張る」こと。自分に課せられる可能性があるさまざまな制約を認識しましょう。

製造ラインに取り組んでいる場合、大きなプレッシャーがあるかもしれません。ソフトウェアへ加えられる変更の余地が少ないかもしれません。他のものとの依存性が高いかもしれません。常にこうした制約を意識する必要があります。しかし、その中でも小さな改善のために何ができるのか考える必要があります。そしてチーム間のコミュニケーションに注力し、アジャイルソフトウェア開発宣言の1行目にある「プロセスやツールよりも個人と対話を」をチームの強みにすべきです。

それでは、私がここ数ヶ月Fordlabsで取り組んだプロジェクトのひとつについてお話したいと思います。先ほど申し上げたとおり、私たちの仕事の多くはアジャイルな仕事の進め方についてFord全社に教育し、浸透させることです。なぜならFord内のほとんどのグループは、まだアジャイル化に取り組んでいる途中だからです。最近、Ford車を所有する人々のためのweb体験のデザインに取り組むチームとプロジェクトをともにしました。作ったのは今、映しているこのwebサイトです。

学びを得るのが目的だったので、非常にシンプルです。2~3ヶ月だけを費やして、このサイトで試行錯誤し続けました。その中で、私たちはこのwebサイトを長期的に管轄するチームのメンバーと直接仕事をし、様々なプラクティスにどっぷり浸かる機会となるよう支援しました。そしてそのことは様々な学びを与えてくれました。

学びのひとつは、同じタイミングで同じタスクについて共同作業を行なうと安心して学べる環境になるということです。同じタスクに異なる時間で取り組んでも、同じ種類のコラボレーションは生まれません。これらのプラクティスを実際に教える上でのナレッジの受け渡しも同じようにいきませんでした。

二つ目の学びは、プロセスに初めて取り組む人へ教える場合、最初に例を見せることの重要性です。自分たちで実践するにあたって、参照できる実例を与えることができます。どういったものなのか例を見せた後は、教える側は一歩下がり彼ら自身で取り組んでみられるようにすること。自分で失敗すると今取り組んでいることはどうして行なうべきなのかを理解することができます。その後で、「こういう風にやっていたけれど、私ならこうします。なぜなら・・・」と、建設的なフィードバックを与える機会を持ち質問に答えましょう。忘れてはいけないのが、「良い」レベル達成のために「完璧」である必要はないということです。構築中のプロダクトであろうと、反復しているプロセスであろうと、学ぼうとする人々を支援する中で、起こった失敗から学ぶのは大変素晴らしいことです。

さて、あなたの職場でどのように挑戦すべきか考える場合、いくつかおすすめしたい方法があります。まず、ステークホルダーがウォーターフォールの何に価値を感じているのかを見つけること。もしウォーターフォールのプロセスを採用しているなら、それを評価している理由があるはずです。ウォーターフォールのプロセスの何に価値を感じているのかがわかったら、何があまり重要でないかを理解したのと同じです。その上で、アジャイルプロセスに挑戦する余地のある機会をうかがいます。また、新しいプロセスやアジャイルに取り組んでいても開発中のソフトウェアの定期的なデモは続けましょう。このことは、新しいプロセスが開発速度を極端に下げるものではないことを示し、ステークホルダーの安心感につながります。そして、前よりも頻繁に進捗を見ることができるのは、予定通りリリースできるかどうかに関わらず何を構築しているかについての安心感も与えます。また、プロダクトやプロセス内で行なう変更の範囲は小さく限定しましょう。そうすることで、万が一うまくいかなくても素早くピボットして新しいことに挑戦することができます。

後編はこちら

アジャイル開発についてや、ウォーターフォールとの違いを解説した記事
ウォーターフォール開発とは何か。概要を解説
プロダクトマネージャがアジャイル開発に取り組む際のポイント
アジャイル、スクラムの基本知識と、アジャイルを成功させるために大切な3つのこと

採用情報

メンバーズエッジで最高のチームで最高のプロダクトを作りませんか?

最高のプロダクトをつくる 最高のチームで働く

在宅でも、地方でも、首都圏でも。多様な働き方で最高のチームをつくり、お客様のプロダクトパートナーを目指します。アジャイル開発を通じ、開発現場の第一線で活躍し続けたいエンジニアを募集しています。