プログラマの思索

「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」をざっくり読んだ。
ラフな感想をメモ。

【参考】
大規模スクラムはLeSSとSAFeのどちらが良いのか: プログラマの思索

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

プロダクトマネジメントの感想～プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

文化は組織構造に従う: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

【1】Scrum@Scaleというアジャイル開発の大規模開発プロセスがどんな内容であるのか、に興味があった。
詳細は「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」に書かれているのであえて記載する必要はないと思う。

むしろ、既存のLeSSやSAFeと比較して何が異なるのか、が重要だろうと思う。

LeSSは1人のプロダクトオーナー、1つのプロダクトバックログから成るので、1個の製品を複数チームで開発するスタイルみたいなイメージを持っている。
たぶん、この形のスクラムが一番スケールしやすいと思う。
一方、プロダクトオーナーに負荷がかかりやすい弱点があるから、エリアプロダクトオーナーを設けたり、プロダクトオーナーを支援する人やチームを別途作るケースが多いように思う。

SAFeはアジャイル開発の官僚的組織、官僚的プロセスに近いイメージを持っている。
3つのレベルを持ち、開発チーム、リーダー層、経営層でそれぞれ役割分担したアジャイル開発を進めるイメージ。
大規模なシステム開発では、組織やプロセスを整備する必要があるから、SAFeのような仕組みは必要になるだろうと思う。
一方、RUPのようにテーラリングが必要なので、戦略的にカスタマイズを実施しないと難しいだろうと思う。

Scrum@Scaleは、スクラムチームのスケールだけでなく、プロダクトオーナーもスケールも実現する。
つまり、最低限の官僚的組織は持つが、開発チームだけでなくプロダクトオーナーも複数あり、協調動作するスクラムチームごとにプロダクトバックログを持つから、複数のプロダクトバックログを扱うように動く。
この点が他の大規模スクラムと違って、より柔軟な仕組みを持っているように思った。
EATやSoSのような組織を見ると、複数の開発チームやプロダクトオーナーが協調動作するように役割分担しているのに気づく。
レポートラインも最低限の官僚的組織としてうまく整備されている印象を持った。

【2】チャットサービスの開発現場で組織構造が変遷される内容がとても興味深い。
ChatWorkの開発現場だと思うが、最初はUI/UXのチームが重視され、途中で統合認証のような共通基盤の開発チームが入ってきて、最後は統合認証基盤チームは退出し、データマイグレーションなどのTeamsだけが残る。
つまり、チャットツールのビジネス発展に応じて、開発する機能が変わるので、それに応じた開発組織が必要になる。
そうした開発チームはチャットツールという製品の開発フェーズに応じて、新規に入ったり、退出したりして入れ替わる。
そういう組織の入れ替えを意識的に行っているのが味噌と思う。

また、こういう組織の入れ替えは、逆コンウェイ戦略の良い事例になっている。
なぜならば、製品の開発フェーズに応じて、重視される機能やアーキテクチャが変わるので、それに応じた組織を当てはめるべきであり、そういう組織を入れ替えるべきだ、という考え方になるからだ。

では、一般のユーザ企業の基幹系システム開発でも、こういうやり方は通用するだろうか？
たとえば、基幹系システム開発でも、機能追加やリプレース、法規制対応などにより、システムのフェーズは変わる。
基幹系システム開発でアジャイル開発を実践できているならば、Scrum@Scaleのような大規模開発も取り入れることはできるだろう。
つまり、基幹系システムのフェーズごとに開発チームを入れ替えて、逆コンウェイ戦略を実現することは不可能ではない。

しかし、一般の基幹系システム開発では、WF型開発が主流であり、アーキテクチャもインフラ層、データベース層、アプリ層などのように分割されて、それに応じた開発チームから成り立つ組織が多いと思う。
だから、Scrum@Scaleのように開発チームを頻繁に入れ替えるような逆コンウェイ戦略を実現するのは難しい状況が多いのではないか。

また、基幹系システム開発でスクラムを実践できていても、複数のプロダクトバックログを協調動作するように運用するのは、マネジメント上やはり難易度が高いと思う。

【3】「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」は日本の現場の事例もあって良い本と思う。
LeSSやSAFeとの違いについてはもう少し考えてみたいと思う。

LeSSは「大規模スクラム Large-Scale Scrum」の本がお勧め。
SAFeは「SAFe 4.5のエッセンス」の本がお勧め。

「More Effective Agile ソフトウェアリーダーになるための28の道標」では、SAFeが推奨されていたので参考にしている。

ストラテジストとプロジェクトマネージャの役割の違いは何なのか？
ITコーディネータ研修を経験して、IPAが定義するストラテジストとプロジェクトマネージャの役割の違いを自分なりに理解したことをメモ。
ラフなメモ書き。

【参考】
IPA 独立行政法人 情報処理推進機構：制度の概要：ITストラテジスト試験

IPA 独立行政法人 情報処理推進機構：制度の概要：プロジェクトマネージャ試験

【1】ストラテジストとプロジェクトマネージャでは、担当するプロセスのレイヤが異なる。

プロジェクトマネージャの担当領域は、個別プロジェクトのキックオフからリリースまでが一般的だ。
たとえば、SIerのプロジェクトマネージャであれば、請負契約でシステム開発を請け負っているはずだ。

一方、ストラテジストの担当領域は、複数のプロジェクトの内容が固まってRFPやプロジェクト計画書が完成するまでの企画フェーズと、プロジェクトが完了してリリースしたシステムが稼働した後の効果検証フェーズの2つだ。

たとえば、ユーザ企業の事業戦略に基づき、その事業を成功するためのシステムを構築したり、事業を支える業務を支援するシステムが必要になったとする。
事業の規模や業務の規模が大きければ、複数のシステムを構築する必要があるから、複数プロジェクトを並行で走らせる計画を作る。
そういう複数のプロジェクトではそれぞれ、どんなシステムが必要なのか、いつまでにシステムをリリースする必要があるか、を決める。
一般に企画フェーズで、事業戦略に基づくシステム化構想が練られることになる。

さらに、そのシステムをリリースした後、当初想定していた投資対効果が得られているか検証し、さらに改善していく必要がある。
それがリリース後の効果検証フェーズになる。

すなわち、ストラテジストの役割は、プロジェクトマネージャにプロジェクト計画書をお膳立てすることと、プロジェクトマネージャがリリースしたシステムが経営戦略の目標に合致しているか検証することになる。

ストラテジストはシステム化計画とシステムの効果測定だけであり、プロジェクトの実行フェーズはプロジェクトマネージャに委ねる。
よって、ストラテジストとプロジェクトマネージャの担当領域は明確に異なる。

【2】ストラテジストとプロジェクトマネージャでは、彼らの評価指標が明確に異なる。

プロジェクトマネージャは既に決められたQCDを元にリリースする責務がある。
たとえば、SIerのプロジェクトマネージャならば、ユーザ企業と握ったRFPを元に、初期投資予算、マスタスケジュール、体制図、システム要件が基本は確定した範囲内で、それを具体化してシステムとしてリリースする責務がある。
つまり、プロジェクトマネージャの評価指標は、当初決められたプロジェクトのQCDとの差異分析で決まる。

一方、ストラテジストは事業戦略に基づくシステムを構想したからには、そのシステムが事業に貢献したという投資対効果、つまりROIがストラテジストの評価指標になる。

