IT

2017年5月 3日 (水)

プロジェクトにおける「契約管理」を円滑にするために

プロジェクトの中でも「新規アプリケーション開発」の場合は、RFP(提案依頼書)を作成して発注先を選定する場合がある。

そして、発注先が決定したら「契約の締結」である。

プロジェクトでは、契約の締結に関与しなければならないが、実際は、社内の法務部門の専門部署が統括管理をする場合がある。

 

ここで問題が発生するときがある。

 

社内の法務部門は実際の現場をあまり認識できていないこと、

「実務は現場で起きており、会議室ではないが隔離された法務部門内で起きてるんじゃない!」と言いたくなるときがある。

また、お金を出すクライアントが偉いんだ。お金をもらって開発するベンダーは従えばいいんダ!と言う殿様商売的な雰囲気があるときもある。

 

具体的に挙げておこう!

「全行程、発注形態は、“請負契約”で!」

理由は、発注側のリスクが無いから、と言う。

一見、なるほどと思うかもしれませんが、現場からすると、アンビリーバブルである!

経済産業省の情報システムの信頼性向上のための取引慣行・契約に関する研究会による情報システム・モデル取引・契約書にも書かれており、情報処理資格試験にも出題されるくらいだが、要件定義~外部設計行程、そして、システムテスト~本番移行は一般に準委任型になる。

http://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo_gaiyou.pdf

※経済産業省より

これは、事業会社である生命保険会社にしてみれば、自分たちが業務を知っているはずなのに、受託者側に要件定義で請負契約に基づく成果物責任を負わせることはおかしな話になる。

同じく、自社内の他システム連携や外部接続を含めたシステムテスト以降においても同様と言える。

 

ほかにも、

「基本契約書と個別契約書は分けて契約締結すること」

これも、一見普通のように見えるが、“単発”の基本契約書を結べという。これでは、基本契約の意味が無いのではないか!?

基本契約を結ぶ大きな意味は、継続的に受託いただく側とお付き合いをしていくことを前提に締結しておくもので、その後の契約では、基本契約に記載のない部分を個別契約として行えることが大きいというのに、“単発”の基本契約ってなんダ~!と言いたくなる。

 

いくつかのことについて受託者側に“表明保証”を!、とも言う。

“表明保証”とは、事実の存在を契約の一方に表明させ、そしてさらに保証させることにより、その事実がないときは後に損害賠償ができるようにすることが狙いと言うことだが、では、どうやって表明保証をさせるのか、やり方を提示しない。

何様ダ~!と言いたくなる。

 

そして“損害賠償”は、そのような事態になったら、すべて無制限(青天井)の損害賠償責任を、と言う。

これも、何様ダ~!と言いたくなる。

もし、これに合意する受託業者がいるならば、逆に、その会社やばくない!? と思いたくなる。

 

受託者側ばかりに肩を持っているわけではない。

言いたいことを言ってしまったが、理解できる点もある。

 

“瑕疵担保期間”は1年とすること。 これは民法でも1年となるので、これより短くはしたくない。

契約の“解除権”は、発注側のみとし、受託者側には与えないこと。

これも理解できる。但し、会社の倒産リスクなどを勘案して“解約権”は両社にあるようにする。

 

契約締結に際して、慎重を期すことは、とても大事だと思っているが、事業が回らなくなってしまっては本末転倒である。

社内の規程が多くなり、かつ厳格になればなるほど、事業が回しにくくなる。

実態に合わない規程を作り、部分最適(実際は部分最適にもなっていないが)に徹し、全体最適を忘れている。殿様商売だけでなく、官僚商売まで続けていれば、いずれやばくなるのではないか・・・

 

どうすれば生命保険事業を前に推進できるかを共有し、お互いがお互いを理解して、“全体最適”を目指さなければならないのではないか。

 

と、平社員の独り言。失礼しました。

 

m(_ _)m

 

2015年8月15日 (土)

システム本番移行後の「重点監視」について

下記は、障害が許されない国内線旅客システムのケース

 

システム本番移行後は様々な混乱が想定される。(「平穏だったらラッキー」くらいに思うことが重要。)
また、特に初期段階では、ヘル プデスクの対応如何によって利用者の混乱・不満に拍車をかけるケースも散見される。システムの安定稼働までは、ヘルプデスクをはじめ手厚い利用者支援体制 を取ることと、稼働状況を監視・検証する定例会を設けるなどして、改善に努めることが重要である。 

障害が許されない国内線旅客システム稼働においても、稼働直後の様々な事象に素早く対応すべく準備することが必要である。

稼働直後から“ 2 週間”の緊急障害対応に備えた期間を“臨戦期間”と定義し、その間の 24 時間体制を「臨戦体制」とした。

「臨戦体制」の準備として

体制と役割

障害対応のフロー

障害分析に不可欠な各種ログデータの参照ルール

障害対応版のリリース手順の整備

システム稼働状況監視の方法

稼働状況

確認会議体

端末/ファシリティ/ロケーション

が必要になる、と。

 

私たち生命保険の“新契約”のシステム本番移行後も上記と同様な準備をしていましたが、残念ながら多くの障害発生により、2週間の重点監視体制(臨戦体制)では収束することができず、まず1週間の延長、それでもダメで、さらに2週間の延長、計5週間の臨戦体制を継続することとなりました。

障害発生は残念なところですが、腹を括って取り組むしか無い、顧客障害だけは水際でくいとめたいという思いでチーム全体取り組んでいます。

 

それにしても、疲弊します。ブログもなかなかアップできません。勉強も・・・いい訳!?!?

 

「あともう少し」と思って、がんばってきております!

 

ではでは、また。m(_ _)m

 

2015年5月18日 (月)

第6回 システム移行リハーサル!

516日(土)午後から17日(日)の朝まで、システム移行リハーサルでした!

17日は時差ボケと睡眠不足調整まで。月曜日からは通常通り勤務!

6月末のシステム本番まで、もうひと踏ん張りです!

なので、ブログの更新ができまへん・・・

。・゚゚・(≧д≦)・゚゚・。

 

それでも、17日朝は癒しを求めて、寝ていませんが”銭湯”へ行きました!

錦糸町サウナ「ピロー」へ、ここは1000円で好きなだけお風呂とサウナが楽しめます!

午前中はここで仮眠もしました。そして、これまた錦糸町の「キッチン藤」で生姜焼き定食を食べてから、家に帰りましたヨ!

ここの定食はリーズナブルな値段でおいしくて、がっつり食べれてイイと思いますヨ!

さらに、癒しの写真も眺めて? 月曜日からまたがんばります!

m(_ _)m

11018578_10153665933233986_63894327

11229407_10153877941128986_78415251

10420220_10153382317408986_22046282

2015年4月12日 (日)

損害保険ジャパン日本興亜のシステム統合について

損保と生保では、apple to appleで比較するのは難しいですが、

“損害保険ジャパン日本興亜株式会社”とGで少し比べてみましょう。

総資産は、それぞれ8兆円と11兆円、生保は資産形成商品も多いですからネ。

資本金は、700億円と750億円、

年間収入保険料は、2兆円と1.4兆円

国内拠点は、1000店舗と800店舗、但しジャパンには更に海外拠点もあり、代理店数は6万店!

従業員数は、27,000人と17,000人(ともに合併時)

大半の契約が1年もの商品の損保に比べれば、生保商品は複雑と思いますが、1件単価が生保よりは低くなる中で、年間収入保険料2兆円は損保業界トップレベル!

 

これまでの合併具合?を見てみると、同じ4社ずつでした。

