2010年02月の記事一覧 | ビジネス書はこれを読もう

ずっと受けたかったソフトウェアエンジニアリング新人研修

ずっと受けたかったソフトウェアエンジニアリングの新人研修ずっと受けたかったソフトウェアエンジニアリングの新人研修3章要件定義と要求定義　□ 非機能要求の分類　　１）機能性　　　・必要な他システムとの接続できるか、適切なセキュリティは確保されているかなど　　２）信頼性　　　・潜在問題を回避する能力、故障時にデータを回復する能力、など　　３）使用性　　　・利用者が使い方など理解しやすいか、標準の使い方に沿っているかなど　　４）効率性　　　・適切な応答時間で反応するか、適切なメモリ利用量か、など　　５）保守性　　　・欠陥の診断や問題箇所の識別ができるか、必要な修正が加えられるか　　６）移植性　　　・異なる環境でも使えるか、他のソフトと共存できるか、など　　７）障害抑制性　　　・障害の発生を妨げるか、障害の広がりを妨げるか、など　　８）効果性　　　・投資効果は十分か、など　　９）運用性　　　・品質目標をクリアしているか、災害対策は十分か、など　１０）技術要件　　　・技術要件システムの構成は適切か、開発標準は適切か、など　□ 要件定義書の記述項目　（必須）　　　１）背景　　　２）課題　　　３）目的・方針　　　４）概要　　　５）機能　　　６）システム化の範囲　　　７）導入・移行計画　　　８）運用・保守　　　９）工程計画　　１０）体制　　１１）成果物　□ 要件定義書の記述項目（オプション）　　　１）ユーザインターフェース　　　２）システム構成　　　３）作業標準　　　４）品質管理　□ 可能な限り定量的に書く　□ 「しないこと」も明記する第４章システム提案　□ システム提案の記述項目　　　１）背景　　　２）課題　　　３）目的・方針　　　４）概要　　　５）機能　　　６）システム化の範囲　　　７）システム構成　　　８）ソフトウェア構成　　　９）ハードウェア構成　　１０）ネットワーク構成　　１１）システムインターフェース　　１２）導入・移行　　１３）運用・保守　　１４）作業標準　　１５）品質管理　　１６）工程管理　　１７）体制　　１８）費用・工数・規模　　１９）成果物　□ システム提案記述項目（オプション）　　　１）ユーザインターフェース　　　２）開発環境第５章外部設計　□ 外部設計書の作成手順　　　・個別の設計書を作成して、最後にそれらをまとめる　　　１）業務フローの作成　　　２）サブシステムへの分割　　　３）画面レイアウトや帳票レイアウトの作成　　　４）コード設計　　　５）論理データ設計（ER図、CRUD図作成）　　　６）システムインターフェース　　　７）外部設計書として取りまとめる　□ 外部設計書に含める項目　　　１）目的・方針　　　２）概要　　　３）機能　　　４）ユーザインターフェース　　　５）システム構成　　　６）ソフトウェア構成　　　７）ハードウェア構成　　　８）ネットワーク構成　　　９）システムインターフェース　□ 外部設計書のレビューは外部設計書と同じくらい時間を要するようです。　第６章内部設計書　□ 内部設計書の作成手順　　　・個別の設計書を作成して、最後にそれらをまとめる　　　１）画面の詳細設計　　　２）帳票の詳細設計　　　３）外部インターフェースの詳細設計　　　４）ビジネスルールの詳細設計　　　５）リクエスト処理の詳細設計　　　６）メッセージの詳細設計　　　７）物理データ設計　　　８）内部設計書としてまとめる　□ 内部設計書のレビューでは顧客が入ることはありません。　□ 内部設計書に記述する項目　　　１）ユーザインターフェース　　　２）プログラム構造　　　３）データ構造　　　４) 処理ロジック　　　５）メッセージ　　　６）システムインターフェース　　　７）ネットワーク構造　　　－－－必要に応じて　　　８）機能　　　９）システム構成　　１０）ソフトウェア構成　　１１）ハードウェア構成　　１２）ネットワーク構成第７章　製造　□ 製造工程の作業手順　　　１）プログラミング　　　２）ソースコードレビュー　　　３）単体テスト　□ ソースコードレビューのチェックポイント　　　１）規約に沿って書いていあるかどうか　　　２）正しいロジックでかいてあるかどうか　□ コーディング規約　　　１）プログラムの冒頭に付けるコメントの記述ルール　　　２）変数名の付け方や宣言方法に関するルール　　　３）プログラムロジックの記述ルール　　　４）変数型のルール　□ ホワイトボックステストでは、プログラムのすべての分岐を通るようにテストデータを作成するので、プログラムを網羅的にテストできるというメリットがあります。第８章テスト　□ テスト工程で行うこと　　　１）テスト計画書の作成　　　２）テスト環境の準備　　　３）テスト項目の作成　　　４）スタブ、ドライバーの作成　　　５）テストの実施　　　６）不合格項目について障害処理票を作成　　　７）バグ除去　　　８）バグ分析　　　９）テスト成績表の作成　□ 結合テストのテストデータはブラックボックステストの技法を使って作成します。　□ ブラックボックステストの代表的技法　　　１）同値分割　　　　・データをグループ分けし、各グループから１つまたは複数のデータを抽出したものをグループを代表するテストデータとする。　　　２）境界値分析　　　　・有効と無効の境界値データを取り出してテストデータとする　　　３）エラー推測　　　　・経験的に知っているエラーが起こりやすいパターンからテストデータを作る。　□ 総合テストでは、要件定義書、外部設計書の内容が実現できているかどうかを確認します。　□ 総合テストに必要な観点　　　１）処理性能　　　２）障害回復性能　　　３）保守運用性能　　　４）操作応答　　　５）過負荷時動作第９章受け入れテスト　□ 受け入れテストの作業手順　　　１）テスト計画書の作成　　　２）テスト項目の作成　　　３）テスト実施　　　４）テスト成績書の作成 □ 受け入れテストを効率的に行う方法　　　１）開発会社にすべてのテストのテスト項目表を提出してもらい、丁寧かつ網羅的にテストが行われていることを確認する　　　２）開発会社の結合テスト以降の障害処理票を提出してもらい、十分な数の障害処理が行われたことを各hにんする。　　　　　これにより、テストの有効性を判断する。また、障害処理の内容から開発会社のプログラムレベルを推察する。　　　３）障害処理票から、いくつかの処理済み項目を抜き出して再テストし、実際にバグが除去されていて、テストに合格することを確認する　　　４）要件定義書や外部設計書を見ながら、いくつかの独自のテスト項目を作成し、テストを実施する。　第１１章品質管理　□ メトリクス（品質尺度評価）の例　　　１）レビュー工数　　　　・全工数に対するレビュー工数の割合　　　２）テスト工数　　　　・全工数に対するテスト工数の割合　　　３）レビュー実施効率　　　　・レビュー工数に対する指摘件数の割合　　　４）テスト実施効率　　　　・テスト工数に対するバグ件数の割合　　　５）設計工程バグ摘出数　　　　・設計工程で発見・解決したバグ数　　　６）レビュー時の誤り密度　　　　・開発規模（総ステップ数）に対する指摘件数　　　７）レビュー網羅率　　　　・開発規模（総ステップ数）に対するレビュー対象部分の割合　　　８）レビュー時の平均修正時間　　　　・レビューで発見された誤りの修正にかかった時間の平均　　　　９）テスト時のバグ密度　　　　・全テスト項目数に対するバグ件数の割合　　１０）テスト時のバグ収束率　　　　・バグ予測件数に対する総バグ件数の割合　　１１）テスト密度　　　　・ステップ数に対するテスト項目の割合　　１２）テスト網羅率　　　　・テストされた部分の割合。ステップ数やパス数などで算出　　１３）平均バグ寿命　　　　・バグ修正までにかかった時間の平均　　１４）テスト消化率　　　　・全テスト項目に対する実施済みテスト項目の割合　　１５）バグ摘出率　　　　・目標バグ数に対する実績バグの割合　□ 一般にレビューは２時間程度が限界と言われています。　□ レビューで確認すること　　　１）「ですます調」か「である調」に統一されていること　　　２）「てにおは」の使い方が正しく、統一されていること　　　３）用語の定義が明確でぶれていないこと　　　４）数値に単位が付いている　　　５）版数が付いている　　　６）フォント、スタイル、文字サイズが規則通りである　　　７）表現が顧客の要請に一致している　□ テスト計画書の作成　　　１）品質目標　　　２）テストスケジュール/場所　　　３）テスト指標（目標）　　　４）終了条件　　　５）合格条件　　　６）テスト対象　　　７）テストケース　　　８）成績表　　　９）テストツール　　１０）テスト体制　　１１）テスト環境□ テスト項目　　　１）機能テスト（機能の確認）　　　２）信頼性テスト　　　３）性能テスト　　　４）操作性テスト　　　５）複合テスト　　　６）繰り返しテスト　　　７）統合テスト第１２章　セキュリティ　□ 設計段階で考慮するセキュリティ１）主体認証に関する要件２）アクセス制御に関する要件３）権限管理に関する要件４）監視・分析用アクセスログに関する要件５）不正アクセスなどの監視要件（侵入検知システムネットワーク型IDS、ホスト型ＩＤＳの種類監視場所など６）ファイアーウオール設置に関する要件（ファイアーウオールの種類（ハード型/ソフト型）の種類監視場所など７）ウイルス対策要件８）暗号化要件（伝送メッセージ、データベース、外部連携データなど第１３章プロジェクト完了報告　□ 経営陣の立場で考えよう　　　

