ITアーキテクトはA3用紙に図解する [単行本]

ITアーキテクトはA3用紙に図解する [単行本] の 商品概要

• 要旨（「BOOK」データベースより）

  日本トップ企業のＩＴアーキテクトが２０年の経験で培った技。課題マップ／機能配置図／接続切り替え概要図／システム移行ストーリー／システム基盤構築ストーリー。職人ＳＥのノウハウ伝授。

• 目次

  まえがき
  A3用紙に描く図の簡易サンプル
  
  ≪第1章　ITアーキテクトの醍醐味≫
  　理想と現実のはざまにある「実現可能」な最良の提案
  　更地からシステムを作り上げる
  　プロマネとITアーキテクトはプロジェクトの両輪
  　ITアーキテクトが最後の砦
  
  ≪第2章　提案のゴールは、お客様による「選択」≫
  　複数提案してその中から評価基準を見いだす
  　A3用紙1枚に「比較表」を作る
  　「ハード更改」「前回同額」「理想形」「推奨案」の4案を準備
  　システム全体を「選択」してから、サブシステムを「選択」
  　ハード更改案と前回同額案の差を課題解決の原資に
  　理想形は不採用を承知で提案し、次回を見据える
  　費用を棒グラフで示し、面積で費用対効果をビジュアル化
  　運用コストをスコープに入れて試算
  　すべてを伝えることがお客様の理解を深めるとは限らない
  　「表」になっていない「表」に注意
  
  ≪第3章　要件定義での「見える化」≫
  　要件定義で設計した以上の品質は作れない
  　A3用紙に“地図”を描く
  　機能配置図で実装方法を「見える化」
  　見積もりに必要な未決定の要件は必ず「仮決め」する
  　想像しやすい順番で構築方針を考える
  　システム基盤の方向性は、多くの課題が出発点
  　処理「日付」に着目して運用パターンを「見える化」
  　要件定義書は極力少ないページ数にする
  
  ≪第4章　製品選定、導入方針の勘所≫
  　絶対評価は難しい、複数製品を比べて評価基準が見えてくる
  　新バージョンの製品では「できなくなったこと」を確認
  　制約事項、トラブルをヒアリングして落とし穴を塞ぐ
  　製品は徹底的に使う
  　製品のファーストユーザーになるメリットもある
  　高性能なプラットフォームが必ずしも高価格とは限らない
  　製品選定においてもシステム移行を考慮する
  
  ≪第5章　システム基盤設計のチェックポイント≫
  　図解しづらければ、改善の余地がある
  　ムダなパラメーターがないか
  　論理と物理の関係を意識した信頼性設計となっているか
  　システム全体の信頼性はファシリティーを含めて考える
  　オンラインとバッチでの資源の競合を考慮する
  　リカバリー機能を不必要に作り込んでいないか
  　時代とともに疎結合と密結合のバランスは変化する
  
  ≪第6章　システム基盤構築はストーリーを描く≫
  　システム基盤構築のストーリーをA3用紙に描く
  　面積（対象機器）と高さ（構成要素）で立体的に計画する
  　設置工事、環境構築をマスタースケジュールに記載する
  　機器を設置するだけでも考えることは山ほどある
  　ファシリティー要件の提示は長いリードタイムを意識する
  　「普通作ってあるだろう」と考えるのは厳禁
  　主幹となる作業チームを順次推移させる
  　システムパラメーターは必ず「現物」を基に設定する
  
  ≪第7章システムテストの神髄は「再現性」≫
  　A3用紙にテスト範囲を描く
  　全ルートを網羅した「END to END」テストを実施する
  　テスト計画は工程ごとの再現性の高まりを確認する
  　実害がなければ問題にはならない
  　本番を再現できないから不具合を見つけられない
  　処理内容の割合によってシステム負荷が変動する
  　バッチデータの起源はマスターファイルと取引ログ
  　動かし続ければシステムの状態は変化する
  　同じスケジュールで動かさないと見つからない不具合
  　量と繰り返しに負けていないか確認する
  　システム移行を考慮したテスト項目を抽出する
  　外部システムとの接続確認は、変更レベルに応じて決定
  　テスト範囲の境界を重ねることでテスト漏れを防止
  　故障したハードウエアは交換できますか？
  　最後はお客様に運用してもらうこと
  
  ≪第8章　システム移行の鍵は計画の具体化と品質の積み上げ≫
  　システム移行計画もA3用紙で
  　置き換える範囲と使い続ける範囲をまずは明らかにする
  　システム移行は3つの視点で考える
  　要件定義工程から移行計画の検討を開始する
  　移行リハーサルで全手順の確認を目指す
  　サブシステム間の接続ルートを網羅し、切り替え方式を検討
  　システムテストと移行リハーサルの両面で移行本番を想定
  　パラメーターとDBでは異なるデータ移行となる
  　特別な運用は見落としやすい
  　移行テストと本番では日付が異なる
  　移行リハーサルでは、体制・連絡ルートの妥当性も確認
  　作業時間の検証を通じてチェックポイントを確定
  　移行リハーサルごとの到達点を明確化して品質を積み上げる
  　段階移行が必ずしもリスク軽減になるとは限らない
  
  ≪第9章　ITアーキテクトの心得≫
  　ドキュメントに残せばすべて伝わるわけではない
  　何よりも「わからない」ことに対してお客様は怒る
  　わからなければマシンに聞いてみる
  　課題と技術動向の両方をストックしてひも付けする
  　技術者としての悔しさをバネに成長する
  　自身の成長と担当するシステムの成長をシンクロさせる
  　目利き力を養う
  　ITアーキテクトは町医者

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  春田 健治(ハルタ ケンジ)
  ＮＴＴデータ第三金融事業本部しんくみ事業部信用組合担当部長。１９９３年ＮＴＴデータ通信株式会社（現株式会社ＮＴＴデータ）入社。２００９年コミュニティバンキングシステム事業本部課長、２０１５年第三金融事業本部部長。２０１３年ＮＴＴデータ社内資格シニアＩＴアーキテクト認定、２０１６年エグゼクティブＩＴアーキテクト認定

• 内容紹介

  　システム構築に関するノウハウは、開発現場にたまっています。ただ、そうしたノウハウは体系立てて整理されておらず、先輩から後輩に受け継がれるなどして、個人に蓄積しているのが実情です。その結果、各現場には「この人はすごい」「この人こそ“職人SE”」と言われる人がいます。
  
  　本書の著者はそんな“職人SE”の一人。著者は長年、金融システムの「ITアーキテクト」として活躍し、大規模ミッションクリティカルシステムの構築経験が豊富にあります。
  
  　著者が20年以上の時間をかけて身につけたITアーキテクトとしてのノウハウ。それをまとめたのが本書です。著者が普段何気なく実践していることに注目し、「それをいつするのか」「なぜするのか」を整理しました。
  
  　著者の実例が随所に織り込まれており、その取り組みには説得力があります。ITアーキテクトとして一流を目指すあなたにぜひ読んでほしい1冊です。

ITアーキテクトはA3用紙に図解する [単行本] の商品スペック