損害保険ジャパンは、元安田火災、元日産火災、元大成火災、元日本興亜損害保険からなり、

Gは、元K生命、元C生命、元T生命、元S生命からなっています。

 

簡単ですが、以上を踏まえると、Gも相当にかかったとはいえ、システム開発工数のみで45千人月(約450億円)は“スゴイ(ちょっと高くない?)”と思いました!また、システム開発工数以外にも相当の額がかかりますしネ!

 

ただ、これまで経験してきたプロジェクトの中で、あまり注視をしていなかった点で、費用の嵩む要因にはなりますが、

「会議の支援やホテル手配、宿泊設備の設置といったファシリティ管理を担う“プロジェクトサポートオフィス”と呼ぶ専門チームも組織した。技術者たちのモチベーション維持などにつなげるのが狙いである。」

は、今後の合併プロジェクトでの参考になるかもしれません。

 

それでもスゴイですネ! 

理由として、ホストコンピュータはそれぞれに残していること、その中で、合併に際してマストな対応は、「社名変更対応」、「組織変更対応」、「会社ブロックを跨ぐ契約名寄せ対応」、「顧客インターフェースのあるオープン系システムを1つに統合、ないし片寄せ」、それと「新契約時商品販売の片寄せ」、これら以外の“保険料収納の統合”、“合併同時新商品販売”などはできる範囲までになると思うからです。合併同時新商品販売はされていませんネ。システム障害リスクを高めることになるので、する必要はないと思いますが。

 

また、合併により、ユニットコストを下げることは当然のこととして、それで 1+12にならなければ、合併の意味は無いと思っています。これは、どの合併にも当てはまりますけどネ・・・・( ̄◆ ̄;)

 

損害保険ジャパン日本興亜システム統合記事でした

http://itpro.nikkeibp.co.jp/atcl/column/15/031600047/031600002/

失礼いたしました。

m(_ _)m

2015年3月 8日 (日)

アク研行けなくて、ざんねんでした

先週は土曜から日曜日にかけて、プロジェクトのシステム移行リハーサルでした。

これは一部“本番”環境を利用したりするので、休日でないとできないイベントとなります・・・

 

今年最初のアク研に行けなかったのはとてもざんねんでしたが、仕事は大事 ( ̄○ ̄;)!

 

一般に、システム移行は、プロジェクトにおける“最後の難関”と言われたりしますが、プロジェクトはレッドゾーンに入っており、まだまだ難関が続く状況です・・・、みんなで力を合わせてがんばっています!

 

システム移行としては、ここに記載されているところの第6回の辺りでしょう・・・

http://itpro.nikkeibp.co.jp/article/COLUMN/20080303/295290/

 

そして、今日は、システム部門にいたときの元上司Sさんとお会いすることができました。

そこで、ご示唆いただいたこと!

 

【プロジェクト成功のためのポイント】

1. プロジェクトマネジメントについて、その知識と共に行動ができること。

2. 交渉力、コミュニケーション力があること

3. 「業務」に精通していること

その上で、リスクコントロールができていれば、プロジェクトは成功する!

 

上記の中で、外部コンサルタントや一括請負先のベンダーにできないことは、『「業務」に精通していること。』買収を繰り返している企業は、ここに精通したリソースが不足することがあります。

肝に銘じて、推進していければと思っています。(* ̄ー ̄*)

Sさん、貴重なアドバイス、ありがとうございました!

それと、

仕事は大事ですが、勉強もしたい!

貪欲にいかないといけませんネ。

今年もよろしくお願いいたします!

m(_ _)m

 

11011294_442129195944856_3555040725

2014年12月23日 (火)

システム品質向上のために

システム障害が起きる度に、“システム品質強化”と称して評価プロセスを付け加えていくことで、“システム品質評価プロセス”が複雑になることがあるように思っています。

そのうちに、

“形だけ”になりがちなプロセス(ソフトウェアレビュー)が生じることもあるかもしれません。

結果として、実質が少ないのに、とっても複雑な“システム品質評価プロセス”ができることがあるように思います。

 

ソフトウェアレビュー(以下、レビュー)とは、『設計ドキュメントをはじめとした各種ドキュメントやソースコードを人が読み込んで、その問題点を見つける作業』のことです。

 

ソフトウェアテスト(以下、テスト)と混同されがちですが、両者には大きな違いがあります。レビューは、プログラムを動かさずに(静的に)、ドキュメントやソースコードを人が目で追って問題点、すなわち潜在的な不具合を発見しますが、テストはプログラムを動作させながら(動的に)、不具合を発見します。

 

つまり、レビューはプログラムが動作する前の状態──要件定義や設計などを含め、コンパイルや実行ができない段階でも問題点を発見できるのです。これがテストとの大きな違いです。また、レビューとテストは、どちらか一方を使うと他方は使えないというものではなく、相補的に使うものであり、それぞれを適切に実施することが大切です。

 

「なぜレビューをするのか?」、それは、以下4つの「目的」に集約できます。

 

1.開発中のソフトウェアの潜在的不具合(エラー)を早期に見つけて、その後の作業を円滑化し、修正コストを低減するため

2.ソフトウェアの保守性や可読性を高め、次のバージョンを開発するときに再利用しやすくすることで、次のバージョンの開発コストを低減するため

3.プロジェクトメンバー間の情報共有や新しいメンバーへの教育のため

4.現在の設計や実装の代替案がないかを考える場として

 

ウォーターフォール・モデルのように、段階的に詳細化が進んでいく場合、要件定義段階での誤りがテストで発見されると、再設計や再コーディングを要する場合が多く、「初期工程での誤りほど、修正コストが大きくなる」ことが知られています。その点、レビューは要件定義が終わった段階で行うことができます。要件定義の成果物である要求仕様をチェックし、その段階で潜在的不具合を取り除けるため、再設計や再コーディング、そのためのコストも必要なくなる、というわけです。

 

そして、レビューで最も大切なのは「目的意識」だそうです。

しっかりとした「目的意識」を持ち、何を重視するかを決め、そのために、どのような準備をし、どのような手順で行うのかを考えることが、レビューを生かす前提条件となるそうです。

 

そして、レビューにおいて、エラー指摘の記録も非常に重要になるようです。

“確実な記録”こそが、品質・コストに貢献すると言われています。

 

さらに、

「レビュー会議」の4つのポイントがあるようです。

1.「指摘内容を項目ごとに分けて記入する、記入フォーマットの整備」

2.「取りこぼしなく、きちんと記録できているかの確認」

3.「レビュー会議進行中の指摘内容の確認」

4.「レビュー会議終了間際の指摘内容の見直し」

そして、指摘内容を、その場で全員が確認できる環境を作ること

 

「品質特性」について

品質特性は、ソフトウェアの品質を定義し、評価するために用いられるソフトウェアの属性の集合

品質特性はさらにいくつかのレベルに品質副特性として詳細化される。JIS X0129-1 では、「機能性」、「信頼性」、「使用性」、「効率性」、「保守性」、「移植性」の6つの品質特性を定義している。

 

たとえばリアルタイムシステムでは、通常、トランザクションの集中する時間帯にリクエストされたすべてのトランザクションを能率よく処理するための性能が求められる。また、公共の対話型システムでは誰でも利用できる使用性が求められる。システム・ソフトウェアに求められるクリティカルな特性は、適用分野によって実行速度、使用性、セキュリティ、信頼性など多様である。

 

メトリクス(品質測定法)

「品質測定法」は、要求された品質特性あるいは品質副特性を備えている度合いを定量的に測定するための尺度及びその測定方法(測定値を求めるための関数やその計算方法も含まれる)をいう。

 