たとえば、ユーザ企業が新規顧客を開拓するような新規事業を実行しようと決めて、ECサイトが必要になったと検討したとする。
ストラテジストは、そのECサイトは5カ年計画でどれだけの売上と営業利益を確保できるか、初期投資で数千万円や数億円をかけて投資してどれだけ売上を確保できるか、売上と営業利益のシミュレーションを計画する。
その売上を確保するには、ECサイトにはどんなシステム要件、業務用券が必要なのか、洗い出して確定する。
そして、そのECサイトの構築をプロジェクトマネージャに委ねてリリースしてもらった後、数ヶ月や数年をかけて、ECサイトの売上や利益を計測していく。
当初の計画と5カ年の実績の差異分析、つまり投資対効果がストラテジストの評価指標になる。

プロジェクトマネージャの評価指標がプロジェクトのQCDである事実より、プロジェクトマネージャへのプレッシャーはとても大きい。
しかし、ストラテジストの評価指標がシステムの投資対効果である事実を考えると、ストラテジストへのプレッシャーの方がはるかに大きいと思う。
なぜならば、プロジェクトマネージャの担当範囲は所詮、個別プロジェクトだけだが、ストラテジストの担当範囲は事業目標を達成するために平行に走らせるように計画された複数プロジェクトなのでとても広いからだ。

【3】ストラテジストとプロジェクトマネージャでは、利用するモデルや管理手法が明確に異なる。

プロジェクトマネージャは当初定められたプロジェクトのQCDを守るために、WBSとガントチャートによる進捗管理と課題管理が必須だろう。
もちろんそれ以外にも変更管理、品質管理など色々あるが、PJ管理手法のベースにはWBSとガントチャートがある。

一方、ストラテジストは、事業目標よりブレイクダウンされたシステムの投資対効果を達成するために、CSFとKGI、KPIのPDCA管理が必要になる。
事業目標を達成するために、BSCのように財務・顧客・業務・組織と人材の観点での中間目標（CSF）に分解したり、事業部内の各部署に業務分掌となる達成目標（CSF）が定められることになるだろう。

このCSFの考え方は、WBSみたいなものだ。

ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1～CSFはWBSみたいなものと捉える: プログラマの思索

そして、CSFという中間目標を達成できたか否かを定量的に判断するために、KGI/KPIが必要になる。

たとえば、売上や利益の確保という財務レイヤの最終目標に対し、売上高や営業利益率というKGIが出てくる。
そのKGIを達成するには、顧客や市場の観点で、新規顧客獲得数や購買単価、顧客満足度などのKPIが出てくる。
たとえば、BtoCビジネスのECサイトで出てくるAARRRも該当するだろう。

それらを実現するためにさらに業務レイヤで、顧客訪問回数、受注獲得率、顧客提案回数、業務効率化につながる工数削減の度合い、作業時間の短縮度合いなどのKPIも出てくるだろう。
さらに、それらの業務を実行する人材や組織の観点で、有能な人材を示す専門資格者数、研修回数、社内教育、従業員エンゲージメント率などのKPIも出てくるだろう。

つまり、ストラテジストが計画した諸々のシステムは計画時点でそれらKGI/KPIの目標値が設定されて、リリースされたシステムが稼働している間、KGI/KPIをシステムで自動的に測定して、投資対効果を評価することになる。

【4】自分がJavaアプリ開発者だった頃、プロジェクトマネージャの仕事ぶりは実際に見ることができたから、彼らの役割や責務は想像することができた。
しかし、ストラテジストを実際に見かける機会はなかったから、彼の役割や責務を想像することは難しかった。

ストラテジストはユーザ企業の経営戦略や事業戦略をベースにシステム化構想を検討するので、MBAで出てくるような経営戦略ツールを使って、外部環境・内部環境分析を行い、経営課題やCSFを洗い出す技法が必要になる。
つまり、ストラテジストに求められるスキルには、経営課題を解決するためのシステムの骨格を生み出すためにシステムアーキテクトのスキルは必要な前提の上で、外部環境・内部環境分析と経営課題・CSFを確定するための経営戦略ツールも必要になってくる。

たとえば、外部環境分析なら5Fs, PEST分析、内部環境分析ならVRIO分析やバリューチェーンなどのフレームワークを使う。
たとえば、経営課題の抽出であれば、SWOT分析で各要素を洗い出した後、経営戦略の方向性や企業の制約条件を元にクロスSWOT分析から、あるべき姿という経営課題を洗い出す。
その経営課題をCSFへ置き換えたり因果関係にまとめてBSCに当てはめて、各レイヤや各部署のCSFとKGI/KPIに落とし込む。
そこから、どんなシステムが必要になるか、複数個のシステムを洗い出して、具体的なシステム化計画を策定していく。
たぶんそういう流れ。

よって、ストラテジストの所在はユーザ企業の経営層や経営企画部、事業企画部、情報システム部門の領域にある。
つまり、SIerの中の一人の開発者から見れば、ストラテジストははるか遠くのところに位置しているので、彼らの目に止まりにくい。

【5】しかし、アプリ開発の専門技術者とプロジェクトマネージャ、ストラテジストは役割が異なるだけであって、そこに優劣があるわけではない。

実際にシステムを構築するために、システムアーキテクト、ネットワークスペシャリスト、データベーススペシャリスト、エンベデッドスペシャリスト、セキュリティスペシャリストなどの各専門技術者も必要だ。
色んな専門スキルを持つ人達が集まって、彼らが一つのチームとして形成して初めて、一つのシステムのリリース、さらには事業目標が達成される。

現代のシステム開発は色んな領域の専門家集団が必要であり、彼らがチームとして成り立ち、協働することが必要になっているわけだ。

経営戦略企画書やバランススコアカードに出てくるCSFとは一体何なのか？
CSFの使い道は何なのか？
ITコーディネータの先生に教わってようやく理解できた。
気づいたことをラフなメモ書き。

【１】CSFという言葉は知っていた。
CSFはCritical Success Factorの通り、目標達成の成功状態のことだ。
しかし、CSFはどんな時に必要なのか、CSFは何のために使うのか、腹落ちしていなかった。

経営戦略企画書において、バランススコアカードを作る時に、CSFはよく出てくる。
バランススコアカードでは、財務・顧客・内部プロセス・組織と成長のレイヤで、CSFや課題を因果関係や先行後続関係でつなげて戦略マップを作る。
たとえば、研修して人材を育成することで、営業や製造の体制が安定し、業務が効率化されたり、営業活動が活発になったりして、顧客満足度も上がり、原価も削減できて、最終的に売上拡大、利益増大を達成する。
そういうCSFの因果関係ができる。

【２】まず自分が勘違いしていた点は、CSFは成功状態であるから「～できる」という状態表現で書かれることだ。
なぜなら、目標が達成されて成功されたのだから、以前抱えていた問題は解決されて、達成「できた」という状態になるからだ。

一方、問題は「～できない」「～が難しい」という否定表現、課題は「～のために～する」という行動表現で書かれる。
どうやら自分は、経営課題とCSFを混同していたらしい。
本来は、問題に対し、経営課題が抽出されて、経営課題に対応するという対応策を実行すると、最終的に問題が解決されて、目標を達成できた、というCSFに結論付けられる。

他方、CSFは中間目標とも言われる。
最終的な経営目標に到達するためには、いくつかのマイルストーンをおいて、それらマイルストーンを全て通過して初めて最終ゴールに至る。
すなわち、CSFという中間目標は複数個存在するし、CSFの因果関係や前後関係が付けられることで、最終的なゴールへの道筋が明確になる。

