December 19, 2004

スケジュール作成のスケジュール

しばらくバタバタしていて間が空いてしまいました。。

さて、今日は2つのスケジュールについて記述します。
2つといっても、表と裏という類のものではなく、
プロジェクトを進めていくために必要な次元の違う2つのものを指します。

 ① メンバが作業をするための日程や作業内容が記述されているもの
  (例.プロジェクト全体スケジュール、設計作業スケジュール、テスト計画..)

 ② ①のスケジュールを立てるための段取り
  (例.全体スケジュール立案の段取り、テスト計画作成の進め方..)

過去の蓄積やシステム開発の教科書もたくさん出ていることもあり、
①のスケジュールについては、
ほとんどのプロジェクトで作成されているように思います。

しかし、あくまで教科書通りのものが多く、
プロジェクト毎の事情を十分に反映できておらず、
その結果、スケジュール通りに進められないプロジェクトが
多く発生していると感じられます。

大事なのは、②のスケジュール。
妥当なスケジュールを作成するための段取りが極めて重要なのです。
具体的には、以下を確認するための段取りが必要となります。

 - 作業に必要なインプット情報はいつ頃揃いそうか
 - 作業をする人員の確保/スキルの充足は大丈夫か
 - 当該作業はいつまでに、どういったアウトプットを出すべきか
 など

これらはプロジェクト毎に様々な事業があるため、
これらを調整をする方が、①のスケジュールを立案するよりも、
一層難しいものだと考えます。

| | Comments (0) | TrackBack (0)

December 02, 2004

プロトタイプと総合テスト

結合テストがシステム要件の総確認だとすると、
総合テストは業務要件の総確認のための作業と位置づけられます。

では、業務要件の設計作業はどこで行うかというと、
パッケージシステムの場合は、プロトタイプとなります。

プロトタイプは、
業務要件の洗い出しとシステム要件への落とし込みを行う作業であり、
この作業の過程で「プロトタイプ・シナリオ」を作成します。
会社の業務を「プロトタイプ・シナリオ」にまとめた後、
そのシナリオに沿って、
業務要件がシステム要件に反映されているかを確認していきます。

さて、総合テストでは、どういうことを行うかというと、
極めてプロトタイプに近い作業を行うこととなります。
業務要件を網羅的に洗い出した後、
それを確認できる「総合テスト・シナリオ」をまとめます。
そして、そのシナリオに沿って、
業務要件がシステム要件に反映されているかを確認していきます。

つまり、プロトタイプと総合テストは、極めて強い関連性を持つのです。

総合テストでは、テストシナリオの洗い出しが、
品質を担保する重要なタスクとなりますが、
プロトタイプ時に十分なシナリオの洗い出しが行えていると、
それをもとに比較的短期に、かつ品質の高いものを
作成することができると考えます。

| | Comments (2) | TrackBack (0)

December 01, 2004

存在感を発揮する

全てではないと思いますが、
プロジェクトにおいて、PMOや経営層へ食い込む会社は、
自分の「存在感」を高めることをとても大事にしているように感じます。

プロジェクトをうまく遂行するだけであれば、
各人が自分の役割をきちんと果たしておけば良いように思いますが、
それだけに留まらず、
自分の「存在感」を高めることに異常なまでに力を注ぎます。

最初は、私も違和感があったのですが、
今は、そういった振る舞いにも価値があるのだな、
と思うようになりました。

理由は、PMOで仕事をしたり、経営層へ食い込むためには、
「頼りになる奴」という印象を作っておく必要があるからです。
そして、その第一歩が「存在感」を出していることなのです。

あまり前面に出すぎると、
嫌味となり、かえって逆効果となってしまいますが、
そういったことを意識しておくことが、
大きなプロジェクトを運営するうえで、また、
経営層へのパイプを作るうえで大切なのだなと思います。

もちろん、中身があることが前提ですが。。

| | Comments (0) | TrackBack (0)

November 30, 2004

方法論のその先

方法論が注目され始めてから随分と経ち、
今では、プロジェクトにおいて、方法論を用いることが一般的になってきました。

ただ、方法論をきちんと使いこなしていない例も多く見受けられます。

 - 方法論はあるものの、成果物を参照するくらいで、手順等は参照していない
 - SIベンダ側は方法論を用いているが、業務ユーザ側の理解が十分でない
   など

