やってみなはれ〜プロトタイプ開発〜

Biz
文字数:8,518字 | 読了目安: 約11分 | 公開日:2019.07.24 | 更新日:2021.05.01

システム開発の用語に、「アジャイル」と「ウォーターフォール」という考え方があります。今回は、新規事業開発や業務改善にも通ずるプロジェクト運営のあり方をアジャイルとウォータフォールの概念から考えてみます。

「アジャイル」と「ウォーターフォール」

ウォータフォール

「ウォータフォール」は、古くからある考え方で、water fall = 滝のように上流から下流に以下の工程で進めていくものです。

  1. 要件定義
  2. 基本設計
  3. 詳細設計
  4. 開発・実装
  5. テスト
  6. 運用

システムを外注する場合などは、発注元として提案要求:RFP=Request for Proposalを定義するなど、最初に決めたことを実行していくイメージが強くなります。

アジャイル

一方の「アジャイル」は、agile = 敏捷 かつ 臨機応変に上流から下流の工程を往き来しながら開発する考え方です。犬の敏捷性を競うアジリティという競技がありますね。

昔のようにビジネスモデルが単純だった時代は、ウォーターフォール型で良かったのですが、現代のビジネスにはマッチしなくなりました。ビジネスが複雑化するにつれ、RFP(提案要求)や要件定義からしてまともに出来ていたのか、疑問に思わざるを得ないプロジェクトが世の中にはたくさんありました。

歪んだ権力構造の弊害

業務の現場感覚も最新のプログラミング環境における実装技術も持たない、元請け会社やコンサル、管理職が上から目線の要件定義や仕様書を上流側で策定します。下流に行くに従ってその非現実性が明らかになるも、上流に戻るには権力構造的にもコスト的にも対応出来ず、いわゆるデスマーチ( 破綻が見えているのに進まねばならない現場の悲哀を表す用語ですが、IT業界用語かな?)になり、プロジェクトが破綻します。

特に日本的な多重下請け構造はIT業界では致命的な欠陥となります。実装を担当するのは3次請け、4次請けだったりして、伝言ゲームと歪んだ忖度の多重化で要件も仕様もわけわかんなくなっていきます。誰もプロジェクト全体を見渡せなくなり、金融機関のシステム開発で訴訟にまで発展する事例や数百億かけていながら開発中止になった官製プロジェクトがいくつもありました。

現在でも大企業の大型プロジェクトなどであれば、ウォーターフォール的な考え方が必要でしょう。しかし、大企業でも部門毎のシステムや新規事業開発においては、アジャイル型開発が適しています。機動力ときめ細かさが事業の生命線である中小零細はいうまでもありません。

アジャイル型の良い点は、とにかく動作の見えるプログラム、プロトタイプを作ることで、仕様を定義しやすくなること、実際に使う人・現場の意見を集約しやすくなることです。特に中小企業では、ちょっとした業務でも顧客や状況に合わせて細かな調整をしているケースが少なくありません。

また、特別な仕様を知っている人が、一部にしかおらず業務が属人化しているケースも多々あります。こうしたイレギュラーな処理を含めて、すべて仕様書としてまとめようと思うと、暗黙知、例外処理や条件分岐が多くて、要件定義や仕様書の文書化だけでもかなりの工数になってしまいます。

結果、重厚な要件定義書や仕様書に基づいてシステムがある程度出来てしまってから、想定できていなかった使い方や仕様に対応する必要があることが判明して、設計変更や実装工程のやり直しなど、いわゆる手戻りによる影響も甚大なものになります。

現場目線で実践的に

こうした反省から、とにかく作ってみる、やってみる、テストする、使いながら検証しながら作るという発想に重点を置いたのがアジャイル開発です。この考え方はシステム開発に限らず、新規事業の創出から業務改革まで、多様な業務フェーズで活きてきます。

事業開発では、MVP=Minimum Viable Product、実用的な最小限の製品という考え方もあります。要件や機能を絞って製品・サービスをリリースしていこうというものです。いろいろ、不足する機能があったとしても、顧客の反応や要望を見て、順次、改善していくという考え方です。

ただ、ここで問題になるのが日本人の完璧主義です。現場からは完成していないシステムを使わせるのか!といった反発が出ます。情報システム部門も経営者も責任を追求されたくないので、無謬性に執着しがちです。かといって、現場側でシステムの仕様書なり、業務の構造的手順書を書けるかというと書ける人がいません。定義されていないものは、誰もシステム化出来ないわけで、鶏か卵か問題とも言えます。

