DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第77回】テーラリングという言葉に隠れた『不都合な真実』


【第77回】テーラリングという言葉に隠れた『不都合な真実』

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

前回は、プロジェクト標準定着化の試みのひとつとして「プロジェクト標準の発散収束技法」という考え方をご紹介しました。プロジェクトは独自性という特徴をもつことから、組織標準を個別プロジェクト用にテーラリングして活用するのが一般的であり、CMMI(能力成熟度モデル統合)でも推奨されていることです。(※1)

今回は、組織標準やプロジェクト標準の定着化を図るうえで押さえておくべき、テーラリングという便利な概念について考察します。

 

【 テーラリングとは? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
まずは質問です。テーラリングとは何かご存じでしょうか?

<新人P子さん> : 「プロジェクトマネジメント研修で聞いたわ。確かプロジェクトで使う問題・課題一覧とかレビュー記録票とかのフォーマットを使いやすいようにカスタマイズするってことでしょ?」

<ベテランPMのM男氏> : 「なんや?なんでもかんでも横文字にすりゃええってもんじゃないじゃろ!プロジェクトの手順や様式なんて、前にやったプロジェクトのものを流用すりゃええんじゃ!なまじ、あるべき姿なんて追究するから『しくじり先生』のマルクスみたいになるんじゃ!」(※2)

<新人P子さん> : 
「うーん、そういえば実際のプロジェクト現場でも、組織標準をもとにカスタマイズするより、前に使ってたものを参考にして使いまわすことの方が多いような気がするわ。今までやったことのない新しい手順とかフォーマットを使うように標準化チームさんから展開されたときには、いろいろ考えるけど。。。」

<ベテランPMのM男氏> : 「ふん!標準化チームが出してくる新しい手順やフォーマットなんて、現場を苦しめるだけのもんじゃろ?そんなもんにつきあってられんから、何も考えず適当に書いて突き返せばいいんじゃ!まったく、ろくにプロジェクトの現場を知らん連中がとやかく口出ししよって、やってられんわ!」

・・・ おやおや、どうもプロジェクトの現場では、組織としての標準化推進に対して否定的というか、仕方なく従っていることがまだまだ多いのでしょうか?やはり、CMMIで描かれている組織成熟度モデルは、マルクスの描いた社会の発展段階モデルと同じように現実世界にマッチしないものなのでしょうか?

気を取り直して、まずはテーラリングの定義を確認しましょう。少し長くなりますが、ITmedia エンタープライズの情報システム用語事典から引用します。(※3)

tailoring / テーラリング

組織・企業が業務の基本として定めた標準プロセスや開発標準などを手直しして、個別のプロジェクトや顧客の要求に合わせて実用的な標準(手順・成果物・指標など)を作成・実行すること。

一般に業務の標準化は効率と品質を向上するが、大規模な組織で定義される標準は一般的なレベルで記述されていることが多く、そのまま個別具体的な業務に適用できるとは限らない。このとき、基本となる標準を実際の事案に合わせて変更・詳細化し、具体的な業務プロセスやルールを定義する作業をテーラリング(仕立て直し)という。

CMMIでは、プロセスの定義・視覚化を重視するが実際の適用ではテーラリングを行うことが前提となっている。CMMI(段階表現)のレベル3は、個別プロジェクトからプロセスを吸い上げて組織の標準プロセスに反映し、その標準プロセスを加工・修正して次の個別プロジェクト(場合によっては個人)のプロセスを定義・実行するというサイクルを求めている。このとき、テーラリングは「テーラリング指針」という統一基準に基づいて行われる。

この記事から、テーラリングは個別プロジェクトに合わせて実用化すること、一般的なレベルの記載を具体化することという趣旨が読み取れます。これを逆手に読むと、テーラリングのもととなる組織標準は実用的ではなく、具体的でも無いということであり、確かにM男氏やP子さんが言うように、既に具体化、実用化されている、前のプロジェクトで使ったものを流用する方が現実的だと考えられるかもしれません。。。

 

【 業界標準、組織標準とテーラリング 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
さて、ここまでは組織標準を個別プロジェクトに適用するというシチュエーションでのテーラリングに焦点を当ててきました。組織標準は個別プロジェクトの成果のフィードバックにより継続的改善を図るのは言うまでもありません。一方で世の中に出回っているPMBOKやISO9001などの業界標準、グローバルスタンダードもバージョンアップしていくので、システム開発を行う組織としてはその流れにも追随する必要があります。そのことを概観したものを図1に示します。

PMBOKガイド第5版には、テーラリングについて、次のような記載があります。(※4)

プロジェクト・マネージャーとそのチームは、採用しようとする各プロセスおよびその構成要素であるインプットとアウトプットを注意深く検討し、担当するプロジェクトに適用できるかを決定すべきである。プロジェクトの全体的な進め方や方法論を考慮する際に、PMBOKガイドはプロジェクトの情報源として活用できる。このような作業は、テーラリングと呼ばれる。

テーラー(tailor).PMBOKガイドに含まれるプロセスと関連するインプットやアウトプットを慎重に選定すること。プロジェクトの全体的なマネジメント手法に用いる特定のプロセスのサブセットを決定する。