※「メトリクス(metrics)」とは、韻律学、作詞法という意味の英単語。また、測定基準、尺度、計量、距離などを意味する名詞“metric”の複数形。分野や対象を表す名詞に伴って、「~の尺度」「~の測定法」「~の計量法」などの意味を付加する接尾辞でもある。

様々な活動を定量化し、その定量化したデータを管理に使えるように加工した指標のことです。 簡単に言うと、何かしらデータを収集して、そのままの形ではなくて、計算や分析を加えてわかりやすいデータ(数値)に変換したのが「メトリクス」です。

 

最後に、

『システム・ソフトウェアの品質を向上させるためには、西欧の言葉でいう“銀の弾丸”(特効薬)はない。』

と言われているそうです。

やはり、個のシステム品質評価スキルを継続して高めていき、常に「目的意識」を持ち、定量的に評価できるシステム品質評価プロセスを築いていくしかない。

「目的意識」を誤ると、実態のないものになっていく。

 

心しておかなければ!

 

m(_ _)m

2014年5月25日 (日)

「プロジェクトマネジメント」と「プログラムマネジメント」

職場で、「プログラムマネジメント」を導入できないか、検討を始めました。

そこで、今回は「プログラムマネジメント」とは? を確認しておきたいと思います。

 

「プロジェクトマネジメント」との違い Wikipedia

 

ビジネスにおいて、「プログラム」は「プロジェクト」と以下の点で異なる。

 

「プロジェクト」は個別なもので固有の期間を持つ。「プログラム」は持続的であり、一定の成果を継続的に達成するために実施される。

 

「プログラムマネジメント」はビジネスプログラムの管理活動を含み、段階的にプログラムの効率レベルを高めるためのプロジェクト群の管理を含むこともある。複数のプロジェクトの管理としての「プログラムマネジメント」の一般的定義は、「プロジェクトマネジメント」の原則に対して“近視眼的”と考えられる。

必要とされる結果を達成するため、ビジネスプログラムは通常、関連するビジネス制約を理解し、割り当てられたリソースに基づいて結果を達成するのに必要なプロセスを決定する。プロセスの改善はプロジェクトとプログラムの大きな違いとなる継続的操作である。

プロジェクトマネージャは個々のプロジェクトを調整する。そしてプロジェクトマネージャを監督するのはプログラムマネージャとなり、プログラムマネージャはスポンサー(または取締役会)に対して責任を負う。

 

IT情報マネジメント編集部より

大規模で複合的な問題に取り組むに当たり、活動全体を複数プロジェクトの結合体ととらえ、そこに含まれる各プロジェクトの連携・調整・相互作用を通じて状況変化に対応し、戦略的目標の達成を図るマネジメント手法のこと。

 

 従来のプロジェクトマネジメントは、特定の具体的なゴール(要求)を所与の制約条件(資源・コスト・スケジュール)の下で達成・解決することを目指す活動であった。これを実現するために綿密なスケジュールを立案し、進ちょくに応じてそれを見直すという手法を取る。

それに対して、より大きなミッション――例えば「企業風土の改革」「新産業の創出」「発展途上国の開発援助」というような課題に取り組む場合、やってみなければ分からない面が多く、個別具体的な計画を事前に立てることが難しい。実際には、実行時に状況に応じて機敏に手段や対策を変更・中止・追加することが求められる。

 こうしたとき、具体的な実施活動であるプロジェクトの上位に、それを統合的に扱う概念としてプログラムを置き、複数のプロジェクトを集約して運用(計画・整合・監視・調整・選択・変更・中止)する方法が有効である。これをプログラムマネジメントという。

 

 いち早くプログラムの概念を取り入れた標準に、日本生まれのP2Mproject & program management for enterprise innovation / プロジェクト&プログラムマネジメント知識体系)がある。P2Mでは、プログラムを「全体使命を実現する複数のプロジェクトが有機的に結合された事業」と定義、プログラムマネジメントを「全体使命を達成するために、外部環境の変化に対応しながら、柔軟に組織の遂行能力を適合させる実践力である」と定義している。

 

プログラム・マネジメントとは  IT Proより

複数のプロジェクトを同時並行に開発することを「プログラム・マネジメント」といいます。

これまでの仕様書や設計書など成果物を後工程が引き継いで開発する「ウォーターフォール型」では間に合いません。複数のアプリケーションを同時並行に開発して期間を短縮する必要があります。

 

◆「プログラム・マネジメント」の効果

開発の遅延を防ぐ

 稼働させなければならない期日を守るためには、予算や各プロジェクトの進ちょく状況を把握することが欠かせません。そのために、定期的に各プロジェクトの責任者が集まって進ちょく状況を報告します。報告を受けた最高責任者(プログラム・マネジャー)は、それぞれが進めている統合作業やテストが予定通りできるのかといった進ちょく状況や、予算通りに進んでいるかを確認します。遅れているプロジェクトには人員を投入するなどの決断を下し、プロジェクト全体の遅延を防ぎます。

 ウォーターフォール型の開発は成果物で後工程へ引き継ぎをしていたので、成果物がいまどこまで進んでいるかで時間管理ができました。同時並行で進むプログラム・マネジメントの場合は、情報共有する場が必要となるのです。

 共通のテンプレートで管理

 

プログラム・マネジメント  IT mediaより

(前略)

 米国に本拠を置くプロジェクトマネジメント協会(PMI)でも2006年に「The Standard for Program Management」(プログラムマネジメント標準)を発表している。PMIの体系では何をすべきかを定める「ポートフォリオマネジメント」、どの手段を用いるかを定める「プログラムマネジメント」、決められた手段・手順を確実に行う「プロジェクトマネジメント」の三層構造になっている。このPMI標準ではプログラムマネジメントを「プログラムの戦略的利益や目標を達成するために、プログラムを調整、集中してマネジメントすること」とし、プロジェクトマネジメント標準(PMBOK)と同じ9つの知識エリアに、39のプロセスを定義している。

 

ポートフォリオマネジメントIT mediaより

