あいかわらず稀にしか更新しない blog で大変恐縮なのですが、自身 10 冊目（！）となる書籍が発刊されました！（前回の Azure 本から実に 7 年ぶりという遅筆ぶりなのですが；。）

正式タイトルは「業務システム開発 モダナイゼーションガイド～非効率な日本のSIを変革する実践的ベストプラクティス～」。今回の書籍のテーマは、日本の SIer の旧態依然とした Excel まみれの業務システム開発の手法を近代化（モダナイゼーション）して生産性を高めようというもので、以前、弊社のイベント de:code で大変反響のあった「拝啓『変わらない開発現場』を嘆く皆様へ」のフルセット版のようなものになります。タイトルだけでは書籍の内容がさっぱりわからん！ という方が多いのではないかということもあり、こちらに本書のまえがき全文を掲載したいと思います。ご興味のある方は、ぜひ本屋でお手に取っていただければ嬉しいです。（日経 BP さんのサイトでの紹介はこちらです。社内エンジニアの育成テキストなどとしてもご活用いただけると思いますので、もしバルク購入したいというご要望がありましたら、こちらのお問い合わせフォームから日経 BP さんにご連絡ください。）

＃ ちなみにどうでもいいつぶやきですが、個人での印税受け取りは放棄しているため、「儲けた印税で飲みに連れていってください！」的なリクエストはなしで ＆ ワリカンでお願いします；。

本書の執筆にあたっては、日経 BP さんをはじめ、社内外のたくさんの皆様からご協力をいただきました。改めてこの場を借りてお礼申し上げます。ありがとうございましたm(_ _)m。また、イイネ！ ダメダネ！ とか、この本いいよ！ ここ間違ってるよ！ ここはもっといいやり方あるよ！ とかありましたら、Facebook/Twitter/この記事のコメント/はてブなどで反応いただけるとめちゃめちゃ嬉しい ＆ 励みになります。

私の SI 業界での 20 年間の経験の集大成として執筆しました。情報密度がかなり高い本になっていますので、社内勉強会でみんなで検討しながら読むなど、ぜひ周りの方とも情報共有しながら現場でご活用いただければと思います。この書籍が、皆さまの開発現場を少しでも改善するきっかけになること、そしてこの本を踏み台にして、よりよいシステム開発方法論が建設的に議論されていくことを心から願っています。では、以下、まえがきです。

---

業務システム開発 モダナイゼーションガイド～非効率な日本のSIを変革する実践的ベストプラクティス～ まえがきより

---

■ はじめに ～『変わらない開発現場』を嘆く皆様へ～

　「日本の SI ビジネスは崩壊前夜」
　「日本の SI はガラパゴス」
　「日本の SIer の余命はあと5年」
　「ウォータフォールには何のメリットもない」
　「日本のエンジニアはイノベーティブじゃない」

　ネットや雑誌で毎日のように揶揄される日本のエンプラ系 SI（システムインテグレーション）業界。古くは「現代の 3K（キツい・帰れない・給料が安い）」「デジタル土方」、そして最近では「SI オワコン」「SI 終末論」など、次々と生み出される悲惨なキーワード。これらを見るたびに、心を打ち砕かれている現場エンジニアはかなり多いのではないだろうか。

　実際、日本の SI 開発現場は確かにひどい。下図は、数年前にある情報システム子会社の幹部に対して、その会社の実際の現場で発生している問題点を整理・説明するために筆者が作ったものである。ところがこのイラストを他のお客様（SIer や情シス子会社）や弊社内の同僚のコンサルに見せてみると、自社あるいは自分が担当するお客様でも似たような、あるいは全く同様の問題が起こっているという。

　筆者が SI 業界に身を置くようになって約 20 年になるが、実際、コンサルとして日本の様々な開発現場に行ってみると、判を押したかのように似たような問題にぶち当たる。一定の年次になったというだけで十分な知識もないのに「上級 SE」にさせられたプロパー（正社員）が、コストと時間に追われて場当たり的な作業指示を出し、協力会社だけでなく、指示を出した自分自身も作業効率の悪さに苦しむ。そして前述したような心無い罵倒に打ちひしがれながらも、なまじ当たっている面があるだけに言い返せずますます悶々とする。こんなやり方を続けていたら、確かに日本の SI が崩壊するのも時間の問題である。