方法論を適用するには、
単に、方法論の体系と成果物を説明するだけでは十分ではありません。
なぜなら、方法論には全てが文字として記述されている訳ではなく、
方法論を利用するための暗黙の了解や前提条件があるからです。

そのため、新しい方法論を初めて利用する場合は、
その思想や前提条件を十分に理解する時間が必要となります。
具体的には、次のようなことが必要になると考えます。

 - その方法論を利用した経験が豊富で熟知している人がナビゲートすること
 - 方法論の必要性、適用時の課題などを関係者全員で共有化すること
 - 方法論を定着化するためにパイロットを設けること

| | Comments (0) | TrackBack (0)

November 22, 2004

意見対立は思っているよりも小さい

立場の違いや利害関係により、意見が対立することはよくあることです。
プロジェクト事務局から各チームへの依頼に対して、
事務局としては「当たり前だろう!」と思っているにも関わらず、
各チームが猛反発することもよくあります。

ただ、私の見る限り、
実は両者の主張に大きな隔たりはないことが多いように思われます。
多くの場合、感情的なもつれ。例えば、
「分かっちゃいるけど、出来ないんだ」「こっちの事情も分かってくれよ」
という気持ちが背景にあるのではと感じています。

つまり、皆、内心は「それが必要だ」と思っていることが多いのです。
別の言い方をすれば、ある人が直感的に必要だと思うことは、
表では反発するものの、他の人も必要だと認識するケースが多いということです。

そういう時は、「一緒に障害を取り除きましょう」という姿勢で歩み寄り、
感情的なものを除いてあげることが有効です。

まずは、相手の言い分をよく聞いて、問題状況を明確化すれば、
課題が実際には小さいことがわかり、
お互いに、それほど妥協しなくても、折り合えることが多いかなと思います。

| | Comments (0) | TrackBack (0)

November 21, 2004

準備作業の見積

プロジェクトのスケジュールを立案する際には、
各作業の見積を行いますが、準備作業については忘れがちです。

開発やテストそのものの作業は忘れずに見積もりますが、
開発作業に必要な開発標準・成果物サンプルの作成作業については、
忘れられていることが多いです。

しかし、準備作業は意外に工数が掛かるものです。
他のプロジェクトの成果物などを流用することが多いものの、
プロジェクト毎に事情は異なるため、
そのプロジェクトの実情に合わせたアレンジを行う必要があるのです。

また、各作業を開始するためには、
その開始条件を満たす必要がありますが、
それが明確になっていないことも多く、
開始条件を揃えるために想定以上の時間が掛かってしまうこともあります。

そのため、工数を見積もるためには、
その準備作業や開始条件を満たすための作業も含めた
見積を行うことが必須と考えます。

| | Comments (0) | TrackBack (0)

November 20, 2004

プロジェクトの目標効果

どのプロジェクトでも、最初の段階で、
システム導入による目標を定義し、実現に向けて活動を行います。

しかし、設計・開発・テストと進むにつれて、
多くのプロジェクトで、スコープの見直しがあり、
プロジェクトの目標よりも、
とりあえずシステムを運用開始することが優先されるようになります。

そして、その場合、スコープの見直しにより、
どれだけの効果が削減されるのか見極める作業は行われません。

これらを防ぐためには、
プロジェクトの効果目標を定義するとともに、
それを実現するためのシステム機能を明確化しておく必要があります。
つまり、目標効果に対応するシステム機能を紐付けておくのです。

これには、以下の区別も付けられるメリットがあります。

 - プロジェクトの目標に直結するシステム機能(MUST)
 - ユーザの利便性などで設けられたシステム機能(WANT)

そして、スコープ変更や仕様変更があった場合には、
これらの一覧表をもとに、目標効果にどのように影響するかを試算するのです。

| | Comments (72) | TrackBack (0)

November 19, 2004

都合の良い問題提起

課題の整理に慣れていない人の中には、
自分の都合しか考えず、問題提起をする人がいます。

