TOP
データ活用
デジタル人材のいない企業が「アジャイル」でうまくいかない理由～アジャイルとプロトタイピングの違い～

2022/07/08

データ活用

デジタル人材のいない企業が「アジャイル」でうまくいかない理由～アジャイルとプロトタイピングの違い～

前回の記事、デジタル人材に求められる「情報デザイン（設計）」スキルとは？はご覧いただけましたでしょうか？

ビジネスカンファレンスのプレゼンテーション「データ活用・分析人材の視野と視座」を発端に、デジタル人材に求められるスキル「情報デザイン」について考察してみました。

今回は、プレゼンテーションの中で取り上げた「データを活用できる組織と活用できない組織の違い」を深掘りして、組織運営における「アジャイル（敏捷・機動的）」について考えてみます。

アジャイルは一定のスキルを持った集団でしか機能しないチーム運営手法ではないか？
アジャイルが無理ならプロトタイピングにすればいいじゃない
まとめ

アジャイルは一定のスキルを持った集団でしか機能しないチーム運営手法ではないか？

筆者の中での「アジャイル：Agile」とは、英語的な「敏捷・機動的」という単語の裏側に、「頭の回転が速い」だったり「地頭がいい」といった有能さを表す概念が隠されていると感じております。

ところが、日本のソフトウェア開発シーンにおいては、「ウォーターフォール」というプロジェクトオーナー独裁・専制主義的な手法による非効率（実は効率的な場合もある）を打倒するために、民主主義の皮をかぶったポピュリズム：衆愚政治・大衆迎合主義というアンチテーゼとして、アジャイルが広まってしまったものと解釈しています。

とは言え、筆者個人の主観的な印象論ではらちが明かないので、いつもお世話になっているウィキペディア先生に聞いてみましょう。

アジャイルソフトウェア開発 - Wikipedia

アジャイルソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である（アジャイルソフトウェア開発宣言）。すなわち自己組織的なチームが対話の中で方向性・仮説を見いだし、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。

この価値観を共有する開発がアジャイルソフトウェア開発であり、アジャイルソフトウェア開発という言葉はソフトウェア開発工程やソフトウェア開発方法論、またはその総称ではない。

いきなり答えらしきものが見えてしまいました。

自己組織的なチーム
対話の中で方向性・仮説を見出し
顧客へ価値を素早く届け
素早く改善

はてさて、労働生産性の国際比較で経済大国どころか発展途上国に陥りつつあるわが国で、このような自律型・仮説検証型の人材だらけという組織がそこら中にあるとは到底思えないのですが、皆さんの組織ではいかがでしょうか？

「そんな人材、うちの組織にはウジャウジャいるよ」

元気の出るうれしいお言葉、ありがとうございます。

自信を持ってそう受け止めていただいた方は、どうぞ文末の関連コンテンツなどからご自身の興味・関心に沿った記事に進んでいってくださいませ。

「自律型とか仮説検証型とか漢字が多くて何言ってるのかわからない」

まさかこのような方が本記事をご覧になることはないであろうとは思いつつ、それでは身もふたもないのでもう一つ、この文節の小見出しを補強してくれるコンテンツを見つけたのでご紹介します。

アジャイルを機能させる前提条件とは？

アジャイルを機能させるには心理的安全性が不可欠である

　アジャイルのコア技術は本来、技術的でも機械的でもなく、文化的なものである。アジャイルチームは協働による対話的プロセスを実現するために、最終的には心理的安全性――脆弱性が報われる環境――をよりどころにする。

　高度の心理的安全性は、イノベーションを目標とする動作反応を引き出す。心理的安全性が低い場合は、生き残ることを目標とする恐怖反応を誘発する。問いを提起すること、間違いを認めること、アイデアを探索すること、現状に異議を唱えることをチームメンバーがやめると、アジャイルではなくなる。

申し訳ございません。

さすが翻訳ものが多いハーバード・ビジネス・レビューだけに、「心理的安全性」なんてさらにややこしいフレーズが登場してしまいました。