すると、CSFの因果関係を元に、複数個のCSFをつなげて時系列に並べると、その図は経営戦略のロードマップになる。

【３】この考え方は、プロジェクト計画書におけるWBSとガントチャート関係と同じ。
WBSはプロジェクト実行に必要な作業全てであり、先行後続関係を付けて階層化された構造を持つ。
そのWBSは、時系列にマッピングさせればガントチャートになる。

同様に、CSFは経営目標を達成するための中間目標であるから、複数個のCSFには必ず因果関係が発生し、それは先行後続関係になる。
CSFの先行後続関係を時系列にマッピングさせれば、経営戦略のロードマップになる。
あるいは、経営戦略企画書のマスタスケジュールとして作られる。

【４】CSFは何のために使うのか？
CSFは経営戦略のロードマップを作成するために使われる。

経営戦略企画書に出てくるCSFは、プロジェクト計画書のWBSみたいなもの
プロジェクト計画書にあるWBSからガントチャートが作成されるように、経営戦略企画書のロードマップ、マスタスケジュールはCSFから作成される。

【５】そう考えると、バランススコアカードに出てくるKGI、KPIの考え方もスムーズにつながる。
なぜならば、経営戦略の最終目標に至る中間目標を達成できたのか、評価するために、KPIという業績評価指標を使って定量的に評価するわけだ。
CSFは「～できる」という状態表現でかかれるので、評価指標に落としやすい。

たとえば、「顧客満足度が上がっている」というCSFであれば、顧客満足度をアンケートで収集して採点して、以前と比較して上がっているかどうか評価すればいい。
「作業時間が短縮して業務を効率化できた」というCSFであれば、作業時間や作業工数を毎日記録して、該当の作業の時間が以前よりも減っているか測定すればいい。

そういう中間目標をブレイクダウンしていけば、組織や人材の観点のようにより低レベルな業務のKPIで測定するし、ドリルアップすることで顧客や市場、財務という観点のKPIが達成されて、最終的には経営目標であるKGIが達成される。

KPIやKGIという定量的な業績評価指標があるからこそ、毎月、四半期ごとに定点観測して業務プロセスを健康診断のように診断できる。
KPIが順調であれば問題ないが、KPIが落ちていれば、その原因を探り改善策を立てて、業務を見直していくことになる。
いわゆるPDCAが自然に行われることになる。

【６】CSFという概念を使いこなすことで、経営戦略のロードマップやマスタスケジュールが生成されて、KGIやKPIで定点観測して評価するという流れがベースにある。
この考え方は、プロジェクトマネージャよりもストラテジストと言われる立場で必要であると思う。

つまり、個別プロジェクトを切り盛りするプロジェクトマネージャではなく、より経営戦略に近い立場にいるストラテジストが常に考えているはずだから。

ストラテジストとプロジェクトマネージャの考え方の違い、役割の違いについては別で考察してみる。

@sugimoto_keiさんのツイートを読んで、PM理論ではP志向の方がM志向よりも生産性が高いことを主張していることに気づいたのでメモ。

【参考】
杉本啓さんはTwitterを使っています: 「多くのひとは職場での人間関係を気にし過ぎる。その人が自分を支配しようとして色々束縛するなら、それは人間関係の問題だが、そうでないなら、人間関係は気にしないで自分がやるべき仕事をすれば、ほとんどの場合、解決する。人間関係が気になるのは仕事がうまくいってないから。その逆ではない。」 / Twitter

杉本啓さんはTwitterを使っています: 「昔の経営学で、課業志向と人間関係志向という概念があったが、これは課業志向の考え方。基本的には、課業志向でできることをまずやるのが先決だと思う。人間関係というものは答えがないし、根本的に解決することもできない。」 / Twitter

杉本啓さんはTwitterを使っています: 「多くのひとはたぶん、集団の中で自分の居場所を作ることが重要だと考えているのだろう。それが人間関係志向ということ。それはわかるのだが、そうではなく、何を達成するのか、そのためにどうするか考える。これが課業志向。そうすると人間関係は大して気にならなくなるし、却って良くなるものだ。」 / Twitter

【PM理論とは】歴史や特徴を事例からわかりやすく解説｜リベラルアーツガイド

PM理論とは？理論とリーダー育成における活用場面をわかりやすく解説｜人材育成・社員研修｜ラーニングエージェンシー

PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

心理的安全性はPM理論のメンテナンスの発展形ではないか: プログラマの思索

組織論で紹介される学者はほとんどが欧米人だが唯一の日本人として、三隅二不二のPM理論がよく紹介されている。
昭和の時代にカイ二乗検定を使って統計的に有意な仮説としてPM理論を打ち立てたらしい。
PM理論の考え方は考えてみれば当たり前のように感じて、あまり気に留めていなかったが、@sugimoto_keiさんのツイートを読んで、PM理論が主張したかった本来の内容は違うのではと思った。

組織におけるリーダーの能力は、課業志向と関係志向の2つがあり、両方とも高いレベルを目指すべきとPM理論は言う。
しかし、実は課業志向の方が関係志向よりも生産性が高いことを言いたかったのではないか。
つまり、リーダーシップは結局成果を出して初めて認められるものであり、成果を重視せず関係ばかりに注力しても問題解決にならない、と。
特に、日本人のリーダーや集団は課業志向よりも関係志向を重視しすぎていて、生産性が高くないのではないか、と。

たとえば、リーダーシップとは成果主義が前提であるという考えは、「採用基準」にも記載されていたのを思い出した。
「採用基準」では、成果を求められないリーダーシップに囚われすぎる日本人を批判している。

たとえば、野中先生の「失敗の本質」でも、日本軍という官僚的組織が実は成果主義よりも関係志向を重視していて、リーダー間で忖度し合うことで戦争に負けた経緯が詳しく分析されている。

たとえば、PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研では、典型的な日本企業である日立でも、管理職のリーダークラスは優秀であっても課業志向ではなく、関係思考が強い傾向があるらしい。

こういう話を踏まえた上で考えると、日本人は集団でリーダーシップを発揮するという考え方や行動に何らかの問題があり、それがずっと弱点になっているのではと思う。

今の日本のアジャイル界隈では心理的安全性という概念がとても好まれているが、実は日本人のリーダーシップには関係志向が強すぎて課業志向が欠落しているのではないか、という考え方も心に留めておく。
たぶんコンテキストや環境によってはこの観点も必要だろうと思う。

「採用基準」「生産性」を読み返したらいろんな気付きがあった。
ロジカルでないラフなメモ書き。

【参考】
「採用基準」の感想～日本の根本問題はリーダーシップの総量が不足していること: プログラマの思索

DXとは組織論である: プログラマの思索

Slack導入がDXに繋がる話: プログラマの思索

諸問題を組織論に持っていくのは目的を手段化していないか: プログラマの思索

ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

失敗の本質―日本軍の組織論的研究の感想: プログラマの思索

プログラマとスクラムが社会実装を変えていく　#Findy_GovTech: プログラマの思索

デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索

みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

【1】最近の日本のIT業界を見ていると、主に2つの現象が目につく。
一つは、DXに向いた組織を作ろう、という組織論の話。
もう一つは、DXを実現するためにアジャイル開発をもっと積極的に導入して運用しよう、という話。