正直、一部の担当者しか知らないような業務に対応出来ていない!とか後から言われて、がっくりくることも少なくありません。プログラマはエスパー(超能力者)じゃないので、あんた方の頭の中まで読み取れんわ! と言いたくなることもあります・・・。

しかし、アジャイル開発においては出来るだけ、業務を実行する人たち、現場の人たちを想定して何につまづきそうか、この画面では何を見たいか、何をしたいか想像力をフルに働かせます。ポイントを絞ってヒアリングするように努力していますし、早めに画面構成や遷移を見せることで、仕様の漏れや誤解が生まれないようにしています。

そういった意味でも、経営者や情報システム部門が丁寧に現場の業務をフォローしないといけないのですが、最近の実務は複雑多様化していて、ヒアリングするだけでも一仕事です。また、システム化というのは業務の見直しにもつながるもので、いたるところに地雷が潜んでいる可能性があります。

長年、問題になりながらも放置されてきた業務を明らかにして、対応を決める必要が出てくるなど、現場に嫌がられることも少なくありません。従来、人間が鉛筆をなめて決めていたことも、標準化しようと思ったとたんに、数値化する必要性も出てきます。

暗黙知から形式知へ

暗黙知から形式知への転換が難しいのは、そもそも暗黙知ですから自覚されていないわけです。知っている本人が価値をわかっていないこともあります。聞かれれば答えられる、その状況になれば経験から判断出来るけど、あらかじめ体系的に定義することが出来ないわけです。

結果、各部門や各担当者が独自の判断で運用するなど、業務が属人化していることが多く、誰もシステム化を推進することが出来ない状況がずるずると続くことになります。日常の業務を回すだけで忙しい直接部門は、情報システムや管理部門の支援を期待するわけですが、たいていの場合、管理部門は現場の曖昧性や複雑性を理解出来なかったり、ITベンダーに丸投げだったりして、現場と対立することになります。

不確実でも進む

現在の大企業、官僚、大学などが、従来の成功体験から脱却出来ず、新しい時代への対応が遅れています。日本の公教育の弊害として良く言われていることで、正解がある問題に対応することは得意でも、明らかな正解がない問題を苦手する人が多いことがあげられます。そして、現実社会では明快な答えがない状態でも、前進しないとならないのです。

しかし、企業も行政も上層に行くほど、そもそもの問題を発見する能力、適切な課題を設定する能力のある人がいません。学校での成績が優秀だった人ほど、正しいやり方や他で成功している方法を探してしまい、正解がない状態に耐えられません。そして、長年、何も問題を起こさかった= 何もしなかった人が、企業の上層部に多くなり、現在の日本企業の弱体化につながっています。

中国を始めとする新興国勢力は、ちょっとした失敗などものともせず、ガンガン進んでいきます。最近の中国勢は失敗ー改善サイクルが完全に機能してきています。アメリカ勢は、IT・デジタル技術の先進性を駆使して、既存ビジネスを再定義する手法が広まっています。既存勢力を破壊する勢いで、AmazonやUberに代表されるいわゆるディスラプター(Disruptor)が世界中を席巻しています。ヨーロッパ勢は、人間に対する深い洞察、社会の成熟度や深い歴史を背景にデザインや独自のブランド価値を構築しています。

プロトタイプ志向の勧め

さて、日本はどうするべきか。まだまだ、日本の強みはあるはずです。戦後の高度経済成長期の大量生産大量消費時代の成功体験を脱却して、新たな価値を構築する時期です。新しいことにチャレンジする文化と機運を作って行く必要があります。そこで、お勧めしたいのが、冒頭から説明しているアジャイル開発の考え方であり、プロトタイプ志向です。プロトタイプとは、原型,試作品といった意味です。

仮にでも動くシステムを作れば、関係者から良くも悪くも意見が出てきます。意外なことが判明したりします。新製品開発・新事業開発・業務改善をする場合、市場調査から始めるのか、自社の持っている技術・シーズから始めるか。多様な考え方があります。自社の業務における課題解決を進め、そのノウハウを製品化・サービス化することも考えられます。どれもやってみないと分かりません。そして、やってみたことが、何らかの形で可視化されていないと、何をやっているのか、まわりが理解できません。協力も出来なければ、意見も言えないのです。

