プロジェクトマネジメント

2022/06/19

プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある

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

【参考】
デジタル庁が解くべき課題と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の地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

| | コメント (0)

2022/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

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モデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/04/21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2022/04/17

初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ

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

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

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

「ソフトウェア開発分析データ集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が収集したソフトウェア開発における数多くの統計データが掲載されている。
その統計データが膨大であるために、どのように使えばよいか分かりにくい。
僕も正直悩んでいた。

しかし、初中級プロマネのための 現場で活かせ!統計情報1を読むと、初級者・中級者のプロマネは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型開発が主流であり、それなりの品質データや見積データを収集して蓄積しているみたいだ。

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

| | コメント (0)

2022/03/04

タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine

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文に置き換えられるからだ。

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

| | コメント (0)

2022/02/18

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想

文庫本「V字回復の経営」をふと読んで、ようやく、なぜ米国企業はことあるごとに、自分たちの経営手法の源流にトヨタ生産方式をあるのだ、とトヨタ生産方式を礼賛するのか、理由が分かった気がした。
一言で言えば、戦前の日本の敗戦と同じく、米国人に日本の経営の手の内は完全に読み取られただけなのだ。
適当なラフな感想。

【1】「V字回復の経営」を読むと、日本企業が官僚化して、世界の潮流から遅れてしまった原因は、設計→製造→販売というサプライチェーンが社内で分断されて、リードタイムが長くなっているからだ、という点に尽きると思う。
だいたい、日本人は、チームワークよりも、専門家として能力を発揮しようという考え方が強いと思う。

実際、大企業として組織の規模が大きくなると、設計→製造→販売の一まとまりのプロセスを一つの組織に任せるのではなく、設計だけの組織、製造だけの組織、販売打系の組織、という形で専門分化しがちだ。
なぜなら、図体だけ大きくなりすぎるから、機能別に組織を細かく分けて、それぞれの専門性を発揮させようとするからだ。
その方が規模の経済を活かしやすく、人も組織もスケールしやすい。
また、専門性を持たせるような組織の方が、仕事の中身が限定されるので、組織のトップとしても人事制度が組みやすいし、戦略も立てやすい。

しかし、大企業になるほど内部組織が専門分化すると、官僚制組織になってしまう。
日本政府のように、コロコロ変わる政治家を無視して、各省庁が勝手に動いて決めて、その結果、戦略性のないまま、あらぬ方向に暴走しやすくなる。
日本の組織論の失敗事例を分析し尽くした本である「失敗の本質」に、その有様が詳しく多面的に書かれている。

【2】では、米国企業は80年代に日本企業に負けた後、どうやって90年代に復活したのか?
米国人は、日本的経営手法を丸裸にして分析し尽くした後、リエンジニアリング、シックスシグマ、サプライチェーン、アジャイル開発など、手を変え品を変えて、その概念を経営戦略やソフトウェア開発に適用してきたのだ。

V字回復の経営」によれば、米国人によって日本の手の内は完全に読み取られた。
米国人は自分たちで、日本解体新書を作り上げてしまった、と。

ちょうど、戦前の日本が、日清戦争・日露戦争で一躍世界に躍り出たものの、第二次世界大戦では日本の暗号を米国に完全に読み取られて、最後は完全にやられてしまったのと同じように思える。

【3】では、米国企業は日本の手の内をどのように分析し尽くしてきたのか?

V字回復の経営」を読むと、4つの観点があると思う。
それは、プロダクトポートフォリオマネジメント、かんばん方式は時間の戦略であると見抜いたこと、バリューチェーンで経営戦略を類型化したこと、ITを駆使して設計も生産も販売も経営も全てリードタイムを短縮化できると見抜いたこと、の4つだ。

【4】プロダクトポートフォリオマネジメント(PPM)

20世紀後半に日本企業が急激に成長したメカニズムは、PPMの発想と同じ。
つまり、日本企業は米国企業と違って、短期的な利益よりも、長期的な観点で、まずは市場シェアの拡大を狙う。

すると、市場シェアの拡大→売上増加→経験曲線効果により単位あたりのコストは低下→低コストの強みを活かしてシェアを拡大する、という一連の拡張ループが生まれる。
米国人のコンサルがこのアイデアをPPMという世界初の経営戦略理論を生み出したわけだ。

【5】かんばん方式は時間の戦略である

米国企業は、日本企業の強さに生産現場での高品質、効率化にあると分かったが、なかなか真似ることはできなかった。
米国の労働者は能力にばらつきがあるし、QCサークルやワイガヤみたいにチームの一体感を生み出すことも難しい。

しかし、米国人のコンサルは、トヨタ生産方式を分析して、かんばん方式の本質は在庫減らしではなく、時間の価値という新しい戦略要素を追求する手法と見抜いた。
企業は時間の戦略によって、新たな競争優位を生み出せる、と導いた。

