それは、その担当者の決済箱にたくさんのタスクが入ってきて、処理待ちの行列を作っているときである。これはちょうど、大病院は3時間待ち・3分治療だ、という皮肉と同じ現象である。一人一人の患者に対する医師の作業時間は3分だ。複数の患者をマルチタスク的に並行して診ているわけではない。大勢の待ち行列のために、患者の側から見ると作業期間は3時間になってしまう。プロジェクトにもこれと同様の事象がおこる。特定の繁忙部署やボトルネック工程の前には、長い行列ができている。PERT/CPMの弱点は、ここだ。クリティカル・パスは純作業時間ではなく、総作業期間の長さで決まる。この例のような状況では、一つのプロジェクトの中だけを見ても、クリティカル・パスは定まらない。いって、『平均滞留率』のような曖昧な指標にたよるのも、ありがたくなかろう。プロジェクト・スケジューリングにも、複数のプロジェクトを同時に計画し、うまく優先順位法や山崩しのできるツールが求められているのは、このためなのである。その場合でも、プロジェクト間のトレードオフは、計画者の判断が必要になるのであるが。Comments(0)仕事の最小単位(2)--アクティビティのパフォーマンスを測るアクティビティが『お仕事の最小単位』であり、マネジメントの基本部品であることは前回の説明でご理解いただけたと思う。このアクティビティは、ときに「タスク」と呼ばれることもある。わたしも以前はタスクという呼び名の方を使うことが多かった。task"と呼んでいることなどを考え合わせて、このように語法を変えることにした。ちなみに生産スケジューリングの分野では、アクティビティという語はあまり使われず、ほぼ同じ概念が「タスク」とか「オペレーション」とか、あるいは「オーダー」と呼ばれたりする。プロジェクト・マネジメント理論では仕事を中心に、そのインプットとアウトプットとして材料や成果物がある、と捉えるのに対し、生産スケジューリングでは逆に、材料や成果物など(つまりマテリアル)が視点の中心で、その材料を成果物につなげる媒介としてタスク/オペレーションを考える伝統が強かった。モノが主役で作業は脇役な訳である。わたしはこのような物質中心の思考を転換したくて、あえて作業を抽象化した「工順」という概念を中心に据えようとしてきた。ま、それはさておき、アクティビティに話を戻そう。「人に仕事をしてもらう」がマネジメントの基本であり、その指示する具体的実体がアクティビティである。アクティビティには、必要とするアウトプット・インプット・リソース・完了条件があり、それを明確にして指示を出すわけだ。「ちゃんと」した仕事と、不手際な仕事とは、どこが違うのか。それを決めるためには、仕事の手際を評価する尺度をもたなければならない。マネジメントにおいては、アクティビティのパフォーマンス指標が必要なわけである。アクティビティの評価尺度として、誰もが真っ先に思いつくのはコストであろう。どれだけ低コストで結果を出せるか。あなたが、自分のプロジェクト・チームの立ち上げのために、作業用PCと机を10台ずつ用意する作業をサービス部門に頼むとする。どれだけ費用がかかるかは、たしかに重要なモノサシである。コストさえ安ければそれでいい、と考えるほどあなたは単純ではない(はずだ)。一つ大事なものがある。プロジェクト・ルームはなるべく早く立ち上げたい。社内の購買部門にはコストのみが優先事項だと信じている連中も多いけど、たかがPCの価格ネゴに半月かけて納品が1月後では、肝心の仕事が立ち上がらなくなってしまう。コストと並んで重要なアクティビティのパフォーマンス指標は、『時間』なのである。少なくともこの二つは、アクティビティを測る必須の尺度となる。マネジメントはこの2軸を中心に仕事を導く必要がある。ところで、コストにいったん話を戻すと、費用を考える場合、そのアクティビティを指示する先が、自社なのか、外注先なのか、あるいは自社でも別部門なのかで、少し話が異なってくる。ここでは一応、自社を前提に考えよう。自社のアクティビティのコストとは、本当は何を指すのか。あなたが自分のプロジェクトのテスト工程の一部を、他の部署の誰かに臨時に頼むケースを仮定しよう。ハードウェアのモジュールを10台ほど、出荷前の最終立会検査までに、事前に調整・テストしておかなければならない。計200以上の調整・テスト項目はリストにまとまっており、要領書も作成済みだ。追い込みの時期は忙しいので、力仕事の部分に手助けを頼むわけだ。この仕事を、他部門に依頼する。このとき、コストとは何だろうか。原価管理の考え方では、原価は材料費・経費・そして労務費(人件費)からなる。材料(インプット)として必要なモノは10台のハードウェア・モジュールだが、これは支給するので費用はゼロだ(すでに製造アクティビティで計上済み)。試験器も会社の備品として持っている。問題は隣の部門の人件費である。人件費のコスト化は、会社の取り決めにも依存している。本社の人件費は全部、一般管理費として丼勘定の中においている企業も、いまだにとても多い。いう会社では、誰がどれだけ労力をかけようと、見かけ上は「タダ」である。他方、ホワイトカラーの時間をかなり細かく集計している企業もある。後者の場合、他部門の人件費も、その作業時間に単価(賃率)をかける形で集計される。かりに、あなたの会社はとても先進的で(あるいは、とてもケチで)、各人がどのプロジェクトのどのアクティビティで何時間使ったかを、タイムシート上ですべて把握していると仮定しよう。すると、これでテスト作業に借り出された人たちの時間数が分かるから、賃率をかけると人件費が計算できる。ちなみに、日本企業のホワイトカラーの賃率は1時間数千円から1万円程度の間に入るケースが多い(給料の差よりも、オーバーヘッドの乗せ方の基準の違いで、大きく差が出る)。あなたの依頼したテスト項目を全部こなすのに必要な時間は、延べで約100時間だった。二人がかりで1週間ちょっとの作業量である。慣れている自分達がやれば、もっと手早かったのに、とあなたは思う。2人の人的リソースを、実働で7日近く占有したのである。これがアクティビティの第3の評価指標なのである。単位は(リソース数)×(時間)で通常は測られる。これに単価をかけると、リソースの費用になる。投入できるリソース量を決めると、アクティビティ遂行に必要な所要期間のベースが推算できる。リソース量は、コストと時間という、2つの主要なパフォーマンス指標をつなげるパラメータとなっているわけだ。コスト(Cost)、時間(Time)、リソース量(Resources)。石油メジャーのShellなどでは、仕事の最小単位をアクティビティと呼ぶかわりに、これら三大指標の頭文字をとって、最近『CTR』と呼んだりしている。名は体を表す、面白い言い方である。どこに着目すればいいか、初級マネージャーにとっても明確である。一つの仕事が終わるたびに、これら指標を計測し、前回述べたようなアクティビティの辞書に実績を記録してデータベース化していくのである。ここまで実現できたら、たしかに「マネジメント・システム」と呼んでも良いだろう。Comments(0)仕事の最小単位--アクティビティの構造を学ぶ「マネジメント」という行為の、最も原初的な定義は“人に働いてもらう”ことである。人に働いてもらうことで、自己の、あるいは共通の目的を、達成する。自分自身で手を動かして自己の目的を達成することは、マネジメントとは呼ばない。作業とか行為と呼ばれる。あなたがもし食卓で母親に「ねえ、そこのお塩とって。」と言って手渡しもらったら、あなたは、その瞬間だけは、母親をマネジメントしているのである。母親に働いてもらって、自分の目的を達したからだ。何も言わない前に、母親が気を利かせて塩をとってくれたら、もちろんマネジメントしたことにはならない。そもそも、座っているだけで目の前に夕食が出てきたとしても、たぶんそれは母親が自発的に調理をしてくれたのであって、自分がわざわざ命令を下してやらせている行為ではない。した依頼や指示や命令の有無が、マネジメントと、自発的な協調行動との境界線になる。具体的な作業の内容である。なにかをとってもらうという行為は、大げさに言えば輸送の作業である。輸送であるからには、対象物(荷物)、現所在地、そして送り先が必要になる。“そこ”にある“塩”を“(自分の手元に)”とって、という事項を最低限伝えなければ、相手は動きようがない。玉子を焼いて欲しいとき、具体的に言うべきことはなんだろうか。欲しいアウトプットを正確に伝えなければならない。目玉焼きなのか、厚焼きなのか、錦糸玉子なのか。卵1個分か2個分か、はたまた100個分なのか。味付けは濃いめか薄めか。ついで指示すべきは、いつまでに欲しいのかである。今すぐなのか、夕食の時でいいのか、あるいは3日後のパーティの時の話をしているのか。納期を指定するわけだ。インプットを指定してやる必要があるだろう。相手が母親ならば、どこに何があるか全て承知している。アパートを訪ねてきた友人に依頼するときは、「卵は冷蔵庫にあるし、油と調味料は食器棚の横に」と教えてやらなければなるまい。自分で支給できないときは「来るときコンビニで買ってきて」と、相手による調達を頼ることになる。アウトプットと、納期と、インプット。大事なものが、まだある。リソースというのは、作業を完遂するために必要な道具や場所や用役のことを指す。あ、それは流しの下だ。えーと、電磁調理台しか無くてね・・インプットとリソースの違いは、インプットが作業に使われて無くなる(アウトプットに転換する)のに対し、リソースは作業が終わったら解放されて元に戻ることだ。フライパンもガスレンジも、消えて無くなりはしない。リソースは、作業中には占有される。いってみればリソースというのは化学反応における触媒のようなものなのである。ここでいうリソースとは、あくまで生産管理やプロジェクト・マネジメントでいう用語であり、「生産資源」などと訳されることもある。資源工学の世界で言う、海の底に眠っているかもしれない利用可能な物質やエネルギー類とは異なる)リソースの中で、最も重要な種類のリソースは「人」である。作業に必要で、作業中は占有され、作業が終わったら解放される。resourceという。直訳すると人的資源だが、リクルートの場面では人材とか人財とか訳され、本社上層の会議室の中では要員・労働力などと呼ばれたりする。作業を終えて解放したときは多少減耗しているので、再生するためには、休ませたり眠らせたり食事をとらせたりお酒を飲ませておだてたりしなければならず、けっこう手間暇のかかるリソースである。それでもまあ、ある局面では稀少な価値ももたらすことがあるので、大事にしなければならない。君でなきゃダメなんだ、君の作ったのを食べたいんだ・・・。「君の作る味噌汁を毎朝飲みたい。」--などという陳腐な文句が、いまどき意図した通り機能するかどうかは知らないが、リソースの指定はたいていの場合、重要である。アウトプットと、インプットと、リソース。納期(これはもう少し一般化して、「完了条件」と言ってもいい)。じつは、マネジメント上、とても大事なことが抜けている。「指示情報」と「報告情報」のやりとりが必要だ。指示情報とは、これまで列挙してきたアウトプット・インプット・リソース・完了条件などの伝達である。必要に応じてはレシピ(つまり設計情報ないし作業手順情報)も渡してやらなければならないかもしれない。家族や、同一組織内では、お互いに了解している事項が多いので(これを「コンテキスト・レベルが高い」と形容する)、アウトプットと完了条件だけ指定すれば、あとはくだくだ言わなくても通用するはずである。報告情報とは、完了時、ならびに(必要に応じ)途中途中で、作業がどういう状態であるか、アウトプットはどうなっているかを、指示した人=マネジメント主体に対して伝達するための情報である。誰かに働いてもらっているとき、終わったのか終わっていないのかも分からず、どういう状態にあるのかもさっぱり把握できていないのでは、「マネジメントしている」とは到底言えない。「お塩とって」のように、目の前で一瞬にて終わる作業ならば別だが、海を離れたところにいる誰かに2ヶ月かかる仕事をしてもらう際は、報告情報をもらわなければ困ってしまうだろう。ここまではインプットもアウトプットも物(マテリアル)である場合を記したが、作業の種類によっては、統計分析や企画書作成のように、インプットもアウトプットも情報やデータとなる場合もある。この場合、作業インプットとしての情報・データと、指示情報とは区別して理解すべきである。ところで、指示/報告情報に関連して一点注意したいことがある。マネジメントにおいて、上記のアウトプット・インプット・リソース・完了条件を指定して依頼した場合は、原則として、依頼を受けた側がどのような手順で進めるか(すなわち相手の業務の「内部プロセス」)については、途中でいちいち口をはさまない。小姑のように、箸の上げ下ろしまでいちいち指示をしてはいけない。マネジメントというのは、際限のない命令-服従関係とは異なる。ある仕事のまとまりを、他者に指示したら、その内部には立ち入らず、相手の権限範囲とする。相手が自発的に改善できる領域を与える。これがマネジメントにおける「仕事の最小単位」の意味である。プロジェクト・マネジメント理論において、この仕事の最小単位を『アクティビティ』と呼ぶ(「タスク」と呼ぶこともある)。WBSを作っていくとは、プロジェクト全体を、このようなアクティビティに階層的に分解していく過程を指している。アクティビティはいくらでも下位のサブ・アクティビティに際限なく分解可能だが、適切なレベルでとどめておく(最下位レベルのアクティビティを「ワーク・パッケージ」とも呼ぶ)。明確に文書で規定しておく。できればリスト化し、あるいは辞書のようにデータベース化しておくと良い。誰でも必要に応じてアクセスできるようにしておく。このような形でアクティビティを定義しないまま、共通経験の乏しい(コンテキスト・レベルの低い)海外子会社や外注先に仕事を依頼したって、うまく仕事がマネジメントできるわけがない。オフショア開発を上手に進めたかったら、自社の求めるアクティビティをきちんと規定するところから、まず始めるべきなのである。Measurement"のタイトルで講演発表を行います(英語)。ご興味のある方は、よろしくご来聴ください。今年は第10周年記念として、「スケジューリングシンポジウム2010」が、きたる9月10日(金)・11日(土)、千代田区の法政大学で開催されます。今回はわたしがオーガナイザとして「プロジェクト・マネジメント」のセッションを企画しています(11日14:30~)。講演者とタイトルは次の通りです。荏原製作所)ご興味がある方はぜひご来場ください。Comments(0)バッファー・マネジメントとは何かプロジェクトの計画作業は大きく二段階に分かれる。前半はスコープ定義で、プロジェクトを構成するアクティビティを洗い出し、達成すべき仕事の範囲全体を網羅しカバーする。このアクティビティを階層的に構成して整理番号を付番したものがWBSである。後半は、各アクティビティに必要なリソース・時間・コストを見積り、アクティビティの順序(論理的関係)にしたがって、ロジック・ネットワークを作成する。これがプロジェクトのタイム・テーブル(工程表)のベースとなる。これがスケジューリングである。プロジェクトを表すアクティビティ・ロジック・ネットワークの始点から終点までを結ぶさまざまな経路のうち、最長のものをクリティカル・パスと呼ぶことはよく知られている。プロジェクト全体の所要期間(工期)は、クリティカル・パスよりも短くすることはできない。ここまではまあ、ある意味で基本である。プロジェクトの期限ないし納期設定を考える時、そこに自由度がある場合と、外部から制約条件として与えられる場合がある。受注ビジネスの中で生きている人は、「納期とは客先から与えられた制約条件だ」と考えることが多いだろう。契約によっては、納期遅延に対してペナルティ条項がついていることもある。ように、自社が発案した自発型プロジェクトでは、納期はある程度、自ら設定できる。Projectと呼んで区別する。自発型であっても、新製品の納期が展示会やフェアーなどの期日にしばられることはある。対外発表の時期が、上からぽーんと鶴の一声のように下りてくることもあろう。いずれにせよ、自発型の場合、納期に多少の自由度があるケースが多い。自分が納期を設定できるときは、クリティカル・パスの長さで決めるべきだろうか。クリティカル・パスの長さが120日ならば、納期は120日と宣言して良いだろうか。クリティカル・パスの長さとは、プロジェクトが達成可能な『最短の期間』だからだ。計画段階ですべてを見通すことはできない。予期せぬ事やらミスやらが、途中で生じてくるものである。した外乱・内乱(?)によって、スケジュールというのは常に遅れていく可能性がある。そこで、クリティカル・パス長に、最小限の適切な余裕日数を加えて、納期を設定する方が安全である。この、意図して追加した余裕日数のことを、「バッファー」と呼ぶ。余裕日数としての「バッファー」と、PERT/CPM技法でいう「フロート日数」は、ときどき混乱して使われるので、注意が必要である。PERT/CPMのフロートは、そのアクティビティが遅延したときに、プロジェクト全体の工期に影響を与えるまでの日数を言う。Floatの二種類があるが、説明は省く)。クリティカル・パス上のアクティビティはすべてフロート=0日である。フロートとは個々のアクティビティに付随する属性値だと理解してほしい。これに対してバッファーとは、特定のアクティビティにぶら下がる性質のものではない。全体のプロジェクト・マネジメントの観点から、意図して置かれるものである。「時間のムダとり--スケジュールのサバを切り捨てる」(2009/12/07)でも説明したとおり、適正なスケジューリングにおいては、(1)アクティビティ所要期間の冗長な部分をみつける、(2)それを捨てる(正味分のみにする)、(3)プロジェクト全体に必要最小限の冗長性を付け加える、という、ちょうど情報理論と類似した手続きを行う。このステップ(3)がバッファーなのである。バッファーは生産管理で言う、意図した在庫配置に相当する。それでは、このバッファーを、アクティビティ・ネットワークのどこに配置すべきなのか。全体工程120日のプロジェクトに15日のバッファーを追加するとして、それはどこに置くべきか。細かく分割して、すべてのアクティビティに公平に配分したら、という考え方もあり得よう。いや、クリティカル・パス上のアクティビティだけに個別配分する、という案もある。これらはあまりおすすめできない。前にも書いたが、バッファーには加法性が成り立たず、1日のバッファーを15個持つよりも、15日のバッファーを一箇所にまとめておく方が、ずっと安全なのだ。最初にバッファーを置く、というのは、言いかえると、プロジェクトがスタートしてから15日間は、何の作業にも着手しない、ということになる。これではバッファーとしての意味がない。したがって、プロジェクトの最後にまとめて置く、というのが正解となる。これを、「プロジェクト・バッファー」とも呼ぶ。プロジェクトを遂行していく上で生じるさまざまな遅れにより、このプロジェクト・バッファーは次第に消費されていく運命にある。そこで、プロマネは残りのバッファー日数をウォッチして、あと何日までなら納期に影響がでないか、常に見ていくことをお勧めする。このように、計画段階で上手にバッファーを配置設定し、実行段階でそれをウォッチし続けることを、CCPM技法では「バッファー・マネジメント」と呼んでいる。この目的のために実行段階でしばしば使用されるツールとして、横軸にプロジェクトの経過日数(割合)をとり、縦軸にバッファー日数の消費(比率)をとって定期的にプロットする手法(バッファー・トレンド・グラフ)がある。理想的に言うならば、プロジェクトの進行割合に比例して、バッファー日数が消費されていく、という形になる。開始後40日たったらバッファーは5日消費され、開始後80日では10日消費されている、という具合だから、プロットされた点は斜めの直線になるだろう。現実はなかなかそうはいかず、ジグザグの線になる。グラフ上で点が上の方に来る状態は、プロジェクトの進行に対してフロートの消費が著しく大きいことを意味している。そこで、グラフに原点を通る2本の線を書いて、プロット・エリアを3つに分け、下からグリーン・イエロー・レッドに分けることがよく行われる。プロットされた点が下の方、つまりグリーン・ゾーンなら安全、中間のイエローなら注意、上の方のレッドなら危険、という訳である。このようにCCPM技法では、プロマネが個別のアクティビティ全てを進捗管理するなど無駄な労力であって、クリティカル・アクティビティとバッファー日数だけをきちんとコントロールしておき、あとの精神的余力は他の重要な事に取っておくべきだと考える。この「プロマネの注意は重要な事だけに向けるべき」というのは、とても良い提案だと私は思っている。プロジェクトといえば、最初にスコープをきちっと決めて計画を立て、プロジェクトマネージャが強力なリーダーシップを発揮し、チーム員をぐいぐい引っぱって進めていく・・・そんな風にすべきだとPMの教科書類には書いてあるし、私も参考書にそう書いてきた。そのために、EVMSだCPMだという技法もあるのだ、と。たしかに、マスター・スケジュールも立てず、クリティカル・パスの何たるかも知らないでプロジェクトを始めるのは、海図も持たず舵取りの仕方も知らないまま船出をするようなものだ。これで無事に航海して目的地にたどりつけたら奇跡だろう。いえ、世の中には、そんな事例がいくらでもあるのも事実である(とくに某○○業界では・・)。Guideに書かれているような近代的技法の数々を適用しても、さっぱり成功しないプロジェクトというのも、実は存在する。スコープは不確定で、スケジュールは“可及的速やかに”とされており、予算の大枠は存在するが、細目を決めがたい・・・そんな種類のプロジェクトも、確かにある。新しいカテゴリーの新製品を作るような仕事や、博覧会の展示パビリオンを作るような仕事がそれである。ある米国のプロジェクトマネジメント・コンサルタントは、こうした種類のプロジェクトを“猫型プロジェクト”と呼んで区別することを提案している。Guide風の伝統的なこわもての管理手法は、この種のプロジェクトには全く向かない、と言う。それは、猫に対して犬のしつけを強要するようなもので、相手はこちらの言うことを聞くどころか、そっぽを向いて去っていってしまう。Guideは、どちらかというとスコープがかなり明確で、かつプロジェクトの内容が物量で規定されるようなタイプのプロジェクトを念頭に書いている。いってみれば一括請負型プロジェクトである。したプロジェクトは、計画上の自由度が少ないが、管理対象の物量が多いため、計数管理手法と軍隊型のリーダーシップに向いている。これは“犬型プロジェクト”だしかし、猫型プロジェクトは性格が全く異なる。猫型プロジェクトは基本的に自由度が非常に大きいので、計画や予測より発明の要素が強い。白いキャンバスに絵を書くようなものだ。始めた時点では、どこにたどり着くか、プロマネを含めて誰もよく分からないのだ。ここには命令の原則は通用しない。猫は呼んでも来ないし命令も聞かない。自分の気ままな思いつきで行動する。どこに行くか分からない。猫のように気ままなのだ。猫型プロジェクトの難しさは、自由度が大きい条件下で、発想をどう育てるかという難しさである。そこに必要な手法は、軍隊式チームワークではなく、思いつきを生み出すためのコミュニティ・マネジメントであるという。そのための手法の一つとして、『ジャーナル』を発行することを進めている。英語のJournalはもともと、語源的には“日々の”というニュアンスがある。毎日起きることを、時系列的に、ないしは日誌的に編集したものがジャーナルの原型である。いう仕事に従事する人を「ジャーナリスト」とよぶ。このコンサルタントの処方箋はつまり、プロジェクトの中で毎日起きている出来事やアイデアやインプットなどを、関わるチームの全員にできるだけ毎日、伝えて共有することを勧めているわけだ。まあ最近では、それに向いたTwitterだのSNSだのといった仕組みが発達している。した情報共有系を活用して、なるべく皆のベクトルを一つに合わせてシナジーを生み出すことがコツなのだろう。Guideは、プロジェクト・マネジメントの世界に標準的な概念やプロセスを確立したという意味では、まことに画期的なものである。その功績は誰も否定しない。Guideには「プロジェクトの分類学」が欠けているという不満をずっと私は感じている。プロジェクトには大規模なものも小規模なものもあり、受託型のものも自発的なものもある。スコープが明確でハードな「犬型」と、目標も曖昧模糊としたソフトな「猫型」がある。これらは、みな適したマネジメント手法が違うのである。Guideは提供しようとする。したソリューションがあるかのような信念ないし誤解をふりまいている。読む側もみな、自分をその衣服の型紙に合わせようと、肩をすくめたり首を伸ばしたりしているのではないか。思い出してもらいたい。Guideを'80年代の終わりに着手した人たちは、米国の防衛宇宙産業とエンジニアリング産業が中心だった。彼らのビジネスは、巨大で、複雑で、スコープが明確に定義されていて、請負型で遂行するタイプのプロジェクトだったのだ。したバイアスは、伏流する地下水のように、あの『標準書』のあちこちににじみ出している。Guide的プロジェクト観に偏りすぎていると、私は思う。プロジェクトの世界は多様なのだ。その多様さを、そのまま活かせるようなマネジメント力こそが、求められていると言うべきだろう。世の中には、名刺に書きやすい資格と、そうでない資格がある。『弁護士』だとか『医学博士』だとかは、名刺に書くと箔がつくし、押し出しもきく。『技術士』や『不動産鑑定士』はそれよりやや専門的で地味な印象だが、その道の人は誰もが知るプロフェッショナルである。これに比べて、『漢字検定1級』とか『囲碁5段』とかは、知識レベルの深さでも資格取得の難易度の点でもひけをとらないはずだが、なぜか名刺に書く人は少ない。私が持っている(そして参考書も書いていた)『プロジェクトマネージャ』というのもまた、名刺に書きにくい資格だ。この名称では、取得資格なんだか社内組織上の職位を表わしているんだか、区別がつかないからだ。私も名刺には記していない。資格を取っても名刺に載せられないとさびしいので、もう少し注釈をつけて書こうかと考える向きもあろう。情報処理技術者プロジェクトマネージャ』ということになるが、ずいぶん長くて場所ふさぎだ。おまけに名刺交換の時に、自己紹介の目的にいささか不便である。