企業に導入される情報処理システムの構築費用の算出に使われることがいまでも多い「人月」。関係者の中には、この「人月」に疑問を感じてる方も多くいます。

一般に、雇用契約や委任契約、請負契約は、労務供給契約になります。人の労務について対価が支払われることになります。このようにみると、「人月」による算出については、ある程度合理性があるようにも思えます。また、この業界では下請負の使用が常にあるといえますので、このような事情も「人月」による算出と関連しているように思われます。

なお、請負契約は、仕事の完成を目的とする契約で、完成義務があります。請負人がこの完成義務を履行することによって、注文者にはその仕事の結果に対して報酬支払義務が生じます。

仕事の完成が目的で、それに対する報酬となるので、その報酬からは、労務供給契約でありながら、実際の人の労務内容との関係性において希薄になりがちと感じられます。

情報処理システムの構築費用として、ハードウェアや商用ソフトウェアなど、価格があらかじめ定まっている製品の導入が前提となることがほとんどでしょう。ただ、これらの製品自体の設定やチューニング作業は、人の労務になります。

また、ビジネスプロセス／ビジネスルール／ビジネスロジックや、ユーザビリティ、そしてそれらに合わせた前提製品とのインターフェース、などなど、作り込み作業がある場合も、人の労務になります。

このような作業の定量化／定型化、人の技量の考慮、作らない技術、などなど、「人月」という算出方法についての疑問を解消できそうな、いくつかの方法があげられます。

ソリューション（solution）は、問題などの「解決策」というような意味です。

また、「業務上の問題点の解決や要求・要望の実現を行なうための手段」のように説明されますが、その手段とは、情報システムを指す場合がほとんどのようです。

専門の業者（システムインテグレータ：SIer）などが顧客の要望に応じてシステムの設計を行ない、必要となるあらゆる要素(ハードウェア、ソフトウェア、通信回線、人員など)を組み合わせて提供するもののことをいいます。

とはいえ、情報システムが経営上・業務上のすべての問題を解決できるわけではないことは、いうまでもありません。情報システムを利用するほうが最善であるのか、人の思考・行動によるほうがよいのか、あるいは、両者を共存・分担させたほうがよいのか、といったようなことも実際には考えられているものと思います。

システムインテグレータは、情報システムを提供するのが業務ですから、基本的には情報システムの要件とそれ以外の要件を切り分けて、情報システム化に関する要件のみを進めていくのが役割と考えられている場合も多いようです。

モチベーションは、「動機づけ」と訳されるのが一般的ですが、わかりやすく「やる気」という意味にもとられます。何らかの達成に向けられた意思やそれにともなう行動と考えることもできそうです。

目的の達成のほかに、当初計画していなかったことからも達成を感じることがありえますので、モチベーションも、状況により、人により、といったようなことがいえそうです。

 

さて、マネジメントに関する書籍などでは、モチベーションの理論がよく紹介されます。代表的な３つの理論をちょっとみてみます。

 

マズローの欲求段階説

Ａ．Ｈ．マズローは、人間の欲求を、「生理的」、「安全」、「社会的」、「尊厳」、「自己実現」、のように低次から高次への５段階に分類しました。

そして、低次の欲求が充足される事により、高次の欲求へと移行するものとしています。

 

マグレガーのＸ理論・Ｙ理論

Ｄ．マグレガーは、人間についてＸ理論とＹ理論という２つの対立的な考え方を説明しています。

Ｘ理論は、「人間は本来怠け者で、責任を回避しようとし、放っておくと仕事をしなくなる」というような考え方です。

また、Ｙ理論は、「人間は本来勤勉で、進んで仕事を行い、自己実現のために自ら行動し、進んで問題解決をするし、責任を取ろうとするもの」というような考え方です。

 

ハーズバーグの動機づけ理論・衛生理論

Ｆ．ハーズバーグは、仕事に満足をもたらす要因と不満をもたらす要因は別のものであるとする考え方を示したものです。

満足をもたらす要因は動機づけ要因と呼び、この要因が満たされると満足度が高まりやすい、としています。

また、不満をもたらす要因は衛生要因と呼び、この要因が満たされていないと不満足につながる、としています。ただ、衛生要因が満たされても満足感やモチベーションが高まるものとは限らない、ともしています。

PMBOK®第３版では、「特定の納入日を守る必要のあるスケジュール・アクティビティに対して、共有している欠かすことの出来ない資源が、特定の期間または限られた量でしか利用できない状況において、プロジェクト作業の特定の期間にわたって特定の資源の使用を一定レベルに保つ場合」に、資源平準化が適用されると説明されています。

 