　無論、SIer や情シス子会社のプロパーや日本の SI に関わるエンジニアとて、明らかに沈むとわかっている沈没船に身を委ねたいわけではない。少しでも現場を改善したい、少しでもプロジェクトがうまくいくようにしたいと、日々もがき苦しみながら努力を続けている人たちの方が圧倒的多数だろう。だがしかし、実際には日々の業務をなんとかこなすのが精いっぱいで、抜本的な業務改善までには手が回らない。ニアショアやオフショアを使うだけではもはやインパクトのあるコストメリットが出せなくなりつつある上に、際限のないコストカットの波により現場の労働力が枯渇していく。そんな過酷な現実の中で、どうやって高い生産性と俊敏性を実現させていくかについて悩んでいる現場エンジニアやマネジメントは非常に多いはずである。

　こうした SIer や情シス子会社の日々の悩みに対して、果たしてアジャイルや DevOps といった、欧米流のソリューション（プラクティス）が「そのまま」解決策になるのだろうか？　筆者は、この答えは明らかにノーであると考える。少数精鋭で新しいビジネスを模索し続ける、内製前提の SoE 型システム開発の現場から生まれたソリューション（プラクティス）は、システム化対象となる業務量・業務数の多さから少数精鋭での開発が困難となる、請負前提の SoR 型システム開発の現場に必ずしもそのまま適用できるものではない。

　そもそも多くの SIer や情シス子会社が悩んでいるのは、様々な事情や制約によって高スキルのエンジニアだけを揃えられるわけではないという状況下において、いかに互いのスキル（専門性）を補完し、チーム全体・プロジェクト全体のアウトプットを最大化していくかという命題である。契約形態（内製型と請負型）、開発規模、揃えられる人員とスキルセットといった、数々の前提条件が異なる欧米型ソリューションをそのまま持ってきて、SIer や情シス子会社の悩めるプロパーたちに対してマウントポジションで殴り掛かるのは筋違いというものであろう。だが、まるで欧米礼賛とも言えるこうした言説は未だ後を絶たず、特にネット上では噛み合わない議論から、不毛なけなし合いへと発展・炎上する例がしばしば見受けられる。こんな状況がいつまで続けばよいのだろうか。

　

■ SI 技術（システムインテグレーション技術）の重要性

　本来、技術進化の恩恵は、IT 技術を駆使するシステム業界に属するエンジニアが最も享受できるはずである。にもかかわらず、その恩恵をほとんど受けられていないのは何故か。それは、日本のエンプラ系開発現場では、なんとなく非効率的と感じながらも、数十年前と本質的には大きく変わらないやり方を繰り返し続けているからではないだろうか。

　そしてこの状況を生み出している最大の原因は、日本のエンプラ系 SI の商慣習（多重請負構造）における『上流』の仕事のやり方が、ほとんど進化していないことにあると筆者は考えている。

　Visual Studio や Azure といった開発技術（実装技術、モノ作りの技術）を最終的に触るのは、末端にいる協力会社のエンジニアである。しかし、多重請負構造におけるエンドユーザー企業や IT 部門、SI 関連会社、SIer がこうした開発技術の活用を『妨げる』ようなことをしていては、いつまでたっても開発技術の進化の恩恵を受けることはできない。

　当たり前のことだが、モノ作りのやり方が変われば、設計手法やプロマネ手法（いわゆる『SI 技術（システムインテグレーション技術）』）もそれに合わせた見直しが必要になる。近代的な開発技術の進化を理解し、SI技術を進化させ（＝近代化し）、エンドユーザー企業に対してそのメリットを提案していくのは、IT 部門や SI 関連会社、SIer の責務である。IT 部門や SIer が技術のことを知り、正しくプロジェクトを立て付けなければ、いつまでたっても現場は非効率的な Excel 設計書と Excel テストから脱却できないのである。

　しかし考えてみると、.NET や Javaなど製品技術を解説する本や、プロマネを対象とした専門書は多数あるが、「SI （システムインテグレーション）」に関する技術的なセオリー全般をバランスよく扱っている書籍が意外に少ない。これには以下のような理由が考えられる。

