社内SE−ミニミニ管理者によるシステム管理者奮闘記ブログです。これまで私が社内SE(システム管理者)として経験してきたシステム管理やハードウェア・ネットワークといったインフラ関連から、システム構築におけるプロジェクト管理・プロジェクトマネジメント(PMBOK)、エクセル・アクセスといったオフィスソフト、オラクル等のDBMS、ファシリティ等などシステムに関する幅広いことや失敗談や悩みなどを皆さんと共有していきたいと思ってます。目指すはCIO!定期的に更新していきますので皆様、応援お願いします。VPN、iPad3、iPhone5、エクセルセーフモード、taskkill、Windows7システム修復、ブルースクリーン、サーバールーム、ラッキング、OutlookExpressメールが消えたなどです。]スポンサードリンクプロジェクトスポンサと変革趣意書を作成するプロジェクト憲章(会社によってはシステム化計画とか、事柄稟議書などプロジェクトが正式に了承されたら、プロジェクトスポンサにヒアリングする機会を作るべきです。その際にはプロジェクト発足に至る経緯や求めていること、目的などと一緒に以下の観点も議論して、変革趣意書を作成して合意しておけると良いと思います。変革趣意書のポイント�プロジェクトの観点からなぜこのプロジェクトをやるのか?�なぜ、いまこのプロジェクトをやるのか?問題は以前からあったはずで、このプロジェクトを優先的に取り上げる切っ掛けは何か?�プロジェクトが成功しなかったら何が起こるか?�プロジェクトをやることによるビジネス上のメリットは何か?�やり方を変えるとしたらどこか?PMチームで作成して、ユーザーに手を加えてもらい、プロジェクトスポンサに説明し、合意を得る。プロジェクト憲章と変革趣意書をベースにプロジェクト計画書を作成します。Rankingブログランキングに挑戦中です。]スポンサードリンクソフトウェア開発における品質管理と評価方法ソフトウェアの品質の評価にはどのような視点が必要だと考えてますか?最も使われる評価指標としては設計書やプログラムの不具合(バグ)の数値による評価があるかと思いますが、それだけでは不十分です。特定の作業フェーズ(WBS)での不具合の件数だけで捉えることだけでも不十分です。ソフトウェアの品質は種々の要素から評価をし、さらに変動を捉えていくことが必要です。それを全ての機能において実施していくことも作業効率の点から好ましくありません。「ソフトウェアの品質とは何か、どのような視点で品質を管理し評価していくことが必要であるのか」を説明いたします。その後、プログラム品質管理の考えます。考え方として、品質基準とする各要素の考え方および品質の変動状況の捉え方について深く考える。その考えを元に計画時点で検討すべき事項が何であるかが分かります。品質基準の要素としては、チェックリスト(テストケース)件数と不良(バグ)件数にプラスして管理すべき必要な観点があります。ソフトウェア品質管理の目的1「ソフトウェアの品質」についての理解を深める。2「ソフトウェアの品質」を向上させるための方法を理解する。➡開発規模に応じた適正なバグ件数を検出することを目標とする。総合的な品質評価の考え方と留意点−バグ0件は品質が良いのか➡試験シナリオが適切でないため、バグを検出できていないと考えるべき。6.まとめ−最初に仮説を立てることが重要−ツールによる効率化やチェックリスト適用の利点と欠点<品質評価>プログラムに関する各種データ(規模、工程別のテスト結果等)を見て、品質が保持されているのかどうかを評価します。「懸念」が残るプログラムがあれば、その理由および品質評価をさらに行なうために確認すべき事項を整理し、品質に問題ありと評価された場合には追加試験を計画します。※追加試験は品質向上(Q↑)のために、期間延長(D↓)、コスト増加(C↓)となることに留意します。そのため、このプロジェクトでは「QCDのうち何が最も重要な指標」であるかをプロジェクトスポンサに確認しておき、変革趣意書にまとめておくのも良いと思います。Rankingブログランキングに挑戦中です。]スポンサードリンクステージゲート/関門(PMBOK)PMBOKやプロジェクト管理におけるステージゲートという言葉をご存知だろうか。このステージゲートは、経営用語として一般的な用語です。ステージゲート法ステージゲートは、新規事業や新製品のアイデアが生まれてから、事業化・製品化されるまでに必要なステップと作業ロードマップを与える考え方です。特徴は、開発プロセスの途中の過程で経営判断を行う「ゲート」によってステージに分けていることです。この方法では、機能組織に合せたステージはなく、ステージは基本的に組織横断的なプロジェクトで構成され、ゲートに進むために必要な作業は並行して行われます。オペレーションなどのリスクの管理をするために、必要な情報が収集されていきます。ゲートのもっとも重要な役割は、評価の低いプロジェクトを中止し、そのリソースを見込みのあるプロジェクトに再配分する。ゲートにおける評価は、ステージで生まれた成果の質、経済合理性などに注目し、それぞれのプロジェクトがどの程度の成功をおさめるかを評価します。イノベーションでは、この評価とリソースの再配分が成功の分岐点になるのです。このステージゲート法をITにおきかえて考えます。ステージ≒工程やフェーズとすると、「プロジェクトフェーズ/工程の1つが終了したら、そこまでの成果物とパフォーマンスを検討して、プロジェクトを先に進めるかどうかを判断」することになります。このステージゲートは品質管理や調達マネジメントの観点からも重要なポイントです。このステージゲートのイメージを工程別に記載します。作成して、ユーザーを含めて実施するインスペクションによるレビュと合意形成。(外部設計にあたる画面定義や画面項目定義、インターフェース定義など)を作成して、ユーザーを含めて実施するインスペクションによるレビュと合意形成。その結果、基本設計書への開発実施責任者などの権限者による押印などの承認行為。開発実施責任者などの権限者による押印などの承認行為。会社によりPMOも参加する。け入れ試験などによる機能要件やシステム環境、業務フローによる業務継続性の検証などの結果報告と開発実施責任者などの権限者による押印に加え、受け入れ側による承認行為。会社によりPMOも参加する。(実際に独自のシナリオにて試験を実施することもある。)本番移行工程UAT(受け入れ試験)結果報告と共に本番環境への摘要是非を問う本番環境リリース判定や、システム切替などのタイミングにて実施する移行判定や初回稼働確認による移行完了確認など。Rankingブログランキングに挑戦中です。]スポンサードリンク世界一わかりやすいプロジェクトマネジメント本書は当社での社内大学情報システム学部プロジェクトマネジメントコースのテキストや経験豊富なPMPホルダーによるプロジェクトマネジメント講習会でも必読書として紹介されている書籍です。「名ばかりのプロジェクトマネジメント」ではありませんか?これらにより、引き起こされるのは「開発したシステムが稼働しない・バグ多数」「要望通りの機能ではない・業務では使えない・機能要件にマッチしない」などです。要は無駄な投資になる。一般企業の情報システム部門では取り入れ出来ていない・受け入れ出来ていない・正しく活用出来ていないのは、プロジェクトマネジメントの必要性や使い方への理解が足りていないことです。ここで今一度、必要性について再認識してもらう必要があると思っています。第4版」は、プロジェクトマネジメントの必要性を分かりやすく説いている優良書といえます。PMBOKガイドでは理解しにくい表現(英訳が分かりにくい)も多く読みにくい印象ですが、本書は読みやすい表現になっているため、PMBOKガイドを読む前に「PMBOKの概要」や「プロジェクトマネジメントとは」を理解するのに適しています。これからPMBOKを勉強する人やプロジェクトマネージャを目指す人は必読・必携です!なお、実践でも役立つ経験則やらヒューマンスキルなどもフォローしています。以下、出版社(総合法令出版)のホームページより抜粋。内容紹介アマゾンジャパン「オールタイムベストビジネス書100」に選ばれた名著の最新版!プロジェクトマネジメントとは、「ヒト」「モノ」「カネ」を適切に管理し、プロジェクトを納期どおりに完成させ、かつ想定したどおりの利益を生み出す活動のこと。Management」の最新バージョンの日本語訳版がついに登場。プロジェクトマネジメントの各フェーズごとに、想定されるリスクを乗り越えて成功に導くための具体的ノウハウやツールを紹介。プロジェクト・マネジャーとしてチームを率いていくためのアイデアを実践的に提供する。プロジェクトマネジメントのデファクトスタンダードである「PMBOK」の最新第5版に完全準拠しているので、グローバルなプロジェクトにも対応。アマゾンジャパンが昨年10月に選出した「オールタイムベストビジネス書100」の中で、プロジェクトマネジメント関連で唯一選出された、プロジェクトマネジメントの基本中の基本書である。Rankingブログランキングに挑戦中です。]スポンサードリンクRACI(レイシー)チャート/PMBOKRACI図やRACIチャート、レイシーチャートをご存知だろうか。プロジェクト経験者なら感じていることだが、プロジェクトはある一定の期間にて独自の成果物を生み出す活動ですが、その間には工程が変わることでプロジェクトメンバーが交代/入れ替え、入場退場が繰り返されます。工程の切り替わりでチームの交代/引き継ぎ(企画から開発、開発から運用)なども、それにあたります。このような状況での課題解決をイメージしてみて下さい。その都度、その都度で状況がかわり、「誰に何を聞いたら解決するか?」といった単純なことで時間を費やすことが多いです。その解決策として、RACI図(RACIチャート、レイシーチャート)は使えます。diagram)は、プロジェクトや何らかの工程をチームあるいは人々に役割分担させる際に使用される図の一種である。複数の組織が共同で行うプロジェクトマネジメントなどで、役割分担を明確化するのに特に有効とされる。RACIチャートとも。プロジェクトの各タスクについて、関係者がどのような役割を担っているのかを明確にするために使われます。RACI図は、タスクを4種類の参加者の責任型に分割する。プロジェクトや工程毎に各参加者には異なる役割が割り当てられる。タスク達成のために働く責任者。複数のリソースについて責任を持つことがある。タスクの正しい完了について外部からの問合せに対して責任を持って対応する。各タスクの窓口は1つでなければならない。