この2つの話の背景には、2つの問題意識が真因として隠れていると思う。
具体的には、組織論の話題、アジャイル開発の話題の背後には、日本人はリーダーシップが不足していること、日本人は生産性の意識も言動も非常に低いことだ。

【2】今のビジネス界隈では、DXがバズワードだ。
DXを実現するには、既存の業務であれ、新規の事業であれ、ソフトウェアでコスト削減、さらには売上の創出が求められている。
DXを実現するには、ソフトウェア開発者、そしてそれを取り囲む組織という基盤が必要だ。

しかし、DXに関する組織論のテーマはすごくフワフワとしていると思う。
命令指揮系統ではなくフラットに風通しを良くしよう、心理的安全性が担保されるような組織風土を作りましょう、という組織文化の話題が多い。
だがそういう甘い言葉の背後には、今までの組織文化や事業スタイルを捨てて、新しい事業や新しい組織の関係を作ろうとする原動力が必要なのに、たくさんの壁にぶち当たる怖さが説明されていないように思える。
だから、何となく、現状を批判するだけで何も変わらない、という現象が出ているように思える。

実際は、既存の組織風土を変えるのは、今までの人間関係や組織との関係を変えることであり、自らリーダーシップを発揮して動いていかなければ何も変わらない。
ものすごく自頭の良い人やできる人に従ってやれば問題解決するわけではない。
自らチェンジ・エージェントになり、たくさんの困難な壁にぶち当たるごとに、一つずつ壁を壊したり乗り越えていくパワーが必要になる。

「採用基準」では、問題解決には、問題解決スキルだけでなく、問題解決リーダーシップ（Problem Solving Leadership）が必要と主張している。
たとえば、目の前に起こったいじめの問題に対し、MECEやロジックツリーだと言っても何も変わらないし、実際に解決するように行動して初めて、問題解決の方向に動き出す。
それが本来のリーダーシップ。

すると、このリーダーシップの背後には、「自らリスクを取る」という概念が隠れていることが分かる。
自分の思いどおりに変わらない状況に対し、自分と異なる価値観を持つ人を説得して調整したり、自分が持っていない知識やスキルはそいうう専門スキルを持った人たちに働きかけてチームとして問題解決を図ることが必要になってくる。
そういう行動は、思い通りの結果にならないかもしれないリスクに自らチャレンジすることを求める。

しかし、日本人はリスクを取りたがらないと一般的に言われている。
すべてのリスクを回避してリスクをゼロにすることばかりに専念している。
だから、リスクを取ってリーダーシップを発揮するという行為、選択肢が取りにくい人が日本には多いのだろう。

実際、「採用基準」に記載されている通り、日本人はチームプレーでチームに貢献した成果を問われる経験が極端に少ない。
たとえば、小中高校生なら、受験という行動はその人だけの能力測定試験であり、個人プレーにすぎない。
社会人になっても、プロジェクトリーダーや管理職にならない限り、自分だけの仕事の成果しか問われない。
すると、一般職の日本人は一生、チームでの成果を求められる、というリーダーシップ経験を積まずに終わる人が多い。

そんなリーダーシップ経験のない人は、わがままな振る舞いが多い。
チームで成果を出すためにそれぞれの役割を認識せず、自分が一番成果を出しやすい行動に走ってしまいがちだから。
自分が成果を出しやすい個人プレーに走るのは、自分が苦手な場面に行動するリスクを取らないことにも通じる。

そんなことを考えると、リーダーシップ不足という弱点をごまかして隠すことで、組織論というふわふわしたテーマに流れてしまうのだろう。
そしてリーダーシップ不足という日本人論の問題点は、日本人はリスク許容度が低いことに真因があると思う。

【3】アジャイル開発は20年以上前から提唱されているのに日本ではなかなか導入すらされなかったが、ここ最近になって積極的に取り入れようとする流れが出てきた。

アジャイル開発の本質は一体何なのか？
僕は、アジャイル開発とは時間価値を最優先にしたソフトウェア開発だ、と一言で言えると考える。
WF型開発のように、時間も労力もかけて品質を作り込んで、高品質なソフトウェアをリリースするのではなく、小刻みにいち早くソフトウェアをリリースすることで売上もキャッシュも獲得していく戦略を取る。
1年間で1回のリリースではなく、5回リリースできるなら、5回分のフィードバックが得られて、その分、市場ニーズに合ったソフトウェアへいち早く開発できるようになる。
つまり、リリース頻度が5倍多いなら、ソフトウェアの価値も5倍高まるメリットが生まれる。

では、なぜアジャイル開発は日本で受け入れられなかったのか？
アジャイル開発の源流はトヨタ生産方式と言われていて、日本人にも馴染みがあるのに、なぜアジャイル開発は日本人にフィットしなかったのか？
たぶんその最大の理由は、ソフトウェア開発の生産性が低いことが問題だ、という意識が非常に薄いことだと思う。

官公庁みたいな縦割り組織の日本人は生真面目なタイプが多いので、決められたルールに従う方が重要であり、コストや期間を度外視したり生産性を重視する行動に行きやすい。
また、ソフトウェア開発者派遣のような人月ビジネスでは、たくさんの工数がかかるほど儲かるので、生産性を上げるモチベーションがビジネスモデル上生まれにくい。
今の日本の製造業では生産工程の改善により原価低減による付加価値向上を目指すが、3％の生産性向上よりも30％以上、2倍以上の生産性向上を目指すような、イノベーションを取るような行動が生まれていない。

なぜ米国企業は90年代に蘇ったのか～日本の手の内は完全に読み取られた～V字回復の経営の感想: プログラマの思索

生産性が低い現象が問題だ、と考えて、その問題解決を図ることにより、生産性をさらに大幅に向上させるという正のループを作り出せていない。
特に、3％の生産性向上のようなちょっとした改善ではなく、30％や2倍以上の生産性向上を図ろうとすれば、今までのやり方を捨てて、新たなアイデアを試す、といったリスクを取らなければ実現できないだろう。
しかし、今までリスクを取ったことがない人が、いきなりハイリスクハイリターンの選択肢を取るのは非常に難しいだろう。
なぜならば、仕事でもプライベートでも、そういうハイリスクハイリターンの練習を経験していなければ、実践で試すことは難しいだろうから。

日本人の生産性が著しく低い、という点にも、日本人はリスクを取りたがらない、という現象がその問題の背後に隠れている。

つまり、「ソフトウェア開発のように、時間価値が重要な意味を持つビジネスでは、生産性に比重をおいて時間戦略を取るべきだ」という考え方が日本人も日本企業も受け入れられていないからだ。
その真因には、日本人のリスク許容度が低いこと、土建業界やIT業界に限らず自動車業界においても日本のあちこちの業界で多重請負ビジネスがはびこっていることにあるのだろうと思う。

なぜ米国企業は90年代に蘇ったのか～日本の手の内は完全に読み取られた～V字回復の経営の感想: プログラマの思索

【4】リーダーシップ不足や生産性が著しく低いという現象には、リスクを取らないという日本人の気性が出ているのではないか。
あえてリスクを取ることで、大きなリターンを得る、というハイリスクハイリターンの選択肢を最初から捨てている場合が多いのではないか。

リーダーシップがあり、生産性が高い人は、いろんな問題解決に対してリスク許容度が広いので、かなり大きなリスクを自ら選択することができる。
つまり、リスク対応力とその人の問題解決能力は比例しているのだろうと思う。

