ＩＴアーキテクトはＡ３用紙に図解する

春田 健治【著】

日経ＢＰ（2016/10発売）

• サイズ B6判／ページ数 198p／高さ 19cm
• 商品コード 9784822237882
• NDC分類 007.61
• Cコード C3055

出版社内容情報

　システム構築に関するノウハウは、開発現場にたまっています。ただ、そうしたノウハウは体系立てて整理されておらず、先輩から後輩に受け継がれるなどして、個人に蓄積しているのが実情です。その結果、各現場には「この人はすごい」「この人こそ“職人SE”」と言われる人がいます。

　本書の著者はそんな“職人SE”の一人。著者は長年、金融システムの「ITアーキテクト」として活躍し、大規模ミッションクリティカルシステムの構築経験が豊富にあります。

　著者が20年以上の時間をかけて身につけたITアーキテクトとしてのノウハウ。それをまとめたのが本書です。著者が普段何気なく実践していることに注目し、「それをいつするのか」「なぜするのか」を整理しました。

　著者の実例が随所に織り込まれており、その取り組みには説得力があります。ITアーキテクトとして一流を目指すあなたにぜひ読んでほしい1冊です。

まえがき
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アーキテクトは町医者

春田 健治［ハルタ ケンジ］

内容説明

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

目次

第１章　ＩＴアーキテクトの醍醐味
第２章　提案のゴールは、お客様による「選択」
第３章　要件定義での「見える化」
第４章　製品選定、導入方針の勘所
第５章　システム基盤設計のチェックポイント
第６章　システム基盤構築はストーリーを描く
第７章　システムテストの神髄は「再現性」
第８章　システム移行の鍵は計画の具体化と品質の積み上げ
第９章　ＩＴアーキテクトの心得

著者等紹介

春田健治［ハルタケンジ］
ＮＴＴデータ第三金融事業本部しんくみ事業部信用組合担当部長。１９９３年ＮＴＴデータ通信株式会社（現株式会社ＮＴＴデータ）入社。２００９年コミュニティバンキングシステム事業本部課長、２０１５年第三金融事業本部部長。２０１３年ＮＴＴデータ社内資格シニアＩＴアーキテクト認定、２０１６年エグゼクティブＩＴアーキテクト認定（本データはこの書籍が刊行された当時に掲載されていたものです）
※書籍に掲載されている著者及び編者、訳者、監修者、イラストレーターなどの紹介情報です。

感想・レビュー

※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。

[subuta]

多人数が参照する資料はA3紙1枚にまとめるよう勧めている。題名を見たときは図表作りについての本かと思ったが、実際は大規模システム構築の勘所を伝える内容だった。

2019/02/24

[ninn.atsu]

自分自身、比較的実践していることばかり書かれていたので、それほど新鮮な感じではなかったが、ノウハウという意味でなかなか伝えられない部分を文字にしてあるので有用だと思う。でも、やっぱりアーキテクトという職種は自分でも色々試して失敗して身をもって体験していかないと納得しないのではないだろうか。マシンにきいてみる、つまり手を動かせってことが一番のノウハウでしょうかね

2016/11/05

[mimi]

冒頭に図表例がある。本文は、A3スタイルにまとめるという点での特別なテクニックではなく、実際の一つの図要素の作り方を示している

2017/01/27

[sho_kisaragi]

日本のエンプラ界のITアーキテクトの活動内容を知るために。 技術書というよりエッセイに近しい。経験豊富だとは思うけれども、技術的な裏付けというより経験談とストーリーを読んで、そんな世界もあるんだなと言うことを知ることのできる内容。わたしも似たような経験があるので、ああ自分だけじゃないんだなという自信にはなりました。

2023/10/15

[NN100]

同じ職務や立場ではないけれど、IT設備導入として共感するところがありました。図解して共有することが大切ということ、失敗の体験をもとにしたノウハウが紹介されていました。

2021/03/28