プロトタイプを作成して、システムの画面構成や画面遷移を構築してみると、必要な選択枝、チェックすべきビジネスロジック、多様な組み合わせなどが可視化されることになります。どの選択枝や機能が必要なのか有益なのかを判断する機会となり、業務の戦略的な見直しにも通ずる活動になります。

従来的な意味では上流から下流まで一方通行だったものが、上流から下流を行ったり来たりしながら、その活動を業務改善につなげたり、新規事業の創出に活用したり、人材教育や人材獲得に応用したり、一つの活動を縦横斜めに活用するよう、事業の全局面に適応させるパラレルな視点を持つことが重要です。

パラレルとシリアル

「パラレル」と「シリアル」も考えておきたい概念の一つです。古い考え方の人たちに共通する傾向として、シリアル思考があります。シリアル=逐次処理思考で、一つ一つこなさないと先に進めないかのように自らを拘束している傾向です。目の前のことしか考えておらず、パスも一つしかなくて、余計な手順や作業ばかり積み上がっている上に、少し先の手順やトラブルを想定出来ていなかったりします。

具体的な作業、実装、運用は一つの仕事に集中すべきですが、個人においても組織においても、視野を広く持ち、同時並行的に前後左右を自由に行き来できる「パラレル」な思考を取り入れることも重要です。三手ぐらい先までは3〜5パターン位の可能性を考慮しておく位のことはしておきたいものです。

経営者は広い視野を持ち、全体を把握しながらITのハンドルを握っている必要があります。もし、自分自身はITが苦手だとしても、経営レベルでITを語れるパートナーを持ち、時間的、空間的に俯瞰した戦略を構想すれば良いのです。

具体的な進め方はどうする

さて、具体的な進め方をどうするかですが、昨今はPDCAサイクルを回せ、とも言われていますが、計画にとらわれて、一方通行的なシリアル思考に陥ることにも気をつけないといけません。朝令暮改、七転び八起き、臨機応変に取り組む姿勢も重要です。とかく、計画変更を出来ないことや当初の目的に縛られるのもお役所を筆頭とする官僚的組織の持つ弱点です。そして、いかなる組織も官僚的になりやすいことを自覚しておく必要もあります。

PDCAは Plan – Do – Check – Action の略語ですが、昨今は悠長に計画している時間はない、という文脈で、OODA ループという考え方も提案されています。 Observation – Orientation – Decide- Action の略で、米ソ冷戦時代の戦略分析において導出された概念です。戦闘機の絶対的性能よりも、視界の広さや操縦追従性の高さなど、操縦士の情勢判断や意志決定の速さも含めた能力に軍事的優位性が認められたという研究がベースにあります。

総合的に監視して(Observation)、時空間の情勢を見極め(Orientation)、意思決定して(Decidion)、行動する(Action)ですね。ビジネスでも、大きな長期的な計画を立てるより、細かな市場分析・情勢分析と機動的な対策が重要な時代になり、これからはPDCAよりOODAだ!みたいな言われ方もされています。

これはこれで、流行り言葉、バズワードに踊らされないようにしないといけませんが、計画変更に稟議書が必要となるような、行政を始めとする大規模組織は考慮すべき概念の一つと言えます。

現場への権限移譲も必要になるし、機動的な判断が出来る人材をどうやって教育するのか、人事上の評価基準をどう設定するかという管理上の疑問も出てきますが、これはまた長くなるので、別の機会に取り上げたいと思います。

PDCAとOODAを組み合わせるとか、Researchを入れてRPDCAだとか、いや、管理しない方がうまく行くだとか、動画配信サービスで急成長のNetfrixのように上下左右のあらゆる方向で相互に評価するとか、いろいろな考え方がありますが、自社の置かれた状況、市場、組織、人材等、多様な条件から最適な手法を採用すれば良いでしょう。

やってみなはれ

具体的な手法や実装は別の記事に書きますが、システムであれば画面構成を紙に書いて行うペーパープロトタイピングでも良いのです。もう少し画面を作り込むならAdobe XDなどもあります。Apple子会社であるClaris社のFileMaker、サイボウズのKintoneなどを使えば、実際に動くプロトタイプまで作れますし、用途によってはそのまま実務で使えるシステムを作ることもできます。

「プロトタイプ・パラレル・アジャイルに動く」フェーズと、「ウォーターフォール・シリアル・計画的に動く」フェーズを、見極めることも大切です。アジャイルで動かしたプロジェクトで知見がたまったところで、計画に一度立ち返りましょう。ある程度、計画を立てたら計画にとらわれすぎず、アジャイルに動きましょう。こういうメリハリが必要ですし、そのコントロールを自覚的かつ自律的に行うことが重要です。

