WBSとは

WBSとは、Work(作業)Breakdown(分解)Structure(構造化)である。
Workは、Task(タスク)と同意。
構造化は、フォーマット定義があれば難しく考えなくともよいので
簡単に言えば「タスクの分解」となる。

タスクの分解をしましょう!と、言うと3つのプロセスになるようだ。
1、無邪気に考える。    <--7割くらい?
2、ボトムアップで考える。 <--2割くらい?
3、トップダウンで考える。 <--1割いるかな?

そこで『網羅的』にね!と、条件を追加すると・・・
1、無邪気に考える。    <--網羅的ではないと気づく
2、ボトムアップで考える。 <--考えやすい
3、トップダウンで考える。 <--複雑になればなるほどコッチ

となる。
これはナゼかというと、たとえば研修のような簡単で単純な(擬似的な)プロジェクトであればあるほどボトムアップが効率的であるが、実際の(複雑怪奇な)プロジェクトではボトムアップはほとんど通用しない場合が多い。
(・・・ということを研修等で説明するのは難しい)

ボトムアップ/トップダウンのどちらが網羅的になるのか、、、は、各々の経験値・経験則になると思うが
個人的な見解は「網羅的に・・」という意味では、圧倒的にトップダウンの考え方で実施するべきと考える。
「やりやすさ・・考えやすさ・・」という意味では、ボトムアップの考え方が選ばれる傾向にあると思うが、正直には実践向きではない。

いわゆる実践的なWBSとは、工程管理と進捗管理が可能なWBSである。
逆に言うと、工程管理と進捗管理ができないWBSは作成する意味がない。

システム開発の基本プロセスとは・・・

システム開発のプロセスの基本といえば、ウォーターフォールモデルである。
上流工程から下流工程まで、水が流れるがごとくタスクが展開するプロセスの呼称である。
昨今は、ウォーターフォールをあえて採用せず、アジャイル・イテレーション・プロトタイプ・ハイブリッドなどなど様々な手法を採用している開発ベンダは多い。
全ての基本はウォーターフォールモデルである。

■ウォーターフォールの工程

 

■企画(戦略)
・KGI/KPI
やりたいことはなんだ?明確なゴールを決める。
ゴールに向けてマイルストーンを設定する。
・QCD
Quality:品質,Cost:費用,Delivery:納期を決める。
ドリームプランにならないように、どのレベルの品質を目指すか、
いつまでに、費用対効果を明確に具体的に「見える化」する。
・5W1H
何のために(目的)、だれが(体制)、何を、いつまでに、どうするか
を整理して計画する。

■要件定義①・・・ユーザ主導の業務要件定義
わかりやすいのは業務フローを見える化する。
業務フローのAsIs-ToBeが定義できれば、今はこうだけど、ああ成りたいが具体化され、要件整理ができる。
要件が整理できたら、システム開発ベンダ向けに提案依頼書:RFP(Request For Proposal)を作成する。
※情報提供依頼書:RFI(Request For Infomation)でも構わない。

■要件定義②・・・開発ベンダ主導のシステム要件定義
ユーザが思い描いている要件を、開発ベンダがどのように実現していくかをインフラ構成・画面仕様・バッチ処理などのシステム要件(仕様)に整理する。
ーー>設計工程以降の見積り根拠を決める。

プロジェクト計画として、スケジュールや体制、マネジメント方針を決める。

■設計・・・基本設計と詳細設計
基本設計は、ユーザが積極的に介入するべきシステムの方向性を決める工程となる。システム構成(コンテキスト)、アーキテクチャ設計、データベース設計(論理設計)、機能一覧、画面設計(UIスケッチ)、インターフェース一覧など

詳細設計は、開発ベンダ主導でシステムの実装方法を決める工程となる。
データベース設計(物理設計)、機能詳細仕様、画面詳細仕様(UI仕様)、バッチ処理仕様、インターフェース詳細仕様、ログ仕様、バックアップ仕様など

■開発・・・単体テストも含む
開発ベンダ主幹の工程になる、ユーザは進捗管理の介入のみになるが
V字モデルを意識して後工程準備も含めてプロジェクト管理を継続する。

■テスト・・・結合テストとシステムテスト
シングルベンダやマルチベンダ、オフショアなどプロジェクト体系によって、テスト工程や複雑さ難易度は変わる。
インフラなど様々な周辺環境の状況を含め計画・実行・検証が必要になる。