資産運用や経営資源の配分を考えるとき、投資案件の11つを個別に評価するのではなく、その集合全体(ポートフォリオ)でのバランスを考慮に入れて分析・検討を行い、合理的な取捨選択・優先順位を導き出して、最適な投資の意思決定を図るマネジメント手法のこと。

 

 ポートフォリオ(portfolio)とは、イタリア語のportafoglio=書類を運ぶものに由来する英語で、紙ばさみや書類入れを意味する。金融・証券界では、投資家の有価証券を紙ばさみに入れて持ち運んでいたことから、投資家やファンドが保有している有価証券・金融資産の一覧表(あるいは、資産構成そのもの)をポートフォリオというようになった。さらに転じて、事業会社が保持している複数の事業や製品ライン、各種の経営資源、あるいはプロジェクトの集合をいう。

 

 投資・資産運用の世界でいうポートフォリオマネジメントとは、投資家のリスク選好度などに基づいて、分散投資(diversification)のために投資先・金融商品の組み合わせ=ポートフォリオを構築・メンテナンスすることをいう。特定の期待収益率/リスクと標準偏差(または分散)から数理的・統計的に最適ポートフォリオを導き出す、モダンポートフォリオ理論(MPT)を利用した手法を指すこともあるが、単に値動きの異なる資産を組み合わせること(例えば不動産・債券・株式、景気敏感株とディフェンシブ株など)をいう場合も多い。

 

 経営戦略の分野では、プロダクト・ポートフォリオマネジメント(PPM)、事業ポートフォリオマネジメントが知られる。米国では1960年代から企業のコングロマリット化が進んだが、その多角化(diversification)戦略を支援するために登場した経営分析手法である。1980年代になると米国では経営者主権から株主(機関投資家やファンド)主権に移行したこともあってPPMは下火になったが、以後も各種の無形資産(技術、人材、サービス、パテント、ブランド、知的財産)をポートフォリオの考え方で管理するアプローチが多数提案されている。

 

 プロジェクトマネジメントの世界では、複数の個別プロジェクトの状況や特性(進ちょく、リソース、将来性、技術リスクなど)を横断的に把握することで、プロジェクトの選定・着手順序・追加投資・改善・中止などの意思決定を行う「プロジェクト・ポートフォリオマネジメント」が叫ばれるようになっている。英国・プロジェクトマネジメント協会(APM)のPM知識体系「APMBoK」がトピックの1つに取り上げており、米国・プロジェクトマネジメント協会(PMI)も2006年に、「The Standard for Portfolio Management」(ポートフォリオマネジメント標準)をリリースしている。このPMI標準ではポートフォリオマネジメントを「特定の戦略的ビジネス目標を達成するために、1つまたは複数のポートフォリオを集中してマネジメントすること」としている。

 

 ITマネジメントにおいても、IT資産/ITプロジェクトにポートフォリオ・アプローチを適用する「ITポートフォリオマネジメント」「アプリケーション・ポートフォリオマネジメント」が提唱されている。これは目的や性格、特性が異なるIT資産/ITプロジェクトを、経営戦略との整合性、事業への貢献度、ROI、自社の適応能力、技術的実用性といった複数の評価軸を組み合わせて評価を行い、IT予算の最適配分を行うもの。経済産業省は20053月に「業績評価参照モデル(PRM)を用いたITポートフォリオモデル活用ガイド」を公表している。また、米国・ITガバナンス協会(ITGI)が2006年に出版したVAL ITフレームワークでは、IT投資をポートフォリオ(プログラム、プロジェクト、サービス、資産のグループ)としてマネジメントすることを推奨している。

 

「プログラム」とかプロジェクトといった用語・概念は、'60年代米国のアポロ計画のあたりから使われるようになった。アポロ計画自体は、プログラムである(=The Apollo Program)。プログラムの下に、アポロ1号、アポロ2号、などロケット打ち上げに関する個別ミッションがある。これが「プロジェクトProject」と呼ばれた。プロジェクトはさらに、設計・製作・飛行などの「フェーズPhase」(あるいはActivity)に分解される。このように、巨大な事業全体を、構造的に分解して、管理していくのは、米国的思考法の得意とするところだ。

 

                       

 

アポロ計画がスタートしたとき、最終目標は「10年以内に月面に人間を送る」だったが、それ以上の明確なスコープも詳細な予算も、まだ存在しなかった。つまり、オープン・エンドな事業だったのである。それを逐次的に具体化・詳細化していくために、複数のロケット打ち上げプロジェクトを積み重ねていく方法がとられた。つまり、アポロ・プログラムは複数プロジェクトを時系列的にたばねたものである。先行プロジェクトと後続プロジェクトの間には、直前に達成された成果にもとづくフィードバックがあった。全プロジェクトのスコープが最初からきっちりと確定していた訳ではなかった。

 

「プログラムとは複数のプロジェクトを束ねたものである」と定義するとき、それが同時的バンドルを意味するのか、時系列的バンドルを意味するかについては、実は相当な質的開きがあることに注意してほしい。プログラムが事業として、外部環境の変化、あるいは内部での能力・知識の成長とともに、適応的に発展していくためには、どこかにフレキシビリティーがなければならないはずである。時系列的なプロジェクトの集合で、かつプロジェクト間にフィードバックが存在するなら、たしかにそこに変化への柔軟性や進化が見られるだろう。

 

他方、巨大な事業を同時に複数のプロジェクトに分解する場合、そして各プロジェクトのスコープが皆確定している場合、どこにフレキシビリティーが保証されるのか? プロジェクト間の相互調整的なインタフェースだけでは、はなはだ限定的であることが分かるだろう。

 

ちなみに、日米欧の三国は、プログラムをどう定義しているか。米国Project Management Institute PMI)、英国Office of Government Commerce (OGC)、そして日本プロジェクトマネジメント協会(PMAJ)の標準書から、それぞれ引用してみよう:

 

米国PMI: The Standard for Program Management (2008)

A Program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.

 

英国OGC: Managing Successful Programmes (2007)

A temporary flexible organization created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits to the organization's strategic objectives

 

日本PM協会: 新版P2M標準ガイドブック (2007)

使命(ミッション)を実現するために、複数のプロジェクトが有機的に結合された事業。 - 「大規模システム型プログラム」と「戦略型プログラム」(創出・変革型)とに分類される(定常業務はサービスプロジェクトとして位置づけられている)。

 

文言はある程度似通っているが、標準書全体の文脈を含めて読み取ると、米国ではプログラム=「巨大なプロジェクト」というとらえ方が強いが、日欧では「事業を創出する諸活動」との文脈でとらえる傾向があるように、わたしには思える。その違いは、すなわちオープンエンドな、変化への適応能力(Adaptive Solution)の差違である。複数のプロジェクトを同時的にバンドルしても、それが主体的な適応能力や、スコープ・バウンダリーの拡がりを支援するものでない限り、それは「プログラム」の名前には値しないと考えられる。

 

逆に言うならば、別段、複数プロジェクトの形に分割されていなくても、そこに適応能力とフレキシビリティーを支える仕組みがあれば、それはプログラム・マネジメントだと呼んで良いだろうと、わたしは思う。いいかえれば、生みだす成果物の価値に応じて、スコープや、納期や、必要予算の枠さえ拡大できるような主体性の強さである。ただし、そうなると、WBSとかPERT/CPMとかEVMSとか、明確なスコープ・バウンダリーを前提するプロジェクト・マネジメント技法はそのままでは適用しづらいだろう。だから、ある程度、“固いスコープ”の部分と、“柔らかでオープンエンド”な部分を有機的に組み合わせていかざるを得ないだろう。

 

いずれにせよ、「プログラム」であるかどうかは、実行する側の主体性の強さによって定義すべきだとわたしは思うのである。

 

※バンドル(英語: bundle)とは、ある製品に対し別の製品が付属している状態で販売等をすること。

※顧客から指定されるScope, Cost, Scheduleの制約条件=『鉄の三角形』jと言う。

※ジョン・コッターの定義を借りて、

マネジメント:現在のシステムを機能させ続けるために、複雑さに対処すること

リーダーシップ:現在のシステムをよりよくするために、変革を推し進めること

 

プロジェクトがトラブって、火を吹くことは無論ある。そのとき、PMOのメンバーが火消しに行ったりはしない。PMOは現業に手を出さないのが鉄則である。手を出したら、当事者が「仕事のオーナーシップ」=当事者意識を失うからだ。他の部署から腕利きのプロマネをリリーフ投入して助けたりもしない。

 

ではどうするか。それは、プロマネの上司が問題解決に踏み込むのである。上司はそのためにいる。わたしの業界では、トラブルは建設段階になって吹き出すことが多い。したがって、プロジェクト部門の部長やら役員やらが、問題を起こした海外の建設現場に1年も2年も駐在して、陣頭指揮をふるう例を何度も見てきた。その人はプロジェクト・スポンサーである場合も、そうでない場合もある。希にはプロマネが途中交代になることもあるが、原則は職制上の上司がカバーすることになっている(その間、同じ部門の他のプロジェクトは、別の管理職が管掌することになる)。

 