ドキュメント・レビュー!!要求仕様書・設計書のレビュー実践とチェックポイント

ドキュメント・レビュー!!要求仕様書・設計書のレビュー実践とチェックポイントドキュメント・レビュー！！要求仕様書・設計書のレビュー実践とチェックポイント第１章システム開発上流工程と主要なドキュメント　□ システム仕様書　　１）システムの目的や達成すべき目標　　２）現状分析と課題やニーズ　　３）新旧業務フロー　　４）用語と定義　　５）データモデル図　　６）ユーザ・インターフェース条件　　７）メッセージ表　　８）機能要求　　９）機能外要求　１０）運用要件　１１）移行要件　１２）システム構成図　１３）制約事項　□ 機能要求と機能外要求をまとめて国際基準では「ISO/IEC9126（JISX0129)ソフトウェア品質特性」として定義している　□ 設計書はシステムに対する要求を実現するためのアーキテクチャや構成要素の組み合わせなどを記述する　□ 設計書　　１）システムの目的や達成すべき目標　　２）システムの概要　　３）設計方針　　４）用語と定義　　５）コード設計　　６）入出力設計　　７）ソフトウェア構造図　　８）ソフトウェア一覧表　　９）インターフェース設計　１０）データベース設計　１１）ユーザ・インターフェース設計　１２）メッセージ設計　１３）機能設計　１４）機能外設計　１５）運用設計　１６）移行設計　１７）システム構成設計　１８）制約事項　□ 環境変化の激しい時代だからこそ、開発にも運用にも小回りの利くシステムが必要であり、統合データベースはいかにも、小回りや融通の利かない重厚長大な感じがする。　□ システムでは基礎にあたるのは、データベースとアーキテクチャである。　□ 情報処理の基本は5W2Hである。　□ 戦略とはシナリオの仮説である　□ 「学習と成長」→「内部プロセス」→「顧客」→「財務」というように下からシナリオをつなげて戦略を策定してもよい。　□ システム＝人間系＋機械系　□ ビジョンや経営戦略→業務体系→データ体系→アプリケーション体系→技術体系　□ 市場変改に応じて、迅速かつ柔軟に変化し、無駄な動きがなく、効率良く入力を、出力に変換できるフィードバック制御システム　□ しっかりと目的や目標が明確になっており、全体から細部へと構造化されており各要素の因果関係が明確で、論理が自然な思考の流れや時系列に沿っており、整然としていることが多い。　□ ビジョン←→要件定義←→要件定義←→システム仕様というように、上位文書と下位文書記載事項は過不足なく、すべて関連付けられなければならない。　□ 要件を満足する出力を得るために必要十分な速度、対象となるデータ量、利用者数（同時、最大）などをあらかじめ想定して仕様書に明記しておくべきである。　□ IEEE830　□ 第三者によるレビューは、当事者が気がつかない、常識や暗黙の了解を指摘してもらえるところにも意義がある　□ ドキュメントレビューでは、設計書として具備すべき内容や検討すべき内容が適切に盛り込まれているか否かを確認することを第一目的としている。　□ ドキュメントの基本として「何を作るのか」←→「いくらでつくるのか」←→「どう作るか」が明確かつ容易に追跡できないのでは、ドキュメントの内容が妥当かどうかをレビューするには至らないということである。　□ ソフトウェア品質特性　　１）機能性　　２）信頼性　　３）使用性　　４）効率性　　５）保守性　　６）移植性　□ 設計根拠が明確になっているか　第２章ドキュメントレビューとは　□ 三現主義（現場、現物、現実）を徹底　□ レビューをマイルストーンにおいて実施することで、品質と進捗状況の両方をチェックすることができる。　□ 困難なプロジェクトであればあるほど、リーダーシップはメンバーの一人ひとり、誰もが発揮しなければならないものである。　□ 仕様書と設計書に矛盾があることも少なくない。その場合は。議事録も必要になる。　□ 一連の変更要求に対するプロセスが適切に行われ、プロジェクト計画が適切に更新されているかどうかを見るためにも、ドキュメントレビューは有効である。　□ スコープには、プロジェクトで作成すべき成果物を定義した成果物スコープとプロジェクトで実施すべき作業範囲を定義したプロジェクトスコープがある。　□ 品質管理の低下対策として、ロバスト設計、ノイズ除去、フィードバック制御である。　□ 指摘事項としては、「要求事項の漏れ」などが多数あり、、原因として「業務分析不足」が多いのであれば、業務分析のプロセスを改善し、業務フローの描き方やヒアリング方法などについて標準化や教育などを行う。　□ このプロセスを改善し品質保証（実行）することが、いわゆる「品質工程（プロセス）で作り込む」という品質保証の考え方である。　□ 組織は戦略に従う　□ 要員の一人ひとりが常に結果を評価し、そこからのフィードバクを受け入れ、学習し成長続ける組織「学習する組織」を構築するのにもドキュメントレビューは有効である。　□ 「風通し」が悪く、成長のない組織では、発生する問題（ノイズ）に、相互作用を及ぼしながら相乗効果や相互扶助により対処しながらプロジェクトを成功裏に収めることは困難である。　□ 単純な解決策は、とにかく記録し文書化することである。　□ リスク対策は、回避、移転、軽減、受容　□ さまざまな形でリスクの予兆が現れるのが、ドキュメント（現物）であるからだ。　□ 会社間にまたがることの最大のリスクは、コミュニケーションの問題である。　□ 技術的なリスクであっても、よくよく聞いてみると、人の思考過程に起因することが多い。　□ 特にリーダークラスとは、こまめにコミュニケーションを図るとともにドキュメント・レビューを通じリスクの兆候をも逃さずに手をうちたい。　□ レビューでの、よくある勘違い　　１）レビューはセレモニーである　　２）レビューは説明会である　　３）レビューはQ&Aである　　４）レビューは討議の場である　　５）レビューはつるし上げの場である　□ 完成度が70%から80%でもよいので利害関係者や有識者のレビューを受けることで、フィードバックを得て、早めに軌道修正するというレビュー本来の目的第３章ドキュメントレビューの実施要領　□ レビューの議長は別に任命した方が良い　□ レビューの参加者からの質問には丁寧に答え、なぜ、そのようにしたかという点を簡潔に応える必要がある。　　□ レビューにはドキュメントの前工程と後工程のプロジェクトメンバーがいる。　□ ものづくりでは、要求から最終製品までの情報伝達が確実に行われるかどうかで成否が決まるので、これをレビューすることが一つのポイントである。　□ 戦略とは、「正しいこと」を選択することである。　□ レビューが終了したら、議長は必ずレビュー報告書を作成してプロジェクト管理者に報告するとともに、参加者へ配布すること。　□ 要求仕様書に対する指摘事項の分類例　　１）記述ミス　　２）入出力画面や帳票の漏れ　　３）機能漏れ　　４）追跡性　　５）要求の矛盾　　６）業務プロセスとの不具合　　７）データ過不足　　８）業務用語の不統一　□ 原因の分類例　　１）勘違い　　２）業務調査不足　　３）誤理解　　４）理解不足　　５）コミュニケーション不足　　６）業務上の不都合　　７）利害関係の衝突　□ ドキュメント・レビューの結果を定量的にデータベース化して、指摘事項の傾向を分析し有効活用することで、CMMIに示されるような組織の能力熟成度レベルを改善することも可能である。　第４章ドキュメントレビュー40のチェックリスト　■ 要求仕様書　□ 画面・ファイル　　・要求されているすべての画面は、業務プロセスと関連づけられてなければならない。　　・それは、業務フロー上で確認できるように記述されて入れう必要がある　□ 入力～処理～出力　　・後工程の出力を得るために処理に入力した情報を、前工程に順番に要求していくことで、最終的に必要な出力を得るために、必要十分なだけの入力情報を処理することができる無駄の無い業務プロセスとシステムになっているかどうかチェックするのである。　□ 真の要求機能に対する実現可能性とは、技術的に可能であり、かつ、費用対効果的にも可能なことである。。　　　その要求項目が合目的であり、かつ、その実現に対して中核をなすものであるならば、予算外の投資をしてでも実現可能とする必要がある。　□ 見積書との整合性を確認することで、間違えや勘違いを早急に発見することだ　□ 運用上の制約条件や障害発生時の回復時間などを規定しているか。　□ システムを運用する上での要件として、実行スケジュールや実行条件などが明確になっている必要がある。　■ 見積書　□ 要求仕様書で要求されている機能が、すべて機能としてリストアップされてなければならない　□ 要求仕様書に要求されている画面、帳票、ファイルと１対１で、リストアップされているものだ。　□ ファンクションポイント法では、システムに対する機能は基本的に入力（画面、帳票）、出力、照会、外部インターフェース、内部論理ファイルのいずれかであると考える。　□ 要求仕様書の要求事項と見積書で整合性が取れているだけではなく、入力、出力、入出力の区分も整合性が取れている必要がある。　□ 要求仕様書がデータ型を定義できるように明確に記述されているかを相互にチェックすることが肝要である。　□ あくまで利用者から見た「作るもの」が易しいか難しいかを評価するのであり、、開発者にとっての「作り方」が難しいか易しいかを評価するのではないということをチェックしなければならない。　□ 過去の実績によれば31%以上の修正率となる場合、その作業負荷は、新規作成と同程度になるようだ。