■受入れテスト
開発ベンダの開発フェーズ(システム要件定義~システムテスト)が完了し
ユーザが品質検証する工程になる。
リリースを判定する(=リリースするに値する品質が保たれている事を保障する)と同意。第三者(テストベンダ)に委託する場合もある。

■移行
リリース判定され本番稼動承認されたシステム(データを含む全ての資産)を、開発環境から本番環境に移行すること。
開発規模によっては、移行計画書・手順書(リハーサル)を準備する。

■監視・保守
リリース直後の短期間の特別監視を指す。
特別な監視条件は、プロジェクト毎(監視条件、ログレベルなど)に定める。

■運用
リリース後の通常運用。

体制における課題

プロジェクト体制に課題が存在する状況
・上層部からの無邪気な指示
・根拠のない戦略
・目的のない企画
・計画のない開発
・慢性的な改修
・フィードバックする仕組みがない

 

 

 

 

 

 

 

 

 

 

 

 

改善するべき課題
・手続きの明確化
・意思決定の明確化
ビジョンの明確化
・要求の明確化
・評価の標準化

ユーザーが本当に必要なモノ

多難なシステム開発プロジェクトの姿を風刺した絵である。

 

・顧客が説明した要件
・プロジェクトリーダの理解
・アナリストのデザイン
・プログラマのコード
・営業の表現、約束
・プロジェクトの書類
・実装された運用
・顧客への請求金額
・得られたサポート
・顧客が本当に必要だった物

ユーザーが本当に必要なモノを、そもそも説明できていない、、、というオチである。
開発ベンダも全く気づいていない。
誇張しているようにも思えるが、実際の現場はまさにこの状況である。

さて、どうすれば良いのか?

本質的な問題は、関係者間の意思疎通(コミュニケーション)にある。
必ずしも開発ベンダだけの原因ではない、、、を理解する必要がある。

履歴2007-

MovableTypeと同時期に独自ブログ型ポータルサイトCMSを開発したベンチャー企業と協業する。システム責任者として企画・提案~サイト構築~運用、カスタマイズを担当する。
(2007-2010)
・商社向け・ASPサービス提供(LAMP)
・ギフト販売企業向け・ASPサービス提供(LAMP)
・住宅建材メーカ向け・ASPサービス提供(LAMP)
・情報通信商社向け・ASPサービス提供(LAMP)
・商社向け・ASPサービス提供(LAMP)
・JA向け・ASPサービス提供(LAMP)
・JA向け・広報誌ナビシステム(LAMP)

独立系システム開発会社として活動する。
(2008-2012)
・アパレル向け・ECサイト保守(ExcelVBA)
・エンタテイメント企業向け・売上計上システム(LAMP)
・神奈川県麺類同業組合向け・ポータルサイト(LAMP)
・外国人向けホテル予約サイト(LAMP)
・セラピスト事業会社向け・サイト構築(LAMP)
・ITベンダ向け・企業診断パッケージ開発(ExcelVBA)
・自治体向け・情報システム調達知識習得研修会
・社会福祉法人向け・業務支援システム(LAMP)
・会計ソフトメーカ向け・EA導入支援

ITコーディネータ(業務支援、システムコンサル)として活動する。
(2011-現在に至る)
・AsIs-ToBe業務フロー作成支援(ホストからのマイグレーション)
・新規サービス:開発PMO(タブレットアプリ)
・サービス統合:開発PMO(タブレットアプリ)
・新規サービス1期:PM支援(ハイブリッド端末アプリ)
・新規サービス2期:PM支援(ハイブリッド端末アプリ)
・新規サービス3期:PM支援(ハイブリッド端末アプリ)
・新規サービス:開発PMO(ハイブリッド端末アプリ、音声サービス)

PMOとは

PMO(Project Management Office)とは、プロジェクト管理を統括する組織のこと。プロジェクトの計画や進捗管理、リスク管理、品質管理などを一元的に行い、プロジェクトの成功に貢献する役割を担う。
以下に、システム開発においてPMOが必要な場合の理由を示す。

大規模なシステム開発
大規模なシステム開発には、多数の関係者や複雑な工程が関わることがある。PMOが統括することで、計画や進捗管理、リスク管理、品質管理などが適切に行われ、プロジェクトの成功につながる。

