昔のことです。「なぜアジャイルが導入できないのか」が話題になりました。
その当時、アジャイルが導入できない理由は＜文化＞であると、友人が調査を引用しTwitterで呟いていました。その＜文化＞とは、失敗を許さない＜文化＞、不確実性を忌避する＜文化＞（完全性を尊重する＜文化＞）、計画を尊重する＜文化＞のようです。そのような＜文化＞があるから、日本ではアジャイルが導入できないと結論づけていました。
銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) - ari's world の記事と関連し、2018年に数枚の図を書きました。そのうちの一枚の絵に対して、簡単に説明をつけて公開します。もはや伝説級の昔話かも、なので、物語的に楽しんでいただけたらと…
人々は＜文化＞に縛られ、＜文化＞を作り出している
人々は、「文化」によって思考や行動は規定されます。例えば、「恥ずかしい」と思うのも、「楽しい」と思うのも、このような文化を通じて学んできていることなのです。
その一方で、「文化」は作られる側面もあります。そこに関わる人たちが文化を作り上げて、恒常的に維持しているのです。文化は存在するだけでなく、人々によって生産され、常に燃料を投下しているのです。
では、なぜ、そのような失敗を許さず、完全性を求め、計画を尊重する文化が生まれたのでしょうか。そして、我々は、どのようにすれば良いのでしょうか。
私自身は、SIerと言われる仕事をしたことはありません。でも、そのような仕事をしている友達は多く、いろいろなことを聞いていました。友達からよく聞くことは、第三者だからこそ、見えてくる風景があるのかもしれません。
もちろん、ないのかもしれません。文化が生み出された理由をゆるく考えてみました。
文化に燃料をくべて、燃え続けさせること
アジャイルだとか、ウォーターフォールだとか、の話をする前に、ちょっと夏休みの宿題を考えてみましょう。
夏休みの宿題を 最終日になっても 終わらせることができず、「ヤバイ」って言っている人いませんか。私、8月31日は、毎年のように「ヤバイ」って思ってました。
例えば、最終日に1ヶ月分の日記をつけていました。毎日「晴れ、今日も元気でした。」と、書いてしました。毎日、元気なのは本当でしたが、「晴れ」なわけもないです。でも、毎日のように「晴れ、今日も元気」「晴れ、今日も元気」と書いていました。
夏休みになる前に、早めに宿題をやろうと志します。そんな志をいだきながら、夏休みの終わりを迎える、そんな志のある子どもでしたw。
もしかしたら、おおらかな時代や地域性だったのかもしれません。それとも親の方針だったのかもしれません。理由はよくわかりませんが、親からは何も言われなかったような気がします。ありがたかったです。
でも、もし親が困ったとしたら、何て言うでしょうか。
- 「夏休みになったら、ちゃんと計画を立てるのよ」
- 「どんな計画になっているの？」
- 「宿題にモレはない？」
- 「今日は、どれだけやったの？」
- 「計算や漢字の練習は、間違えないでね。」
- （まったく、この子は、ちゃんと見てないとやらないんだから）
こんな、感じでしょうか。しっかりと計画を立てさせ、約束し、それ通りにやっているかを確認していく、そんな感じにやっているのではないでしょうか？
プロジェクトの成功率は高いとは言えない らしい
そもそも、ITにおけるプロジェクトの成功率は、高いのでしょうか。JUAS、IPA、日経コンピュータなどが調査しています。例えば、検索したところ、日経コンピュータの記事がトップに出てきました。
プロジェクト成功率(2018) ： 52.8％ https://business.nikkei.com/atcl/opinion/15/100753/030700005/?P=1
100円のジュースを10本買ったら、5本は飲めないってことですよね。だんだんとプロジェクト成功率が上がってきたとは言え、約半分は失敗している、ということです。
さらに、（総務省 情報通信白書 2018）によると、IT投資しても十分に利益を生み出さない、資産にならないことが明らかになっています。
このような業界に対して、信頼できますか？
いろいろな理由があるにせよ、不安や不信が高まり、信頼がおけない状況になっていたのではないでしょうか。
夏休みの最終日でも、宿題が終わっていないのか状態ですよね？？
相互に信頼できないことが＜文化＞を強化しているのかも
あるプロダクトが欲しいけれど、こんな失敗だらけで信頼できない相手とは、どのように付き合いますか？例えば、このような付き合い方をしちゃいませんか？
- 一緒に力を合わせたら、共倒れになっちゃいます。しっかりと役割を分けましょう。ユーザ企業とIT企業（ベンダー）です。
- やるべきことを洗い出しましょう。ヌケモレがあってはいけません。完全なものを作っていても、ズレちゃいます。だから、もっと徹底して完全なリストを作りましょう。
- しっかりと計画を立てさせましょう。なんせ、相手は失敗だらけですからね。
- 不確実性は、失敗を生みます。変動要因を明らかにして、リスク管理を徹底しましょう。
- プロジェクトが失敗したときは、投資が無駄になっちゃいますからね。失敗をしたら相手が悪いはずです。契約で決めておいて、しっかり回収しましょう。
宿題をやらない子どもに対する方策と似ていませんか？
さまざまな標準や知識体系がありました。そのような知識体系をマジメにこなすことによって、このような＜文化＞を形成していました。
さらに相互に信頼できないことによって、このような＜文化＞を生み出し、存続させてしまう側面があったのではないでしょうか。
たとえば、こんなストーリーが目に浮かびます。
プロジェクトが失敗する理由は、要件定義にあるそうです
プロジェクトに対する調査では、様々な失敗要因が調査されています。
満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。
3回分の調査結果を見ると、プロジェクトが失敗する理由は要件定義の不備に集約できる。要件定義とは導入する情報システムで実現したい事項を整理し、決めることだ。 https://business.nikkei.com/atcl/opinion/15/100753/030700005/?P=2
「要件定義に不備があった」「追加の開発作業が発生」「仕様変更」など、もう百万回ほど聞いてきました、というのは、嘘だけど、失敗に対する精神的なインパクトを入れると、そのぐらいたくさん聞いてきた。
宿題をやらないのが悪いのではなく、宿題を出す側の両方に問題があります。答えが明確でわかりやすい単純な問題であれば、予測を立てて行えます。しかし、あらかじめ宿題として、適切に提示できないことが問題になっています）
新しいバズワードの表層的・強迫的な導入は、失敗を生み出す
IT側の問題もあったのではないでしょうか。
これまで、IT業界は、様々な技術や方法を紹介してきました。これまた長いリストになりそうなので、10秒ぐらいで書けることだけでも…
まだまだ、たくさん、出てきますね。
そう、その技術や方法が紹介されたときは、「アジャイルさえ入れれば、世界は平和」とか、「人工知能の時代だ、世界は変わる」とかとか、そんな文言が踊ります。いや、そこまでじゃないか。でも、まぁ、いろいろな言葉が使われてきました。
例えば、「アジャイル」が紹介された時も、多くの企業が飛びつきました（アジャイルでも、人工知能でも、なんでも良いです）。それもいいことだな、と、個人的に思います。経験し失敗することは貴重な情報です。
これらの方法や技術を追いかけるのも、楽しいです。大好きです。
ちなみに、過去で一番ハマったのは、コンピュータやインターネットの規格です。企画じゃありません、規格です。OSやアプリ、データベースからネットワーク、セキュリティからプログラミング言語仕様…、ホワイトペーパーやマニュアル、RFCなど、いろいろな規格を読みまくりました（法律も好きでした）。どのぐらい好きかというと、同僚が入院した際に、分厚いデータベースのマニュアルを持っていったぐらいです。ひどく怒られましたが、その時は何を怒られているか わかりませんでした。マニュアルや規格を読むほど楽しいものはないって思っていました。
閑話休題。
その上で、いいますが、やっぱり、それらはツールにすぎません。良いツールは人を助けます。けど、その先の世界を見つめる必要があります。本末転倒の状態を引き起こし、価値を提供し享受できない状況を生み出すことすらありました。
こんなに面白いツールは、なかなかないんですけどね。
どうにかうまくやっていくことを困難にすること
もしバズワードのような感じで技術や方法を導入しようとしていたら、自分たちの問題が解決されないのではないでしょうか。
どのような問題を解いているのか、どのような結果になるのかを、わからないでバズワードを使っているのです。しかも、いいような夢を見ながら泳いでいるです。雲の上に建築を立てようとしているようにも見えます。それだったら何もしないほうがマシです。
百万人ぐらいから反論があると思うから、書いておくけど、この雲の上に建築の話は、私のことです。もしかしたら世の中にはそんな人がいるかもしれません。きっと、その人は、暗闇の中で泳いで頑張っている人です（そっと応援してあげてください）。
いろいろなツールに対して、どんな問題を説いているのか十分に理解して使っていない、例えば、ノコギリで釘を打つような状態になってしまっているではないでしょうか。
「ちゃんと宿題やりなさい」「早めにやるのよ」と言っても、授業をしっかり理解せず、宿題も理解していない状態に似ていませんか
信頼と成熟に向けたストーリー
今までだったら「国語の勉強しなさい」とか「この問題集を解きなさい」とか、親が発注者、子どもが受注者の関係のようです。
去年の夏は、それをやめました。
私自身は、国語がとても苦手です。第3子も、私に似たのか国語が得意とは言えません。そこで、去年の夏休みは、子どもと一緒に国語の勉強をしました。（ゆるい組織）
国語についての書籍や資料をたくさん読み、子どもと一緒に問題集を解き、子どもに説明しました。（知の創造と共有）
あくまで目安ではありますが、子どもの偏差値も20ぐらい上がりました。
子供だけではありません。私の、論理力や抽象能力、表現力も、大幅に高まったようです（少なくとも、この文章よりヒドい状態ではあったのです）。
ゆるい組織（ゆるい役割と立場）で、文脈を共有しよう
夏休みの宿題は、宿題を出す側と、宿題をやる側の両方が歩み寄ると、楽しいことです。
組織を分断し、対立を内包するような関係、いわゆる発注者と受注者の関係性、ではなく、お互いの文脈を共有できる組織（ゆるい組織）を実現しましょう。
参考：ゆるい組織は、「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイドを公開：IPA 独立行政法人 情報処理推進機構に「組織構造のバウンダリをゆるめる」にも書きました。
（透明性とは、それぞれ違う組織の状況を可視化したもの、組織をゆるめるは、組織間の境界を取り払う働きのことです）
「知」の創造と「知」の共有
ゆるめられた組織において、この文脈を共に観察し、共に学び続けていきましょう。
今まで、子どもの勉強においても「あれをしなさい」「これをやってね」のようなスタイルと、子どもと一緒に学ぶスタイルの両方をバランスよく取り入れることです。
学んだことを、構造化することによって、共有と修正できるようにするワークが有効です。
（宣伝：気づきを構造化することで「知」を産み出し、その「知」を共有するためのパターンライティングのワークショップを開催しています）
そのことから、このような文化が生み出されていくのではないでしょうか。
あらたに作り出される文化の例
- 苦手科目については、一緒に学ぶ（ゆるい組織と共に学ぶ）
- 学んだことや気がついたことなどを共有する（「知」の創造や「知」の共有）
共に作り上げている状態においての失敗は、責任を追求するものではなく、貴重な情報として扱われます。この失敗をどのようにすれば良いのか、共に考えるきっかけとなります（失敗を許さない文化より、共に学習しながら成長する文化）
不確実であれば「正解」はわからなくなります。常に観察し、仮説を検証していくようになります。「データはどのようになっていますか？」「これは正しい問いですか？」や「どうやって確かめますか」の話題になるでしょう（不確実性を忌避する文化より、「観察」と「問い」が尊重される文化）。
学びや観察も、健全なコミュニケーションが前提になります。相手を見下したり、無駄に攻撃的になったりすると、その創造や学習の文化は、簡単に壊れてしまい、破壊的な文化へと容易に移行します（完全性・計画を重視する文化より、健全なコミュニケーションを重視する文化へ）
それに伴い、「失敗」「生産性」「品質」や「学習」などの言葉が、自ずと再定義されていきます。
そして、お互いの信頼を回復させながら、共に歩んでいくことが良いのではないでしょうか（と、その当時は思いました）。
夏休みは好きだったな。宿題を除けば
4枚書いた絵のうち、1枚しか紹介できませんでした（残りの3枚については、何かの機会に議論したいです）。
- 教育からのアプローチ
- コミュニケーションからのアプローチ
- 組織からのアプローチ
- 方法論からのアプローチ
現在のバリエーションは、「知」の創造と共有の＜文化＞、観察と学習の＜文化＞としてみました。それぞれについては、いろいろお話しながらお声がけください。ワークショップも開催します（宣伝）。
そもそも、夏休みの宿題は、なんのためにあるのでしょう。学びってなんでしょう。そんなことを考えながら、今日はお開きとさせてください。
落ち着いたら、美味しいものでも食べにいきましょう。オンラインでの雑談も大好きです。
