ICTで、地域とシニアの元気と活き活きを応援します!

自治体のICT

自治体のICT

はじめに

 今まで、開発手やプロジェクトマネジメントは、主に開発者側(例えばシステム開発の受注者側)の立場から、発注者の仕様に従い、納期までに機能、品質の確かなものを提供するにはどうすれば良いかの観点から語られることが多かった。しかし、実際には開発作業は様々な関係者で成り立っていて、特に発注者の協力が極めて重要である。
 このため、実際に開発する側の観点のみならず、発注者の観点からのプロジェクト管理も非常に重要といえる。システム開発プロジェクトは目に見えないものを構築するだけに予期せぬ出来事が起こることも多々あり、危機や難局を乗り越え、当初目標どおりにシステムを仕上げるためには、発注者、受注者双方がプロジェクト進捗の確認、作業計画の作成・調整、関係者の意識共有など、日々のマネジメント業務が不可欠である。
 発注者側がシステム開発に大きく関与するケースに関し、どちらかというと発注者側の視点にたち、開発業務を進める上で重視すべき考え方や事項についてまとめた。プロジェクトを成功に導くためにマネージャーは何に着目し、どうすべきかをとりまとめた。

1.自治体が内包するシステム化の阻害要因

自治体が抱えるシステム化のマイナス要因として、
① 一般的に職員の人事異動サイクルが3~5年程度と短く、ユーザーである業務担当職員は、端末操作による日々の業務処理に精一杯で本来身に着けるべき業務スキルが体系的なノウハウとして身につきにくい。また、情報部門においても、システムの運用に追われ、業務改善のための広範な専門知識の取得が難しい。
② 本来業務知識やシステム化の背景として端末操作によって回答が得られる業務スキルがファンクションキー操作に転化し、業務に必要とされる本来の知識が希薄になりつつある。
③ 法令改正等による外的要因によってシステムが毎年次変更を余儀なくされることが多い。
ことが挙げられる。
①②については、小規模な組織では業務全体が見渡せるため問題は比較的発生しにくい。これに対して大規模な組織では、組織が拡大し業務が細分化した現状では、ある特定の職員が全体的な把握をすることは困難になりつつある。また、システム開発担当者も同様の異動サイクルとなっていることから、担当者が入れ替わるごとに業務品質が変動しやすい。
加えて、③の要因により、業務及びシステム運用に必要な手順書・マニュアル類の整備が不十分となり、極端な例では個人ごとにローカル・ルールができ顧客たる住民に均質なサービスの提供が困難になることもある。
結果として、職員ごとに必要な機能が異なったり、複数年に渡るプロジェクトでは人事異動で担当者や上司が代わったとたんに同意されていた機能要件が振り出しに戻ることも決して稀ではない。そのため妥協の産物として機能がいくつも追加され、システムの複雑化、運用管理の難しさを増大させ、プロジェクトも当初予定の工数を大きく上回ることとなり、日程計画が破綻することになる。
ページのトップへ

2.システム肥大化の要因

前回、BPRの視点でのシステム構築を話しましたが、システム肥大化の要因として図1のように本来システム化になじまない、業務マネージメントの一部や本来の業務ではあるが、極めて稀なケース、基準が定められていないケース(条例や規則で「特に首長が認める場合」等)も含めてシステム化の要望が業務担当課からだされることが多々あります。
例えば、業務マネージメントでは年に1~2回しか出力しない統計資料(クロス集計ごとに何種類も)とか、業務では年に1~2件程度の例外的な案件といったものです
いずれにしても、最初にシステム化の範囲と範囲を決める基本的な方向を十分検討しておく必要があります。

図1: システム化の範囲は費用対効果で検討
画像の説明

図2:肥大化したシステムは、管理運用にも影響が
画像の説明