問題解決は、マネジメントの職能の一つである。必須の、重要な職能だ。これができなければ、プロマネ達のマネジメントはできない。つまり上司である意味がない。

「成功したら、全部お前の手柄だ。でも万が一失敗した時には、骨は拾ってやる」--これがプロマネに与えるべき、一番大事なメッセージではないか。

プロマネの悩みは、プロジェクト・マネジメントよりも上位のレベルでこそ対応すべきではないか。それはすなわち、通常の用語では「プログラム・マネジメント」レベルということになる。そして、その仕事は(PMOなどではなく)職制上のラインが引き受けるべき仕事である。プロマネよりも一段階上のマネジメント・レベルの重要性に、もう少し皆が気づけばいいのにと、その時以来、わたしは思い続けているのである。

 

IT Mediaより

「プログラムマネジメント」とは、分かりやすく言うと「共通の目標を持つさまざまな取り組みを統合管理することで、組織の戦略的目標の達成を図るマネジメント手法」である。プログラムマネジメントは、上記のストーリーのような新規事業開発をはじめ、組織・業務改革、地域開発、企業合併といった“多様な活動が相互に連携することで大きな成果につながる取り組み”の中で生み出された知見である。

 

 本連載では、その中で特に新規事業開発の例、つまりソフトウェアベンダにおけるクラウド事業立ち上げを通じて、PMIR)のPGM標準の枠組みから、プログラムマネジメントのポイントを解説していく。ただ、標準にある学術的な定義や説明だけでは具体的な適用のイメージがわきにくい。そのため、PMIR)標準を金科玉条とするのではなく、研究会メンバーの実際の成功・失敗経験を入れ込むことで、プログラムマネジメントの重要性やノウハウを実感していただけるような展開を目指していく。

 

 市場競争が激化し、ビジネスの展開スピードも加速している今、なぜプログラムマネジメントが企業が勝ち残るための鍵となるのか?――では次のページから、さっそく本論に入ろう。

 

 “変革の成功“には、「変革後の姿が優れていること」と、「変革後へスムーズに移行すること」という2つの要素が必要だからだ。より具体的に言えば、「変革後の姿が優れていること」とは、「ビジネスモデル、マーケティングやビジネスプロセス等が、競合や既存のやり方に比べどのような優位性があるか」である。

 

 例としては、アスクルのSOHOをターゲットにした文房具翌日配達や、トヨタのカンバン方式導入などが挙げられる。アスクルは「細々した文具をいちいち買いに走るのは面倒」という庶務担当者の未発見のニーズをビジネスモデルに取り込み、トヨタは「後工程が必要な時に、必要なだけ生産をする」という考え方で、生産方式の在り方を大きく変えたのである。

 

 一方、「変革後へスムーズに移行すること」とは、「曲がりなりにも機能している現在の事業の在り方にとらわれず、変革に対する抵抗に負けずに、どう変革後の姿を構築するか」である。アスクルの例で言えば、「社内でアスクルの立ち上げを任されたリーダーが、どのように社内外の関係者を説得し、リソースを確保し、受注や配送といった事業の仕組みを築いて行ったのか」ということである。

 

  「変革後の優れた姿」については資料も多いが、「変革後への移行」については実践できるほど体系的に整理された資料は少ない。あっても「トップのリーダーシップが大切」といったような、属人的なエピソードにとどまるものが多い。後者は、言わば“改革の舞台裏”のことであるため、情報としてなかなか表には出てこないのだ。

 

 しかし現実には、何千万円もかけて作成した素晴らしい改革案や事業プランの多くが、実行途上や実行前に挫折している。この事実が、後者のノウハウが、前者に劣らないほど重要であることを示している。もちろん変革後の姿を正しく描くことがまず重要であるが、移行に失敗すれば、素晴らしいプランも「絵に描いた餅」になってしまうのだ。

 

 これを受けて、現在、多くのコンサルティングファームが、「戦略立案」から「実行支援」にサービスの重心を移しつつある。MBA取得者やコンサルタント出身者が増えたことで、企業側の戦略立案能力は高まってきた。しかし、「変革の実現」は立案とは異なるノウハウが求められる。そのため、コンサルティングファームを起用する理由として、彼らの有する“改革実現ノウハウ”がより重視されつつあるからだ。

 

 そして本連載で解説する「プログラムマネジメント」とは、まさしく後者の「変革後への移行」のノウハウとなるものである。具体的には、変革を実現するために、

 

  経営トップの期待を明文化し、期待に応えるために必要なミッションを定義する

 ミッションに沿って、組織や実行ステップ、必要な投資計画を立案する

 環境が変わり、当初の計画ではミッションの達成が危ぶまれる場合には、柔軟に計画を変更していく

 

 といった、“舞台裏に隠されたノウハウの集大成”である。

 

プログラムとプロジェクトの違い

 

 「変革実行の取り組み」は、従来「期限・予算の制約がある中で、要件・機能を実現する取り組み」である「プロジェクト」としてノウハウ化されてきた。しかし、建設やシステム開発など“アウトプットが明確な案件”を想定した「プロジェクト」と、変革実行という“より幅広い成果”を目指す「プログラム」では、案件の特性が大きく異なる。そのため、それぞれ異なるマネジメント方法が必要なのである。このため、プロジェクトマネジメントとは別の方法論として、日米欧各地域でプログラムマネジメント標準が開発されてきたのである。今、“競争力の源”として各地域で注目されているのだ。

 

 前のページで紹介した事例「A社のクラウド事業の立ち上げ」も、「達成すべき目標と時点が設定されていたこと」は「プロジェクト」と共通だが、「新たな事業の柱となることが期待されており、これを成功させるためには組織や業務のあり方に大きな変更を要すること」と、「クラウド事業はA社内にまだ知見が少なく、目標達成のために責任者には大きな裁量が与えられる――言い換えれば、柔軟かつ積極的な計画変更が期待されること」は、「プロジェクト」にはない「プログラム」特有の要素である。

 

 多くのプロジェクトは、“既存のビジネスの仕組み”――つまり組織やビジネスプロセス、ルールの中で行われる。受託開発プロジェクトであれば、営業が受注した後、要件定義、設計、開発、テストというステップで進んでいく。ある程度の規模の組織であれば、自社内で決められたルール、プロセスが存在し、それに従うことでスムーズにプロジェクトが遂行される。建設や新製品開発プロジェクトも同様である。

 

 しかし、新規事業開発や企業合併といったプログラムレベルの案件になると、これまでのビジネスの枠組み、つまりマーケティングや開発の方針をはじめ、組織、ビジネスプロセスを再構築する必要が出てくる。逆に、こういった再構築の必要がなければ「変革」とは言えないのである。

 

 また、マネジメント上の自由度についても違いがある。プロジェクトは原則として「計画通り」に進むことを良しとする。ベースラインの引き直しや、アプローチ自体を変更するのは「当初計画の失敗」を認めた上でのことになる。

 

 一方、プログラムレベルの案件は、重要度が高く、期間も比較的長いため、事業環境や自社の戦略の変化といった外的要因に影響される。例えば、営業戦略の再構築の場合、同業他社が合併をすることでシェア順位に変化があれば、自社ではあらためて市場分析を行い、必要に応じて方針見直しを提案することが期待される。これも当初計画をなるべく遵守することが望ましいプロジェクトとは異なる点である。

 

ポートフォリオマネジメント

ポートフォリオとは、「戦略的なビジネス目標を達成するための仕事を効果的にマネジメントすることを目的にグループとしてまとめられた、プロジェクト、プログラム、および関連業務の集合である」と定義されています。

ポートフォリオマネジメントとは「1つ以上のポートフォリオを一元化してマネジメントすること」と定義されています。