　① 日本の商慣習を前提としたシステム開発手法が生み出されていない
　② そうしたノウハウは（あったとしても）SIer の門外不出となっており情報が流通していない
　③ ベンダーから提供される情報は実装技術に特化しすぎている
　④ プロマネ向けに書かれた書籍は設計・実装・テスト技術に触れていないものが多い

　実際、筆者が実際の開発現場に行くと、「なぜこんな基本中の基本が見落とされているのか？」と思うようなことが少なくないが、逆に「そうしたことを短時間で学べる書籍はないか？」と問われると、なかなかおすすめできる書籍がない。これではいつまでたっても日本のシステム開発の現場はなかなか変わらないだろう。こうした現状を打破していくため、筆者が 20 年間かけて、コンサルティングの現場で培ってきたノウハウとベストプラクティスを、可能な限りお伝えしたいと考えて本書を執筆することにした。

　

■ 本書の内容とゴールについて

　本書は、日本の SI 業界における多重請負構造を前提条件とした上で、SI（システムインテグレーション）に必要となる基礎知識やノウハウ（SI 技術）を幅広く提供する。これにより、多重請負構造の上流の立場にある IT 部門や SIer のプロパーが、システム開発を正しい方向に導き、開発現場を近代化できるようになることを目指すものである。

　

■ 本書の構成について

　本書では、以下の 4 つの章を通して、SI 技術に関するノウハウを幅広く提供する。全て通して読んでいただくことが望ましいが、悩んでいるところや興味があるところだけをかいつまんで読んでいただいても構わない。

第 1 章 開発プロセスと V 字型モデル

　ネットの世界では、「イケてない開発 vs イケてる開発」という文脈で、しばしば「ウォータフォール vs アジャイル」の対立構図が取り上げられる。しかしこうした近視眼的な見方では、システム開発の本質を見失う。そこで第1章では、ウォータフォールとアジャイルの特性の違いを解説すると共に、改めて、システム開発の基本とも言える V 字モデルの重要性について振り返る。そして V 字型モデルの段階的詳細化の最大の問題・課題とも言える「後工程の予測・推定の必要性」について述べ、手戻りを軽減・防止するための基本的な対策方針を説明する。

　また、開発プロセスのテーラリングにおいては、SoR 型システム開発と SoE 型システム開発とを正しく分けて考えることが最初の起点となる。これらのシステム開発の特性の違いを解説すると共に、日本の SI がガラパゴスなのではなく、むしろ欧米の SI こそがガラパゴスであることを述べる。これを通して、現在の日本のエンプラ系 SI 業界が行うべきことが、「SoE 型システム開発で生まれた様々なベストプラクティスのエッセンスを、SoR 型システム開発へ還元すること」であることを説明する。

第 2 章 フェーズとロールモデル

　プロジェクトの成否は、最初の建付け（チーム編成とタスク検討）により大きく左右されるが、実際の開発現場を見ると、チーム編成にしてもタスク検討にしても、基本的なセオリーが守られていないことが少なからずある。よくある問題としては、「専門性（ロール）」を意識しないアサインや、非機能要件に基づく設計プロセスである「方式設計」の漏れ、そして技術力の軽視から来るアーキテクトの不在問題などがある。

　そこで第 2 章では、業務システム開発の骨格となる、2つのタスクの流れ（機能要件に基づく流れと非機能要件に基づく流れ）と、5 つのロール（業務 SE、アーキテクト、デベロッパー、テスター、プロマネ）について解説する。そして、チーム編成で特によく見られるいくつかの問題を取り上げ、正しくチーム編成とタスクを建て付けるための基本を説明する。

第 3 章 各タスクの実施の要点

　開発生産性の改善には、（当たり前だが）作業の手戻り防止と、ムダな作業の排除が欠かせない。にもかかわらず実際の現場では、Excel での画面設計書をひたすら手でこねくり回して時間を無駄にしたり、実施証跡を取るためにテスト結果のスクリーンショットを Excel にひたすら貼り付けたり、保守されることもなく腐っていく内部設計書を粗製乱造しまくるといったデタラメが横行しているのが実態である。こうしたムリ・ムダ・ムラが改善されない大きな理由のひとつは、「そのタスクがなぜ必要なのか（Why）」「そのタスクでは少なくとも何を検討して何を作る必要があるのか（What）」が十分に議論・理解されていないことである。手戻り防止とムダな作業の排除には、チーム内での根拠のある議論が必要になるが、そのための基礎知識が足りていない場合が非常に多いと考えられる。

