この記事はPeter G Walenによるゲスト投稿です。
従うべき「プロセス」が役に立たないのに、どうして最高の仕事を提供できるのでしょうか？義務付けられているにもかかわらず、良い仕事を提供できるでしょうか？「ルール」が邪魔になるとき、よい結果を出し、顧客を喜ばせることを目標にできるでしょうか？
完璧な組織ならこんな問題はありません。要件から設計、開発、テスト、デリバリーまで、ソフトウェア開発に携わる誰もが発言権を持ち、その意見が価値ある重要なものとして扱われます。私たちの大部分は、そんな組織では働いていません。
正式なプロセスを活用して成果を出せるでしょうか？プロセスにもかかわらず成果を出せるでしょうか？この2つの質問への答えは、私の経験や他の人との対話から言えば、「かもね」の連続ではないでしょうか。
「正式な」プロセスが新しく導入されたものか、ずっと存在していたが誰も気にかけていなかったものかは関係ありません。大事なのは、質の高いソフトウェアを提供するためにどのような影響を与えるかを明らかにすることです。
始める前に
以下は私がやったことです。
作業モデルに反対するのもいいでしょう。あれこれ不服を唱えるのもいいでしょう。しかし、実際に作業プロセスに取り組もうとしていなかったなら、反対や不服はたいして重要視されないのが普通でしょう。似たようなプロセスモデルでの経験やその結果を述べることもできますが、あなたが予想した結果を経営層やリーダー層に理解してもらうには、苦労することが多いでしょう。
落ち着きましょう。もったいぶって、大変なことになるだろうなどと言うのはやめて、正式なプロセスモデルの背後にある意図を考えましょう。プロセスが導入された理由や、なぜ以前は強制されていなかったものが強制されようとしているかという点の重要性を明らかにしましょう。
何が起きているのか、一見してもわからないかもしれません。そのプロセスが意図しているのは、明白な危険ではなくとも、何らかの懸念であることを理解しましょう。
最初の「短期間」
まず、義務付けられた作業モデルを持つ組織の大半は、モデルを変えようとする試みに抵抗します。定義どおりのプロセスへの反対は、結局「まずはやってみる」必要があるという反応で終わるのが通常です。
試しにやってみましょう。定められたとおりのアプローチに忠実に従いながら、影響や進捗をメモしていきます。何がうまくいって、何がうまくいかなかったかを記録します。記録された結果は、単なる感想ではなく、客観的なエビデンスを反映するようにしましょう。
新しいやり方に細心の注意を払いながら正確に従うことで、それがうまくいくかどうかを皆が確かめる機会が生まれます。ソフトウェアに問題がある製品ができあがったり、重要な期日に間に合わなかった場合、皆の経験に基づいて議論する下地ができます。
正式なプロセスを推進する立場の人たちは、チームが何か間違ったことをしたのだと反論することがよくあります。目標を達成できなかったり、成果物に問題があったのは、皆がプロセスに忠実に従っていなかったから、あるいは指示を正しく解釈していなかったからだと言うのです。
この場合、有効な対応は、プロセスを推進する人たちをプロジェクトチームに加えてチームと密接に作業させ、プロセスの手順をどのように実行できるか、どのように目標を達成できるかを教え導くことです。より一般的な「ソリューション」は、プロセスを推進する人たちにもう一度、概要で計画されたのと同じチェックポイントを確認しながら、最初から最後まで通して手順を見直してもらうことです。
前者のアプローチはまれです。後者のほうがはるかに一般的です。
もちろん、問題は、モデルが根拠としている理論がプロジェクト作業の現実には対応できないことにあります。モデルが仮説的な概念から導き出されたものである場合、興味深い可能性を示すことがあります。ただし、実際の作業環境でテストされ、証明されるまでは、モデルはせいぜい未検証の仮説にとどまります。
答えを出すべき根本的な問いは次のとおりです。正式なプロセスモデルは特定のニーズに対処する品質の高いソフトウェアをデリバリーする能力の助けとなるのか、それとも妨げとなるのか？
プロセスの「一言一句」に従いながら、このソフトウェアをタイムリーにデリバリーできるか、あるいは途中で何らかの微調整が必要なのか？
方向ではなくタッキング（上手回し）を変える
サイズを問わず、帆船は風上に向かって一直線に進むことはできません。東に向かっていて、風が東から吹いている場合、「だいたい東」に進む―タッキング（あるいはウェアリングまたはジャイビング）をする―必要があります。つまり、方向をほんの少しだけずらし、風を利用できるようにします。ある程度の距離を進んだら、方向を変えます。「だいたい東」に進むのは変わりませんが、異なる経路で東に向かいます。
目的地に向かってジグザグに進むのです。
その途中、状況に合わせて細かな調整を行えることがわかります。荷重を移動させたり、帆の張り具合を変えることで、「トリム」を改善できます。ソフトウェアプロジェクトでも、同様のことが可能な場合があります。
規定のプロセスがX、Y、Zを要求しているとします。状況によっては、それでうまくいくでしょう。そうでない場合、品質の高いソフトウェアをデリバリーするという目標を達成する助けにはならないかもしれません。ときには、目標への妨げになることもあるかもしれません。
プロセスモデルが要求するようにXまたはYまたはZを実行することが、特定のプロジェクトにおいて成果物の品質を改善しないと証明できる場合もあるかもしれません。Zと似たようなことをやっても、プロジェクトの品質を向上させることはできるでしょうか。
それなら目標が達成され、Zの「意図」も達成されます。どうやって目標にたどり着いたかは、指示とは多少異なるかもしれません。それでも一番の目標は達成されました。顧客のニーズを満たす品質の高いソフトウェアをデリバリーしたのですから。
それをうまく実証できたら、Yをほんの少し変更するよう求められるのも遠い先ではないかもしれません。
プロジェクトの作業を順調に進め、できるかぎり品質の高いソフトウェアをデリバリーすることは組織にとって死活問題です。作業の品質を高めるには、チームの士気を保つことが死活問題です。作業プロセス モデルがチームを妨げることで士気が下がるなら、プロジェクトの成功にとってリスクとなります。
文字ではなく、真意
課題は「プロセスに従う」という点に戻ってきます。チームが確かで誠実な努力をしたことを見せられるようにします。プロジェクトが従うよう定められた要件を満たすやり方では、成功に届かないことを確実に示せるようにします。
チームが「ゴール」に向かいながら、顧客と組織の当面のニーズを満たしていたことを証明できます。プロセスの過程で、どのようにプラクティスを改善し、ソフトウェアの品質を維持向上できるかを学んだことを示します。
これらの知見をリーダー層に示すことが、プロセスの背後にある本当の目的に光を当てることにつながるかもしれません。リーダー層がプロセスモデルの導入によって対処しようとしている要請が明らかになるかもしれません。
もし、プロセスモデルの意図について様々な解釈を受け入れることができ、モデルの実行にある程度のバリエーションを持たせることができれば、それぞれのチームは、たとえ文書化された手順どおりではなくても、新しいモデルの真意に取り組むことが可能です。
事実に基づいたオープンな話し合いの結果、リーダー層や経営層と、作業を行うチームの両方のニーズを満たすプロセスモデルが生まれるかもしれません。そうなるためには、両者の努力が必要です。
正式なプロセスモデルが、特定のニーズを満たす品質の高いソフトウェアをデリバリーする能力をどのように助けるのか、あるいは妨げるか、という問題に焦点を当て続けることです。
さまざまなプロセスを推進する人たちに、どんな問題が発生するかを理解してもらうには、義務付けられたプロセスモデルに従って実行する努力を見せる必要があります。皆が忍耐を持って、言葉や感情ではなく、懸念を表すメッセージに耳を傾ける必要があります。
役に立つモデルにする
結局のところ、多くの人が同意することがいくつかあります。成功はどこにでもあり、思いがけない場所にもあります。成功させるには、誰もがオープンになり、すすんで試し、多少の妥協をする必要があります。努力から得られたものを示せるなら、たいていの人は何かしらの改善が可能だと認めるでしょう。
一般的に、適切にコミュニケーションをマネジメントすることで信頼が築かれるため、「マネージング・アップ（部下が上司を管理すること）」の必要性があるでしょう。組織全体にわたる、有効でオープンなコミュニケーションがなければ、古いものであれ新しいものであれ、どんな「作業モデル」も結局は失敗します。
個人、チーム、組織にとっての成功はいずれ実現できるでしょう。それには、個人や「チーム群」が1つのチームとして働く必要があります。全員が個人の集りはなく、一丸となって働くことが必須です。互いに支え合い、高め合い、責任を負い合いながら、チームの成功のために最大限の貢献をしなければならないのです。
ソフトウェア開発組織にとっての成功とは、顧客を喜ばせる高品質な製品をデリバリーすることです。それ以上に大切なことなど、そうはありません。クールなギミックや「モチベーションを上げるテクニック」などは誰にとっての成功にもつながりません。
「皆が」協働し、「成功」を生み出せなければなりません。成功を測る最も有効なものさしは、顧客のニーズを満たす品質の高いソフトウェアをデリバリーしているかどうかです。
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。
（この記事は、開発元Gurock社の Blog 「Finding Success Within Imposed Working Models」2020年8月1８日の翻訳記事です。）