【5】組織論やアジャイル開発をテーマにしている人たちは、日本人の弱点である「リーダーシップ不足」「生産性が著しく低い」「リスク許容度が著しく低い」という真因におそらく気づいている。
その真因をいろんな角度から、いろんな言葉で、いろんな手段で解決を試みようとしているのだろうと思う。
そういう観点を持って、今のDXにかかわるテーマを取捨選択して聞いてみたいと思う。

とある勉強会で、プロセス設計はどの範囲を指すのか、を議論した。
自分の考えをメモ。
ラフなメモ書き。

【参考】
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索

ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

ソフトウェアPJの企画フェーズの責任者は誰なのか？: プログラマの思索

みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

プログラマとスクラムが社会実装を変えていく　#Findy_GovTech: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

DXとは組織論である: プログラマの思索

ソフトウェア・ファーストの感想: プログラマの思索

プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール: プログラマの思索

【1】プロセス設計とは何か？

「SEはプロセス設計する能力が必要」と清水吉男さんは言われていたと思う。
PJ計画時に、担当SEは担当PJでどんなプロセスが必要でどんな成果物が必要なのか、を明確にすべき。
なぜならば、システムの特徴、PJ特性に応じて、プロセスや成果物はどのPJでも微妙に異なるからだ。
それを不明確なまま進めると、じきにプロジェクトの運営がうまくいかなくなる。

イメージとしては、XDDPならばPFDというDFDを描いて、プロセスと成果物のデータフロー図を描くものと思う。

【2】プロセス設計の考え方は標準から各PJへのテーラリングが基本

では、プロセス設計とはどんな構造を持つのか？
きちんとしたSIであれば、社内に標準プロセスがあり、それを担当PJごとにテーラリングしたサブプロセスを定めることになる。
つまり、「プロセス」クラスと「サブプロセス」クラスという型が継承関係にある。

プロジェクト計画が確定すると、「サブプロセス」のインスタンセスが生成される。
PJ実行フェーズで、プロセスのインスタンスをもとに、具体的な成果物（たぶん、設計書などのExcel帳票）が作られていく。

つまり、プロマネは担当PJの特徴、システム特性に応じて、標準プロセスをテーラリングないしカスタマイズする自由度は許されている。
ここにプロセス設計の能力が必要とされる。

【3】プロセス設計の範囲は、PMO事務局とプロマネで異なる

では、プロセス設計の範囲はどこなのか？
(1)プロセス設計とは、プロセスインスタンスから標準プロセスへ抽象化する手法？
(2)プロセス設計とは、標準プロセスをプロセスインスタンスに具体的に実現する手法？
(3)プロセス設計とは、標準プロセスからサブプロセスへテーラリングする手法？

僕の考えでは、プロセス設計の範囲は、PMO事務局とプロマネで異なる。

全社横断的PMO事務局は、社内の案件に対し、標準プロセスを定めたガイドラインを定義し、その推進活動を担当する。
PMOの作業範囲は、「プロセスというクラス」の部分で標準プロセスの型をガイドラインで定義し、各案件のPMには、標準プロセスは守ってもらうことになる。
一方、プロマネには、PJ特性に応じて成果物やプロセスを取捨選択したりカスタマイズしてテーラリングする。

つまり、PMOが担当するプロセス設計の作業範囲は「プロセスというクラス」になる。
なぜならば、標準プロセスを定めたガイドラインの保守改訂はPMOの範疇だから。

一方、案件のプロマネの作業範囲は「サブプロセスというクラス」でPJのテーラリングを行ったプロセスを取捨選択ないしカスタマイズして決めて、PJ計画の活動で具体的なプロセスと成果物（たぶんExcel帳票）を確定すること（プロセスインスタンス）になる。
なぜならば、プロセスをテーラリングして詳細化する作業は、プロマネの担当だから。

【4】テーラリングはどのように評価されるのか

実際の現場では、PMOとプロマネの間で対立はある。

PMOは、ガイドラインがベースラインなので基本はPMに守ってもらうことが最優先であり、実際の案件とのギャップがあれば、それは吸い上げて真因を深掘りする作業を担当する。
テーラリングの自由度は許される範囲内でプロマネにあるから、プロマネの説明の根拠を一つずつ確認して、問いただしていく作業が必要がある。
実際は、そのテーラリングの妥当性で揉めることが多い。

たとえば、プロマネが案件の予算を申請する時、役員を含めた経営陣やPMO事務局が投資計画の内容を精査して、案件の予算確保と実行承認を決定するだろう。
その時に、会社標準のプロセスに即して投資計画を立案しますが、基本はテーラリングが必ず入る。

テーラリングの例としてはこんなものがある。

・標準では許されない工程の重複や統合、省略を許す
・標準化されていない開発方法、技術を適用する
・メトリクスの許容値を調整したり、代替メトリクスを計画する

たとえば、SAPのようなパッケージ製品の導入であれば、すでに開発プロセスがベンダ製品に埋め込まれている。
社内標準とは異なるベンダ製品のプロセスを社内の体制で実行できるか、などをPMが経営陣に説明する必要がある。

あるいは、機械学習の開発基盤を導入する案件であれば、標準化されていない開発手法を適用することになる。
開発リスクを見込んだスケジュールを作っているか、コストを見込んでいるか、をPMが経営陣に説明する必要がある。

あるいは、品質基準を変更してPJ用にテーラリングしたならば、品質基準を変更した妥当性の根拠をPMが経営陣に説明する必要がある。

プロマネが作った投資計画書やPJ計画書をレビューして、細かく精査すると、コストの妥当性、開発リスクの検討、品質基準の設定が甘い時も多い。
そういうレビューを通じて、投資計画の精度を高めるし、プロジェクト実行時の各ゲートレビューでPJの実行状況をPMOがモニタリングしてチェックすることになる。

【5】とは言え、プロセス設計とその評価プロセスの質は、SIであってもユーザ企業であっても、バラつきが多い。

システムの有効性を知りたい経営者、利用ユーザなどの第三者であれば、こういう仕組みがしっかりしていると、安心してシステム開発を任せられる。
たぶん、日本政府のデジタル庁が目指しているあるべき姿も、この辺りの内容に近いのでは、と推測する。
なぜならば、内製部隊を持てない場合、ベンダに委託する必要があるが、こういうプロセスの仕組みをしっかりすることで、ベンダから提供される成果物が標準化できるし、社内でもユーザ要求や仕様をまとめる能力が高まるし、最終的にベンダロックインを防いだり、プロジェクトの進行状況を適宜チェックする仕掛けができるからだ。

ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知＝知識、暗黙知＝身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか？
経験は知識よりも勝るのか？

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ！」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

プロジェクト管理の基本はテーラリングだと思う。
そして、Redmineはプロセスをテーラリングするツールだと思う。
ラフなメモ。

【1】プロジェクト管理の基本的な考え方は何だろうか？

QCDのコントロール、課題管理、スケジュール管理とか、色々あるだろうが、僕は、標準プロセスを各案件、それぞれの現場にテーラリングする能力が問われている、カスタマイズする能力が問われていると思う。
なぜならば、現場にあるプロジェクトはどれもバラバラであり、過去の経験と全く同じプロジェクトはありえない。
そこで、標準プロセスを元に、過去の経験やベストプラクティスのいずれかを、それぞれの現場の案件に適用して、プロジェクトの成功を目指すことになる。