一般に、ビジネスとは、設計→製造→販売という一連のプロセスから成立する。
ここにカンバン方式が生み出した時間の戦略を当てはめれば、設計→製造→販売というプロセス全体のリードタイムをいかに短くするか、という問題に置き換えられる。

つまり、企業戦略の要素であるヒト・モノ・カネ・情報の次に、時間が大事だと見抜いたわけだ。
この発想は、ビジエスプロセス・リエンジニアリング、サプライチェーンマネジメントからアジャイル開発に至るまで、その背後にあるように思う。

日本の大企業を見ると、組織の図体が大きくなると、設計→製造→販売というプロセス全体のリードタイムが長くなりがちなので、設計だけ、製造だけ、販売だけ、というプロセス単体の効率化に走る。
すると、各プロセスに特化した設計事業部、生産事業部、販売事業部という機能別組織を新たに作ったり、あるいは、設計だけ、生産だけ、販売だけの子会社をたくさん分社化しがちだ。
実際、日本の家電メーカーや自動車メーカーを見れば、生産と販売が分社化されているのがほとんどだ。
今では、家電メーカーも自動車メーカーも、派遣や委託という形で、製造すら、どんどん外部へアウトソースしている場合がほとんどではないか。

すると、どの組織もタコツボ化されてしまい、自分たちの製品を受け取る顧客からどんどん遠くなるので、顧客のことを考えなくなる。
まったく顧客志向ではない。

一方、米国企業は、時間の戦略が重要と概念化し理論化することで、スピード重視の経営スタイルに変革した。
そのやり方は、たとえば、業務プロセスを改革しリードタイムを短縮させるというリエンジニアリングだったり、原材料の仕入れから設計、製造、販売までのプロセスでリードタイムを短縮するサプライチェーンマネジメントだったり、ソフトウェア開発ならばユーザーストーリーで要件をまとめて設計からプログラミング、テスト、リリースまでを一気通貫に開発してしまうアジャイル開発だったりするわけだ。

つまり、製造業の生産プロセスのリードタイムを短縮するという手法を、一連の供給連鎖、価値連鎖、ソフトウェア開発まで一般化することで、よりスピーディに対応できるようにしたわけだ。

【6】バリューチェーンで経営戦略を類型化

一方、ポーターはバリューチェーンを提唱した。
そこから、経営戦略は、ポーターの基本戦略であるコストリーダーシップ戦略、差別化戦略、集中戦略に類型化される。
ポーターの基本戦略からの結論は、99%の企業は差別化戦略しかありえないことだ。

すると、企業は市場においてポジショニング戦略を取ることで、差別化したポジションを取り、競争優位を生み出そうとするわけだ。

【7】ITを駆使すれば設計も生産も販売も経営も全てリードタイムを短縮化できる

他方、90年代から現代まで急激に進化したものは、ITを駆使すれば、設計→製造→販売という一連のプロセスだけでなく、あらゆる業務のリードタイムを短縮できることだろう。
ブルーカラーの生産現場だけでなく、ホワイトカラーの生産性も同様に、トヨタ生産方式を導入することで同じように効率化できる。

たぶん、アジャイル開発がその典型例だろう。
日本のソフトウェア開発では、今もウォーターフォール型開発が典型的であり、請負契約や準委任契約というビジネス慣習の制約もあるために、なかなかアジャイル開発を実践しにくいのが一般的だろう。
IPAの資料にも、アジャイル開発が偽装請負にならないように気をつけるべき注意点を公開していたと思う。

アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021 - Publickey

ソフトウェア開発ビジネスが他の生産や販売のビジネスと異なる点は、ソフトウェアは販売後でも簡単にリリースした機能を変更できること、製造やコピーというプロセスがないので素早くリリースできて大規模に販売できる点だろう。

この特徴を生かしているのがSaaSであり、GAFAが展開しているプラットフォームビジネスだろうと思う。
そして、アジャイル開発のやり方を自動車業界に展開しようとしているのがテスラであり、彼らは、Appleが「電話ができるコンピュータ」であるスマホを生み出して携帯電話もデジカメも駆逐してしまったように、「移動能力を持つコンピュータ」である電気自動車を生み出してガソリン車やハイブリッド車を駆逐しようとしている。
中島聡さんのメルマガを読んでいると、自動車業界はソフトウェア開発をベースとしたビジネスへ置き換えられるように変わっている時代なのだ、と気付かされる。

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること: プログラマの思索

特に直近30年間では、日本人は世界標準から見てソフトウェアに弱いと思う。
日本ではソフトウェアビジネスやビジネスモデルの基盤にソフトウェアをおくことができていないと思う。
今も日本人はソフトウェア開発とソフトウェア開発に向いた組織づくりに苦闘しているように思える。