「やってみなはれ」は、サントリーを一大企業に成長させた佐治敬三さんの言葉として有名ですね。「みとくんなはれ」は、当時サントリーの広告部でコピーライターをしていた開高健さんの返す言葉です。2人の信頼関係と緊張感にも想いを巡らせつつ、システム開発、新製品・新サービス開発など、「アジャイル開発でプロトタイプを作る」ことから、やってみなはれ!

参考書籍

とりたてて凄いことや斬新なことが書いてあるわけではありませんが、わたしの記事だけでは説得力にかけるでしょうから「アジャイル」についての参考書籍として紹介します。ボストンコンサルティングのコンサルティングの方が書かれた本ですが、32ページとボリュームも軽いので目を通されることをお勧めします。

蛇足ですが、このハーバード・ビジネス・レビューのシリーズは論文となっていますが、参考文献やデータの出処に関する記載もなく、“論文”の体裁にはなっていない気がします。また、ハーバードとかBCGとかのブランド、コンサルをむやみにありがたがる必要もありません。

もし、ビジネスを実践しているあなたがアジャイルに取り組み始めば、あなたこそが先端的なフロントランナーです。大学やコンサルは後から学術的に体系化しているだけです。いわば、過去をまとめているだけです。未来は、いまここから生まれるのであり、事業を実践するものの行動から始まるのです。

ビジネスで本当に重要なことは何か。Netfrix の社内文化を知ると、くだらないルールや空気に縛られている日本企業がアホらしく見えてきます。顧客に価値を提供することに集中して突っ走る文化を持つ企業の強みがそこにあります。そのとき会社が直面する課題に最も有効な能力を持つ人材でチームを構成することが最優先とされる文化は働きがいがあるでしょう。

同時に、そうした人事制度を提唱した本人でさえ、その制度や文化により会社を去ることになったという厳しい側面もあります。映像配信という娯楽性の強い事業分野でもあり、こんな全速力で突っ走っていて、こういう企業文化や事業体が持続可能なのか。少し気になりますが、本質とは関係ない無駄なエネルギーを費やしている日本企業は、Netfrix に見習って欲しいところが多々あります。

著者はOODAループの概念を導出したジョン・ボイド氏とも交流があり、OODAループにおける原典に近い書と言えます。軍事研究がベースにあることから実際の戦争における軍事作戦を題材とした記述が多いので、ビジネス視点では冗長かつ難解です。

わたしは軍事作戦の解説部分は斜め読みしましたが、ジョン・ボイド氏がその戦略を構想するにあたり、孫子や宮本武蔵といった兵法家や、トヨタ生産方式の生みの親である大野耐一氏の考え方にOODAループとの共通性を見いだしているあたりは興味深く感じました。

ジョン・ボイド氏の講演での様子などからも、本ブログでも警鐘を鳴らしている机上の空論の暴走、リアルな現実を観じることなく言葉や数字や計画の方を優先してしまう官僚化を戒めていたことがわかります。

OODAループの原典に近い書として紹介します。マキャベッリやランチェスター、クラウゼヴィッツやハンニバルなどの戦略論好きな方には良いと思いますが、忙しい経営者の方にはあまりお勧め出来る本ではないかもしれません。具体的にOODAループの概念をビジネスに導入する手法を検討したい方は、次に紹介するOODAループ思考[入門]をお勧めします。

意外と重い内容なのでここで紹介するか迷ったのですが、2代目社長として「やってみなはれ」でサントリーを一大企業に育てた佐治敬三さんと、盟友とも言うべき開高健さんの物語です。いろいろな意味で「やってみなはれ」の重みを感じる書です。本書を読むと佐治さん自身も行動の人であったことがわかります。ウィスキーやビールの味を決めるブレンダーであり、セールスの現場にも立ち続け、実務に携わっていたことにも感銘を受けました。いまやここまでのバイタリティと行動力を持ち、現場に立つ経営者はなかなかいないでしょう。

従軍記者としてベトナム戦争の現場を体験し、自身も命の危険にさらされるなど、現地・現物とそこにいる生身の人を大切にした開高さんも行動する人でした。外野や安全な場所から他者を批判する人が多い中、行動する人であること、やってみることの大切さを考えさせてくれる書です。

タイトルとURLをコピーしました