PMBOKガイドなどの業界標準をもとに、個別プロジェクト向けに直接テーラリングするということはあまりしないと思います。図1で示すように組織標準を作るときにPMBOKガイドなどをテーラリングするというのが一般的ではないでしょうか?つまり、テーラリングには、業界標準をもとに組織標準を作り上げるステップと、組織標準をもとに個別プロジェクト標準を作り上げる2段階のステップがあるということになります。

PMBOKガイドなどの業界標準が一般的であったり実用性に欠けるのは仕方ないにしても、それをテーラリングして作る組織標準が具体的、実用的なものであれば、M男氏とP子さんの悩みは解消するのではないでしょうか?

組織標準を作る立場の方(標準化チームなど)が目指すべきは、できるだけテーラリングが少なくて済む、そのまま使えるプロジェクト標準です。少なくとも、前にやったプロジェクトから流用するよりも、組織標準をもとにした方が使いやすいと感じられるようなプロジェクト標準の構築と提供の仕方を考える必要があるはずです。

「個別プロジェクトへのテーラリングのもととなる組織標準を実用的なものにしよう!」

 

【 テーラリングという言葉に隠れた『不都合な真実』 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
『不都合な真実』は、アル・ゴア元アメリカ副大統領が、過去の気象データや温暖化により変化した自然の光景を用い、地球温暖化という環境問題を直視しない政府の姿勢を批判する内容の映画です。経済の発展を優先させてきた資本主義社会に一石を投じようとするものでした。(※5)

前章で見た通り、テーラリングには業界標準をもとに組織標準を作り上げるステップと、組織標準をもとに個別プロジェクト標準を作り上げる2段階のステップがあります。その語源であるテーラー(仕立て直し)は、幅広い解釈ができる概念です。そして、CMMIのレベル3以上では組織標準を個別プロジェクトに適用する際にテーラリングする(すなわち、個別最適化を図る)ことが前提となっています。

このことから、システム開発プロジェクトにおいて、テーラリングをすること自体、かなり肯定的にとらえられる土壌があるように感じています。確かに、何も考えずに組織標準で規定された通りに仕事をするだけでは、標準の良し悪しを評価できずに継続的改善に結びつきづらいことは理解できます。

しかし、標準化の目的は属人化による多様化、複雑化、無秩序化を無くして、一定の品質や生産性を保つためのものです。いわば底上げ的な活動であり、あまり自由度を持たせるべきものでは無いと考えられます。たとえば、前回のブログで取り上げた問題・課題一覧やレビュー記録票のフォーマットなどは、個別プロジェクトごとにテーラリングを検討すべき幅がそんなに無くても良いはずです。

ところが、私がこれまで携わってきたシステム開発プロジェクトでは、プロジェクトマネジメントに必要なさまざまな手順や様式をいちいち定義しなおすことが多かったのが現実です。われわれアイ・ティ・イノベーションのコンサルタントは、Modusシリーズという当社オリジナルの実用的な標準のラインアップを準備しているため、個別プロジェクトの標準を作ることは手馴れているのですが、プロジェクトの立ち上げの多忙な時期にそのようなテーラリングを行い、関係するステークフォルダと調整していく作業はプロジェクト・マネージャーにとって、かなり負担となるケースもあります。(※6)

どのプロジェクトにおいてもテーラリングによる負荷が高い原因は、組織標準の質の悪さに起因していると考えられます。つまり、テーラリングが肯定的にとらえられている土壌に甘えて、組織標準の具体化や実用化、そして、個別プロジェクトへの適用結果にもとづくフィードバック、すなわち継続的改善がしっかり行えていない組織が多いことが『不都合な真実』なのです。

システム開発プロジェクトの成功率を上げるためには、組織標準の質の悪さという『不都合な真実』を直視して、前章で示したテーラリングの2段階のステップをきちんと識別した上で、具体的で実用的な組織標準の構築と継続的改善のアクションを実践していくことが必要です。

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1 「能力成熟度モデル統合」『フリー百科事典 ウィキペディア日本語版』
2015年11月3日 (火) 03:58 UTC https://ja.wikipedia.org/wiki/能力成熟度モデル統合

※2 『しくじり先生』のマルクスについては、当ブログの以下の回参照。
【第75回】すべてのプロジェクトは崩壊を運命づけられている?

※3 ITmedia エンタープライズ > 情報マネジメント用語辞典 > 情報システム用語事典 > テーラリング(てーらりんぐ)
http://www.itmedia.co.jp/im/articles/0710/30/news140.html

※4 Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド(PMBOK®ガイド)』(第5版)Project Management Institute, Inc.

※5 「不都合な真実」『フリー百科事典 ウィキペディア日本語版』
2016年5月8日 (日) 21:27 UTC https://ja.wikipedia.org/wiki/不都合な真実

※6 Modusシリーズについては、株式会社アイ・ティ・イノベーションのコーポレートサイト「方法論」のページ参照。
https://www.it-innovation.co.jp/products/


| 目次
Pocket

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事