つまり、案件の特徴を見抜いて、標準プロセスから、案件に合ったベストプラクティスを適用して効果を引き出すわけだ。
プロジェクトマネージャは、案件を自分のコントロールの配下におくために、自分の手持ちの武器のうち、有効な武器だけを抽出して、プロジェクトごとにカスタマイズして適用しているわけだ。

すると、2つの疑問が湧いてくる。

【2】1つは、標準プロセスがなければ、そもそもテーラリングができないので、テーラリングという考え方が合っているのか、という点。

PMBOKのようなプロジェクト管理の基本知識では、予実管理が基本だ。
つまり、標準が前提としてあって、実際の実績が標準からどれくらい離れるのか、を測定して制御するイメージ。

しかし、標準プロセスが事前に定まっている環境は、大企業や歴史の長いSIなど、それなりに自分たちの開発の歴史を持って、そこから標準プロセスを作り出した人たちだろう。
そうでない場合は、標準プロセスがあいまいか、そもそも存在しないかもしれない。

そういう状況は、カオスと言えるだろう。
案件を受注するたびに、いつも初めてのプロセスを自分たちで作って運用していかないといけない。
それはあまりにも大変すぎるし、失敗しやすい。

アジャイル開発がそんな場面で利用されやすいだろうが、スクラムのようなきちんと決まっている最低限のフレームワークを用いることで、そういうカオスを制御しようとしている。
スクラムから離れて自分たちのアジャイル開発を見出すのは、スクラムの守破離のうち、守りをきちんとマスターした後でいい。

だから、何らかの標準プロセスが前提にあるのが基本ではないかと思う。

【3】もう一つは、プロマネが標準プロセスからテーラリングできる自由度の範囲はどれくらいあるのか、という点。

PMOの立場では、標準プロセスを策定して、各案件のプロマネに提示して使ってもらう。
しかし、案件ごとに特徴がバラバラだから、標準プロセスをそのまま100％当てはめるて運用は難しい。
だから、プロマネには、基本は守ってもらうけど、ある程度カスタマイズして、プロジェクトをスムーズに運用してください、とある程度のカスタマイズお自由は手渡す。

では、どれくらいの自由度がプロマネにはあるのだろうか？
この自由度は、その会社のプロマネの能力レベルに依存する、という身も蓋もない話。

プロマネの能力が高ければ、標準プロセスを元に、担当案件ではこの部分をカスタマイズして、プロジェクトを運用しやすくします、と宣言して進める。
プロジェクトをコントロールするには、この部分のカスタマイズが必要だと彼らは分かっている。
彼らは、カスタマイズする根拠を説明して、ステークホルダーに納得させるだけの能力を持っている。

一方、プロマネの能力が低い場合、彼らは、プロジェクトの実績の妥当性を標準プロセスに求めたがる。
こういう運用をしているのは標準プロセスに即しているからです、開発を委託したベンダの成果物の品質が悪いのは標準プロセスに従ったからです、などと平気に言う。
つまり、プロマネは、案件の遂行の妥当性を第三者に説明する根拠として、標準プロセスを使おうとする。

すると、PMOは、標準プロセスが現場にフィットしていないからそういう意見が出てくるのだ、と判断して、標準プロセスをどんどん詳細化し、ガチガチに決めていく。
そうすることで、テーラリングの自由度が下がり、プロマネが自由に運用できる裁量が狭くなる悪循環に陥る。
自分で自分の首を絞めている感じ。

そういう現象も多いので、標準プロセスの策定では、プロマネにどんなインセンティブを与えれば、彼らが良い方向にカスタマイズしてくれるか、を考える時が多い。

その気持ちは、まるで法律家みたいだ。
政府が定める法規制によって、市場や社会を良い方向へ誘導しようと計画するが、実際は、生身の人間は小賢しいので、その意図をすぐに行動に反映して自分の利害に合うように変な方向にカスタマイズする、みたいな感じ。
マクロ経済学で言えば、ルーカス批判。
量子力学で言えば、不確定性原理みたいなものか。

【4】他方、Redmineを使うと、標準プロセスとテーラリングのバランスをある程度保証して、プロマネに運用してもらうことができると考える。

Redmineはとても自由度が高いプロジェクト管理ツールだ。
とはいえ、Redmineも汎用ツールなので、Redmineに埋め込まれた機能によって、プロセスの自由度はある程度限られる。
つまり、Redmineで提供する「プロジェクト」ごとに、スクラッチのシステム開発やパッケージ製品導入、サポートデスクなどのドメインで、ワークフローやチケット管理などをテンプレート化しておく。
そのドメインのテンプレートをプロマネに手渡し、そこから先はプロマネに自由に運用してもらう。

つまり、ドメインごとのテンプレートで標準プロセスは固めておき、それから先の運用はプロマネの自由裁量にある程度任せる。
もちろん、チケット起票やチケットの完了条件については、Redmineの機能で制限することは難しいから、運用ルールで縛ることになる。
ただし、各案件ごとに、開発者のスキルが違っていたり、開発やリリースの手順が違う時もあるだろうから、チケット管理にテーラリングを当てはめて、ある程度の自由裁量で運用ルールを変更する余地は残す。

そうすれば、Redmineで標準プロセスを元に、プロマネがテーラリングして、案件ごとに合った運用ルールを策定できて、プロジェクトを成功させる確率を高めることができるはず。

ただし、この運用の前提条件は、プロマネがRedmineの機能やカスタマイズできる範囲を理解し尽くしておくことだ。
つまり、Redmineをプロセスのテーラリングに使うツールとして用いることができる能力を前提としている。

そうでなければ、プロジェクトのテーラリングをRedmine上で実現できないからだ。
個人的には、Excel手順書で運用ルールを逐一テーラリングするよりも、ある程度ツールで標準プロセスを遵守して、ツールの基板上でテーラリングする方が、コントロールしやすいのではないかと考えている。

初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。
理解できた内容をラフなメモ。

【参考】
初中級プロマネのための　現場で活かせ！統計情報１

初中級プロマネのための　現場で活かせ！統計情報２

「ソフトウェア開発分析データ集2020」の発行：IPA 独立行政法人 情報処理推進機構

「ソフトウェア開発データ白書」のダウンロード：IPA 独立行政法人 情報処理推進機構

初中級プロマネのための現場で活かせ！統計情報 　2019年4月19日| CITP Community

CITPアニュアルレポート2018を公開しました | CITP Community

【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。

【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。

1つ目は、プロマネとしてシステムの企画書や提案書を書いている時に、見積もりの妥当性を説明するために、日本の他社事例の数値を元に遜色ないことを理由として、見積もり工数や金額は妥当です、とロジカルに説明したいこと。
もう一つは、プロマネとしてリリース判定会議で、システムの開発やテストの結果が、日本の他社の成功した事例と遜色ないことを理由として、品質は妥当です、とロジカルに説明したいこと。

プロマネは、経営層が考えた戦略を受けてその内容をシステムとして実現する時に、自分が考えた企画内容の妥当性を説明したい。
その時に、経営層から聞かれるのは、投資効果が見込める妥当性はあるのか、初期投資の金額の妥当性はあるのか、という点だ。
この根拠を作るために、実際に業務システムの無駄な問題点を工数や金額で事前調査したり、削減できるコストがこれだけあるとか、売上や利益がこれだけ伸びるとか、色々話を膨らませる。

特に難しいのは、初期投資としての見積金額が本当にこれで妥当なのか、という点だ。
まだ実際に作ってもないし、あいまいな調査を元に機能一覧を洗い出して、その積み上げで工数を算出し、人月単価を元に見積金額を弾くわけだが、それを各工程に分けて積み上げて、本当に正しいのか、と言われると、正直難しい。
実際は、色んな前提条件をたくさん置いて、こうなります、という説明しかできない。