さて、次の問題を考えてみます。

 

問題：Ａプロジェクトにおいては、稼動開始日の厳守と短期開発が条件となっています。また、ある特殊技術の知識・経験も必須なため、Ａプロジェクトは、その知識・経験を有していて稼動可能なメンバーをできる限りすべて集めて結成されています。

資源平準化を行い、メンバー全員がまったく遊びのない状態でスケジュールを作成しましたが、このスケジュールでは稼動開始日に間に合わないことがわかりました。この場合に採用すべき工程短縮策として、最も効果が期待できるものは、次のうちのどれですか。

 

ア　クラッシング

イ　ファスト・トラッキング

ウ　生産性向上

 

 

この問題では、有限のメンバー（資源）の使用を一定レベルに保つ資源平準化が行われ、その結果、期日に間に合わないというものです。（一般に、資源平準化の結果、全体的なプロジェクト期間が延びる可能性があることがいわれています。）

 

まず、アのクラッシングについて。問題文からは、メンバーの追加は見込めない状況といえます。

特殊技術の知識のいらない補助的作業に、追加メンバーをあてることも考えられますし、期間中に教育することも考えられますが、問題文から短期開発であることから、どの程度スケジュール短縮につながるかというと、あまり期待できないかもしれません。

 

つぎに、イのファスト・トラッキングについて。資源平準化は、一般的にクリティカル・パス上の作業から優先的にメンバーの割り当てを行います。クリティカル・パス上の作業について、さらに並行作業が可能かどうかは、クリティカル・パス分析の精度によるところもありますが、これについてもあまり期待できないかもしれません。

 

最後に、ウの生産性向上について。どの程度の生産性を見込んでスケジュールを作成したのかにもよりそうです。高度な生産性であらかじめ計画している場合には、あまり期待できないかもしれません。ただ、所要時間について三点見積りなどの確率的分析によって、スケジュールを作成している場合には、可能性はあるかもしれません。

 

三点見積もりは、次の３種類の値から算出するものです。

 

最頻値 実現可能性が最も高いスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。

楽観値 最良のシナリオで実現されるスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。

悲観値 最悪のシナリオで実現されるスケジュールアクティビティの所要期間またはコストの見積り値（見込み値）。

 

三点見積もりについては、PMBOK®第３版では、主に、第６章のプロジェクト・タイム・マネジメントと第１１章のプロジェクト・リスク・マネジメントで取り上げられています。

一般に、次のような計算式が使われます。

 

 

この計算式は、ＰＥＲＴ（Program Evaluation Review and Technique）加重平均値を求める式にもなっています。

また、確率分布による定量的リスク分析において、ベータ分布が使われる場合も、上記の計算式となります。

 

ちなみに、三角分布が使われる場合の計算式は、次のようになります。

 

 

 

例題で確認してみます。

 

問題：あるアクティビティの所要期間について、楽観的見積りが２日、最頻見積りが４日、悲観的見積りが１２日でした。ベータ分布に基づく三点見積りによる見積り値は何日ですか。

 

 

 

スケジュールを短縮する手法として、クラッシング（Crashing）とファスト・トラッキング（Fast Tracking）がよくいわれます。

簡単な問題で、この２つの手法の特徴をみてみます。

 

問題：最小の追加費用でプロジェクト工期を短縮する方法として適切なものは、次のうちどれですか。

 

ア　クラッシング

イ　ファスト・トラッキング

 

答えは、ア。

 

クラッシングは、例えば、２人で１０日かかる作業項目について、要員を追加して５日で完了させるという方法です。PMBOK®では、「コストとスケジュールのトレードオフを分析し、最小の追加コストで最大の期間短縮を得る方法を決定するスケジュール短縮技法である。」としています。

 

問題：プロジェクトを予定より早く完了させる必要が生じました。アクティビティを分析して同時期に実施できるものについては、並行実施して期間を短縮する方法として適切なものは、次のうちどれですか。

 

ア　クラッシング

イ　ファスト・トラッキング

 

答えは、イ。

 

ファスト・トラッキングは、例えば、すべての設計書が完成する前に、共通処理等のプログラミングを実施するなどの方法があてはまります。PMBOK®では、「通常は順を追って実行するフェーズやアクティビティを並行して実行するというスケジュール短縮技法である。」としています。

 

なお、クラッシングについては、例えば要員追加によるコスト増、ファスト・トラッキングについては、手戻り増が考えられます。

工期短縮の手法については、手戻り減という点に注目した、フロントローディングやテストファーストをミックスした手法がとられることも多いと思われます。

 

 