複数のプロジェクトを同時に進める場合
企業が複数のシステム開発プロジェクトを同時に進める場合、PMOが統括することで、プロジェクト間の調整や資源配分などが適切に行われ、各プロジェクトの成功につながる。

品質向上のため
PMOが品質管理を統括することで、品質向上につながる。品質管理においては、プロジェクトの進捗管理やチェックポイントの設定、品質評価などを行い、開発過程での品質向上を目指す。

ただし、小規模なシステム開発や、外部ベンダーに開発を委託している場合など、PMOが必要でない場合もある。プロジェクトの規模や複雑度、開発手法やチーム構成などを考慮し、必要性を判断することが重要だ。

 

 

 

 

 

 

 

 

 

PMOに求められる役割は、プロジェクト管理を統括すること。具体的には、以下のような役割がある。

プロジェクト計画の策定
PMOは、プロジェクトの目標やスケジュール、品質目標、予算などを定めるプロジェクト計画を策定する。計画は、ステークホルダーの要望や制約事項を考慮した上で、プロジェクトの成功に向けた方針を定めるものである。

プロジェクトの進捗管理
PMOは、プロジェクトの進捗状況を管理する。スケジュールや予算、品質目標などと比較して、プロジェクトが適切に進んでいるかどうかを判断し、必要に応じて調整を行う。

リスク管理
PMOは、プロジェクトにおけるリスクを管理する。リスクの特定、評価、対応策の策定、監視などを行い、プロジェクトのリスクを最小限に抑え、プロジェクトの成功に向けた対策を講じる。

品質管理
PMOは、プロジェクトの品質管理を統括する。品質目標の策定、品質評価の方法の確立、品質監査の実施などを行い、プロジェクトの品質を向上させる。

プロジェクトマネジメントの支援
PMOは、プロジェクトマネジャーの業務を支援する。プロジェクトマネジャーの補佐、プロジェクトマネジャーの教育や指導、プロジェクトマネジャーのツールやプロセスの提供などを行い、プロジェクトマネジャーの業務の効率化を図る。

これらの役割を通じて、PMOはプロジェクトの成功に貢献する。ただし、PMOがどのような役割を果たすかは、企業やプロジェクトによって異なる。PMOが担当する範囲や役割は、プロジェクトの性質に合わせて設計される必要がある。

履歴2003-2004

フリーランサーとなり、営業や経営の基礎を学ぶ。
システム開発を生業としながら、ITコーディネータを目指す。
自治体職員によるRFP作成研修アドバイザ、業務改善プロジェクト、業務分析、RFP作成、業者選択といった上流工程(顧客側プロセス)を経験した。
・WEB制作会社向け・収支管理システム(ExcelVBA)
・経済産業省向け・RFP作成支援セミナー
・印刷業者向け・業務改善プロジェクト
・蜂蜜販売会社向け・ECサイト構築(ExcelVBA)

履歴2002-2003

一身上の都合により転職。

自社開発の商品管理パッケージの設計・開発を担当、顧客への企画/提案型のビジネススタイルを学ぶ。
・アパレル向け・商品管理システム(VB6.0)

ONサイトでのシステム開発支援スタイルを学ぶ。
・精密機器メーカ向け・発注業務支援システム(VB6.0)

履歴1989-2002

都市銀行系シンクタンクのシステム開発部門へ配属となり、主に金融系汎用機システム開発の基礎を学ぶ。
・クレジットカード会社向け・顧客管理システム(IBM汎用機,COBOL)
・金融機関向け・会員管理システム(AS400,RPG)

Windowsでのクライアント/サーバのシステム開発に携わりPCシステム開発の基礎を学ぶ。
・社内向け・会計システム(win3.1,VB4.0)
・大学向け・情報管理システム(win3.1,access2.0)
・結婚式場向け・受注管理システム(win3.1,access2.0)
・卸業者向け・請求管理システム(win3.1,COBOL)

大規模システム導入に伴い運用支援、業務改革支援を目的に各拠点に常駐。
顧客先にて業務改善型システム導入を体験し、システム運用の重要さを学ぶ。
プロジェクトの全国展開サブリーダとして基幹部門でのマネジメントをしつつシステム開発リーダを担うことになった。
・特殊法人向け・OCRシステム(winNT,VB5.0)
・保険組合向け・OCRシステム(winNT,VB5.0)