やればできる/タッド・バッジ

やればできる You can do it 日本初・外国人頭取の銀行改革第１章私が見た「日本の銀行」　□ 週３日は、なるべく午後７時半には会社をでてください　□ 本来、仕事で目指す方向は、シンプルでればあるほど有効なのです　□ ビジョンがあって初めて、誰が何をすべきなのかという役割は生まれてくるのです。　□ カルチャーから変えなければ、企業は変われない　□ しかも、スピーディーに変える必要がある　□ ビジネスを成功に導く基本原則　　１）パッション、熱意をもった人材が、力を合わせて目標に向かう。これこそ何よりも大切な事です　　２）明確なビジョンとリーダーシップです　　３）エンパワーメント、人に権限の移譲をしていくということです　　４）社員間の信頼です　□ コンペティション、競争がなかったという問題です。　□ 私たちは、お客様の当たり前のニーズに合わせただけです　□ 企業もビジネスモデルを常に変えていく必要があります。　□ リーダーがやるべきは、「改革」ではありません。自らが主体的に行動を起こす「変革」なのです。　□ 何よりも大切なことは、意思をもったリーダーシップがあるかどうかです。アイディアとリーダーシップがあれば、必ず変革が起こせるのです。第２章東京スター銀行流「銀行改革」　□ ３つの方法論　　１） E（エデュケーション）　　２） S（ソリューション）　　３） P（パートナーシップ）　□ 成長性、効率性、安定性　□ 企業に価値基準がなければ、人を評価することなどできない　□ ７つの価値基準　　１） Integrity　信頼です　　２） Customer Forcus　お客様が一番です　　３） Boundaryless　境界線がない　　４） meritoracy　成果主義　　５） Speed　スピード　　６） Passion　情熱は不可欠です　　７） Over-Performance　期待以上の成果　□ ごく普通のものを組み合わせていくことで、全体としてユニークなものを作り上げることができる　□ 彼らは、新しいチャレンジをして、成果を生んだ成功体験がとても少なかったのです。だから、自信を持つことができなかったのです。　□ リーダーは、コミュニケーションの重要性を知り、コミュニケーションによってうまくいく環境を創っていくことが求められるのです。　□ 変わらないでいることがいかにリスクの高いことかを、破たんによって全員が認識していったのだと思います。第３章私のキャリアを生んだもの　□ 私の言う愛の特徴は、約束や責任や努力です。大変なことですが、努力に見合うだけの見返りはあります。　□ 明確な目標を持っているにしても、いないにしても、つながっているのです。だからこそ、出会ったどんな仕事も、どんな経験も、決して無駄にしてはいけないと思うのです。　□ 上司の権限だけのマネジメントでは人は付いてこない　□ スタッフを大切にすること。信頼すること。権限を委譲し、できるだけ判断を委ねること。　□ キャリアというのは、自分でしっかり責任を持ち、前を向いてスキルアップする努力をしていかないと、すぐに後退してしまいます。　□ 現実をしっかり見据えよ、という考えです。現実をしっかりと見据えられない人には、現実にそった決断はできないからです。　□ 一人で何もかもやるのではなく、マネジメントのリーダーを定め、チームで立ち上げに挑んだことが功を奏したのです。　□ 日本の組織では、コミュニケーションがより重要になるということに気づきました。　□ ここで、守りに入るべきではない第４章日本企業へ、日本のビジネスパーソンへ　□ 重要なのは、仕事とプライベートの「ワーク・ライフ・バランス」であり、ハーモニーです。　□ 家族の中で「父親」という肩書きは、一生ものです。　□ 家族との関係ををより良くするヒント　　１）みなさん自信が、奥さんやご主人との絆を育てることです　　２）家族と一緒に過ごす時間、子供と過ごす時間を、自発的に作ることです　　３）毎朝一日が始まる前に、自分の人生で最も大切な人たちについて考える時間を取ることです　□ 家族の絆口座は、あなたの生涯にわたって素晴らしい配当をもたらしてくれると思います。　□ 家族とのいい関係を作るためには、自分にしっかりとした強さがなければなりません　　１）フィジカル（身体）　　２）ファイナンシャル（経済力）　　３）ソーシャル（社会性）　　４）メンタル（精神力）　□ 自分が日々どこに向かっているのか、長期的、短期的に何を目指そうとしているのかが、しっかりと把握できるようになりました。　□ 会社の未来は、自分でコントロールしなければならない。そうでないと、他の誰かにコントロールされてしまう。　□ 人生は長くありません。やりたいことができないような環境に身を置いているのは、あまりに寂しいことです。　□ 子どもたちは、いいことをするのに手一杯にさせることが大切なのです。　□ 子どもたちにはいいことをするのに忙しければ、悪ことを考える暇はなくなるし、やりがいのある活動に従事していれば、悪いことに誘惑されることもないはずです。　□ 転職　　１）今就いている仕事は何か改善したり直していくようなチャンスのある仕事かどうか　　２）会社が行う新しいことに挑めるかどうか　　３）その仕事をすることで日々勉強ができたり、成長できるか　□ リスクのないところに、リターンはありません　□ だからこそ、勇気が必要なのです。　□ 成功するビジネスパーソン　　１）自分で責任を持っている人である　　２）ワーク・ライフ・バランスを大事にしている　□ あきらめずに前に進めばなんとかなる　□ 知識はあった方が良い　□ 私たち人間にも実はリザーブタンクがある　□ ルールよりも大事なことがある　□ 結果を出している人の共通点　　１）実績を持っている　　２）人格エピローグ　□ 何よりも大切になるのは、リーダーシップ　□ 把握している問題点について、解決に向けた取り組みをいかにスピーディーに進めていけるか　□ 様々な意見をとりまとめ、勇気を持った行動を取ることができるかどうか