　そこで第 3 章では、要件定義、外部設計、方式設計、内部設計、実装・単体機能テスト、結合機能テスト、システムテストのそれぞれについて、各タスクの実施の要点を解説する。これにより、「根拠のある作業」「根拠のある SI」を実現できるようにする。この章では、SoE 型開発現場で生まれたベストプラクティスを、SoR 型開発現場に取り込むための多数のTipsを織り込んでいる。この章に書かれた内容をきちんと実践するだけでも、QCD（品質・コスト・期間）はかなり改善できるはずである。

　また第 3 章の最後では、近代的なインフラや運用管理の基礎概念についても解説する。優れたシステム開発のための基礎となる「運用環境第一主義（Production First Mindset）」の考え方について触れ、その実現に必要となる近代的なインフラや運用管理の要点を解説する。これらが正しく理解できると、クラウドや DevOps の必要性も、必然的に理解できるはずである。

第 4 章 システム開発現場の近代化に向けて

　実際の現場では、「今のやり方を変える必要などない」という、論理的とは言えない部課長の鶴の一声で、現場改善の芽はもちろんのこと、若手社員のやる気まで潰してしまうケースも少なくない。しかし、現場を変えていけるのは現場のエンジニアでしかなく、また彼らを勇気づけ、ルールや仕組みを変えていけるのはマネジメントでしかない。本来、両者は二人三脚が必要であり、そのためには根拠のある議論に基づいた歩み寄りが必要となる。

　そこで本書の締めくくりとなる第 4 章では、会社や組織、そして個人が何を意識し、どこを目指していけばよいのかの指針について、筆者の見解を述べる。具体的には、SoR 型システム開発では中堅層のプロマネや業務 SE の再教育、社内アーキテクトの育成、初級エンジニアの設計・実装スキルの底上げ、成果物の品質確保プロセスの作り込みなどが必要であること、また SoE 型システム開発では最新テクノロジの要点の理解、デザイン思考の利用などによるビジネスニーズの深掘り、プロトタイピングによる概念実証を行うための社内 PoC チームなどが必要であることを解説していく。そしてエンジニアやマネジメント個々人がどのような考え方を持って何に取り組むべきかを説明する。

　第 4 章は第 1 章から第 3 章を踏まえて読んだ方がより納得感があると思われるが、忙しいマネジメントや上席の方は、この章だけをピックアップして読んでいただいてもよいだろう。

　

■ 本書の解説について

　筆者はここまで .NET 関連の書籍を 9 冊執筆してきているが、10 冊目となる本書では、.NET や Azure といった実装技術そのものに関する説明はほとんど行わない。“How” ではなく “Why”、すなわちなぜその作業をしなければならないのか？　にフォーカスした解説を行う。理由は以下の通りである。

　・ 具体的なやり方は、その気になって調べればいくらでも情報が見つかる。
　・ なぜそれをする必要があるのか？ を理解すると、自信を持ってシステム開発に取り組める。

　SI（システム開発）のそれぞれの作業（タスク）には、意味と根拠が必ずある。一つ一つの作業の「理由」「意味」を正しく理解して、作業のムリ・ムダ・ムラを排除すること、そして「あるべき論」を正しく理解した上で、現実の「制約条件」と組み合わせ、落としどころを探ることで、『根拠のある作業』『根拠のある SI』を実現することができる。

　

■ 本書で想定している読者と前提知識について

　本書は主に IT 部門や SIer のプロパー（業務 SE、プロマネ、アーキテクトなど）をターゲットとして執筆している。前述したように、発注元になる IT 部門や SIer のプロパーが正しいアプローチを知らないと、システム開発の現場を適切な方向に導くことができず、新しい開発技術の恩恵を受けることができなくなるためである。

　また、現場経験年数としては5年以上の方を想定して執筆している。ある程度の現場経験があると、肌感覚として理解できる部分、納得できる部分がたくさん出てくるのではないかと思う。完全な新卒エンジニアでも読めないことはないと思われるが、その場合には、数年後にまた本書を読み返してみていただけると、違った発見があるかもしれない。