【8】そんなことを思うと、日本人がトヨタ生産方式を徹底的に分析できず、米国人にそのアイデアを経営手法やソフトウェア開発手法まで洗練化させて概念化して理論化できたのはなぜなのか、と思ったりする。
なぜ、日本人は融通が効かず、新しいアイデアや環境を取り入れられないのか?
日本人は抽象的な思考能力が低かったからなのか?
正直良くわからない。

| | コメント (0)

2022/02/02

諸問題を組織論に持っていくのは目的を手段化していないか

諸問題を組織論に持っていくのは目的を手段化していないかと気づいたのでメモ。

【参考】
(1) ひさてるさんさんはTwitterを使っています 「エンジニア意識高くなると組織論みたいなとこに興味出てくるのはそうなんだけど、技術とドメインにこだわることから離れてマネジメント手法こそが最優先みたいな思想を見ると、いくらアジャイルのプロセスなんだぞと言ってても、やはり人は大地から離れて生きていくことはできないのという気持ちになる」 / Twitter

(1) 杉本啓さんはTwitterを使っています 「本当にそう。組織論にかぶれると、あらゆることが組織の問題に見えてくる。コンサルティング会社にいたころ、同じプロジェクトにアサインされたコンサルタントに、問題構造分析で、すべての問題構造図で「根本の問題」の箇所に「組織が悪い」と書く人がいて、辟易した。 https://t.co/jNsklAq4a7」 / Twitter

(1) akipiiさんはTwitterを使っています 「チャンドラーの、組織は戦略に従うの経験則に、暗黙的に流れてるのだろうと思う。こういうビジネスが必要だと思っても、人や組織がマッチしてないじゃないか、と分かって、組織づくりばかりに専念してる感じかな?」 / Twitter

(1) 杉本啓さんはTwitterを使っています 「僕が、コンウェイの法則をあまり好きじゃないのも、この辺が遠因。」 / Twitter

DXとは組織論である」みたいな論調が最近はやたら多い。
確かにその傾向はあるだろう。
DXを実践するには、IT化した業務、ソフトウェアを基盤にしたビジネスモデルが必要だから、それを実行できる人や組織が必要だ。

しかし、その本質は、「組織は戦略に従う」というチャンドラーの経験則に過ぎないと考える。
なぜなら、DXを実現する経営戦略が先にあって、その戦略を実行できる組織が必要だよ、という事実が、たぶん、どこにでも普遍的に見られるだけだからだ。

だから、色んな諸問題を組織が悪いから実行できないのだ、だから組織を何とか変えよう、という動きに進んで、それが自己目的化していないだろうか?
本来は戦略を実行するのが目的なのに、組織を変えることが目的化してしまっている、みたいな場合が日本では割と多いのではないか。

そして、なぜ、色んな諸問題を組織が悪いから実行できないのだ、という論点にすり替わってしまうのか、という問題の原因も見えてくる。

実は、「組織(構造)は戦略に従う」というチャンドラーの経験則とは逆に、「戦略は組織(文化)に従う」というアンゾフの経験則がある。
たぶん、会社の偉い人が意思決定した戦略に社員を従わせたいのに、実際はうまく行かない原因は、社員が従わないからだ。
それは組織文化にあるからだ、ということなのだろう。
特に官僚組織では、その組織形態そのものがなかなか変わらないので、長年の慣行が組織文化として固まってしまう場合が多いだろう。

野中郁次郎先生の「失敗の本質」を読むと、日本人は、「組織(構造)は戦略に従う」「戦略は組織(文化)に従う」という経験則に振り回されているような印象を受ける。
本来は、組織は戦略を実行するための仕組みの一つに過ぎないのに、その仕組が暴走自動車みたいにハンドル操作が効かなくなり、勝手にあらぬ方向へアクセルを踏んで自爆した、みたいな感じ。

一方、特に米国のMBAの参考図書に上がっている組織人事論の本とか読んでいると、彼らは、組織を動かすための能力やスキルへ抽象化して、誰もが身につけられる普遍スキルに仕上げているように思える。
リーダーシップ論などは特にそう思う。

| | コメント (0)

2022/01/22

プロジェクトマネージャの意思決定プロセスや判断プロセス

プロジェクトマネージャの意思決定プロセスや判断プロセスはどんな仕組みなのか?

問題解決トレーニング アタマがよくなるビジネス50題」「1分間でマスター 問題解決トレーニング」の内容をまとめてみた。

たぶん、すごく新しい考え方ではない。
限られた時間で、どのプロセスを選択するか、その時の条件に従って、処理プロセスを条件分岐させるだけ。
事実や情報が集まって意思決定できるか、情報が少なすぎて意思決定がすぐにできないか。

こんなストーリーかな。