ドキュメント・レビュー!!要求仕様書・設計書のレビュー実践とチェックポイント/青島弘幸

ドキュメント・レビュー!!要求仕様書・設計書のレビュー実践とチェックポイントドキュメント・レビュー！！要求仕様書・設計書のレビュー実践とチェックポイント※ 今回は第４章のチェックリストのみを抜き書きしています□ 要求仕様書のレビュー・チェックリスト　１）題名は、適切なシステム名を明記しているか　２）システム概要（業務フロー）は、システム全体、業務との関連、他システムおよび業務との連携が理解できる内容か　３）帳票は、名称、入出力区分、データ項目、レイアウト、入出力方法、入力チェックおよび条件が明確か　　　各帳票に対応する業務プロセスと利用目的が業務フロー上で明示されているか　４）画面は、名称、入出力区分、データ項目、レイアウト、入出力方法、入力チェックおよび条件が明確か　　　また、各画面操作方法、メニュー構成および遷移が明確か　　　各画面に対応する業務プロセスと利用目的が、業務フロー上で明示されているか　５）ファイル名は、名称、入出力の区分、論理構造、各データ項目の名称、属性、長さ、キー項目などが明確か　　　各ファイルに対応する業務プロセスと利用目的が、業務フロー上で明示されているか　６）各画面・帳票などの要求機能、処理方法は理解できる内容か　　　処理条件、処理サイクル、タイミング、処理件数の平均値と限界値、必要性能（処理時間、レスポンス）、エラー処理、データのバックアップと廃棄処理、セキュリティ対策などは明確か　７）入力～処理～出力が業務プロセスに対して矛盾なく理解できるか　８）各帳票、画面と関連するファイルやデータ項目は関連づけされているか　９）各帳票、画面、ファイルに対し、新規、改修、既存が判別できるか　１０）要求仕様は業務上の期待効果の実現に対し過不足や矛盾はないか　　　　要件定義書など上位文書の各業務要件と要求仕様の追跡性を確保しているか　１１）要求仕様書は、技術的、費用対効果に実現可能かつ必要十分な内容か　１２）要求仕様は、見積書の帳票、画面、ファイルの種類、数と整合性があるか　１３）略語、専門用語、コード表、エラーメッセージ表などの説明があり明確か　１４）購入ハードウェア/ソフトウェアとの関連性は明確かつ整合性はあるか　１５）データの移行作業などが検討されているか　　　　また、移行条件などが明確か　１６）運用上の制約条件や障害発生時の回復時間などを規定しているか□ 見積書のレビュー・チェックリスト　１）数量（工数）、単価、金額は明示されており、計算違いはないか　２）見積の有効期限は、明示されているか　３）要求仕様書に対し、データ型や過不足や矛盾なく定義されているか　４）処理方式ではなく、外部要素に着目してデータ型を定義しているか　５）内部処理の作業用一時ファイルを、データ型として定義しているか　６）データベースは関連セグメントや表のみを対象ファイルとして項目数、難易度を算出しているか　７）各データ型（入力、出力、入出力）の区分は、要求仕様書に対して妥当か　８）難易度別、データの型数は、要求仕様書に対して妥当か　９）何度の選定は、要求仕様書に対して妥当か　１０）修正率の選定は妥当か　　　・類似ソフトの流用、プログラム部品の使用を考慮しているか　　　・全体に対する、改修部分の規模~見て、妥当な修正率か　　　・外付け可能な機能追加は、新規開発とした場合と比較検討する　１１）開発言語の生産性は妥当か　　　・生産性のよい、適切な開発言語、ツールを選択しているか　　　・汎用ソフト、ユーティリティ、開発ツールの使用を考慮しているか　１２） FP係数（単価/FPまたは作業工数/FP）は妥当か　１３）マクロ的に見て、合計金額、合計工数は、ｼｽﾃﾑ規模に対して妥当か　１４）データ型、難易度、FP数、金額は、矛盾や計算違いがないか　１５）別途、購入・移行作業などが必要な場合に見積もりがしているか　１６）ハードウェア、ソフトウェア、ライセンス等、必要十分な購入品に別途見積もりしてあるか　　　　要求仕様書および実際の業務要件、運用環境に対して、必要十分な性能・要領・数量などがサイジングしてあるか□ 設計書レビュー・チェックリスト　１）要求仕様書の要求事項が、確実に設計に反映されていることを追跡しやすいように記述されていること　２）使用している設計手法やテンプレートの選択理由が明確であること　３）アーキテクチャについて、なぜそれが最善の方式であるのか明確かつ、論理的に説明できること　４）代替案を2つ以上、比較検討していること　５）設計上持ち込んだ、制約事項の確認　　　例えば、最大処理件数やデータ容量　６）データ項目の桁数、属性、識別キーなどの確認　７）障害対策やバックアップの確認　８）ユーザビリティやアクセシビリティ、ユニバーサルデザインを考慮していることドキュメント・レビュー!!要求仕様書・設計書のレビュー実践とチェックポイントチェックリスト

