後から知識をつなぎ合わせるということ
「将来をあらかじめ見据えて、点と点をつなぎ合わせることなどできない。
できるのは、後からつなぎ合わせることだけだ」
と、スピーチをしたのはスティーブ・ジョブズですが、今得た知識が目前
の問題を解決する事はできないが、将来の問題解決には強力な手札になる、
ということは実感しています。
二十数年前、会社はこれまで経験したことのない超大規模プロジェクトに
参画する機会がありました。このプロジェクトがスタートして間もなく、
自社メンバーにスキルが不足していることに気が付いた時の経営者は、コ
ンサルタントを招聘し、中堅メンバーに一週間程度のプロマネ研修を受け
させました。ところがこの研修は大層な不評で、不満を口にするもの、内
職するもの、途中からいろいろと口実を設けて参加しなくなるものが続出
しました。
理由はわからないでもありません。研修で学ぶ教科書の知識を、目の前の
実務にどう適用できるのか、誰もわからないのです。プロジェクトの初期
段階でしたしたが、既に課題をいろいろと抱えているメンバーがいました。
彼らは今抱えている課題に、学んだ知識をどう適用すべきかわかりません。
初期段階でしたので、まだ危機感をもっていないメンバーもいました。彼
らこれからどういう状況になるのかわからないので、研修を漫然と聞くだ
けで、知識がどう役に立つのか想像だにつきません。
私もこの研修に参加しましたが、他にもれずこのプロジェクトのなかで知
識が役にたった実感はありませんでした。それどころか研修のきっかけと
なったプロジェクトが終わった後、別の多くのプロジェクトに関わること
になりますが、その中でも研修内容が役にたった、という状況は殆どない、
というのが正直なところです。
ただ少しハッピーだったのは、このプロジェクトが終わった後に、評価を
行う宿題をもらったことでしょうか。なんせ、いろいろとあった大規模プ
ロジェクトです。みな息も絶え絶え走りぬいて、精も根も尽き果てている、
戦後の混乱期状態。それでも経営者はこの経験をそのままにしておくのは
もったいない、と考えたのでしょう。お客様と大学の研究室を巻き込んで
プロジェクトの経緯と評価をおこなうプロジェクトを始めました。そこに
私もアサインしてもらったのです。
その評価プロジェクトで改めて、システムの見積法や開発論、マネージメ
ントについて勉強する機会を得ることができました。
プロジェクトが終わった後で基本を勉強するなんて、本末転倒だと思われ
るかもしれません。
しかし経験したあとで教科書を読むことで、書いてある内容が実感も含め
て正しく理解できるのも事実ですし、なにより、仮に今回の件でプロジェ
クトが始まる前に知識を身に着けていたら、おそらくこんな無謀なことは
やめておけ、という結論になっていたと思います。なまじっか知識をもっ
てしまうとリスクだけに目が行き、行動することを躊躇してしまいます。
幸運にも大規模プロジェクトの成功体験と基礎知識を勉強する機会を得ま
したが、だからと言ってその後の仕事にほとんど知識が役立つことがなか
ったことは前述の通り。というのも、こんなにややこしい大規模プロジェ
クトがそう何回もあるわけではなく（あってもたまりませんが）、そのプ
ロジェクトで作ったシステムの運用保守と、機能改善が主な業務となって
しまったため、高度な開発論やマネージメント力が必要になることは殆ど
なくなってしまったのです。工数見積もりや計画書、仕様書の作成等は行
いますが、規模も小さくリスクも少ないので過去の資料の使いまわし。そ
こに斬新さは求められず、マンネリズムの極み状態になっていました。
ところが最近、この状況がすこし変わりつつあります。
新規のお客様から、アジャイルで開発したい、クラウドを活用したい、と
の要望が増え始めたのです。ただし要望するお客様がアジャイルやクラウ
ドに対して正しい知識を持っているとは限りません。ただしくいうと、お
客様はアジャイルやクラウドについて何も知りません。ただ、なんとな
く安く、早く、良いものができると思い込んで要望します。そしてベンダ
ー側も計画不要、ドキュメント不要、予算青天井の妄想を抱いてそれに乗
っかり、不幸なプロジェクトが量産されているようです。
その辺りのことを書いた過去のコラムもありますので、宣伝。
「アジャイル狂詩曲」
アジャイル自体はエクストリーム・プログラミングやスクラムなど、一部
手法化されている部分もありますが、全体としては最初に何して、次に何
してと、確立された手順のない、概念的なモデルでしかありません。その
ためBtoBビジネスでこの方法を採用することは難しく、「何ができるか
わからない」「コストの妥当性がわからない」「契約の仕方がわからない」
の三重苦で、特に大手企業などでは契約自体のハードルが高くなります。
当然、開発手法として妥当性と、契約方法との相性は別物なので、（中途
半端な知識や妄想は排除して）きちんと考えるとアジャイル憲章は開発す
るうえでの合理性を持っていることがわかります。おそらく官僚化してし
まったW/Fから、よりモノづくりの原点回帰を目指しているのだと思いま
す。
そうなると、アジャイルは開発方法論としては理にかなっているが、
BtoBビジネスに適応するには課題がある、ということになります。だと
したら、その課題を埋める方法、進め方、契約の仕方を新たに考えないと
いけません。もともとアジャイル自体が確立された手順のない概念モデル
ですから、実際のプロジェクトに適用するには、そのプロジェクトでのや
り方を決めないと前に進めない、という当たり前の話でもあります。そこ
を手を抜いてそれぞれの勝手な思込みや妄想で開発を進めるからトラブル
になるというのは前述の通り。実際には契約の事までを考えると、それは
W/Fとのハイブリットのようなやり方になると思われます。
最近の試みとして、我々なりのアジャイル開発のやり方を定義して、希望
されるお客様に説明と合意をとった上で進めているプロジェクトがいくつ
かあります。そして今のところ順調です。まだやり方自体は見直しをかけ
つつ試行錯誤していますが、イメージとしてはW/Fの形態をとりつつ、ア
ジャイルに進めている、そんな感じです。
W/Fは計画重視でプロセスが定義され、手戻りを起こさないことに重点が
置かれています。一方でアジャイルはコミュニケーションを重視し、変化
を受け入れ、問題解決に重点が置かれています。しかし初期のW/Fには計
画の見直しが提唱されていますし、アジャイルにはどこにもドキュメント
をつくってはいけない、とは書かれていません。この世の中に、これが唯
一正しいやり方、そんなものが存在すると思うのは妄想です。開発するも
のや条件に応じて、都度、適切なやり方を決めるしかないのです。
そのやり方を思い付きで決めてしまっいては失敗する確率が高まります。
だから先人たちの知恵である、いろいろな方法論を学習し、その特性を理
解したうえで、それぞれのプロジェクトにあわせることが肝要なのです。
「我々なりのアジャイル開発のやり方」を考えるうえで、先の大規模プロ
ジェクト経験、研修で得た知識、評価プロジェクトで勉強した内容がベー
スになったことは間違いありません。
「配られたカードでカードで勝負するしかないのさ...」スヌーピー
戦争を始めるときは、持っている兵力で戦うしかありません。戦争を始め
た後に兵力を増やすことはできないのです。言い換えるならば、持ってい
る手札は多い方が良い。
先のスピーチで退学を決めたジョブズが、興味本位で潜り込んで聞いたカ
リグラフの講義がマッキントッシュの設計に大きく関係していると話てい
ます。過去に得た経験と知識が、今の問題解決に大きく貢献する。そのこ
とを実感した、という話でした。
「ハングリーであれ。愚かであれ」