つまり、ポートフォリオマネジメントは、特定の目標を達成するために、プロジェクトやプログラムを特定し、優先順位を付けて実施の認可やマネジメント、コントロールを行うことを言います。

 

プログラムマネジメント

プログラムとは、「プロジェクトを個々にマネジメントすることでは得られない成果価値とコントロールを実現するために、調和のとれた方法でマネジメントされる相互に関連するプロジェクトのグループである」と定義されています。

プログラムマネジメントとは、「プログラムの戦略目標と成果価値を達成するために、調和を保ちつつ一元的にプログラムをマネジメントすること」と定義されています。

プログラムは、複数のプロジェクトを統合することで、より高い成果が期待できるプロジェクトをプログラムとしてマネジメントします。

そのため、各プロジェクトの関係が、単に顧客や納入社、技術、資源などを共有しているだけの場合は、プログラムとしてではなく、プロジェクトのポートフォリオとしてマネジメントすべきです。

 

プログラムのように複数のプロジェクトをマネジメントするためには、以下の点が重要になります。

 

 複数のプロジェクトに影響する資源の制約条件やコンフリクトを解決すること

 目的と目標に影響する組織的および戦略的な方向性を一致させる

 共通したガバナンスに従って課題解決、変更管理を行う

 

言葉の意味するところはイメージできるのですが、具体的な「行動」をできるようにするには、どうするとよいか・・・

つづく・・・To be continued!!!  m(_ _)m

 

2012年10月31日 (水)

要件定義はだれがどこまでを行うのか・・・

ときどき、システム化をするときに、最初から最後までをすべてITベンダーへお願いすることがあります。

ときどき、システムの要件定義は自分たちで行うのがよい、ITベンダーにお願いすると高いしね、と言われることもあります。

 

また、「大失敗プロジェクトの原因は“要件定義”にあり」と言われることも多いようです。

ユーザー部門・企業は「要件定義もできないのか」とITベンダーを非難し、ITベンダーは「ユーザー企業の要求が曖昧で…」と言います。

 

「要件定義」は誰の仕事なのでしょうか?

 

以下はネットで調べさせていただいた内容をサマリーしたものです。ご了承ください。
また、あらためて理解を深めることができました。ありがとうございました。
m(_ _)m

 

「要件定義」は言うまでもなく、システム仕様を確定させる作業である。

システム仕様は契約時に確定しているものだ。ソフト開発がモノ作りと発想すれば、製造業と同様、顧客の要求スペックが固まっていないのに契約することはあり得ない。従って「要件定義」、つまりシステム仕様の確定はユーザー企業の責任となる。今でも組み込みソフトの領域では、この原則はよく守られているはずだ。

 

一方、業務アプリケーションの領域では、こうはいかない。先進ユーザーの中には、「ITに関するビジネス上のニーズをシステム仕様に落とすのは自分たちの仕事」とする企業が少数ながらいる。

しかし、多くのユーザー企業がITに関して“アマチュア化”しつつあるために、システム仕様の確定を自ら行うのは難しくなった。ITベンダーも出来るだけ上流工程に進出したいために、曖昧なニーズの案件を「要件定義」から積極的に引き受けるようになった。かつてITベンダーにとって「要件定義」は、契約時に決まっているはずのシステム仕様の再確認作業だったが、今や本業中の本業になった・・・

 

ITベンダーが「要件定義」から請け負っておいて、「ユーザーの要求が曖昧だったので、要件定義がうまくいかなかった」と言っているようでは、プロフェッショナルとは言えない。ただ、この「要件定義」、システム仕様の確定作業はかつて、ユーザー業務にもITにも精通した情報システム部門が中心になって行っていた仕事だ。そのシステム部門が解体したり、システム子会社として外へ出されたりしたために、その穴を埋める形で、徐々にITベンダーの仕事となったわけだ。

 

*****

 

要件を定義する上では、エンジニアによる技術的な見解が必須であり、IT資源調達計画後に選定されたITベンダーをパートナーとし、外部リソースであるエンジニアにユーザの要求事項に対する次期システム要件を定義させます。もちろん、ユーザ部門・企業の合意が必要なのは言うまでもありません。

 

ユーザ側は経営戦略に整合したIT戦略の策定を行う中で課題を可視化し、自社(または自部門)の新業務プロセスをまとめます。そして、これを次期ITの要求事項としてSierに提示する形式的なもの要件定義書の一部(要求定義書)として作成します。要求の定義なしにユーザ側はITベンダーに「要件定義」をしろ、とは言えません。

 

もちろん、ユーザ側に技術力があれば要求定義から要件定義にまで発展させ、設計以降をどうするか考えることも可能でしょう。

 

「結論」としては、やはり ユーザー部門・企業とITベンダーとのインタラクティブなコミュニケーションによる共同作業と言えるのではないでしょうか。

 

最後に、それぞれのフェーズの定義も復習として書き留めておきたいと思います。

 

要件定義

requirements definition

 

システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などのを明確にしていく作業のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行う作業の一つである。

 

要件定義では、利用者(ユーザー)がそのシステムなどで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。

まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」設計・実装すべきかは、後の工程で検討される。

 

要件定義に先立って、利用者が業務を進める際に、そのシステムなどを使って何がしたいのか、何ができなければ困るのかといった内容を聞き取ってまとめる作業を「要求定義」というが、「要件定義」と「要求定義」を同義とする立場もあり、その場合は、このような利用者からの要求をまとめる作業も「要件定義」に含まれる。

 

基本設計 (外部設計と呼ぶ場合もある)

basic design

 

製品の基本的な設計。構成や仕様、機能などの概要をまとめたものを意味する場合と、中枢や基盤的な部分の設計を意味する場合がある。

 

汎用的な製品について言う場合には後者である場合が多く、「同じシリーズの製品は基本設計が共通している」というような用法となる。

 

情報システムやソフトウェアの受託開発などでは前者の意味である場合が多く、開発工程の中で「要件定義」と「詳細設計」の間に位置する工程を意味する。

 

顧客が必要としている要件をまとめた「要件定義」を元に、どのようなシステムを開発すればそれを満たすことが出来るかを検討し、機器の構成や実装すべき機能、画面や帳票など操作や入出力に関する事項、生成・保管されるデータの概要など、システムの基礎的な仕様をまとめたものを「基本設計」という。

 

「要件定義」と「基本設計」の違い

 

「要件定義」の一般的項目

 

・業務要件:現状、新業務フロー等

・システム要件:インフラ系を中心にネットワークやプロダクト等

・セキュリティー要件:セキュリティに関しての要求事項等

・機能要件:大まかな機能や、「これを実現して欲しい」等の要求

・運用要件:運用まわり、バックアップ、容量見積等

・その他:ケースバイケースで他に何かあれば

・昔はレスポンス要件等もあったがWEB等は保証できない

 

「基本設計」の一般的項目

 

・システム設計:インフラ、ネットワーク、機器構成、プロダクト構成等

・画面設計:デザイン、項目定義等

・DB設計:論理/物理設計、ER図等

・処理設計:DFD、IPO、URUD、コード設計等

・業務・運用設計:サービススケジュール、バックアップ、リカバリー方法、新業務フローの詳細等

・テスト設計:テスト方法、ツール等の設計

・その他:補足資料他

 

詳細設計 内部設計/プログラム設計と呼ぶ場合もある)

detail design

 

ソフトウェアや情報システムの開発工程の一つで、全体の構成や行うべき処理の詳細など実装に必要な仕様を定義する工程。方法論の違いにより、「詳細設計」に当たる工程を「内部設計」と呼ぶ場合もある。

 

