プロセスという考え方の整理

このブログを訪問される方は、「プロセス」というものについて、何がしかのイメージをお持ちでしょう。私の経験では、「プロセス」(もちろんソフトウェアやITのプロセス)という言葉でイメージするものは人によってかなり違います。

Aさんは、プロセスとは仕事の手順だと思っています。某IT雑誌の記者の方は、プロセスとは明確な手順のことと理解されて、「自宅から会社へ通う経路やその途中でのイベントの選択にはいろいろある」ということをプロセス概念の易しい解説として書かれていました。

Bさんは、プロセスとは、プロジェクト実施の上で登場するフェーズまたはステップのことだとイメージしています。この場合、プロセスは時間的な流れと、プロセスXの次には(あるいはプロセスXの結果を受けて)プロセスYがあるというプロセス自体の上流・下流概念(流れは一本の場合と、支流や分岐を含む場合とある)が重要となります。

Cさんは、ISO 9000規格をよく知っているので、プロセスとは、入力を出力にかえる活動だととらえています。このプロセスは、組織の業務を遂行するための「プロセスのシステム」を構成していて、その業務の品質(業務品質は、製品品質を支えるものです)が問題となります。

Dさんは、ソフトウェア開発の歴史を知っていて、(開発者のではなく)ソフトウェアのライフサイクル・プロセスというものの重要性を見聞して来たので、ソフトウェア・プロセスの考え方というのは、ライフサイクル全体を通した問題点を強く意識することだと思っています。

Eさんは、プロセスとは、ソフトウェア・エンジニアリング・プロセスの省略した言い方だと思っているので、ソフトウェア・エンジニアリングという工学的な手法をいろいろなソフトウェア開発場面で駆使するあり方のことだと思っています。

プロセスについて、議論をはじめる際には、これらのどのようなプロセスを問題にしたいのかを整理した方がよいと思います。そうでないと、議論が表面的になり、仮に議論が何らかの合意に達したいように見えても、参加者のイメージは実は分裂したままというのがよくあることだと思います。

ちなみに、私は、上のAさんから、Eさんの意見のどれとも違って、”組織やチームが持つ、技術的によく練られ・高度化された、ソフトウェア開発・運用のトータルな(かつ区分された)方法のこと”と考えています。皆さんはどうでしょう。

伏見 諭(合同会社ソフデラ)

伏見 諭 について

ふしみ さとし
合同会社ソフデラ 代表社員
■ 技術系を中心とするソフトウェア小規模開発、中規模開発、大規模開発等に長年従事してきた。また、開発プロセスに関する調査、コンサルティングを行ってきた。最近はソフトウェアの信頼性に関する調査に重点を置いている。スピナッチキューブの開発にも参加。
■ 情報規格調査会SC7/WG24主査
■ JISA技術委員会標準化委員会委員長
■ IPA SEC 連携委員
カテゴリー: プロセス改善, 未分類 タグ: , , パーマリンク

プロセスという考え方の整理 への3件のフィードバック

  1. 宮崎 幸生 のコメント:

    富士通クオリティ・ラボの宮崎です。さすがに伏見さん、中身の濃い投稿、ありがとうございます。

    昔は、フェーズ(工程)という概念が主流で、誰もめったにプロセスとは言わなかったと記憶しています。では、何故プロセスと言い出したのでしょうか?あたり前のことですが、フェーズという概念と異なるからプロセスという用語を使いだしたのです。フェーズと言う時には、その中に目的の異なるいろいろな作業が含まれています。例えば、要件定義フェーズであれば、いわゆる要件定義が中心の作業ではあるでしょうが、移行のことも考えなければならないし、構成管理、標準化、要員教育、進捗管理、品質管理など様々な種類の作業をしなければなりません。ではいったいどれくらいの種類の目的の異なる作業があるのでしょうか?このあたりの整理からプロセスという概念が生まれてきたような気がします。

    したがって、プロセスはそれぞれが明確に目的の異なる作業(CMMIやISOなどの世界標準では、経験的に効果のあった作業)であり、そのための技術やスキルも異なります。要件定義の専門家とは言っても、要件定義フェーズの専門家とは普通は言わないのです。プロセスを明確にすることにより、プロジェクトに必要な体制、ツール・手法、トレーニングなどがもれなく考えられるようになるし、作業成果物の整理・再利用などにも役立つわけです。

  2. 伏見 諭 のコメント:

    伏見です。

    宮崎さんありがとうございます。多分、宮崎さんのプロセスのイメージと私のとはあまり違ないと思います。私の言い分より、明晰で、わかりやすいご呈示だと思いました。

    ところで、私がこのテーマを提示したのは、ITコミュニティ全体としてどうもプロセスという考え方を正しく把握している人はかなり少ないのではないかと思うからです。IT雑誌の記者等もわかっていない気がしますし、プロセス改善(特にアセスメントと結びついたそれ)を毛嫌いする方もプロセスとは何か、プロセスの改善とは何かを結構間違ってとらえて、嫌っておられるように思います。またもっと困るのは、ソフトウェア開発においてプロセスというエンジニアリング問題があるということを理解していただけない方も結構多いということです。アセスメントとか、改善とか言う前に、「プロセスは重要」ということを広く理解していただくにはどうすればいいのかと悩んでしまいます。実践的には、「プロセスアセスメントを真面目に突き詰めれば正しい理解に到達する」というケースもあるでしょうが、アセスメント受けながら嫌いになって行ったり、形骸化して飽きてしまったりというケースも結構あるわけで、何とかならないかと思っています。

  3. 堀田 勝美 のコメント:

    プロセスという言葉自体は、いろいろな分野で使われていますし、昔からある言葉ですので、いろいろな理解があるのも頷けます。
    私が知っているプロセスは、リアルタイムソフトウェアのことでした。
    ISO9001-1987のJIS版では、英語のプロセスコントロールを、たしか工程管理と訳していました。ですから、議論の背景に合わせてその意味合いを捉える必要があろうかと思います。このフォーラムでは、プロセス改善を背景としていますので、基本的には、人の仕事の仕方、有り方という意味だと思います。ですから、仕事に興味のない人は別として、毛嫌いする人がいるとすれば、何か捉え方に偏見がある、あるいは誤解しているのではないかと思います。例えば、プロセスとは人の自由を束縛したり、発想を妨げるものといったような。プロセスとは何かという議論の前に、何故、プロセスに着目するのかということが前提にあるのではないかと思います。ソフトウェアエンジニアリングでは、生産性や品質を向上させるために、これまで技術に着目してきたと思います。また、人によって生産性は何倍も開きがあるといった議論もされてきました。プロジェクトマネージャの力量は、如何に優秀な人材を集められるかだといった議論もありました。

コメントを残す