原因が分かって問題解決の手法も明確なら、改善プロセスを選択する。
正攻法なので時間はかかるが、確実に効果を上げる。
30%ぐらいまでの投資対効果を目指す。

時間があれば、仮説を立ててゆっくり考えることはできる。
改革プロセスはそんな感じ。
100%ぐらいの効果を目指すから、今までとは異なるアイデアを持ち出す必要がある。
じっくり計画を立てて、壮大なイメージを十分に練って、トライアルを実行して仮説を試す。

一方、時間がなければ、対処療法的な意思決定を下す時が多い。
まずはパッチ当て。
その後で原因を分析し、根本治療を目指す。

そういう意味ではGTDに似ている。
メール処理みたいに、情報を分類して、条件分岐に従って意思決定を素早く下す。

GTDは箱の使い分けが鍵を握る: プログラマの思索

このやり方でやれば、日々の業務的意思決定は効率的かもしれない。
一方、企画書や提案書をじっくり書き上げたり、機能の実装でどれが一番最善なのか考えながらプログラミングする方法には向かないのではないか、と思った。

いろいろ試してみる。

| | コメント (0)

2022/01/16

「世界を動かすプロジェクトマネジメントの教科書」の概念図

「世界を動かすプロジェクトマネジメントの教科書」の本を読んだ。
自分の理解を深めるために概念図を書いたのでメモしておく。
ラフなメモ。

世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方:書籍案内|技術評論社

【1】「世界を動かすプロジェクトマネジメントの教科書」で気づきがあった点は、プロジェクトの立ち上げ・計画フェーズが最重要であることだと思う。
日本企業では誰が最終責任者なのか分からない場面が多々あるが、「世界を動かすプロジェクトマネジメントの教科書」のシナリオでは、プロジェクトマネージャすら不在の場面がある点も驚きだった。


【2】「世界を動かすプロジェクトマネジメントの教科書」の一節に、ソフトウェア企業のSEが、「SIerでは、プログラマ→SE→シニアSE→プロジェクトマネージャのようなキャリアが多いです」と話す部分がある。
僕の経験上、シニアSE→プロジェクトマネージャの断絶は大きいし、仕事内容も大きく変わる。

100人月以上の案件のプロジェクトマネージャの仕事では、もはやPJの細部の作業まで見ていない。
プログラミングや設計書の作成などの実務にタッチしないし、実作業の進捗管理すら、各サブチームのサブリーダーに任せている。
では、プロジェクトマネージャは何をやっているのか?

彼らの仕事の中身を見ると、ひたすらプロジェクトの計画書、見積書、報告書の作成とそれら書類を利害関係者に説明する会議に出ているだけだ。
顧客への説明はもちろん、インフラ基盤や開発、製品端末などを委託したベンダへの説明がほとんどだ。
その会議のための報告書を作成するために、社内の法務部、購買部、部門長、他部門の関係部署、場合によっては役員と交渉している。

第三者が見ると、プロジェクトマネージャは報告書作成マシーンに見える。
その作業だけで手一杯なのだ。
プログラミングや設計が楽しい人から見れば、そういう作業が楽しいのかなと思う時もある。
ひたすらドキュメントを作っているだけだからだ。

【3】一方で、プロジェクトマネージャのレベルになると会社の中では中間管理職に相当するので、それなりの役職を持ち権限と責任を持つ。
すると、会社内ではそれなりのパワーを発揮できる醍醐味もある。
案件に必要なリソースを自由に使えるからだ。

プロジェクトマネージャはコミュニケーションが重要、とよく言われるが、僕はその言葉はあまり本質的ではないと思う。
直接的に言えば、組織から与えられた権力を正当に行使できるし、むしろ、その権力を案件の達成のためにどんどん使って、部下はもちろん、社内の他の部署、社内の経営層、お客様まで巻き込むことだと思う。
だから、政治家みたいに、権力行使が好きな人の方が向いているという気はする。

しかし、たとえば、IT企業であれば、単に役職さえ与えられればプロジェクトマネージャとしてやれるわけではない。
技術力は当然必要だし、PMBOKに代表されるようなプロジェクト管理技法は一通り知っておく必要がある。
その他に、PJの原価や利益などに関する財務会計の知識、請負・準委任契約や知的財産などの法務の知識、部下をコントロールしたりやる気を起こさせるような人事手法やリーダーシップなども当然要求される。
単純に知識さえあればOKというわけではない。

「世界を動かすプロジェクトマネジメントの教科書」を読むと、改めて、IT業界以外のプロジェクトマネージャも別の観点で苦労しているんだな、とか、IT業界では当たり前でも他の業界では当たり前でないんだな、とか、気付きも多かった。

この辺りはまたまとめてみたい。

| | コメント (0)

2022/01/14

【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine

プロジェクト&プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説~タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点:P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

| | コメント (0)

より以前の記事一覧