一日の終わりに、その週の終わりに、何度こうに自分自身に問いかけたことがありますか？「あれって一体何の意味があったんだろう。」と。
現代におけるほとんどのチームはプロダクト開発のアプローチがアジャイルであることを公言しています。つまり
1.ユーザーフィードバックに基づいている
2.変化する状況に適応し、新しいフィードバックが入ってくる
ということです。しかし、残念ながら多すぎるほど多くのチームがこの手法を実際に使いこなせていません。使いこなすどころか、ストレス、過労、早急すぎる意思決定の文化が現場を支配していて、アジャイル理論は製品の最初のバージョンがリリースされるとともに捨てられるのが現状です。
自分たちが顧客中心で十分な順応性があると信じていたとしても、それが必ずしも行動に反映されるとは限りません。私たちは働きすぎと、性急に物事を決めることに多くのストレスを抱えてしまうので、「どのような効果を生むか」という尺度を鈍らせているのです。私たちのアクティビティは様々なことを犠牲にして、より多くの成果を求めること、つまり仕事に影響を与えるものにばかり集中してしまっています。
より多くの機能を持たせること、さらにやることを増やすバックログの構築、終わりのないやることリストを終わらせようとすること、などがその一端です。タスクが終わり製品がローンチすると、安心して大きなため息をつき、すぐさままた次にやることに取りかかります。また、見落としがちな副次的な影響として、チームはエンジニアたちを非人間的にし、車輪の歯車のように扱ってコードを書かせることになります。
企業の成功に積極的に貢献できる自立した個人として扱わずに、です。
そしてこの時点であなたは「いったい何の意味があったんだ。」と自分に問いかけるのをやめたのではないかと私は推測しています。その決断は正しいものです。作業の結果が見えない場合、何が問題なのでしょうか。そもそもなぜそれをやるべきだったのかがわかっていないとしたら？最初にやったことをなぜやったのか、本当にわかっていないとしたらそれは本当に意味がないことです。
そもそもなぜそうしたのかという明確な正当性を持たずに、単純に多くのことをやり遂げるだけの作業には全く意味がありません。理にかなっていないだけでなく、非常に危険なことです。ただ単により多くのものを構築するのではなく、「インパクトのあるものを構築する」ということにどのように焦点を当てるべきかについての真剣に考えず、盲目的に意思決定を行うことは、ビジネスにとっての実存的な脅威になります。
これは的を得ないダイエットのようなもので、手当たり次第食べたりエクササイズした後に数ヶ月間目を閉じて痩せることを願っているようなものです。
なぜ要点を見失ってしまうのか
少しでも常識のある人と話をすれば、実際に何かをする前に、今から何をするのかを正確に理解するのはごく理論的な道理だと納得するでしょう。少なくとも、それをすることで何が起こるかと言う漠然とした仮説を立てるべきです。例えば、この機能の代わりになるようにあの機能を構築するんだ、といった具合にです。
ではなぜこの常識的な議論が現実の世界では行われていないのでしょうか。それはあまりにも多くのチームがストレスとオーバーワーク、忙しそうにデスクにかじりつく、そういった労働文化に支配されているからです。
仕事の生産性に関係ない「フレックス制」のはずなのに、他のみんながそうしているからといって午後６時までデスクにかじりつくのが暗黙の了解のような文化では、あなたが戦略的に考え、仕事にもっと影響力を持つ人間になるきっかけは訪れません。また、ハードワークが評価されて昇進できるような文化的規範の職場では、仕事に影響を与えるよりも、多くを成し遂げること、つまり重労働に焦点を当てて奨励していることになります。
そしてチームがクリエイティブでスマートな活動よりもハードワークの文化を積極的に促進していると、ストレスやオーバーワークに繋がり、忙しそうに一日中デスクに座っているという文化が生まれます。またその状況を変えるのは容易なことではありません。
そのため、たとえアジャイルを公言していたとしても、チームは積極的に、または戦力的に考えることを辞めてしまうのです。アジャイルは中心的な信条として顧客のニーズに対応し、同時に顧客に大きな影響を与える価値を提供するものでなければいけません。
チームはやらなければならない仕事量に圧倒されて（オーバーワークによってより多くの仕事量をこなすことを良しとする、企業全体の文化として蔓延している価値観によるものですが）、クリアな思考を持って戦略的に考えることが難しくなっています。そのためチームの意識は目の前のこと、つまり、やり終えなければならないタスクのリストに集中してしまいます。
そしてその週にリストにあることをどれだけやり終えたかが進捗であり成功であると考えてしまうのです。
繰り返しになりますが、アジャイル理論、またはスクラムのようなアジャイル方法論は、はっきりと「構築のために構築してしまう罠」について警告しています。さらに私の考えを述べるとするならば、プロダクトオーナーのポジションを設けることは、影響力の高い作業にのみチームを集中させるといった優先順位付け問題に関しての理論的な解決策です。
スタートアップは不確実なので、今やっていることを検討し、評価し、実行することをチームの中心的な活動にするべきだと私は考えます。
アジャイルはなぜ正しい労働文化でしか機能しないのか
アジャイル理論を適応するには、単純に企業の労働においての文化を変えることが前提条件として必要です。最終的には影響力の高い仕事をし、利益のあるビジネスを構築したいという目標を持つ必要があります。これは私のマネージングの経験と生産性について科学的な視点で書かれた文献に基づく考えですが、企業の労働文化の変化は、下に挙げる信念に従って明確に行われるべきです。
1.素晴らしい決断が素晴らしい製品を生み出す
2.ストレス、睡眠不足、不健康、忙しないマインドのもとでは素晴らしい決断はできない
3.チームとして冷静で、クリアで、ハッピーなマインドのチームを形成する
4.これらの原則を育むことによってのみ、私たちは効果的に協力し、影響力の高い洞察を得ることができ、小さな一歩を踏み出すのではなく、飛躍的に前進するアイデアを思いつくことができる
単に忙しそうにしたり、より多くの成果を上げたりするのではなく、効果を生むチームを再編成するにはためにはどのようにして文化的変化を起こせばいいのでしょうか。これはとても難しいことで、私が成功する製品、成功するビジネスの構築のための具体的な方法について本を出した理由でもあります。
基盤を再構築しない限り、真の成功は望めません。より効果的な環境を整えるために次のような特性を養うことで、自分たち自身を変身させてください。
1.堅牢であること：困難や失敗を乗り越えられるようになります。
2.物事をより深く心に留めておくこと：物事を明確かつ合理的に見ることができるようになります。
3.何が本当に大切か見極められるようになること：決定を下す際に本当に重要なこと、つまり本質的なことがわかるようになります。
チームが無意味な仕事に時間を浪費するのをやめ、効果の高い仕事を積極的にできるように、チームのアクティビティにおいてこれらを評価ポイントとして奨励しましょう。
新しいベンチャーでは避けられない不確実性に適応できるように、可能な限りリーン&アジャイルなプロセスを作るようにすることも大切です。しかし、このような変革を行うには、忍耐と困難を必要とする多面的なアプローチが必要であるため、ここでは、低労力、高インパクトという1つの具体的な戦略について説明します。
労働文化を変えることと本当のアジャイルのための戦略
チーム全体の運営方法を根本的に変えることはできませんが、チームの文化によってもたらされる複雑で根深い思考と習慣のために、効果的な仕事に焦点を当てた文化を徐々に育むために起こせる1つの具体的な変化があります。
もしあなたのチームがカンバンボードを使ってタスクを管理するような、伝統的なToDoリストに従っているとすれば、それらのタスクがどのように管理されているかを考え直す必要があります。
「Done」の意味は「Done」じゃない
カンバンボードを使っているほとんどのチームは３つないし４つのカラムで作業しているのではないでしょうか。
1.Icebox:検討中の機能または現時点では最適ではないと判断された機能を置いておきます。
2.Backlog:定義されたタスクまたは定義中のタスク。スクラムに従っている場合、バックログはチームの規模やチームの計画の進捗状況に応じて、特定のスプリントに分割されている可能性もあります。
3.Work-in-Progress:現在取り組んでいることです。
4.Done: 完了したタスク、または配置中のタスク。
この記事の冒頭で述べたように、自分たちの作業の結果が何であるかを知らないことは問題です。私たちはある機能をローンチした場合、実際アウトプットを目にすることができますが、ユーザーにどのように受け取られているかを実際に目にすることはできません。そしてその機能が成功だったか失敗だったかという結果も目に見えるものではないのです。
プロダクトに関する、インタラクティブでポジティブな影響を与えるような小さな変化になり得るのは、カンバンボードを微調整して、「Icebox」を抜いて、「Being Validated（検証中）」を付け足すことです。
1.Backlog: 議論中、または定義が終わり構築の準備ができたタスクの短いリスト。どんな重要な機能もディスカッションで定期的に議論されるはずなので、「Icebox」は設定しない方がいいと私は考えました。「Icebox」は、以前に出た、もはや意味をなさないアイデアついて感傷的な愛着を持たせてしまうことがあるので、１、２週間ごとに新しいアイデアで始めることが効果的だと思います。
2.Work-in-progress: 現在取り組んでいること
3.Done:完了したタスク、レビュー中または配置中のタスク。（レビューに多くの時間を必要とするような複雑なコードを書かないようにしていますが、より複雑な製品で作業しているのであれば、ここにレビューを追加することは意味があるかもしれません。)
4.Being Validated: この「検証中」を用いたシステムで、タスクは「experiments（試験中）」に再定義されます。それぞれの「experiments」には非常に明確な仮説があり、現在取り組んでいる戦略を検証するための重要な測定基準と関連しています。
タスクを完了するのではなく、実験を検証する
「Being Validated」の追加は難しいものではありませんが、前提条件として各エクスペリメントで何を検証しようとしているのかをチーム内で明確に定義する必要があります。したがって各タスクは明確なエクスペリメントとして定義される必要があります。このエクスペリメントのアプローチとしては以下のようなものがあります。
Objective
エクスペリメントのすべての活動に焦点を当て、それが真か偽かを検証するためのタイトルとしての明確な仮説。たとえば、 「機能xによって収益が10%増加する」 と考えている場合、最初にエクスペリメントの一部として、実行する変更の影響を実際に追跡できることを確認します。そのあと、その機能が成功したか失敗したかを実際に確認します。そしてその情報に基づいて次の実験を決定するという手順です。
Description
仮説の基礎となる特定のデータ駆動型の正当化を必要とするディスクリプション。例えば機能Xが収益を10％増加させると仮定しているのなら「10％」という数字はどこから来たのか、過去のエクスペリメントの結果か、競合他社か、心理学モデルによるものかというものです。結果を予測することは、将来のエクスペリメントで何に取り組むべきかをより効果的に判断するのに役立ちます。
Checklist
チームとしてこなすことは全て、すでに設定した仮説に対する答えになるよう方向付けられるので、このエクスペリメントを実現させるための全てのサブタスクは同じカード内に収まっているべきです。繰り返しになりますが、やみくもにやることリストの項目を増やすのではなく、チーム全体が設定した仮説に答えたり見直したりすることに集中してください。
このプロセスを効果的に運用するのには企業の労働文化を変えることが必須です。たとえば、作業結果の確認を急ぐのではなく、作業の重要な一部として確認することなどがそうです。こういったワークフローに対する単純な変更によって、チームとしての影響力を高めるために段階的な改善がもたらされます。
突然アジャイルで効果的なチームに返信できる飛び道具はありません。しかしながら最初は非現実的に思えたり、仮説に基づいたエクスペリメントが実行できなくても、「Being Validated（検証中）」の項目はそこにあるでけでチームは以下のような正しい疑問を持つことができるようになります。
・自分たちが構築している昨日の結果はどのようなものだったか。
・Xの機能ではなく、Yの機能を構築するべき理由は何か。
・これらの決定をするにあたって必要なデータはどれか。
・これは本当に10％の収益増をもたらすのか。マーケティング結果だけに頼っていないか。
効果的な仕事に焦点を当てた正しい疑問を持つことに文化をシフトさせることを最終目的に設定しましょう。
おすすめ新着記事
おすすめタグ