ペア・プログラミングなるものが流行ったことがあります。今でも使われているのかもしれませんが、最近はあまり聞かなくなったコンピュータ・プログラミングの手法のひとつです。基礎が身についている人にとっては費用対効果の著しく低い方法論で、やがて適切な場所に適切なタイミングで適用するように落ち着いたのでしょう。
プログラミング経験がないと何を言っているのかわからないでしょうから、少し補足します。乱暴な言い方をすると、二人の組でひとつのプログラミングをするものです。プログラミングは元来孤独なもので、少し長い文章を書くのに似ています。二人でひとつの文章を書くのが難しいように、プログラミングも二人ではやりにくいのです。
では、なぜ面倒だと分かっているのに二人でプログラミングするのかと言えば、自分の頭にある設計図を相手に伝える必要があるということにポイントがあります。クリアな設計図がなければ相手に伝えることはできません。ロジックが破綻していると、プログラムを書いて説明しているうちに矛盾や問題点に気付きます。聞いている側も理解しなければ続きを書けませんから、一所懸命に聞きます。理解しようとすればするほど、課題にも気付きます。課題でなくても、より効率的な方法を思いつく可能性もあります。そうやって、効率的で安全な間違いのないプログラミングができるのです。
一説には、効率が15%低下する代わりに不具合も15%低下するとのこと。プログラムを書くよりも不具合を修正する方が工数がかかりますから、より効率的になると見ることもできます。
でも、それって本当でしょうか？数字を前提抜きで見て良いのでしょうか？そうやって頭をクリアにする以外に方法はないのでしょうか？この二人のスキルレベルが同じだったら、より効率的な設計にはたどり着けないかもしれません。二人の工数を使うことに見合った結果となることも必要です。
ペア・プログラミングはひとつの例ですが、最近流行りの「壁打ち」にも疑問を感じ始めます。仕事の一部の何かが出来上がったら、あるいは、なかなか解決できない課題にぶち当たったら、誰かを壁にして説明しながら整理する。そうやって得られた結果で再び思考を重ね次に進む。
聞こえは良くても、そもそも最初から整理できていたら不要なプロセスです。途中で躓くということは、何か詰めきれていなかったことがあるのかもしれませんし、想定できない突発的な例外事項が発生したのかもしれません。仕事の進め方にきっと問題があるのです。仕事をするのに、リスク管理しないなんてことはありません。出張旅費の精算をするだけだって、領収書が揃っているかとか、精算する予定の時間に別件が入ったとしても間に合うかとか、そんなことは頭の中で考えています。
アイデアを誰かに話してアドバイスをもらうと言うとしっかりプロセスを踏んでいるように感じますが、そうしたアクションは日常の中にあります。責任を持ってジョブを行う担当者が、事前に深く考え、調査し、整理してベストな解を出すのは当たり前です。事前に深く考えたつもりで自信がないなら、それは十分考えていないと言っているようなものです。その過程で、同僚に簡単に相談してみることは当然あるでしょう。でも、壁打ちなどと言ってプロセスに組み込んでいるなら、考え直したほうが良いかもしれません。それを日本では、根回しと言っています。
しっかり考えて、会議の場で理路整然と説明する。答えは１か０。否定されたら再考するのです。ヨーロッパで仕事をしていたら、そんな癖がつきます。
そうであれば、なぜ壁打ちなんてものが流行るのでしょうか。一つの答えはペア・プログラミングと同じです。一人でやることが当たり前のことに、一人では出来ない担当者がいるとすれば、アドバイスをするなり教育するなりが必要となります。ペア・プログラミングの背景には、水準の低い技術者のスキル向上や責任の分散があります。つまり、人を育てる＋リスク分散する仕組みでもあるのです。
壁打ちも同じ。ペアプログラミングは著しく効率が悪いと書きました。もちろん、それは、スキルが極めて高い場合の話です。壁打ちだって、スキルが十分高ければ、自分にとっても相手にとっても「ムダ」な時間となるのです。しかも、組織のスキルは向上しません。
もう、反論したくてしょうがない人がいるだろうと思います。それはそれでOKです。ただ、こんなふうな見方でいる人も少なからずいます。
「で、あなたの意見はどうなんだ？アドバイスをもらってブラッシュアップするのは良いことだが、あなたはどんな夢を描いて、どれくらい自信をもってこれを提案しているのか？」
壁打ちしてもってきたアイデアがボロボロだったなんて極々普通にあるのです。
l'atelier tanu | tagnoue 