詳細設計は基本設計と実装の中間に位置し、基本設計で定められた機能や操作・表示方法などに基づいて、プログラムやシステムとしてそれをどう実現するかを具体的に定めていく。システムやソフトウェアをどのような構成にするか、それぞれの部分がどのような処理を行うべきか、それら部分間の連携・統合の方法などを決めることが多い。

 

方法論によっては、どのような要素によって全体を構成するかを決定することを内部設計と呼び、それぞれの要素の細かい仕様や処理の詳細を定めることを詳細設計と呼んで区別する場合もある。この場合「、詳細設計」は「内部設計」の実装の中間の工程となる。

 

基本設計」と「詳細設計」の違い

 

 

                                   
 

工程

 
 

ドキュメント成果物

 
 

内容

 
 

基本設計(外部設計)

 
 

業務フロー

 
 

 
 

システム構成図

 
 

 
 

ER

 
 

 
 

テーブル定義書

 
 

 
 

機能一覧表

 
 

 
 

設計書記述様式

 
 

 
 

基本設計書

 

(外部設計書)

 
 

概要

 

I/O関連図

 

画面/帳票レイアウト

 

 

 

                                                                                                                                                               
 

ドキュメント

 
 

ドキュメント成果物

 
 

基本

 

設計

 
 

詳細設計

 
 

業務フロー

 
 

業務の流れを理解し、機能を洗い出す

 
 

 
 

 

 
 

機能一覧表

 
 

開発範囲となる機能(画面・帳票・バッチ)の一覧

 
 

 
 

 

 
 

ネットワーク構成図

 
 

システム構成を把握

 
 

 
 

 

 
 

テーブル定義

 
 

 

 
 

 
 

 

 
 

ER

 
 

 

 
 

 
 

 

 
 

画面遷移図

 
 

画面遷移を図示

 
 

 
 

 

 
 

機能設計書

 
 

機能別の設計書

 
 

 
 

 
 

(表紙)

 
 

 

 
 

 
 

 
 

(目次/概要)

 
 

 

 
 

 

 
 

 
 

I/O関連図)

 
 

データと機能の関係を図示

 
 

 
 

 

 
 

(画面レイアウト)

 
 

画面イメージ

 
 

 
 

 

 
 

(帳票レアイウト)

 
 

帳票イメージ

 
 

 
 

 

 
 

(フローチャート)

 
 

バッチ処理のフローチャート

 
 

 

 
 

 
 

(項目説明書)

 
 

画面/帳票の項目説明

 
 

 

 
 

 
 

(イベント一覧)

 
 

画面操作で発生するイベントの一覧

 
 

 

 
 

 
 

BL一覧)

 
 

機能に含まれるBL(ビジネスロジック)の一覧

 
 

 

 
 

 
 

(更新仕様書)

 
 

機能またはBL単位の更新・処理内容を記述

 
 

 

 
 

 
 

(補足説明諸)

 
 

上記の記述に対する補足説明

 
 

 

 
 

 
 

設計書記述様式

 
 

設計書の記述方法の説明

 
 

 
 

 

 

 

そして、いざ、開発(製造)へ!ザ・メイキング!

(* ̄0 ̄)ノ

 

2011年3月 5日 (土)

システム統合リスク管理態勢の確認検査用チェックリスト

みずほ銀行の合併対応(2002年(平成14年)41日)におけるシステムトラブルを教訓として、同年12月にできたものです。

金融庁のホームページ、「金融制度・検査・監督の枠組み」に掲載があります。

銀行に限らず、保険業界の場合であっても対象として合併時には考慮をする必要があります。

とくに平時とは異なる『特別な態勢・対応』が求められてきます。

認識しておきたいので、とくに平時とは異なるポイント、合併対応をする際に、普通に自然に進めているところでは見落とす可能性のあるポイントを整理しておきます。

「♪」では、少しコメントを加えてみています。

*****

統合プロジェクトを統括管理する役員及び部門(以下、()「統合プロジェクト」とは、統合に「統括役員及び部門」という。)を定め、以下のような体制を、協調して整備しているか。

 広報体制

 顧客に対して適切な情報開示が行われる体制

 顧客からの問い合わせに対して適切に対応できる体制

統合方針に基づき、システムの統合方式、及び統合後の

組織体制、

金融商品・サービス体系、

システム構成、

営業部店網、

事務センターの構成等

のビジネスモデルを明確にし、組織全体に周知しているか。

また、当該ビジネスモデルは、取締役会の承認を受けたものとなっているか。

()「ビジネスモデル」とは、統合方針の下位概念である。

()取締役会は、統合対象金融機関等各々における取締役会を指す。

統合計画及び実行計画の策定

()「統合計画」とは、統合プロジェクトの根幹を成す計画で、経営統合全般に係る計画をいう。

()「実行計画」とは、統合計画をもとに策定される、より細部にわたる計画をいう。ただし、「統合計画」と別に策定されたものか否かを問わない。

統合プロジェクトの移行判定

()システムの移行判定のみならず、統合後に業務としてリリースできるかどうかについて、より慎重に判定しているかどうかを検証する必要があることに留意する。

業務の移行判定基準(システムの移行判定基準を含む。)(の策定)

セキュリティ管理体制の整備

 セキュリティ管理者は、統合対象金融機関等間におけるセキュリティ水準の差異を的確に認識し、必要に応じて基準等を見直しているか。また、統合後の業務を前提としたセキュリティ水準を確保しているか。

 セキュリティ管理者は、見直した基準等のうち、統合前に適用可能なものについては、それに従ってセキュリティが適切に確保されているかを的確に把握しているか。

 システム統合やセンター設備の設置・拡充を必要とするなど、見直した方針等の適用に時間を要する場合、セキュリティ確保のための適切な代替策を講じているか。

 統合対象金融機関等間でのテストなどにおいて本番用顧客データ等の重要データを使用する場合について、当該データの貸与に係る方針、手続きを明確に定め、取締役会等の承認を受けているか。

また、当該方針に基づきデータ貸与先との間で守秘義務契約を締結するなど、顧客データの管理は適切に行われているか。

 本番データの貸与に際しては、手続きに従った運用がなされるなど、セキュリティが適切に確保されているか。

事務部門の組織整備

 システム統合に当たり整備が必要となる事務規定を整備する部署を明確にしているか。

 事務処理に係る営業部店からの問い合わせに迅速かつ正確に対応できる体制を整備しているか。

 システム統合後に事務量が増大する可能性が高いことを認識し、十分な事務処理能力を確保できる体制を整備しているか。

用語の統一と事務規定の整備

事務規定は、システム統合後の業務を網羅し、かつ法令等に則り整備されているか。

()事務規定等の整備については、システムテスト(総合テスト、総合運転テスト)の開始までに、テストに必要な範囲で完了している必要があることに留意する。

サービス体系の整備

顧客において手続きの変更が必要となる場合、その手続きが所定の期間内に完了するよう、適切な方策を講じているか。

顧客データの整備

統合対象金融機関等間において顧客名等の登録内容が異なる場合、その違いを認識し、登録内容を整理するなど、適切な方策を講じているか。

♪可能な限りの「データクレンジング」ですね

企画・開発・移行の体制

・業務要件の変更等が必要となった場合の手続きが明確に定められているか。

・各工程の検証及び承認ルールを明確にしているか。

・統合後のシステム及びセンターの構成を明確にしているか。また、システム構成を二重化するなど、安全面に十分に配慮しているか。

・統合後のシステムで使用するファイルやデータベースを具体的に決定しているか。