プロジェクトを成功に導く品質管理/橋本健一

プロジェクトを成功に導く品質管理 ~ソフトウェア開発でのマネージャの役割プロジェクトを成功に導く品質管理序章ソフトウェア開発の成功とは？　□ 品質管理担当者には大きく分けて３種類の役割があると考えられます。　　１）ソフトウェアそのものの品質管理　　２）ソフトウェア以外の成果物（仕様書など）の品質管理です　　３）プロジェクトマネージメント自体の品質管理です　□ 実はよくよく状況を整理すると、自分とは関係ないところに問題があったりするものです。　□ 情報の共有や、全体に対する視点共有というのは、成功していると「何も起こらない」プロジェクトになります。第２章プロジェクトマネージメント　□ プロジェクト品質管理　　・「提案」もしくは「企画」　　・「要件定義」　　・「作業見積」と「作業計画」　　・「受発注」もしくは「予算の取得」　　・「プロジェクトチーム組織編成」　　・「プロジェクトの運営」　　・「リスク管理」　　・「課題管理」　　・「リソース計画」　　・「製造管理」　　・「試験管理」　　といったプロジェクトマネージメントの内容を、俯瞰視点から客観的に評価し、必要があれば修正を加えること。それがすべてです。第３章リソース　□ 開発者の特性一覧　　・計画性　　・迅速性　　・積極性　　・対応性　　・安定性第４章製造　□ ソフトウェア開発の工程で、最もトラブルが頻発するのは製造工程と試験工程です。　□ 要件定義や見積段階で見逃してきた、もしくは後回しにしてきた問題が表面化することによります。　□ 製造工程以前の工程の不備は、製造工程で挽回するしかありませんし、製造工程の問題は試験工程に跳ね返ります。　□ 要件以外に記述されたほうが良い情報として、工数や優先度、内容詳細や備考などが上げられます。　□ 優先度の二つの概念　　１）他の作業に先行して行う必要があるかどうかの優先度　　２）その要件自体の全体に対する相対的な優先度　□ 設計の目的は、コーディングを行うために必要な資料を揃えることです　□ 多数のアプリケーション、ミドルウェア、サーバなどを、どのように連携させていくべきかを定めるアーキテクチャーです。こちらのほうは、設計段階で概ねの見通しをつけなければいけません。　□ コーディング工程にいくつかのマイルストンを設定し、全体目標を共有します。また各メンバの直近数日の作業目標を明らかにし、作業項目単位での遅延状況や問題点などを把握する必要があります。　□ 実際のマイルストン設置の方法を考えてみます。コーディング視点から捉えた場合、一般的には、プロトタイプフェーズ、仕様変更適用フェーズ、仕様確定フェーズ、試験修正フェーズの４つのフェーズがあると考えられます。　□ ある程度の仕様変更を前提とした開発体制が必要となります。　□ 顧客とプロジェクトメンバにこのフェーズの期間と位置づけの共通認識を作ることができます。　第５章試験　□ ソフトウェアの品質　　１）ソフトウェアの仕様が適切であるか　　２）ソフトウェアが仕様通りに正しく実装されているか　□ 試験計画の目標は「少ない手間で」「早く」「たくさん」「危険な」バグを検出することにあります。　□ テストケースの考え方　　・基本的な機能、使用頻度が高い機能は優先して組み合わせます。　　・類似の処理が複数ある部分は、他の条件に対して同一とみなし、１回ずつテストされれば良いと考えます。　　・プログラム的に特殊な処理、複雑な処理をしている部分は、必ず一度組み合わせます。　　・テスト上、問題が多く発生している部分は優先して組み合わせるように変更します。第６章品質管理計画　□ 品質管理計画で考える事　　・品質管理の対象となる「成果物」　　・成果物に対する「品質管理作業（レビュー、試験など）」とその「目的」と「作成計画」　　・各品質管理作業の「実施体制」　□ 品質管理の対象となる成果物　　１）工程全般での成果物　　　・週報や議事録　　２）製造工程前　　　・企画書、提案書、要件定義書、見積書、契約書　　　　ここで最も重視すべきは実現性です。リスク管理表が重要な成果物になります。　　３）製造工程　　　・詳細要件定義書、設計書、ソース、実行環境、試験仕様書　　　　課題管理表も成果物として考えられます。　　　・製造工程で重要なのは、要件を発散させないことと、いかに試験工数と修正工数を低減させるかという点にあります。　　　・日々の進捗報告や仕様変更などでコツコツと伏線を張り、決定事項は文書化して提示し、きちんと管理する必要があるでしょう　　４）試験工程　　　・試験工程では試験報告書、障害管理表、修正ソースなどが成果物になります。　□ レビュー方法　　・アドホックレビュー　　・パスアラウンドレビュー　　・ペアレビュー　　・ウオークスルーレビュー　　・チームレビュー　　・インスペクション　□ レビュー開始基準　　・文書はスペルチェック、校正等が済んでいること　　・ソースコードは一般的な障害が除去されていること　　・バージョン識別子を持っていること　　・未解決の課題がすべて明示されていること　　・先行成果物の品質レベルが確認されていること　　

