ITアーキテクトになるためのシステム設計・開発・運用 ミス撲滅ガイド(日経SYSTEMS)
書籍情報
- 著者:日経SYSTEMS(編)
- 発行日:2013-05-17
- ISBN:9784822277024
- URL:https://bookplus.nikkei.com/atcl/catalog/13/218340/
書籍目次
- 第1章 設計ミスをなくそう 現場を救うレビューの秘訣
- Part1 頑張るだけのレビューはもう限界
- Part2 現場が編み出したワザ
- 五つのレビュー手法を使い分ける
- 新聞社に学ぶレビューの秘訣
- コラム(1) 技術インパクト SDN
- 第2章 開発ドキュメントのやってはいけない 読み手を悩ます文書
- PART1 ドキュメントの見直しがトラブル招く
- PART2 効率のワナ
- 「チラシ分析」でドキュメントの本質を学ぶ
- PART3 品質のワナ
- PART4 活用のワナ
- コラム(2) 技術インパクト OpenPaaS
- 第3章 バグをなくそう 悪条件に負けないテストの秘訣
- PART1 トラブル テストフェーズは悪条件だらけ
- PART2 インタビュー 世界最大規模のテスト
- PART3 ケース 現場の秘訣
- PART4 ワークショップ テスト計画に挑戦
- コラム(3) 技術インパクト インメモリーデータベース
- 第4章 オペミスをなくそう 間違わせないシステムの作り方
- Interview 畑村 洋太郎氏
- Part1 オペミスの正体
- Part2 現場の工夫 ●運用設計編
- ものづくりの現場に学ぶ: 大日本印刷
- Part3 現場の工夫 UI編
- Part4 寄稿 オペミス撲滅に向けて
- コラム(4) 技術インパクト DevOps
- 第5章 工程間の溝をなくそう 思惑の違いを避ける12のヒント
- PART1 溝がもたらす悲劇
- PART2 要件定義と設計間
- PART3 設計と製造間
- PART4 製造と運用保守間
- PART5 後工程で打つ対策 ――全工程
- コラム(5) 技術インパクト JavaScript
- 第6章 上流工程の死角をなくそう 非機能要求のまとめ方
- Part1 もう許されない要求の不備
- Part2 現場のテクニック
- 第7章 進捗遅れをなくそう 危機感高め、 素早く課題を解消
- PART1 進捗は遅れるのが当たり前?
- PART2 進捗遅れを防ぐマネジメント
- 調査で分かった！ 進捗遅れを起こすプロジェクトとマネジャーの性質
- PART3 遅れないITエンジニアの秘訣
- PART4 異業種のプロフェッショナル
- コラム(6) 技術インパクト カラム型DB
- 第8章 クラウドアンチパターン
- Amazon Web Services
- Force.com
- Windows Azure
- Google App Engine
- IaaS
- 第9章 テクノロジーアンチパターン
- DB高速化
- 次世代LAN
- NAS
- NoSQL
- Androidアプリ
- システム関連技術
- 省電力技術
第6章 上流工程の死角をなくそう 非機能要求のまとめ方
非機能要求定義の難しさ
- (1) 情報収集が難しい
- そもそも非機能要求は曖昧
- 抜け漏れなく洗い出すにはスキルと経験が必要
- ユーザーが解答を持っているわけでもない
- (2) 整理・分析が難しい
- 非機能要求は主観が入りやすい
- 非機能要求同士が相関関係を持つことが多々ある
- 非機能要件の妥当性の評価にもスキルや経験が必要
- (3) ドキュメント作成が難しい
- 機能要求と異なり、標準的な表記法が無い
- 毎回手探りでドキュメントを作成することになる
非機能要求を抜け漏れなく洗い出す技法
- (1) ヒアリングシートを活用する
- 具体的な項目は無し
- [MEMO]
- ヒアリングシートの項目こそが知りたかったのだが、そこは掲載されず
- 流石にこれは無能過ぎる
- (2) 伝票視点で要求を引き出す
- 実際に処理する伝票の数から性能要件を推論する
- [MEMO]
- 業務系システムではこれは確実な感じがある
非機能要求を整理・分析する技法
- (1) オープン質問とクローズ質問でヒアリング
- オープンな質問とクローズな質問で必要な情報を絞り込んでいく
- 例:
- 性能が要求される機能は？（オープン質問）
- 先に挙げた機能の中で、特に性能が要求される機能は？（クローズ質問）
- ↑のようにして、優先度が高い機能を絞り込んでいく
- (2) 非機能要求同士の相関関係は図で整理
- 非機能要求同士の相関関係をモデル化・検証するツールは無い
- [MEMO]
- 今も無いのだろうか？
- その為、簡単な図を描いてでも可視化に努める必要がある
- この時、その時点では分からない要求があっても「何が明らかになっていないか」「いつ明らかになるのか」を明記しておく
- (3) 横方向と縦方向に確認し、主観を排除する
- 横方向 == 部署（ユーザー）
- 縦方向 == 経営者
- 部門目線の要求と経営者目線の要求は異なることが多々あるので、縦横両方に確認を取る必要がある
- (4) 松竹梅で妥協案を探る
- 非機能要求の妥当性を評価する際はコスト、実現方式のバランスで評価する
- この時、いきなりひとつの結論だけ提示してもユーザーは納得感を得られない
- そこで、松竹梅の3プランを作成してユーザーに自ら選ばせる
- 松プラン → フルスペック
- 竹プラン → 松プランよりはランクを下げたプラン
- 梅プラン → 竹プランより更にランクを下げたプラン
非機能要求を整理・分析する技法
- (1) ユーザー向けと開発者向けでドキュメントを分ける
- ユーザー向けには、文章表現を業務視点にしたりシステム構成などの図を多用する
- 例えば、システム間の応答時間は文章だけでなくシーケンス図を用いてイメージしやすくするなど
- 開発者向けには、表などで構造的に要求を示したり、具体的な数字で曖昧さを排除する
- [MEMO]
- 完全に分離すると作成・更新の二度手間がつらそう
- 基本はユーザー向けに書きつつ、開発者向けの補足を付録にするぐらいがちょうど良さそうである
- (2) 「結果」だけでなく検討結果も盛り込む
- 最終的な結果だけでなく、検討対象となった選択肢や決定理由も記載する
- 非機能要求は業務と切り離されやすいので、何故そうなったのかが忘却されがち
- 後から蒸し返されて決定が変えられないように、決定理由も記載しておくことでトラブルを回避できる
- [MEMO]
- 現在でいうADR的な目的か
第7章 進捗遅れをなくそう 危機感高め、 素早く課題を解消
進捗遅れを起こす3つの原因と対策
- (1) 進捗遅れに対する意識が低い:
- チーム全体で進捗遅れに対する危機感を共有し、適度なプレッシャーを掛ける
- (2) 進捗遅れを把握できない:
- 遅れの先行指標となる情報を収集し、いち早くタスクの遅れを発見し対策を打つ
- (3) プロジェクトの課題を放置してしまう:
- 課題管理票をフル活用し、迅速かつ確実に課題を解消していく
危機意識を共有する
- クリティカルパスをチーム全体に共有する
- クリティカルパス担当のメンバーに危機感を持ってもらう
- クリティカルパスは進行状態によって変化するのでMSプロジェクトで自動的に分析する
- [MEMO]
- 要するにエンジニアにプレッシャーを掛けるだけなのだろうか
- 個人の努力に依存するのはマネジメントとは言えないような
- 2013年頃のプロジェクトマネジメントはこんなものだったという事だろうか
- 内容を読むにWF開発が前提のようだ
- 確かに2013年頃はまだWF開発が多かった気もする
タスクごとに余裕無しの期限を設定する
- タスクの見積もりにバッファを乗せることを禁止する
- 人間はバッファがあるとバッファを使い切ってしまう
- 削ったバッファの余裕分は共有バッファとしてタスクが期限オーバーした時に使う
- 問題点:
- バッファと見なす基準が曖昧で判断の一貫性が保てない
- 結局、タスクが期限オーバーすることが増え、共有バッファを使うことが日常化した
- 結果、プロジェクトの雰囲気がダレた（共有バッファを使えばよいという考えが蔓延した）
- [MEMO]
- スクラムのように一定期間のスプリントを回した方が遥かにマシのような気がする
ここ一番の「頑張ろうミーティング」
- チーム全体にカツを入れる為にフロア全体に大声でプロジェクト成功への協力をお願いする
- [MEMO]
- ドン引きである
タスクを2人日以内に細分化
- 全てのタスクを2人日以内に細分化
- 仕掛中は進捗率をゼロと見なし、完了時点で100%にする
- タスクの進捗を0か100で捉えることで進捗状況の把握が正確になる
- [MEMO]
- これは良い施策
成果物のチェックイン時刻を見る
- チェックイン時刻 == コミット & プッシュした時刻（SVNやCVSの用語）
- 深夜のチェックインが増えてくると、残業が増えているということであり、実質的に進捗遅れが発生していると見なすことができる
- [MEMO]
- 時代を感じる
メンバーの設計書を斜め読みする
- 設計書を斜め読みして、設計書の記述の雑さからメンバーの疲弊度を読み取る
- 設計書の記述が雑になってきているという事は時間的な余裕が無いか、精神的に疲弊している可能性が読み取れる
- 問題がありそうなら本人のケアを行うなどの施策に繋げられる
- [MEMO]
- これも良い施策
- とはいえ、スクラム開発ではあまり有効に機能しないかもしれない
EVMの指標でメンバー別の進捗を把握
- EVMによる進捗管理:
- タスク毎に工数（予定出来高）の見積もりを行い、タスクが完了するとその工数を実績出来高としてカウントする
- 全タスクの予定出来高の合計が100人日で実績出来高が50人日なら進捗率は50%という計算を行う
- これと同じ管理を個人に対しても行う
- 週次でメンバー毎の出来高をグラフ化して状況を見ていく
- SPI（出来高）が1.0以上なら問題なし
- SPI（出来高）が1.0を下回るなら進捗遅れが発生している
- SPI（出来高）が1.0を下回る状態が続くようなら、担当タスクの調整などの対応を行う
- [MEMO]
- 面倒臭そう
- 昔のWF開発では開発者がこのような工数計算の為の入力作業を行う事が多かった
- 進捗には一切寄与しない上に入力ミスは許されないという非常に面倒かつ虚無のタスクであった
- そのような開発者個人の間接工数が多くなり、一体何をやっているのかという事態も稀によく発生した
- そう考えるとWFなどという無駄な手間ばかり掛かる開発プロセスをよくも採用していたものだと思う
課題の対策立案はあえて短い期限を設定する
- 課題対応のタスクをメンバーに割り当てる時、課題の対応方針の検討もタスク内に含む時がある
- そのような場合は会議終了後1〜3時間後に対応方針を報告するよう期限を設定する
- 課題の対応方針は何日も掛けて考える性質のものではないし、時間が経てば経つほど相談もしづらくなる
- であれば、期限を1〜3時間後に設定し、すぐに検討し実行に移す方がよい
- [MEMO]
- これは良い施策
マル秘の課題管理票で人に関わる課題を管理
- PMとサブリーダークラスだけがアクセスできる課題管理表を作成する
- この課題管理表では、「特定のメンバーの生産性が落ちている」などの個人に関するネガティブな課題を扱う
- 個人のネガティブな情報はかなりセンシティブな情報なのでチーム全体の課題管理とは完全に別に扱う
- 人間同士の相性など実際に仕事をしてみないと分からない機微な部分をPMとサブリーダーで共有する
- [MEMO]
- これも良い施策
- 生々しさを感じて忌避感を感じなくもないが、こういうものも必要ではある
- とはいえ、アクセス管理は厳重にしないといけない
- 大抵の場合、本音は人間を傷付けるものだからだ
第9章 テクノロジーアンチパターン
DB高速化の手段4選
- (1) インメモリDB
- メモリ上で処理を実行することでディスクアクセスを排除する
- データ読込速度の高速化に高い効果
- (2) SSD
- HDDと比較すると高速アクセスが可能
- [MEMO]
- 2020年代では既にSSDがデファクトである
- (3) DB高速化アプライアンス
- DBが行う処理の一部をハードウェアが肩代わりすることで処理の高速化を図る
- (4) IaaS/PaaS
- CPUやメモリ、ディスクなどのサーバリソースを動的に増減することで、スケールアップやスケールアウトを実行する
- [MEMO]
- 今時はこれが一般的だろうか