そんな時に、日本のSIで成功した事例では、こういうデータがあるので、工数や金額に妥当性があると言えれば、自分たちの会社も日本のSIで普通のレベルだと仮定できれば、こんな数値になるのは妥当でしょう、と言える。
そういうロジックに持ち込みたい。

つまり、プロマネの勘や度胸のような直感に頼らず、利害関係者にロジカルに説明するための根拠づくりに、IPAデータ白書を使いたいのだ。

【2】IPAデータ白書には、日本のトップレベルのSIが収集したソフトウェア開発における数多くの統計データが掲載されている。
その統計データが膨大であるために、どのように使えばよいか分かりにくい。
僕も正直悩んでいた。

しかし、初中級プロマネのための　現場で活かせ！統計情報１を読むと、初級者・中級者のプロマネはIPAデータ白書をこういう風に使うと役立つよ、という指針を書いてくれているのでとても役立つ。

IPAデータ白書の主な使い道は、見積り、生産性、品質の3つの観点で使うと良いだろう。

【3】企画提案の段階では、要件定義工程比率や工程別の工数比率、工程別の工期の比率が役立つ。

たとえば、要件定義工程は準委任、設計・開発・テストは請負契約でやる場合、トータルの工数や工期を提案段階である程度見積る。
その時に、要件定義フェーズはこれくらいの工数や工期が必要である根拠として、IPAデータ白書の数値を用いて算出するとよい。
なぜならば、経験上、要件定義フェーズをケチって実施してしまい、実際の開発フェーズに入ると要件がどんどん覆されて遅滞してしまい、最終的にプロジェクトが赤字になるか、失敗プロジェクトで終わってしまうという失敗事例がすごく多いからだ。
やはり、要件定義工程にある程度の工数や工期を割り当てて、メンバーも労力も割いた方が次の開発フェーズはスムーズに進みやすい。

あるいは、設計・開発・テストの各工程の工数別割合をIPAデータ白書の数値を用いて算出し、プロジェクトが成功するならこれくらいの比率の工数が必要だ、という根拠に使う。
なぜならば、開発工程の見積は実際にプログラマが見積もればある程度明確になりやすいので、その工数を元に設計やテスト工程の工数を算出できるからだ。
失敗プロジェクトでは、設計工程は十分に工数を取るが、テスト工程の工数をケチって、実際のプロジェクトで破綻する時も多いからだ。

【4】また、設計や開発工程の見積もりには、生産性の指標が役立つ。

たとえば、SLOC規模あたり設計書ページ数を使えば、プログラム規模を元に設計書ページ数を見積もれるので、設計書の規模感や設計書作成の工数の根拠を算出できる。
あるいは、SLOC 規模別 SLOC 生産性 や SLOC 規模と工数の関係を使えば、プログラム規模を元に各工程の工数をある程度見積もることができる。

つまり、設計、開発、テスト工程の工数の見積の精度を向上させることもできる。

【5】設計・開発工程がほぼ終わり、テスト工程に入る時には、レビュー指摘件数、SLOC 規模 テストケース数、SLOC 規模 検出バグ数を使えば、品質の妥当性をチェックすることに使える。

たとえば、設計工程のレビューの指摘件数を収集できれば、SLOC 規模/工数あたり/ページあたりの数値がIPAデータ白書にあるので、その基準値を元にレビュー指摘件数が妥当であるか、管理図を使って検査できる。
外れ値が出るならば、レビュープロセスに原因があるのか、設計書という成果物が悪いのか、さらに原因分析していく。

あるいは、開発が終わればプログラム行数は簡単に測定できるので、開発規模に応じたテスト工程ごとのテストケース数や検出バグ数を予測することができる。
IPAデータ白書の数値を元に、開発規模から妥当なテストケース数はこれくらいと分かれば、そのケース数から外れ値が出ていないかチェックすればいい。

そして、実際にテストしてみて、バグ数がIPAデータ白書の基準値よりも多く出るならば、品質が悪い可能性があるのでさらに原因分析していく。

つまり、設計・テスト工程の品質の妥当性にIPAデータ白書の数値は使えるはず。

ソフトウェア開発データ白書と定量データの活用方法を参考にすれば、ゾーン分析やトレンド分析、信頼度成長曲線など数多くの品質管理技法を適用することもできるだろう。

「ソフトウェア開発データ白書2018-2019」のご紹介～プロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果～も参考になる。

【6】IPAデータ白書の統計情報はたしかに、見積り、生産性、品質の観点で使えるし、それなりに役立つ。
しかし、いくつかの留意点はある。

1つ目は、WF型開発を前提としたメトリクスであること。
実際に収集した事例の数値では、ほとんどがWF型開発であり、アジャイル開発を前提としたメトリクスではない。

2つ目は、開発言語やシステムの種類、開発フレームワークをすべて混ぜ込んで、グロスで集計した数値であること。
以前は、JavaやCobolなど数多くの言語で分類されていたが、最近は言語の区別もなく、せいぜい、新規開発・改良開発・再構築の開発種別の違いだけしかない。
つまり、色んなシステムのデータを一つの数値でまとめているので、本当に精緻なデータなのか、という疑問はある。

3つ目は、IPAデータ白書に提出した日本の各SIの統計データは、工程の定義や開発規模、テストケース数、バグ数などの定義が各社でバラバラである可能性が大きいことだ。
この点はIPAのFAQサイトにも記載されていて、その点を考慮して色々精査されているみたい。

「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答：IPA 独立行政法人 情報処理推進機構

4つ目は、この数値を鵜呑みにして使わないように、IPA自身も注意喚起を記載している点だ。
あくまでも参考データであり、自分のソフトウェア企業がこの数値に当てはまるとは限らない。

とは言え、IPAデータ白書は10年以上の歴史があり、その統計データの推移を見ると、そんなに大きく変わっているわけではないようだ。
日本でDXが叫ばれていても、日本のSIではやはりWF型開発が主流であり、それなりの品質データや見積データを収集して蓄積しているみたいだ。

個人的には、日本で少しずつ浸透しつつあるアジャイル開発の統計データが収集されて、実際の統計データとして採用されると参考にしたいと思う。

RedmineJapanの懇親会で友人たちと議論しているとき、「タスク分割は親子チケットにすべきか、それともチェックリストにすべきか」というテーマで盛り上がった。
考えたことをメモ。
結論のないラフなメモ。

【参考】
ActivityとTaskはどう違うか ? ガントチャートと課題管理表から考える : タイム・コンサルタントの日誌から

akipiiさんはTwitterを使っています 「懇親会は人数が少ないのに、Redmineの濃い話で盛り上がる。Redmineでは、親子チケットを切る基準と1チケット内でチェックリストを作る基準の違いは何か？進捗率はどう決めるべきか？面白すぎw #RedmineJapan」 / Twitter

【1】Redmineでチケット駆動開発を実践すると、チケットの粒度に悩む。

タスクの粒度が大きすぎるチケットは、完了までの期間が長くなるので、進捗を管理しにくい。
肥満児チケットも言う。
こういう肥満児チケットは、完了条件が曖昧なので、作業していくと次から次へと問題が噴出して、進捗率が90％のまま停滞しがち。
たとえば、1本のプログラム開発のチケットでも、エラー処理のメッセージが決まっていなかったと後で判明して保留になったり、実際に作り込んでみるとSQLチューニングしないと使えない代物だった、とか。