プロジェクトの工期維持・短縮のための施策として、「フロントローディング」と、「テストファースト」という手法を耳にすることがよくあります。どちらも手戻りをなくすことによって、工期と品質の維持、または、工期短縮と品質向上を目的とする点で共通しているようです。

どのような内容の手法かというと、どちらもその定義はいくつか存在しています。

「フロントローディング」は、一般的には、「設計の前倒し」ともいわれています。

 

• 業務設計と平行して方式設計や運用設計などを行う。
• 業務設計の上流工程で下流工程での課題点をあらかじめ検証する。

 

の２点が「フロントローディング」の代表的な特徴と、わたしは思っています。ときには、設計と開発を平行して進行させる場合にも使われることがあるようです。

 

「テストファースト」は、テストを先行させることです。おもにアジャイル手法で解説されています。実際には、

 

• 実装コードのコーディングに入る前にテストコードのコーディングを行う
• コードを書く前にテストケースを作成する

 

のような内容で説明されることが多いようです。そして、プログラミングとユニットテスト（単体テスト）の工程を対象としていることが多いようです。

 

「テストファースト」については、結合テストやシステムテストの全テストケースについても、プログラミング前に作成して公開する、とういうような取り組みがあってもいいのではないかと思うことがありました。上流工程で作成する設計書だけでは、具体的事例との整合についての表現が乏しくなりがちと思われます。このようなことによって発生する手戻りや障害を事前になくすことができるのではないか、と考えられます。

 

多くのプロジェクト計画書では、ソフトウェアテストの各段階ごとに完了基準を数値的に設定しておくことがほとんどだと思います。テスト項目数とバグ数について、その数値的基準を、ステップ数あたり何件とか、仕様書のページ数あたり何件とか。これらは、過去の経験値から設定されたり、会社の指針から設定されている場合が多いと思います。しかし、これらはあくまでも目安で、テスト仕様書が完成するまでは、実際の数字が確定しないこととなります。

 

テスト工程をはじめるにあたって、テスト推進チームが発足するなどして、テスト作業の体制やルールなどの標準化などをすすめていくわけですが、このテスト推進チームにおいてもテスト項目数や目標検出バグ数の見積り、その妥当性の判断の指針の決定は重要な作業で、詳細スケジュールの決定にも関係してきます。

 

ソフトウェアテストの最初の段階となる単体テストでは、ロジック網羅、条件分岐、限界値・代表値などのテスト内容を実施して、そのすべての消化が単体テストの完了基準となることが多いと思います。

その次の段階の結合テストで、最初から動かなくてテスト項目が消化できない、そして結合テストのスケジュール遅延ということがよくあったりします。

このような結合テスト初期段階のつまづきを予防するために、単体テストの後半に、結合テスト的な項目を２０％から３０％含ませるなどして、あるいはプレ結合テストというような形で実施して、次工程となる結合テストの実施可能性を判断して、単体テストの完了とするというようなことを行うこともあると思います。

そして、この実施方法をもとにすると、結合テストにおいてもシステムテスト的な項目の一部を実施し、そして、システムテストにおいても受入れ・運用テスト的な項目の一部を実施するということになります。

 

現実的な完了の判断は、このような現テスト工程の状況についてアセスメントを実施して、次のテスト工程へ進むかの判定会議によることになるかと思います。

このアセスメントや判定会議では、テスト項目の内容分類と消化数、バグ発生原因分類や発生状況の推移、バグ対応状況の推移などの統計もカギとなります。

テスト項目数は、有用な統計にするための根本的な数字ですから、それなりに相当な数が必要だと思います。ただ、テスト項目数は、スケジュールや要員にも直接関連しますので、妥当数を判断することが重要となります。

 

なお、テスト項目は、全テスト工程を通して全網羅を目指さなければならないと考えます。トップダウン的にみれば、各テスト工程は、この全網羅を段階的に配分しているわけで、その配分に見合っている必要があると思います。

 

さて、結局のところ、実際のテスト項目数は、テスト直前にならないと明確にならないようです。

ただ、ウォータフォール型の開発によれば、要件定義が終われば、その人員は運用テストの準備に、また、システム設計が終われば、その人員はシステムテスト、結合テストの準備に取り掛かることに理論上なっていますので、必ずしもテスト直前にならないと明確にならないわけでもなさそうです。

さらには、設計書にシナリオを作成することもよくあります。このシナリオが後のテストケースとして利用されることを考えれば、シナリオからテスト項目数を見積もることもできるそうです。

 

バランススコアカード（BSC : Balanced Score Card）は、経営業績評価の手法のひとつです。