「戦う組織」の作り方/渡邉美樹

「戦う組織」の作り方 (PHPビジネス新書)「戦う組織」の作り方第１章１００年続く「強い組織」を作るために　□ 強すぎるリーダーシップは、組織がトップに依存する体質を生みやすいという弊害がある。　　□ 企業というものは大きくなるとともに、その社会責任が重くなっていくからだ。　□ 「伴走者」として、後継者の離陸をささえるのも重要な仕事　□ 社員一人ひとりが自律的に考え、厳しい状況の中でも道を拓いていけるという組織になれる　□ 事業ポートフォリオを組むときに重視することの一つであるリスク分散できているということだ。　□ 下地を整える　　　１）未来を見据えた新しい事業を生み出すこと　　　２）企業にとってもっとも重要な「企業理念」を、私がいなくなっても決して忘れることがないよう、すべての社員に徹底させていくこと　□ 「自分たちだからこそできること」や「自分たちだからやるべきこと」必死になって考え続けるしかないだろう。　□ 定着は難しい。しかしやめるわけにはいかない。「気と気勝負」で思いを相手に伝えていくしかないと考えている。それが経営者の使命なのだから。第２章成長を続ける「戦う組織」の作り方　□ 組織はその成長段階に合わせて、必要とする人材をどんどん変えていく　□ 「戦う組織とは厳しい集団でなくてはならないが、人の可能性を見切る冷たい集団であってはいけない。　□ まずは、会社のあるべき姿と現状のギャップを正確に捉えることが重要になる　□ トップ自らが介護施設のユニフォームを着て、現場に入ることだ。そして態度と言葉で、その経営理念をスタッフに伝えることである。　□ リーダーたる者は、常に一番の勝負どころに立ち続けなければならない　□ 自分にとって楽な場所ほど、部下に譲り渡さなければいけないのだ。　□ 土壇場まで追い込まれないと、人は変われないのだ。　□ 中堅の人材を変えるには、忍耐が必要だ。だが、ある時点で覚悟を決めることもまた、トップにとって必要なことである。第３章組織を引っ張る「戦うリーダー」の条件　□ 「戦う組織」を作れるかどうかは、リーダーで９９％決まる　□ 戦う組織のリーダー育成の最大のポイントは「追い込むこと」だと思っている　□ リーダーになる人間の条件をもう一つ挙げるとしたら、私は「変わらないこと」だと思っている。　□ 熱さと冷静さの両方を持っていることが、将来リーダーになる上でとても大切なのだ　□ 失敗を回避するよりも、逃げずに戦い続けることの方がリーダーの成長には大切だ。第４章「戦う部下」を育てるリーダー力の磨き方　□ 私にできるのは、部下が育っていける環境を整えることと、育つきっかけを提供することだけだ。　□ 夢やビジョンがなければ、仕事に対する意欲を保てず、成長も止まってしまうことになる。　□ 伸びる資質をもった部下を、自分よりも優秀なビジネスパーソンに伸ばしていくのがリーダーの大事な役割だ。　□ それぞれの人が持っている資質をどれも認め、「そのいいところを伸ばしてあげたい」と思えることが、器の大きなリーダーの条件の一つになる。　□ 自分を越えて大きく育つかもしれない部下の存在を、素直に認められる心を持つことだ　□ 思考の三原則　　１）長い目でみること　　２）多面的に　　３）根本的に　□ シビアでありながらも、多面的な評価が不可欠となるのだ。　□ 「属性」で部下と接していては、決して部下の資質を見極め、伸ばすことはできない　□ 叱る相手のことを事前に知った上で叱るのが基本だ　□ 部下を叱るときには、自分の感情をコントロール出来ていることが条件となる。　□ 人事は落ち着くべきところに落ち着く　□ 役職には上下はなく、役割が違うだけだ。　□ 伸びる人は、自分のキャパシティお少し超える程度、つまり１２０％ぐらい課題をいつも自らに与えて、挑戦しているものなのだ。　□ ビジネスモデルを構築できる人材に　□ 「想像力」と「仮説力」　□ 夢とは誰かとの競争に勝つためではなく、自分の思いを叶えるために持つものだ。　□ 「腹を括れること」　□ 現実から逃げないこと