ITアーキテクト最強の指南書 の商品レビュー

日経BP社

2021/08/08

ITのお勉強。

「システム開発は本来、ユーザー企業の情報システム部門が主導して進めるべきものです。それができずにITベンダーに”丸投げ”してしまうことが、さまざまなトラブルの元凶であると10年ほど前から指摘し、解決策を模索してきました。
　最近は、小規模な開発ではユーザー企業が主導する事例も増えてきましたが、数億円超の大規模な開発ではいまだに丸投げが多く、失敗が相次いでいます。これを根本的に解決するために私が得た解は、ユーザー企業側にシステム全体を統括するITアーキテクト、いわば『エンタープライズアーキテクト』を置くというものです。」
「SaaS APIを”探して使う”とその機能はスクラッチ開発で作らずに済む。そのことは『安い』『早い』『うまい』という三つのメリットをもたらす。
　安いとは、初期コストの低さだ。…
　早いとは、システムの開発期間を短くできることだ。…」
　うまいとは、スクラッチ開発では難しい機能を実現できることだ。」
「面倒なのは非機能面の検証だ。セキュリティ、サービス継続性、サポート体制、利用規約などが主なチェック項目となる。…
　例えばセキュリティでは、認証方式の確認が必要だ。多くのSaaS APIは、エンドユーザーの操作で発行される文字列『トークン』を使って認証する。『SaaS APIの認証方式は種類が多い。主要なものだけでOAuth、OpenID Connect、API Keyの3種類がある。さらにそれぞれで複数の実装方法がある』」
・ハイブリッドクラウドのユーザ企業が続々
　全社的な業務システム→アンリツ、エイチ・アンド・エス、ガリバーインターナショナル、ソニー銀行、日本通運
　消費者向けWebサービス、社内業務システム→富士ゼロックス
「データ連携の壁は大きく三つある。すなわち、(1)連携、(2)コントロールできない停止、(3)API仕様、だ。」
「CAP定理とは分散システムにおける定理で、一貫性の『C』、可用性の『A』、ネットワーク分断耐性の『P』のうち、同時に満たせるのは二つに限られるというものだ。」
「DBの処理を分散し、アプリ側で『失敗したらやり直す』アプローチでデータの正しさを確保して速さを獲得するやり方をこの記事では『ゆるハヤ設計』と呼ぶ。」
「RDBMS以外の新たなタイプのデータベースには、高い拡張性や可用性を備えるものが多数ある。それらは『SQLだけではない』という意味から、『NoSQL』と呼ばれる。一般にNoSQLを扱うDBMSは、RDBMSが持つトランザクション処理機能、およびテーブルを突き合わせる機能(結合)を実装しない。これにより、分散処理を可能にし、高い拡張性や可用性を実現している。
　主なNoSQLには、(1)キー(標識)とバリュー(値)の組としてデータを管理する『KVS』、(2)テーブル構造の定義が不要な『ドキュメント指向DB』、(3)列単位での処理に特化した『列指向データベース』、(4)経路計算など場所や人の関係性管理が得意な『グラフデータベース』がある。」
・ありがちな七つの勘違い
?ウイルスをみつけたらソッコーで退治→ウイルスは保管しておき敵の戦略を探る
?開発会社が自主的に対策してくれる→発注者と開発会社の双方に対策の責任がある
?事故発生！セキュリティベンダーを呼んですぐ対処→セキュリティベンダーが多忙ですぐには来てくれない
?最新セキュリティ機器なら”穴”はない→機器にはそれぞれ防御できる範囲がある
?ログを取っているから調査できる→必要な情報を必要な期間記録していないことが多い
?怪しいメールを開かないよう教育→開封率の評価だけでなく、体制の確認につなげる
?インシデントの情報開示は最小限→情報を公開したほうが有利に働くことがある