このためには、要件定義や機能要件を検討する以前に現在の業務を詳細に洗い出しておく必要があります。一般的にいわれる業務分析ですが、難しく考える必要はありません。次のような方法でも十分に問題点が見えてくるはずです。
 ①1年間の業務の主な作業を時系列に書き出す。
 ②同様の作業を半年単位、四半期単位、1ケ月単位、1週間単位と単位区切りを短くしながら行い、段階的に詳細な記述をする。
 ③最後に1日の業務の内容を時系列に書き出す。できれば、作業項目単位で使用した帳票名も書き出し、現物も取り揃える。
この表をEXCEL等でつくり、プロジェクターで拡大投影しながら関係職員で議論するだけでも多くの課題が見えてくるはずです。
ページのトップへ

3.プロジェクト管理のポイント

 マネジメント業務は大変人間臭い仕事の側面をもっている。しかし、その努力が結実せず、不幸にしてプロジェクトの運営がうまくいかなくなることがある。具体的には、プロジェクト運営の問題は下記のような現象となって現れてくる。
・マネージャーが全体像(進捗や品質)について第三者に判るように説明できない
・問題が解決可能な具体的な課題に変換されない
・課題解決の期限が何度も修正される等
 このような状態に陥らないようにする、または症状を早く発見するために、開発責任者やマネージャーが守るべき原則がある。
 仕事を他のメンバーや委託先に依頼しているにもかかわらず、出来不出来の責任の半分は自分にある(つまり発注者側にある)、という見方である。

(1)出来の悪い仕事の責任の半分は発注者側にある

 仕事を委託された側は発注者のオーダーに基づいて作業を行い、経過や結果を報告し承認を経て仕事を完成させる。発注者は仕事の成果と引き換えに委託料を支払うことになる。この過程で発注者にはマネジメント責任が発生する。発注者は、委託先の選定/仕事の内容提示/仕様の規定/進捗の把握/修正のオーダー/結果の評価など、仕事を完成させるためのキーとなる重要な行為を担当することになる。よって、それらの行為が適切に実行されないと、システム開発の方向や進捗が遅れ、プロジェクトの成功がおぼつかなくなるのは当然といえる。
 大きなプロジェクトなどで仕事の委託関係が階層化されている場合でも、各階層で発注者としてのマネジメント責任が生じる。
 委託関係が階層化された場合、各階層の担当者にとって重要な原則がある。その原則とは、「①開発プロジェクト責任者以外の課長や発注者側の担当者は、職務上の権限は限られている、②一般には仕事を任された形になっていても、開発の基本条件(発注会社と委託先の基本条件)に抵触する事項については判断情報を上位マネージャーに報告し、その都度、判断を仰ぐ義務がある」ということである。当たり前のことであるが、コスト、納期、影響範囲の大きい仕様変更の可能性等が予想される場合は速やかに報告し、判断を仰がねばならない。
 一方、発注者側の開発責任者は各階層において前述の原則を自組織内のメンバーや委託先に浸透させることが重要となる。しかし表面的には理解を示してもなかなか行動の伴わない人間が必ず存在するものである。実際には、このような人がいることを前提にプロジェクトの運営を行なうことになる。以下は、ひとつの例である。

例1:企業グループなどの仲間内だけで仕事をしてきた組織や人は、以心伝心で仕事ができると勘違いし、あいまいなオーダーと報告で仕事を進める傾向がある。この場合、結果が出た時点でオーダーと差に気付き大きな手戻りを生じさせる危険がある。
例2:他組織や他社との業務取引の経験の少ない人は、契約という概念や指示(業務命令)という概念がなかなか理解できず、上位マネージャーの指示を軽視したり、感情面の人間関係を重視するあまり委託先へ契約上必要な指示が出せない場合がある。

 この例に示すような組織や人に限って自分の責任範囲を矮小化し、仕事がうまく進まない原因を委託先のせいにすることがあるように思う。ただし、一般的には悪意でなくビジネスやマネジメントの基本を知らないことから生ずることなので、発注者側の開発責任者は委託先から報告を受けた際などに説明を注意深く聞き分けて、委託先の力量、責任感などを掌握した上で、必要に応じて是正措置を講じなければならない。
 一人ひとりが自分の職務をわきまえ責任を自覚しているプロジェクトは、問題が発生しても機動的な動きができるようになるので、意識的にそのような状態にプロジェクトを近づけてゆくことが、開発責任者のポイントの一つである。