■よくない例

 営業システムチームから
 「設定変更を行うので、テスト環境を2時間だけ利用中止としたい」
 という要求があった。

 しかし、この要求を受け取ったテスト環境の管理者は、普段から
 「テスト環境の管理は、テストチームの自分ではなく、インフラチームが行うべきだ」
 と考えていた。

 そこで、このテスト環境の管理者は、営業システムチームからの要求を口実に、
 「営業システムチームから申請があったが、
  そもそも、テスト環境の管理は、インフラチームが行うべきだ」という説明資料を作成し、
 課題会議に付議することとした。

■よい例

 この場合、まずは、申請をしてきた営業システムチームに応えてあげる必要があります。
 テスト環境管理者がどう思っていようが、
 実態としては、各チームの窓口となっているわけですから、これに応える義務があります。

 そこで、説明資料としては、こう書くべきだと考えます。

  1. 「営業システムチームの申請により、2時間システムを止めます」
    ⇒ まずは、申請に応える (短期的対応)

  2. 「しかし、本来はインフラチームが行うべき作業であり、
    今後はインフラチームでの対応をお願いしたい」
    ⇒ 次に、常々伝えたいと考えていたことを説明する (長期的対応)

 チームの役割分担については、調整に時間の掛かる事項ですから、
 短期的には、申請に応えつつ、
 長期的に、大きな課題に対応するといった話の持って行き方が必要になると考えます。

なお、課題をきちんと整理して考えられるかは、
課題を順序良く解決するというだけでなく、
プロジェクトをうまく進めていくために不可欠な能力だと考えます。

| | Comments (3) | TrackBack (0)

November 18, 2004

総合テストシナリオの作成方法

総合テストのシナリオ作りは、システムの品質を保証する最後の砦です。
にも関わらず、人間の勘に頼ったものが多いように思います。

本当であれば、業務要件のバリエーションに基づき、
それを網羅するようなシナリオのバリエーションを用意すべきです。
しかし、大抵は、業務要件を一番押さえてそうな代表者数人により、
「これくらいやってれば大丈夫かな」といった具合に、
とりあえず思いつく限りのシナリオを洗い出してみるという場合が多いです。

その場合、シナリオの網羅性は、
シナリオ作りに参画してもらう人に大きく依存してしまいます。
小さなプロジェクトの場合は何とかなることが多いですが、
大きなプロジェクトの場合に
気の利かない人・全体を押さえていない人が担当してしまった時は、
大変な結果になると容易に予測できます。

では、どうするべきか。
業務要件定義を行う際に、なるべく業務のバリエーションが分かるように、
業務機能一覧を作成することが有効です。

 ■業務機能一覧を作成する
  1. 全社業務の概念図を描き、まずは業務プロセスを大きく分割する
  2. 分割された業務プロセスに基づき、レベル感が統一されるように業務機能を
    一覧化する
  3. 業務機能に対し、取りうるバリエーションを記述する

 ■業務シナリオを追記する
  4. 複数の業務機能をまたぐ大きな業務シナリオを洗い出す
  5. 洗い出された業務シナリオに対し、関連する業務機能をチェックしマトリクスを
    作る

 ■ユーザによる確認を行う
  6. 完成した業務機能一覧を関連するユーザにレビューしてもらう
  7. 必要に応じて、ERPなどの場合は、業務シナリオをもとにプロトタイプを実施する

上記の作業により作成された業務機能一覧により、
網羅的に業務のバリエーションを押さえることが出来ると考えます。

| | Comments (1364) | TrackBack (0)

November 17, 2004

体制の作り方

プロジェクトを推進していくためには、
体制をしっかり定義することが大切です。

しかし、多くのプロジェクトで、
「体制はこうあるべき」という考え方に縛られて、
個々の実態に合った体制となっていない事象が
見受けられます。

大切なのは、必要な機能が有効に働くような環境を
整備することです。

例えば、「仕様調整の機能」について。。

絶対にここに配置すべき!というものはなく、
プロジェクト管理事務局の直下にあるチームに置くか、
アプリケーション設計チームとして独立したチームとするか、
いくつかの選択肢があります。

個々のプロジェクトの事情に応じて、
このチームのリーダはしっかりしている、
このチームに情報が集まりやすい、などの理由で
決めるべきものだと考えます。

| | Comments (0) | TrackBack (0)

その他のカテゴリー

SE