一方、タスクの粒度が小さすぎるチケットは、作業しやすいが、大量のチケット保守に苦労する。
経験的には、1チームで管理できるチケット枚数には上限があると思う。
それ以上のチケット枚数になると、チケットが放置されて、今日は何をやればいいのか、今後どの順番でチケットをやっていけばいいのか、混乱しがちになる。

管理者も担当者も、細かくチケットを切って、チケットを1個ずつこなしていくようにしたい。
では、どのように細かいタスクをチケット管理すべきなのか？

【2】タスクの粒度の解決方法としては、親子チケットにすべきか、それともチェックリストにすべきか、という問題に落ち着くのではないか。

1個のタスクを親子チケットで階層化し、細かく切った子チケットを親チケットでグルーピングして、親チケットでステータスや進捗率を把握する。
一方、1枚のチケットの中にチェックリストを設けて、チェックリストの1項目ずつ消し込んでいくことで、どこまでやり切ったのか、後は何が残っているのか、を把握する。

どちらが良いのだろうか？

【3】チェックリストを使いたい場面は、担当者が1人で決まっていて、自分のタスクを作業の順序や作業の詳細ごとにチェックリストに落とし込んで、作業をこなしてはチェックリストを消し込んでいきたい時だろう。
つまり、自分だけのToDo管理に近い作業になる。

たとえば、こういうToDo管理は、研究者が道の問題解決の時に使う手法でもあるし、すでに手順化された作業をチェックリストにして使う時もあるだろう。
たぶん、担当者1人だけの作業に閉じている時、1枚のチケットにチェックリストを書く方がいい。
お手軽だし、チェックリストを考えること自体が、作業分割に繋がり、作業のクリティカルパスを考えることにも役立つ。

しかし、チェックリストのデメリットもある。
チェックリストの進捗を把握するには、1枚のチケットを開きっぱなしにしておく必要がある。
タスクボードやチケット一覧では、チェックリストの中身は見えないし、残項目数がどれだけあるか分からない。
つまり、チェックリストはチケット集計機能に向かない。

【4】親子チケットを使いたい場面は、1つの作業を複数人で分担して並行作業したり、課題の解決方針から複数のアクションタスクが派生してそれらを管理したい時に使いたいだろう。

一般に、WF型開発であれば、1つの工程の中で複数人が作業分担して、作業を逐次実行したり、並行作業で行う。
たとえば、コーディングして、コードレビューを受けて、ビルドを通すという一連の作業では、プログラマとレビューア、ビルド職人で担当者が切り替わる。
あるいは、1つの機能を複数人が分担してプログラム開発を並行作業し、最後に統合してビルドする時もあろうだろう。

そんな時は、各人のタスクを子チケットにして、親チケットでグルーピングして、親チケットでロールアップする方が進捗管理しやすい。
親チケットで進捗やステータスが分かるからだ。
また、チケット一覧やタスクボードで、子チケットを集計すれば、ガントチャートやEVMなど色んな集計機能でPJ全体の情報を把握できる。

しかし、親子チケットのデメリットはある。
何でもかんでも親子チケットにすると、チケット枚数が増えて、一瞥して管理しにくい。
大量のチケットであふれると、チケットは乱発され放置されて、誰も保守しなくなる。
だから、普通は毎日棚卸しタイムを設けるなどしなければ、PJの現状がチケットに反映されないだろう。
それだけの手間を惜しまない気力が必要と思う。

【5】親子チケットが特に重要と思う場面は、課題管理だろうと思う。

プロジェクト運営では、ゴールに向けた作業が全て洗い出されて、タスクがチケットに落とし込まれれば、その時点でほぼコントロールできる可能性が高まる。
作業に落とし込めるということは、ある程度標準化された作業、想定される作業に落とし込めることなので、ほとんど未知のリスクはない。
定常作業がそういう部類だろう。

しかし、一般には初めてのプロジェクトでは、どんな作業があるか分からない時もある。
むしろ、作業を進めていくうちに、今まで経験しなかった課題が噴出して、それらをもぐら叩きのように丁寧に潰し込んでいかざるを得ない。

すると、それら課題を発生の都度チケットにして、課題チケットを一つずつステータス管理していく必要がある。
僕は、プロジェクトマネジメントのほとんどは課題管理、もっと言えば、リスク管理に尽きると思っている。
なぜならば、未知のリスクに遭遇した時、それらの問題を課題に置き換えて、それら課題を潰し込んでいきながらゴールへ近づいていくというイメージが強いからだ。

【6】では、課題管理では何が重要なのか？
一つは、課題のステータス管理。
もう一つは、課題の解決方針から導出されるタスク群のステータス管理だ。
つまり、課題は親チケットにして、それに子チケットのタスクがぶら下がるイメージだ。

課題を調査して、試行錯誤して解決方針を決定し、タスクに落とし込んで、それらタスクが完遂されて初めて、課題は完了する。
すると、課題は今はどのステータスで滞留しているのか、を知りたくなってくる。
大抵の場合、課題の解決方針を決定するまで持ち込むのが割と大変ではないか。

そもそも、課題の解決方針がすぐに分かるようならば、それは課題ではなく、タスクであるべきだ。
なぜならば、タスクとはやるべき作業の具体的内容と完了条件が分かっているものであるが、課題はその解決方針すらも分かっていないのでどんな作業内容すらも分からないからだ。

課題を解決するには、技術情報を調査したり、集めた情報を分析したり、経験者からアドバイスをもらう、などいろんな手段があるだろう。

課題を解決する時に重要なのは、何を持って課題を解決できたとするのか、課題の完了条件を決めることだろう。
課題の方針が決まれば完了とするなら、課題チケットだけで、子チケットにタスクチケットは必要ではない。

一方、課題の方針を決めてそれらをタスクに落とし込んで、それらタスクを実践して結果をさらに分析してみて評価する、という方法もあるだろう。
つまり、課題は親チケットにして、解決方針の内容を子チケットのタスクで詳細化していくイメージだ。

能力のあるプロジェクトマネージャは、課題管理やリスク管理に敏感で、落とし穴にはまらないように未然防止策を立てていたり、落とし穴にはまり込んだ時のコストやスケジュールをバッファとして保持するなど、リスク対策をよく考えている人が多い。

【7】「親子チケットにすべきか、それともチェックリストにすべきか」という問いは、タスク管理よりも課題管理のほうが重要ではないか、と思う。
最初は、いきなり課題チケットからタスクチケットに分割できる訳ではない。
試行錯誤しながら課題を解決する必要があるから、チェックリストでまずはラフでもいいので書き込んで、それらを一つずつ潰していきながら、解決方針を探り当てる。

チケット管理の面白さは、こういうプロジェクト管理の技法を実際にチケットの中で色々試せることだ。
どういう場面でチケット管理のどの技法を使うと有効なのか？

それを手順に落とし込むことができたら、チケット管理という意思決定は、単純な条件分岐だけの意思決定まで落とせるるはずだ。
なぜならば、場面ごとのIF文ごとにチケット管理の技法を実行する、というSwitch文に置き換えられるからだ。

プロジェクトマネジメントとは、最終的には、単純な条件分岐だけの意思決定まで落とし込んで、プロジェクト運営の問題を具体化して分割することに過ぎないのではないか、と思っている。