なぜ、アジャイル型プロジェクトのお客様・上司報告で問題が起こることが多いのか？
はじめに
こんにちは。 SHIFTアジャイルコーチの谷川です。
私も、当社でアジャイルコーチとしての業務を一年以上経験し、数多くのことを学ぶことができました。
日本でも、ようやく、開発の世界では、「アジャイル開発」がかなりメジャーになってきていると思いますが、プロジェクト管理の世界では、まだまだアジャイルはメジャーになり切れていないと感じています。
そこで、今回は、「なぜ、アジャイル型プロジェクトのお客様・上司へのプロジェクト報告で問題が発生することが多いのか？」 について、掘り下げてみたいと思います。
部門運営とプロジェクト管理と開発管理の関係
下記の図１に一般的な部、課といった階層構造を持つ組織における部門運営スタイルを示します。
部には部長がいて、その部門の部門運営をします。
課には課長がいて、その課の運営をします。
そして、課の中にはいくつかのプロジェクトがあり、それぞれのプロジェクトが管理される訳ですが、一般的には、そのプロジェクトの責任者としては、その課の課長さんがなって、課内のプロジェクト管理をするのが多いと思います。
そして、各プロジェクトの毎に開発があれば、その開発管理があり、プロジェクトの特性によって様々な開発スタイル（ウォーターフォール型、アジャイル型など）が選択されると思います。
そして、部には、会社の運営方針（ミッション、ビジョン、バリューなど）に沿った部門運営方針があり、その部門運営方針に沿って各課の運営方針があり、また、その課の運営方針に沿って各プロジェクトが運営され、更にプロジェクト管理の中の開発に関わる部分について、開発方針が検討されるのが一般的だと思います。
ウォーターフォール、アジャイルの選択は主に開発管理の部分
現在、ウォーターフォール型か、アジャイル型かと、議論されているのは、ほとんどが上記図の末端の開発管理の部分です。
主にソフトウェア開発の現場において、ウォーターフォール型開発かアジャイル型開発かの議論で盛り上がっています。
そして、図１にある開発管理の上にあるプロジェクト管理、課運営、部門運営の部分では、PMBOKに代表されるようなウォーターフォール型プロジェクト管理が主流となっています。
つまり、プロジェクト管理の世界では、ウォーターフォール型のプロジェクト管理が主流であり、アジャイル型のプロジェクト管理は、まだまだマイナーなのです。
そのため、アジャイル開発の現場では、プロジェクト、課、部などの上司への報告時に問題が発生することが多いのですが、この原因が、このプロジェクト管理と開発管理のスタイルの違いにあるのです。
なぜ、プロジェクト管理の主流はウォーターフォール型なのか？
ここで、なぜ、プロジェクト管理や部課運営にウォーターフォール型管理が多い状況になっているのかを考察してみたいと思います。
ここには、日本の企業文化、風習がかなり深く関係しています。
日本の企業文化と組織構造
部署ごとの運営管理方針・方法は、企業の組織構造と密接な関係があります。その会社が目指す、ミッション、ビジョン、バリューを実現するために、最適な組織構造を持っているはずであり、当然、その運営方針もそれに従ったものになります。
現時点では、官僚主義的な多段階組織構造を持つ企業が多いと思いますが、ほとんどの場合、「最適化」 を目指した組織構造になっており、管理手法もウォーターフォール型プロジェクト管理が主流となっています。
また、組織構造と、企業における人事評価制度、給与体系には密接な関係があります。従来型の企業では、職級毎に給与体系が作られていて、職級があがると、それに伴って給与も上がる仕組みの体系をもっている企業が多いと思います。 そのため、組織構造の変革というのは簡単なものではなく、年に何回も行われるようなものではありません。
つまり、部署ごとの運営管理方法を変えるタイミングも頻繁にある訳ではなく、よほど大きな問題が発生しない限り、企業文化や組織構造は大きく変更されることはないと思います。
高度成長期の成功体験の影響
日本企業は、2000年以前の高度成長期には、「標準化」、「効率化」、「最適化」 を追求するスタイルでかなり成功した過去があります。まさに、このときの管理スタイルがPMBOKに代表されるようなウォーターフォール型プロジェクト管理だったのです。
この成功があまりにも大きかったため、この成功体験を活かした運営をしている企業や人が数多く存在します。これが、今でも、日本企業における、部署ごとの運営管理方法の主流が、ウォーターフォール型プロジェクト管理になっている理由です。
これが、一概に悪いとは言えません。今でも、その企業や部門が成長しているのであれば何も問題ないと思います。
特に大きな課題感を感じていない部署では、引き続きその部門運営スタイルが継承され、また、後述するように現場はとても忙しいため、新しい運営スタイルを学ぶ機会があまりなく、アジャイルなどの新しい管理方式を知らない方が多い状況となっています。
部課長は経験豊富な方が多く、且つ忙しくて時間がない
一般的に、経験の多い方が管理職となることが多いので、部や課などを運営を任される管理職には日本の高度成長期を知っているような年配の方が多くなります。
そして、これらの方々は、ウォーターフォール型プロジェクト管理が全盛の時代に育った方が多いため、自然と部門運営もこのスタイルが主流になります。
また、今時の部課長さんは、とても忙しく、個人の勉強のための時間を確保することが難しく、よほどの高い意識を持っていない限り、新しい技術、知識を習得するための時間確保がかなり難しい状況にあります。
そのため、アジャイルが、開発管理だけでなく、プロジェクト管理や部門運営にも活用できることを知らない方が多いのです。
開発以外のプロジェクトなどにアジャイル・スクラムを適用する「業務スクラム」については、下記の記事を参考にしてください。
スクラム経験者を爆誕させる「業務スクラム」とは？(2023/6/30)
https://note.com/shift_tech/n/n298f3f3d7465
日本企業復活のためには、この部課長さんのような事業活動の中心になるべく中間管理職が元気を取り戻す必要があると思うのですが、忙しすぎて、疲弊してしまっているため、なかなかうまく行っていない現場を数多く見てきました。
VUCAの時代を生き抜くためには、この中間管理職の方々のマネジメント力をもっと強化していく必要があると思います。
この問題は社内だけでなくお客様との間にも発生する
上記は、社内における上司へのプロジェクト報告のときに問題が発生することを紹介しましたが、同様なことが社外のお客様との間にも発生します。
お客様キーマン、管理者も、ウォーターフォール型プロジェクト管理しか知らないケースがあるからです。
そのときに、下記のような問題が発生することがあります。
お客様が開発の進捗具合が理解できない
アジャイル開発が適切に、効率的に進んでいるのかお客様が理解できない お客様キーマン、管理者にあまりアジャイルの知識がない場合、アジャイルの現場で使われる用語を使用してプロジェクト報告をしても、うまく理解されないことがあります。
その場合、お客様にアジャイルを理解させる努力は必要だと思いますが、そう簡単ではないので、お客様に理解していただけるようにアジャイル用語をウォーターフォール用語に変換して伝えることが求められます。
開発の進捗状況を報告する場合には、アジャイル開発の進捗を、ウォーターフォール型開発のプロジェクト報告で使われるような手法、用語を使って報告しなければならないため、かなりの労力を使うことになります。
対策
アジャイル開発の進捗状況を、ウォーターフォール型プロジェクト管理で用いる各種メトリクスを使って表現する方法を、お客様と事前に合意し、報告するようにします。
開発着手前に、ウォーターフォール型プロジェクト管理の報告メトリクスのすり合わせを行い、合意しておく
お客様要件とバックログとの対応表を作成し、要件に漏れがないことを報告
開発進捗度＝完成したバックログ数／バックログの総数
バックログに関連するタスク、サブタスクを一覧にして、WBSのような表を作る
WBSに予定と実績の線を記入し、ガントチャートを作成
リリースバーンダウンチャートにて、リリースまでの作業進捗情報を可視化
品質管理（品質保証、品質担保）の話がかみ合わない
アジャイル開発とウォーターフォール型開発では、テストと品質管理に関する考え方がまったく違います。
アジャイル開発は要件が明確でないことが多く、仮説の検証を繰り返す開発スタイルであるため、「はやく結果を検証するために、対応することを省いて／絞って対応する」 のが特徴になります。
一方、ウォーターフォール型開発の場合、要件が明確になっているため、その要件を着実に実装するために、様々なOUTPUTを用意しながら計画通りに開発を進めていきます。
そして、出来上がったものに対するテストの仕方も異なり、ウォーターフォール型開発では、要件、仕様に沿って、単体テスト、結合テスト、総合テストと順に100%網羅を目標に進めていきますが、アジャイル型開発では、お客様への提供価値を基準に開発を進めるため、開発段階での過剰品質（単体テスト100%消化など）は求められず、まずは動くものを作ることが優先されます。
そのため、品質管理方針も、コーディング量やバグ摘出数などを計画通りに品質を管理していくウォーターフォール型開発の考え方をアジャイル型開発に持ち込むことには無理があり、現場を混乱させることになります。
つまり、アジャイル型開発の現場において、ウォーターフォール型プロジェクト管理の視点で必要になってくるOUTPUT、メトリクスを採取しなければならなくなった時点で、アジャイル型開発のメリットである対応スピードが失われることになります。
そのため、上記のような場合には、双方のメリット・デメリットを明確にして、早めにその辺のすり合わせをやるべきです。
当社では、SQF（SHIFT Quality Flamework）という品質管理標準を持っており、また、アジャイル開発においても、SQF4A（SHIFT Quality Flamework for Agile）というアジャイル開発にも対応した品質管理標準を持っていますので、これに沿った作業を進めることで、ウォーターフォール型プロジェクト管理しか知らないお客様にもアジャイル開発における品質管理状況をわかりやすく説明することが可能になっております。
対策
アジャイル開発の品質確保の状況を、ウォーターフォール型プロジェクト管理で用いる各種メトリクスなどを使って表現して、お客様に報告するようにします。
テスト設計時に、ウォーターフォール型プロジェクト管理でのテスト手法（単体テスト、結合テスト、総合テスト、受け入れテスト）ベースで何をどこまでテストするか、また、アジャイル型のテストをする場合、どのようなメトリクスを使って報告するのかをすり合わせし、合意しておく
採取するメトリクスを決定する際には、下記の視点を加えて検討する。
テスト網羅度
バグ収束度
バグの偏り、内容分析
採取したメトリクスから、品質分析を実施し、品質担保の状況をお客様に報告する
お客様・管理職向けのアジャイル教育がカギ
「アジャイル型プロジェクトのお客様・上司へのプロジェクト報告で問題が発生することが多い」 という問題の解決策は、ずばり、「お客様、管理職向けのアジャイル教育」 だと思っております。
プロジェクト管理、部門運営という場面でも、ウォーターフォール型管理ではなく、アジャイル型の管理をすることができることを正しく理解していただくことが重要です。
経験豊富な方々への教育というのはかなりハードルが高く感じる方もいると思いますので、当社では、ここを 「アジャイル啓発活動」 として、アジャイルコーチが担当させていただいております。
私も、働き方改革、働き甲斐改革、エンゲージメント向上のための活動を長年続けてきており、その中で経営陣などの方々に向けた地道なアジャイル啓発活動を経験してきておりますので、お客様と共にこの難しい課題に一緒にチャレンジしていけたらとても良い未来を一緒に見ることができるのではないかと思っています。
是非、この難しい課題解決に向けて、一緒にチャレンジしていきましょう。
おわりに
「アジャイル・スクラムが開発以外のプロジェクトにも活用できること」 を知らない方は、まだまだ本当にたくさんいる状況です。
これが、アジャイルがまだまだメジャーになり切れない一つの要因だと思っています。
私は、これを知ったことで、現場で起きている様々な課題を解決することができましたし、自分自身がWell-beingな状態になれているので、ものすごく仕事が楽しくなりました。もっともっと数多くの人にこれを知ってもらい、「感動」 を味わってもらいたいと思います。
当社には、アジャイル啓発についてのノウハウがたくさんありますので、是非、お気軽に声を掛けてください。
◆参考文献
なし
執筆者プロフィール：谷川 智彦（たにかわ ともひこ）
2023年5月にSHIFTに入社。
組織アジャイル教信者。真剣に「組織アジャイル」でいきいき、ワクワク、幸せに働くことができ、日本を元気にすることができると思っている。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
PHOTO：UnsplashのJohn Schnobrich