「スクラム開発においては、プロジェクトマネージャーは存在しません。」

　とある資料を作るために、新規事業開発チームメンバーのスキルを表現するキーワードを検索していたら、とある職種解説ページの、とある文章が目に飛び込んできた。

プロジェクトマネージャー

プロジェクトマネージャーとは、ウォーターフォール開発においてスケジュール管理やチーム管理などプロジェクト全体の責任を負う人のことです。勘違いされやすいですが、スクラム開発においては、プロジェクトマネージャーは存在しません。

　こういう文章が生まれてしまう文脈や背景はよくわかるが、実際にこういう表現を見かけると、なんだかなぁという気持ちになる。

　ウォーターフォールとか、アジャイルとか言うけれど、それは概念としてはあるかもしれないけれど、実践という意味では、この世にはどちらも存在しない。

　ウォーターフォールを志向しながらくんずほぐれつしながらアジャイルライクなことになってしまうこともあるし、アジャイルを試行してみた結果、ウォーターフォールライクになることもある。
　人はよくそれで「教科書通りに実践できてない」と落ち込んでしまったりする。その気持ちはもちろんわかるけれども、それはよく考えると、随分変な話だ。
　弁当を食べ終わった後で、弁当箱がイメージと違ったことを気に病んでいる感じ。

　ランチが腹に収まって、ピクニックが継続できたら、それで良いじゃないか。全然卑下する必要なんか、ないじゃない？

✳︎✳︎✳︎

　いやいや、ランチが食べれなかったんだとか、不味かった(開発がうまくいかなかった、成果物は生まれたけどイマイチだった)んだ、だから反省も卑下も、する必要があるんだ、という人もいる。

　もちろんそこには反省があってしかるべきなんだけど、その総括が、「教科書通りに実践できなかったから、ダメだったんだ」となると、それもまた違うだろうと思う。

　教科書通りの現実が、あるわけないのである。

　教科書に書かれているのは、抽象概念である。

　もちろんそこには、真実が多量に含まれてはいるわけだが、それを目の前の現実に適用するには、用途にあわせて希釈すべきである。
　そういう気を利かせることができないのは、マニュアル人間、というやつである。

　ルーチンワークならいざ知らず、プロジェクト(前例のない開発行為)が、マニュアルで進行できるわけがない。

　そもそもルーチンワークの場ですらも、例外は発生するし、そこでもっともダメなのが「マニュアル人間」ではなかったか。

✳︎✳︎✳︎

　「スクラム開発においては、プロジェクトマネージャーは存在しません」という言明は、こうした現実が、まったくもって見えていないからこそできる表現である。

　このテキストが抱えている深刻な自己矛盾が、当の「プロダクトオーナー」の職掌と、それに必要なスキルを以下だと解説する局面で露呈する。

プロダクトのビジョンを決めて共有する
顧客の要件を的確に反映する
優先順位を明確にする
開発・製品に関する幅広い知識
適切なコミュニケーション能力
発言力・決断力

　これって、「プロジェクトマネージャー」と、何が違うのか？
　にらめっこするドキュメントが、WBSか、プロダクトバックログかの、実に些細な違いでしか、ないんじゃないか。

　存在するじゃないか、「プロジェクトマネージャー」。せめて、「似たような責任範囲はありますが、その責任分担の仕方や呼び名に違いがあります」ぐらいのことは書けなかったのだろうか。
　とかく最近はアジャイルアジャイルと猫も杓子もな風潮があるが、極論すれば、開発行為に対する光の当て方の違いでしかない。

　直円錐を横から見たら二等辺三角形に見える。
　直円錐を上から見たら正円に見える。
　斜め上から眺めて陰影を取り去って、輪郭だけを切り取ったら、なにがなんだかよくわからない形に見える。

　WBSや詳細設計書を書く際に、顧客価値を意識しない人はいない。顧客価値を言語化したあとで、機能設計をせずに開発するのも不可能だ。
　問題は、どういう順番で考えた方が確実に良いものができるか、という点であり、確かにこの「光の当て方」は、生産性を大きく左右する。

　つまり、最大の問題は、「どんな開発行為のときには、どんな光の当て方をするのが良いか」である。
　残念ながら開発行為に取り組む前は、それが直円錐だという情報は与えられない。「斜め上から眺めて陰影を取り去って、輪郭だけを切り取ったら、なにがなんだかよくわからない形」から、その立体図を類推し、光を横から当てたらいいか、上から当てたらいいか、考える。

　良識ある実践家とは、そういうことをやっているし、真の意味でのエキスパートとは、その類推精度が高い人である。

✳︎✳︎✳︎

　99.9%の解説者は、そこに対しては永遠に口をつぐむ。

　なぜ口をつぐむのか。その手つきは徹頭徹尾、個別具体のケーススタディであり、そのプロセスを一般化した原典がないからだ。ゆえに、その点について、自信を持って断言できることが、存在しないからだ。
　一番大切なことには自信がなくて断言を避けて、差し障りのないことについてだけ、断言するポーズをとる。そこにはモラルのかけらもない。

✳︎✳︎✳︎

　ライターは、これぐらい単純化せずに語らないと、サクッと読める簡単解説にならない、と言うかもしれない。でも百歩譲ってそうだとしても、サクッと読めて有害な誤解を招く文章を撒き散らすことに、なんのメリットがあるのか。

　「世の中の開発行為には、正円(計画駆動)か二等辺三角形(実績駆動)のどちらかのアプローチを選ぶしかありません」
　イデアとしては(というか現実問題としては)、まさしくその通りだ。
　これをそのまま実践できると思って解説する解説者も、そのまま実践できると思って実践しようとする実践者も、論外である。

　なぜなら、私たちの目の前にある開発行為は、丸でも三角でもない、立体物なのだから。なんなら、直円錐ですらない。
　しかもそれは、神ならぬ人間の立場からは、永遠に俯瞰できない。ある角度から光を当てた影から、全体像を類推するしかない。

✳︎✳︎✳︎

　「プロジェクトマネージャーは、存在しません」という断言は、どこからやってきたのか。まともに物事を考えるということを、やっていたら、出てくるわけがないのである。

　我が国の「ITリテラシの低さ」の原因と結果が、まさにここにあるのだ。

　浅はかな文章を浅はかに引用し、解説する人間がいる。その動機は「新しいものを礼賛し、古いものを否定すれば、ありがたいことを言っているように見える」という唾棄すべきものである。
　それをまた検索、発見した人間が、浅はかに理解する。その人はいつかどこかの現場で「新しいもの」を知って大喜びでマウントポジションを取ろうとすることだろう。
　そこには似たような人がまた微妙にニュアンスの違う言葉を仕入れていて、二人の間には不毛なマウントの取り合い合戦が繰り広げられることになるだろう。
　そんなことでは、当然ながら、ろくに仕事が進まない。結果的に敗戦処理をしながら、「意識高い人」が「ITリテラシの低さ」を嘆く。そんな馬鹿馬鹿しいことが延々と再生産されていく。

　どうにかできないものかと、常に、考えてしまう。