「心理的安全性」と「安心できる」はずいぶん違う

　自分の気まぐれやわがまま、不安定な気持ちをそのまま受け止めてくれそうで、まるで家族の中にいるような「安全・安心」な感じがしますよね。実際、最近は、「うちの職場はみんな仲がいい」「友達付き合いしてくれる上司がいる」と感じている方も多いでしょう。そういう方は、心理的安全性が確保された生産性の高い組織にいる可能性が高い。

　もしもそう思っているとしたら、あなたは心理的安全性を完全に誤解しています。

　「何でも言い合える関係」ということは、あなたが言えるだけでなく、反論もされるのです。耳の痛くなるようなこと、できれば聞きたくないことを指摘され、厳しいこともズバズバ言われます。

　それでも信頼関係が揺らぐことなく、お互いにダメ出しやツッコミも不安なくできる。

　そういう状態こそが、「心理的安全性が確保された」ということなのです。

筆者も「心理的安全性：Psychological safety」なる心理学用語を初めて目にした時は、「殴ったね！オヤジにもぶたれたことがないのに！」などと発言するような人材がわがままし放題の学級崩壊を想起してしまいましたが、漢字のイメージとは真逆の状態であるようです。

喧々囂々の議論の中で日々切磋琢磨し合う、まさしく自律した人材がベースになった集団でこそ機能する考え方のようです。

この心理的安全性がバズったのは、これまたいつもお世話になっている Google先生の社内分析レポートがきっかけだったと記憶しており、GAFAの組織ならではとうらやましく感じたものでした。

自己組織的なチーム
対話の中で方向性・仮説を見出し
顧客へ価値を素早く届け
素早く改善

ここまでの内容をまとめると、やはりウィキペディア先生のおっしゃることは間違ってなさそうで、アジャイルなるものは前記の要件を満たして余りある、高スキル人材の集団であってこそ機能できると考えるのが妥当かと思います。

結果、IQ：200超えは無理だとしても相応の高スキル人材で構成された集団でなければ、モノゴトをアジャイルに進めようとしても失敗してしまうのでしょうか？

その答えを出すのはちょっと早そうなので、ウォーターフォール → アジャイルと続いた文脈から、筆者のオススメをご紹介します。

アジャイルが無理ならプロトタイピングにすればいいじゃない

※この小見出しは、「パンがなければお菓子を食べればいいじゃない」へのオマージュであります。

プロトタイピング - Wikipedia

ソフトウェア開発工程のモデルの1つとしてプロトタイピング・モデルがある。要求を集め、プロトタイピングを行い、ユーザーがそれを検証する。エンドユーザーは何が必要か明確に意識していないことが多く、要求分析フェーズで明確な要求や目的を開発者に伝えられないことがある。このためにプロトタイプが使われる。ユーザーがプロトタイプを検証した後、そのフィードバックに基づいて新たなプロトタイプが作られ、再度ユーザーがその検証を行う。各サイクルはユーザーから聞き出すところから始まり、それに基づいてプロトタイプが作られ、それをユーザーがテストし、最初に戻る。

安直には、自動車業界や外食産業などでよく聞く「プロトタイプ：試作」からの派生であることは想像つくのですが、ウィキペディア先生によるプロトタイピングの定義を補完すべく、筆者が大好きなスティーブ・ジョブズの格言も添えさせていただきます。

顧客は形にして見せてもらうまで、自分が何が欲しいのかわからないものだ。

この格言は、成熟社会における商品企画・開発の世界で金言とも言われるものであります。

マーケットインとプロダクトアウトの向こう側　～二元論を超えて～

　マーケティングを勉強したことがない人でも、「プロダクトアウト」と「マーケットイン」という言葉は聞いたことがあると思います。改めて説明するまでもないかもしれませんが、念のために確認しておくと、一般的に「プロダクトアウト」というのは技術や製造設備といった提供側からの発想で商品開発・生産・販売といった活動を行うこと、「マーケットイン」とは市場や購買者という買い手の立場に立って、買い手が必要とするものを提供していこうとすることを指しています。