ページのトップへ

(2)システムは正直である

 システムの仕様定義や設計に曖昧な部分を残したまま開発を進めると大きな手戻りを発生させたり、最悪の場合は機能の矛盾や処理方式の欠陥が原因でシステムがまともに動かない事態を招く。このような問題を防止するため一般的にシステム開発では作業の手順を「工程」に分割し、工程毎の達成確認をしながら、次の工程へ進むという方法をとる。
 工程終了判断のために、開発プロジェクトで定めた手順の中に(例:各種手順書や開発実施要領)チェックリストや判断指標が示されているのが普通で、発注側と委託先のメンバーで構成される管理チームは、それらを利用して判断を行なうことが基本となる。
 また、開発作業では、不測の事態が発生することが稀ではなく、標準的な指標が使えないこともある。その場合は、複数の経験者の意見を求めて判断する。
 好ましいことではないが、現実には当該工程で達成すべき目標に到達できていないが、全体の作業を進めるために工程終了の判断をしなければならないことが起こる。この場合、未達成事項を担当者との間で明らかにした上で、その対策を検討する。
 ひとつの例として、遅れを次工程で回復させることを条件に当該工程の終了判断をする場合、新たな作業スケジュール、達成条件、追加人員の投入の有無などをチェックし、課題管理の対象とする。
 工程終了判断時の委託先の報告において、よく見かける傾向として下記がある。
①委託先の開発会社は立場上、達成度が高いという判断に偏りがちである。
②未達成事項の先送りを主張する場合、その問題自身が矮小化されて扱われている場合が多々ある。
 未達成事項を先送りする場合は、付帯する問題の有無も確認し、全体計画への影響の程度をその都度必ず判断する。これは、当事者にとってみれば次工程の作業が苦しくなるのが判っているので時として実態を直視せずに問題を矮小化したり、さらなる先送りを主張することがあるからだ。実際には委託先の事情を聞くともっともなこともあるので状況を考慮しながら対処するが、このようなことを安直に受け入れ始めるといろいろな矛盾が拡大され、あとでツケが廻ってくる。
現状を言葉では言いつくろえるがシステムは嘘をつかない。再発するリスクを大きくしないため、発注側の開発責任者は委託先とよく話し合って計画的な回復の方策を見つけることが大切である。

(3)マネージャーは常に開発状況を把握すべし

 開発責任者や各マネージャーは、進捗などの状況を確認するために定期報告を求め、それをチェックする。また、各工程の終了判断をするために工程の後半で、開発状態や完了見込みに関する報告を求める。さらに、定例の報告以外に適宜メンバーや委託先からの意見も聞き、プロジェクト運営に反映してゆく。
 委託先の開発会社は立場上、達成度が高いという判断になりがちで、発注者側の責任者も委託先からの報告を鵜呑みにしたり、楽観的な判断を積み重ねて問題発見の機会を逸してしまうことがある。
 実際の開発作業では、本来発注者自身が行なわなければならない業務を委託先に代行してもらう場合もある。この場合は、委託先からの報告のみを信じ、その報告の裏付けデータに目を通すのを怠ると、後で重大な問題を招くことになる。本来早期に発見できる問題が発見されないで、システムの内部に矛盾を抱えたまま作業が進行し、サービス開始時期を変更せざるを得ない等の事態に発展してしまう場合もある。
 委託先に楽観的判断の傾向が認められる場合は、発注側の責任者はあえて慎重に解釈し、バランスを保った現状認識が必要である。
 さらに、各工程終了時の達成確認や報告チェックに関連して重要な事項として、「事実確認」がある。開発状態に関する報告に関しては、報告内容が「事実」であるかどうかをマネージャー自らが確認する義務がある。一般的には、意見などを事実状態と分離して報告してもらえば判別できるので、定期報告の様式や工程別の成果報告様式に反映させておく。
 しかし事実と規定した報告に関しても、人の目を通して認識・報告されたものであり、事実と期待や予想が混在している場合もあり、いろいろなノイズが含まれていると認識する。
  以上述べたように、状況把握の遅れはマネージャーの責任であり、状況把握には事実を確認することが重要であるとの認識をもって、各種報告を捉えることが必要である。