バランススコアカードの特徴といえば、「財務の視点」、「顧客の視点」、「業務プロセスの視点」、「学習と成長の視点」の４つ視点において、目標と戦略を明確にし、評価するというような手法であることです。

おおまかな手順としては、それぞれ４つの視点から、

 

1. 具体的目標を設定
2. 重要成功要因（KSF : Key Success Factor）を抽出
3. 重要業績達成指標（KPI : Key Performance Indicator）を設定
4. アクションプランを策定

 

というものです。

説明によっては、重要目標達成指標（KGI : Key Goal Indicator）を設定したり、用語について重要成功要因（CSF : Critical Success Factor）とあったりします。おそらく、自由度の高い評価フレームワークであるということなのでしょう。

それぞれ４つの視点について、もう少しみてみたいと思います。

「財務の視点」：直感的にイメージしやすいのは、「利益」、「売上」、「コスト」だと思います。財務的な成果が対象となります。

「顧客の視点」：これについても直感的にイメージしやすいのは、「顧客満足度」だと思います。「有用性」、「品質」、「価格」などが思いあたります。あるいは、「シェア」、「市場成長」などもこの視点にあたります。

「業務プロセスの視点」：意外と直感的に定義しにくい視点と感じます。個人的な理解として、事業や業務の運営・運用について、「開発（実用化といったほうがしっくりいくかもしれません。）」→「改善（悪いところを改める。まれに、よりよくするという場合もあるかもしれません。）」→「改革（改めて変える。）」→「革新（旧来の方法を変えて新しくする。イノベーション。）」といったような視点なのだろうと思っています。

「学習と成長の視点」：「学習」から直感でイメージできるのは、「（技術・知識）習得」、「研究」。「成長」からは、「発展」、「進化」、「増大」、「成熟」など。また、具体的な例示として「社員のモチベーション」などがあげられています。

これら４つの視点の内容をみてみると、いうまでもないかもしれませんが、それぞれの内容について非常に関連性が強い、つまり、要因（原因）・結果の関係でつながることがわかります。このことも、バランススコアカードの特徴といえると思います。

バランススコアカードは、SWOT分析（内部環境の強み(Strong)・弱み(Weakness)、外部環境の機会(Opportunity)・脅威(Threats)を分析）や、PPM分析（市場占有率と市場成長率から、金のなる木・花形・負け犬・問題児の４つに分類して分析）というような分析手法とあわせて用いられることも多いようです。

 

 

これまで、情報処理技術者試験の午前試験問題で、ＲＡＤ（Rapid Application Development）の特徴を問うものが何度か出題され、なんとなく印象に残っています。いずれも「タイムボックス」の説明が正解となっています。

ＲＡＤ（Rapid Application Development）とは、部分的に定義された要求から開発を開始し、後続する開発で要求を見直していく開発手法で、プロトタイピングを繰り返して完成させていきます。

プロトタイピングを繰り返す手法として、スパイラルモデルがありますが、ＲＡＤにおいては、「タイムボックス」を設定することに特徴があります。「タイムボックス」は、スパイラルモデルで懸念される無制限の繰り返しを防ぐために、開発期間をあらかじめ定めることを意味しています。

ちなみに、ＲＡＤの特徴をあらわすキーワードとして、他に「ワークショップ」があります。「ワークショップ」は、ユーザを含めてすべての関係者が参加し協力するということを意味しています。

 

ところで、アジャイル開発関連の書籍を読んでいると、ＲＡＤのことばがでてきます。ＲＡＤを起源とするＤＳＤＭ（ダイナミック・システム開発方法論）の説明のためです。

アジャイル開発において、「反復」または「繰り返し」をあらわすことばとして、イテレーション（iteration）が使われています。

そして、イテレーションの「タイムボックス」化と、その「タイムボックス」化したイテレーションの終了日の厳守を重要としています。なお、「タイムボックス」の終了日までに予定していたスコープのすべてが実現できないときは、終了日までに実現可能なスコープまでに縮小して完成させ、いかなるときも作業ペースを一定に保つことを重視しています。

関連して、ＲＵＰ（Rational Unified Process）が有名です。イテレーションを、方向づけ、推敲、作成、移行、の４つのフェーズに体系化している点が特徴です。ＲＵＰにおいては、「タイムボクシング」ということばが定義されています。

「タイムボクシング」は、最も重要な任務の目標に注力し、開発のトレードオフを発生させないようにするための構造を提供します。不可能あるいは不合理な目標を設定したり、「タイムボックス」の中で粗悪な品質のものを提供しようとするわけではありません。（『ラショナル統一プロセス≪ＲＵＰ≫ガイドブック』より。）

「タイムボックス」は、確実に、高い精度が求められてきています。