　逆に、業務 SE、アーキテクト、プロマネなどそれぞれの道の「プロ」からすると、自分の専門領域に関する情報としては物足りない部分があるはずである。本書は特定のロールの「プロ」向けに書いた書籍（例えばプロマネのプロ向けに書いた書籍）ではなく、どのようなロールの人であっても必ず知っておいていただきたい「SI 技術の基礎」をまとめた書籍である。現場経験年数が長い方は、ご自身の専門ロール以外の部分を読んでいただけると幸いである。

　

■ 本書の免責事項について

　日本人は書籍に対してバイブル的な存在を求める傾向があると感じているが、残念ながらそうした情報は全世界どこを見回してみてもなかなか存在しないのが実情である。そうした中で、筆者の独自研究と現場経験に基づいて、筆者自身が「こうした情報があればよいのに」という希望を形にしたのが本書（およびこの書籍を書くための元ネタとなっている、マイクロソフトのコンサルティングサービスが提供する Visual Studio Workshop）である。

　このため、本書には筆者個人の考えや解釈などが多く含まれているが、これはあくまで筆者の個人的見解であり、必ずしもマイクロソフトおよびコンサルティングサービスとしての公式見解というわけではない。この点に関しては、ご容赦いただければと思う。

　なお、書籍をいきなり読むのが少しつらい、という方には、以下のサイトにまとめてある各種イベントビデオもご活用いただければと思う。扱っているトピックは限定的だが、本書でどのような話を取り扱っているのかの一端を短時間でご確認いただくことができると思う。

　・ 『変わらない開発現場』シリーズ 情報ポインタ一覧
　https://blogs.msdn.microsoft.com/nakama/2017/06/17/sier-modernization/

　

■ 本書で利用しているツールや画面スナップショットについて

　先に、.NET や Azure といった実装技術そのものに関する説明はほとんど行わないと書いたが、ある程度具体的なツールや手法を示した方が理解しやすいものについては、マイクロソフトの製品やサービスを例にとって説明を行っている。筆者は基本的にマイクロソフト以外の技術に明るくないため、解説はマイクロソフト製品をベースに行っているが、同様のことは（おそらく手間は増えるだろうが）OSS 系ツールや他社製テクノロジであっても実現できるだろう。

　また広範な領域の情報を限られた時間で執筆している関係で、すでに紹介しているツールや画面スナップショットが古くなっているものもある。また、Azure や Visual Studio、Visual Studio Team Services（VSTS）はどんどん進化を続けるため、読者の皆様が本書を読むころにはすでに古くなってしまっている可能性が高い。しかし、本書で解説している「SIの基本」はさほど変わらないはずである。実際に現場で「SI の基本」を実践する際には、その時点での最新のツールを調査した上で利用していただきたい。

　

■ 本書に関するご意見・ご感想などについて

　限られた時間での執筆であることに加え、筆者の経験不足・知識不足により、書き足らずのところや、さらに良い手法が存在するところもあると思う。こうした部分については、ぜひ本書を素材または踏み台として、ネット上や社内勉強会、各種コミュニティなどでオープンに議論していただければと考えている。

　本書に関するご意見やご感想などは、以下のメールアドレス宛にお寄せ頂ければ幸いである。今後の執筆内容などに可能な限り反映させ、より分かりやすい、より良いコンテンツを提供していきたいと考えている。

　・ 日経BP社
　[email protected]

　

■ 最後に

　特に、開発方法論に関するネット上での議論は空中戦や宗教論争になりやすく、なかなか地に足の着いた議論になりにくい。本書はその領域に対する「言語化」を試みたものでもある。日本の労働人口の減少と生産性改善の必要性が叫ばれる中で、日本人同士がいがみ合い、けなし合うのはあまりにも不毛だと筆者は考える。開発現場のエンジニアが「SI 技術の基本」について共通認識と共通言語を持ち、「根拠のある議論」に基づいてお互いが学ぶべきところを学び合い、「根拠のある SI」を各自が自信を持って実践できるようになることを心から願っている。そして本書の知見が、皆様の開発現場の改善と近代化に少しでも貢献できたのであれば、望外の幸せである。

2018年1月
赤間　信幸
日本マイクロソフト株式会社　エンタープライズサービス事業本部
プリンシパルコンサルタント