ページのトップへ

(4)「そうであることの確認」と、「そうでないこと」の確認

 仕事の進み具合や状態を確認する場合、期待していることに関して現状はどうか、というチェック形式を一般的にとる。ルーチン的な業務ではこれでだいたい事足りるが、システム開発のマネジメントでは確認がこれでは十分とはいえない。
 開発状態をバランスよく見極めておく必要がある。問題を早く発見したり、それ以上大きくしないためには
・期待したくないこと(付随する問題)の状態はどうか
・問題(目標と現状とのギャップ)に対して取り組むべき課題は何か
という観点でも継続的に状態を把握することが必要である。継続的にモニターしていると「変化」に気付くので、問題が小さいうちに発見できるという大きな効用がある。
 対象物の認識方法にそうでない場合の観点を加えることによってそうあるべきことsを再認識させる効果もあるので、曖昧性や漏れを低減するのに有効である。
そうでない場合の内容を発見する(隠れていることに光を当てる)こと及びその事象への対応は、開発責任者、マネージャーの重要な仕事である。発見したら課題を確認するとともに、作業計画の修正やリソースの調整が必要かどうか必ず点検する。放置するとシステムは矛盾を正直に抱えたまま作り上げられるという事実を常に念頭におかねばならない。
ページのトップへ

4.「開発作業計画」と「進捗管理」

(1)開発作業計画の策定

 マネージャーの重要な仕事のひとつに作業計画の作成・承認がある。その作業計画を作る際の重要なポイントとして下記の3点がある。
1)開発物の構成要素及び開発プロセスに着目し工程を組み立てる
 実際の開発作業では、本来発注者自身が行なわなければならない業務を委託先に代行してもらう場合もある。そうすることで開発管理作業を効率的に実施できる場合もあるという理由による。これは、開発作業計画を自ら作成する場合も、委託先に作成代行してもらいそれを承認する場合にも当てはまる。
 委託先に開発作業計画の作成を代行してもらう場合、委託先からあがってきた開発作業計画案を、リソース裏付けの確認なしに鵜呑みにしない。
開発作業計画が、仕様策定・調整、ソフト設計、デバッグ、テスト準備、ハードウェア工事、ネットワーク工事・設定、テスト、システムテスト、移行、運用試験等の工程毎に紙の上ではもっともらしく報告され、そこには疑いの余地もないように思えることがよくあるが、発注者側としては詳細にわたりチェックしなければならない。
 作業対象を開発物の構成要素と開発プロセスの両面で漏れなく拾い出すためには、プロセス資産(各種開発作業標準、チェックリスト、レビューリスト等)や過去の作業記録を参考にして、抜けや作業の並行性/同期性などに問題がないかどうかチェックする。
 またプロセスの中には重要な会議(定例会議や工程終了承認会議など)を盛り込むことも忘れてはならない。
ページのトップへ

2)各工程を実施するための所要資源(以下リソース)を明らかにする
 第2のポイントはリソースの裏付けを得ることである。リソースの裏付けのない計画は、単なる願望に過ぎないといっても過言ではない。