・既存システムで使用しているファイルやデータベースを照合し、データ項目毎に、プログラムによって移行可能な項目と、移行に際して手作業が必要となる項目を明確にしているか。

・統合後にデータ処理量が増大することを認識し、バッチジョブの処理時間やハードウェアの処理能力等を十分に検討した上で、運用部門と連携を図りシステムを設計しているか。また、想定される事務量を適切に処理できるだけのハードウェアを確保しているか。

・開発計画や体制を具体的に定め、取締役会等の承認を受けているか。また、開発計画は期限を優先するあまり、リスク管理を軽視したものとなっていないか。

・開発計画では、データの移行計画や体制等を具体的に定めているか。また、移行計画には本番を想定した訓練が織り込まれているか。

システム開発の管理

システム統合作業における開発に関わる書類やプログラムの作成方式を標準化しているか。

♪どこまでを標準化するかは「判断」できるのではないだろうか。例えば、開発案件整理・調整資料は、必然的に統一がされるだろうし、統合用のシステム開発プロセスも同様に考える。また、もし、統合する各社のホストの種類が異なる場合には、合わせられない作業もあるだろう。

マニュアルやドキュメント類は、統合対象金融機関等間で理解ができるものとなっているか。

()外部委託先においても、理解ができるものとなっている必要があることに留意する。

♪通常、各個社においては、外部委託先における理解は可能と考えている

テスト等

 テスト体制」を整備しているか。

 レビュー実施計画」を策定するとともに、工程毎のレビュー実施状況を検証し、品質状況を管理しているか。また、その結果に基づく問題点の把握課題管理を適切に行っているか

 テスト計画」を策定しているか。

 テスト計画には、関係諸機関や対外接続先とのテストが含まれているか

 テスト計画には、「負荷テスト」、「障害テスト」等が含まれているか。

 品質管理基準」を設定し、テスト結果を検証しているか。

システム統合後のシステムオペレーションについて、十分に訓練を実施しているか。また、訓練にはユーザー部門も参加しているか。

♪各種の「トレーニング計画」が必要になると考えています。

()ユーザー部門とは、事務部門、システム部門のみならず、事務センター、コンピュータセンター、営業部店等を含むことに留意する。その上で、全ての関係部署間の連携が十分に機能しているかを検証する必要があることに留意する。

コンティンジェンシープランの整備

 既存のコンティンジェンシープランについて、システム統合後のシステムの構成や組織体制に基づいた見直しを行った上で、取締役会の承認を受けているか。

 コンティンジェンシープランの発動権限者及び発動基準は明確に定められているか。

 コンティンジェンシープランに基づく訓練は実施されているか。なお、統合後の体制をできるだけ早い段階で明確にした上で、訓練を実施していることが望ましい。

統合日前後における不測の事態への対応

 システム統合日前後における不測の事態への対応プラン(システム統合の中止を含む。)を整備しているか。また、それは、取締役会の承認を受けているか。

 当該プランには、移行開始後における不測の事態への対応が含まれているか。

 当該プランの発動権限者及び発動基準は明確に定められているか。

 当該プランに基づく訓練は実施されているか。

内部監査

「業務監査及びシステム監査」を行うことができる体制となっているか。また、システムの開発過程等プロセス監査に精通した要員を確保しているか。

内部監査部門は、必要に応じて業務監査とシステム監査を連携して行うことができる体制となっているか。

「監査計画」については、統合プロジェクト開始段階からの計画を含んでいるか。

第三者評価機関

取締役会等は、システム統合に係る重要事項の意思決定に際しては、第三者機関による評価を活用しているか。また、システム統合に限らず、統合プロジェクト全般についても、第三者機関による評価の対象としていることが望ましい。

*****

以上、整理をしてみました。

最近は、メガバンクが増えて、それに合わせて?保険業界も合併等によるメガ化が進んでいるように思います。これにより、社会が良くなっていくのであれば良いのですが、少なくとも合併時においては、All happyWin Winとはいかない場面もあるように思います。

業界という視点で言えば、独占化が進み、戦前の財閥による独占・寡占に類似してきているようにも思います。

考えすぎでしょうか?

2011年1月15日 (土)

ムダのないソフトウエア開発 アジャイル開発を実践する22の方法

Agile(アジャイル)とは「すばやい」、「機敏に」という意味ですが、「アジャイル開発」という時には、それ以前によく言われる、「プロトタイプによる開発」、「スパイラルによる開発」に加えて、さらにムダを排除したような方法と捉えています。

プロジェクトチームにチームワークがあり、コミュニケーションが円滑にできる場合には、適していると思いました。

7つの原則を7つの章として、そこに22の実践方法を紹介されている。

その中で、「人」に関するところをメモしておきたい。

原則1-ムダを排除する

付加価値を生まないプロセスは不要である

誰も読もうとしないペーパーワークは、価値を付加しない

原則2-学習効果を高める

フィードバック、イテレーション(くり返し、反復)、同期を活用する

原則3-決定をできるだけ遅らせる

コンカレント開発は、通常、反復型の開発形式をとる。

コンカレント開発によって、コミットメントを最終責任時点まで遅らせることができるようになる。

意思決定

問題の解決には、二つの戦略がある。広さ優先か、深さ優先かだ。

本著では“広さ優先”を推奨しているようです。

広さ優先手法では、詳細がどうなりそうかを理解するための「専門知識」と、確定すべきタイミングを知る手腕のある「人」が欠かせない。しかし、広さ優先手法では、問題領域は安定していなくてもいい。むしろ、そのビジネス分野が発展し続けると考えられる場合に向く手法なのだ。ただし、広さ優先手法は、問題領域が安定している場合にも、効果的な手法である。

原則4-できるだけ速く提供する

原則5-チームに権限をあたえる

リーダーシップ

プロジェクトリーダーの仕事とは

まず、ムダを認識し、

現在の開発プロセスのバリューストリームマップを描き、最も大きなボトルネックに取り組む。

そして、イテレーション計画ミーティングや毎日の状況報告ミーティングを調整し、情報発信器を提供し、チームがコミットメントを果たすために必要とするリソースを調達する。

また、複数チーム間で同期がきちんと定期的にとれていることを確認し、複数のチームの調整をする。

開発環境に、ソース管理や自動テストなどの標準的なツールが揃っていることを確認し、リファクタリングや統合化された受入れテストが実施されていることを確かめる。

「会計係り」といっしょに収益モデルを作成し、チームが的確なトレードオフをおこなえるようにする。

モチベーションを高める環境を提供し、懐疑主義者を寄せ付けず、成功や作業の節目に喜びあい、夜にはチームメンバーを家に帰す。

アジャイルプロジェクトでは、プロジェクトリーダーが重要な役割を果たす。その役割は、小刻みなマイルストーンを付けたり、リリースプランを作って、イテレーション毎のコミットメントを満たすことに焦点を当てる。

スコープが徐々に膨らむことに気をもむ代わりに、エレガントさが徐々に失われることに気を配る。

変更承認プロセスを気にするのではなく、変更に強い設計プラクティスを気にかける。

プロジェクトリーダーは、テストと統合を、分離された後工程としてではなく、開発の一部として確実に行わせる。

また、導入やトレーニング、顧客サポートに関わる人たちが、プロジェクトの最初から十分に参加しているようにする。

原則6-統一性を作りこむ

原則7-全体を見る

部分最適ではない、全体最適を目指す

以上です。

より以前の記事一覧

その他のカテゴリー

フォト
2017年11月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

最近のトラックバック

ウェブページ

ライフネット生命

無料ブログはココログ

Twitter

  • twitter