　少し前まで、これらの言葉は、「うちはどうしても技術屋発想だから駄目だね。もっとお客様のことを知って、プロダクトアウトからマーケットインへと発想を転換しないと」といった文脈で使われることがほとんどでした。ところが、最近では、「プロダクトアウト」も見直されていて、「提供側からどんどん提案していくべきだ」という主張がされることもあります。この主張の背景には、消費者やお客様は必ずしも自分が欲しいものを明確に知っているわけではなく、形のある商品として提示されて初めてそれが欲しいか否かの判断をするものだ、という認識があるようです。

モノがなく作れば売れた高度成長期の市場であれば、例えば「電化製品の三種の神器」やクイズ番組の優勝賞品だったハワイ旅行、舶来のウイスキーやブランデー、洋モクなどなど、みんなが憧れるモノはほぼ収束されていたため、市場調査：マーケティングリサーチに代表されるマーケットインの手法を使えばよかったわけですね。

ところが、市場も消費者（最近は生活者と呼ぶ）も成長し、モノがあふれた成熟期の市場にあっては、顧客自らが欲しいものを具体的にイメージしておらず、例えばネットショッピングのレコメンドから唐突に「あ、面白そう！」と衝動買いしてしまうようなシーンが繰り返されるというものです。

スティーブ・ジョブズが iPhone のプレゼンテーションで魅せたプロダクトアウトの瞬間は、こちらの記事に埋め込んでいますので、ぜひご覧ください。

企画書・提案書だってプロトタイピングで作ればいいじゃない

ソフトウェア開発に限らず日常のルーティンタスクにおいても、成果創出のスピードやクオリティーを高め・進化させていくことは可能と考える筆者としては、アジャイルの一要件だった「仮説検証型」という概念を「プロトタイピング」という具体的なプロセスに落とし込むことをオススメします。

ご紹介したジョブズの格言ではないですが、何らかの成果物を作らなければならない場合に、作っては見せ・直しては見せ・さらに直しては見せを、ただひたすら愚直に繰り返すわけです。

プログラミングにおけるソースコードレビューに限らずとも、企画書や提案書だって上司・同僚・後輩にレビューしてもらいながらブラッシュアップ＆リバイズを繰り返すだけです。

このような仕事の進め方は、以前の記事で紹介した「守破離」であれば「守」のフェーズに該当し、そこで成果物の作り方という「型」が身についたら「破」のフェーズに進化できる資格が持てたと言えるようになるはずです。

ただこの手法だと、レビューする人たちの時間を奪うことになってしまいますから、これまた以前の記事『わりと知られていない「レガシーIT人材」≦「デジタル人材」』で紹介したように、チャットやクラウドアプリケーションのようなデジタルツールを駆使することで、レビューする人たちのちょっとした空き時間を使ってもらえるようにすることが大前提でもあったりします。

実は筆者も、この記事の原稿や企画書・提案書など、いきなり HTML や Powerpoint などの最終形で書き始めるのではなく、法人契約している Google Workspace で利用できる Googleドキュメントを使って草稿しています。

企画書・提案書であれば全体のシナリオ設計の段階で、大見出し・小見出しといった構成要素を書き出してみて、その段階で一度 Googleドキュメントの［コメント］機能を使ってレビューを依頼します。

レビューする側は、Googleドキュメントの［編集］モードを［提案］モードに切り替えて、構成の順序を入れ替えたり、文言や文章をどんどん校正していけるので、その名の通り［たたき台］だったドキュメントが徹底的にたたかれて、ブラッシュアップ＆リバイズが見る見るうちに進んでいきます。

ファイルサーバーで共有していた Word 文書などのファイル名を変えながら校正のやり取りをしていた時代が遠い昔だったかのように（実際はほんの10年前）、作業効率が劇的に高まったのはもちろんのこと、属人的だったドキュメンテーションスキルの共有も自然と進みますので、チームによる「シン・仕事のやり方改革」も爆速になっているはずです。