ここで、リソースとは人間の工数、作業時間、作業場所、検証環境、作業用資材(例えば、試験用端末、試験用ID 、試験用のデータ類)などを意味する。作業の実行途中で何らかのリソース不足が判った場合、通常、その手当てに時間がかかることが多い。
 リソース不足が頻発すると、その再準備や調整に時間がかかり、致命的な問題へと発展していく。必要な量はいくらか、無理なく調達できるか、などを十分吟味した上で計画を決定する。
 計画策定は、「悲観的に準備し、楽観的に実施する」の原則に則り、悲観的にトラブル発生なども想定して策定する。
 計画の安全性を高めるには、机上シミュレーションも欠かせない。個々の作業対象に対してリソースを数値や固有名詞で割り当ててみて、作業が計画どおり進むケースやトラブルが発生するケースで、リソースが消費される姿を経験者も参加してシミュレートしてみる。これを何度か繰り返すと、リソースの競合回避やマージン設定の仕方が判る。
 また、計画は書面化するとともに基本的な要素は定量化し、数字で表現しておくことがポイントである。
ページのトップへ

3)各工程には実行フェーズに先立って必ず計画策定フェーズを設定し、計画策定フェーズにも人的リソースを割り当てる
 第3番目のポイントは、このような計画策定作業に対しても人的リソースを見積もっておくということである。頭では計画策定作業の稼動について理解していても、開発期間の短縮や工数の縮小等の理由から、計画策定に関するリソース割付が軽視されることがよくある。
 開発側が入れたくても、発注者側の理解が得られないという場合もある。小規模な開発においては目立たない作業であっても、開発規模が大きくなればなるほど、この計画策定作業、シミュレーション作業が重要になってくる。

4)計画の骨子は工程実行の前に完成させる
 開発作業では大規模になればなる程周到な準備が必要であり、計画の骨子は事前に書面化し、メンバーと共有しておくことが大切である。
 実行時の狂いを小さくするために計画段階で仕事のシミュレーションを実施するが、思い通りに進まなくなるのが常で、工程の途中で計画の修正が必要になる。
しかも修正を素早く行なわないと関係者の待機や関連作業との同期合わせのための時間や調整稼動が時間の経過とともに増加する。
 準備を疎かにし、そのときになって一からやり始めるとマネジメントネックによる中断や迷走を引き起こす。作業計画の骨組みが出来て関係者と認識が共有できていれば実行段階での修正判断は比較的迅速・的確にできる。
ページのトップへ

(2)実施責任体制

 作業対象が特定できたら、それらに対する実施責任体制(具体的なリソース(例えば、組織や個人の依頼先)の割当てと指示系統)を決める。マネージャーは自分が所管する全体計画に対して責任を負う。一方、個別要素作業の実施・管理については部下や依頼先が担当する。その分業における実施責任体制を作ることがここでの主目的になる。
 実施責任体制を作るときには、よく組織図などで見かける責任者を筆頭とし階層的体系の中に名前を書くピラミッド構造をいきなり書かない。
 作業対象と具体リソースとの対応表(マトリックス)が先ず必要であり、その表を使って作業対象一つずつに対して個人名などの具体リソースを割り当てる。前述の「ピラミッドの図」は、指揮命令系統(管理体制)を表現することを主目的にしているため、実行すべき作業対象の構造表現が不明確になり、漏れがでる危険性があるからである。
 開発物の構成要素や開発プロセスの種類が多く複雑である場合や、プロジェクトの構成員が必ずしも経験豊富でない場合、プロジェクト開始時に個人や委託先の組織に対してミッションを明確に伝えることが重要となる。
 このような時は、構成要素や開発プロセスと、具体リソースの対応表を用いてまず責任対象を明確に説明する。その後に、「ピラミッドの図」を使うなりして指揮命令や管理体制を示すというアプローチをとる。
ページのトップへ

(3)進捗管理

 ソフトウェア開発のプロセス管理の目的とするところは、ソフトウェアの品質の向上、コスト管理の徹底、納期の遵守にある。進捗管理はこれらの目的を達成するための作業であり、一にも二にも実態把握が基本となります。

1)実態を把握する
 開発プロジェクトの進捗管理の対象とするものは第一に「成果物」であり、その作業は完成度を把握することである。ウォーターフォール型のシステム開発では成果物が判りやすいように、開発工程が明示的に分かれているので実際は工程内の成果物の進捗で完成度を把握することになる。また、併せて「問題の解決状況」を管理することも、進捗管理の重要な作業である。
 開発委託先からの作業進捗の報告として、成果物の完成度ではなく作業のアクティビティが報告されることがある。主題は成果物の完成度と問題の解決状況であり、本質からはずれる場合は、是正を指示する。
 成果物の進捗に関する問題(回復しない進捗遅れ、品質劣化等)は必ず発生する。問題が発生した場合、原因究明の一つとして、リソースのアサイン実態を疑ってみる。開発体制どおりにリソースが割り当てられていない(他の仕事と兼務している)、適任とはいえない人が従事している等の問題点が見つかる場合がある。
発注者側からの問題是正に向けての申し入れに対して、受注者は開発コストの増大を押さえるためリソースの変更や追加投入をギリギリまで遅らせる傾向がある。何とかなるという判断で放置することもある。この場合は、委託先の開発責任者にに伝え実態把握と改善を求めることが重要である。部下の場合は本人から事情を聴取し、作業方法の改善等を指導し、改善がみられない場合はジョブアサインを変更することも必要となる。
ページのトップへ

2)数値で管理する
 工程の終了判断や計画の修正は進捗管理業務の結果として実行されるが、客観性、再現性の高い尺度を用い、できる限り数値で表現する方法を計画時点から用意する。試験の進捗などは、試験項目数など作業で直接取り扱える指標が使われるが、設計やマニュアルの進捗などはドキュメントのページ数だけでは進捗(完成度)の指標にならないことがある。その場合は「代用指標」や「マイルストン」を使って表現する。
 例えば、設計ドキュメントが成果物と定義できるケースでは、執筆段階ではページ数で管理し、その後レビュー等のマイルストン(イベント)を経るごとに完成に近づくというモデルを設定し、数値の進捗率に変換する。どのようなマイルストンを設定するかが進捗判断の重要なポイントになる。
ドキュメントの完成度に着目した例を下記に示す。
 マイルストンに対応する進捗率の表現は、発注者側と受注者側で到達レベルの解釈が異なる場合がある。作業計画を作成する時点で両者で協議し、後日解釈の狂いを生じないように「合意」しておくことが重要である。さらに完了の定義も明確にする必要がある。

2 情報化の目的とBPR(Business  Process Rengineering)

1業務上の目的・目標と、プロジェクトの目的・目標

 そもそもITは何のために必要なのか、その目的・目標(効果目標)は、IT戦略で整理されていなければなりませんが、ITを必要とする業務主管課でこそ、この目的・目標を議論する必要があります。そして必要な効果から逆算して、必要な業務の在り方やIT、それを組み立てる業務改革・システム構築プロジェクトのスケジュールを考えることが要求されます。
 業務上の目的・目標と、プロジェクトの目的・目標は異なります。プロジェクトの目的・目標は、業務上のその中に含まれる関係にあります。 プロジェクトの目的・目標は、業務上の目的・目標の通過点にすぎません。
 効果とは、業務主管課を中心とした「業務の遂行」があって初めて出るものです。システム主管課は、その効果を実現するための仕組み作りや業務遂行の支援を行うもので、使い勝手の良さや、将来にわたって更新・運用しやすい仕組みを作るという責任を持っています。このことを業務主管課は理解する必要があります。

2必要な機能を装備し、ITを活用するには 

情報システムを使いこなす大前提は、仕事をする上で効果的な機能がその業務システムに組み込まれているということが必要となります。そこで業務主管課と協力して、必要な機能は何かを整理する必要があります。
 もちろん、どのプロジェクトでも業務フローを書いたり、業務での問題点を洗い出すなどの作業をします。しかし、その前に、「これが本当に必要な業務なのか」を問う必要があります。
 その業務は、自治体の活動の中で、どのような目的をもっているのか? その業務のサービスの対象(市民、企業、職員)へのアウトプットは何か? そこで要求される品質はどのようなものなのか?

powered by Quick Homepage Maker 5.3
based on PukiWiki 1.4.7 License is GPL. QHM

最新の更新 RSS  Valid XHTML 1.0 Transitional