日経コンピュータ2017/8/3号特集「変わるITトラブル」を読んだ

趣味のITトラブルウォッチャー活動として、日経コンピュータ2017/8/3号の特集「変わるITトラブル　実例1096件分析、新事実が明らかに」を読んだ感想。日経コンピュータ創刊の1981年から現在まで「動かないコンピュータ」コーナーなどに掲載された事例を分析したというもの。なお記事には残念ながらデータは掲載されておらず。

突然のシステムダウン、システム刷新プロジェクトの失敗----。
1981年の本誌創刊号から2017年までにわたって「動かないコンピュータ」などに載せたトラブル事例は実に1098件。これらを分析して、トラブル防止につながる知見を得られないか、こう考え、セキュリティ関連、システムダウン、開発失敗というITトラブルの3大リスクを対象に様々な角度から調べてみた。すると、知られざる傾向と対策が見えてきた。

• 日経コンピュータ2017/8/3号 特集「動かないコンピュータ 変わるITトラブル　実例1096件分析、新事実が明らかに」

なお記事の詳細は同誌を確認いただきたい。

• 雑誌：日経コンピュータDigital
• 日経BP書店｜商品詳細 - 日経コンピュ−タ

三大リスクは本当に「三大リスクなのか？」

最初に気になったのは、この特集で取り上げられた三大リスク（セキュリティ、システムダウン、開発失敗）が本当に重要なものなのかがよく分からなかったというもの。概要でもいいのでデータ全体に触れられていれば良かった。もちろん掲載されているリスクはそれぞれ重要なものではあるが。

三大リスク①セキュリティ編

不具合やハードの故障以外の要因として、サイバー攻撃や脆弱性関係のトラブルが大きなリスクとなりつつあるという分析。記事の中では以下のような分析があって興味深い。

• システムダウンの原因別割合(年代別) 日経コンピュータ調べ
  • 2010年代から急増
• セキュリティに関連したトラブルの原因別割合(2010年代) 日経コンピュータ調べ
  • サイバー攻撃・脆弱性関係が8割以上を占めている
• クレジットカード不正使用被害の発生状況(2014年-2016年) 日本クレジット協会調べ
  • 2015年以降急速に増加

嫌な世の中になったものだ、といっても仕方が無いのだけれども、ユーザの要求に従ってシステムを構築しただけではNGな時代に突入したということだと理解している。また、セキュリティのリスクは常に(攻撃手法等や発見される脆弱性が)変化するので、システム開発時だけではなく運用でもどう刈り取っていくのかよく考えなくてはならない点だ。個別エンジニアのスキルで討ち取るのは困難なので、支援体制がちゃんと整っているかどうかがポイントだと思っている。

しかし、この傾向は別に日本に限った話でもないわけで、そういう意味ではグローバルのトレンドも気になるところだけれども、どこかに整理されているものはないか、別の機会に調べてみようと思っている。

三大リスク②システムダウン編

システムダウンのうち「全面ダウン」の比率が10年代に比率として増加しているという話と、いくつかの最近増加しているトレンドについて整理されている。こちらの章で紹介されている分析は以下の通り

• システムダウン全体に占める全面ダウンと一部ダウンの割合(年代別) 日経コンピュータ調べ
  • 2000年代で若干全面ダウン比率下がるも、2010年代でまた上がる
• 全面システムダウンの原因別割合(年代別) 日経コンピュータ調べ
  • ハード起因の比率が微増
• ハードウェア故障の原因別割合(年代別) 日経コンピュータ調べ
  • サーバーに起因するトラブルが増加
• 平均ダウン時間の変化(年代別) 日経コンピュータ調べ
  • ダウン時間は増加トレンド

記事を注意して読まないといけないのは、システムダウン自体が増加しているわけではなくて、システムダウンのうち「全面ダウンの比率」が増えているという件。件数自体は2000年代から2010年代は減っている。もちろん、件数としてカウントされているのは日経コンピュータの取材、情報収集の範囲に限定されるので実際にシステムダウンが増えているのか、減っているのかというのはなんとも言えないように思える。

ただ、平均的なシステムの複雑度は以前より上がったのは事実だと思っている。

• そもそものシステムに対する要求がゼロ年代から難易度アップ
• システム間の連携も複雑化（というか世の中のシステムが増えた）
• ゼロ年代に構築されたシステムが再構築を経て魔窟化、もしくは延命されて妖怪化
• 採用テクノロジーが複雑化、組み合わせが多様化

で、複雑度が上がれば予期せぬ全面ダウンのリスクも増えるわけで、アンチフラジャイルとかレジリエンスなどは今後重要なテーマになっていくような気がしている。

• ソフトウェアにおけるアンチフラジャイルとレジリエンス - 勘と経験と読経

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

反脆弱性[下]――不確実な世界を生き延びる唯一の考え方

三大リスク③開発失敗編

システム開発失敗の主因は要件定義にあるというストーリー。ただ、ここでも注意が必要で、システム開発失敗の件数そのものは減少傾向である。失敗はしにくくなったが、失敗するときには要件定義工程で大コケする、という話と考えたほうがいいと思っている。本章で提示されている分析は以下の通り。

• 開発失敗の4大要因とその割合(年代別) 日経コンピュータ調べ
  • 2000年代から2010年代について、トップ要因は「ユーザ企業が要件をまとめられず」であるが、2位の「ベンダーが要件を理解できず」が2000年代再開から急浮上している
• 工期遅延理由の分類 JUAS「ユーザ企業ソフトウェアメトリックス調査2016」より
  • 遅延理由の4割が要件定義関連
• 開発失敗の事例におけるソフトウェア開発形態別の割合(年代別) 日経コンピュータ調べ
  • パッケージ導入タイプの失敗が大幅に増加
• 開発失敗により稼動延期期間の割合(年代別)
  • 稼動延期期間は短縮傾向、超リスケは減っている

システム構築の受注者側であるSIベンダ等の開発能力や管理能力の向上の結果、適切な要求オーダーがあればシステムを完成させる能力は向上していると思っている（もちろん色々な課題はある）。ボトルネックが要件定義などのいわゆる上流工程に移っているという理解。発注者・受注者の共同作業である要件定義で、どちらかの能力不足によって「ユーザ企業が要件をまとめられず」または「ベンダーが要求を理解できず」で失敗するというのは当然だろう。

あと記事では言及されていないけれど個人的に気になるのは、システム再構築プロジェクトの増加だと思っている。記事の中では「再構築プロジェクトは大規模・ビックバンになってしまい開発規模の大きさからトラブルになりやすい」といったニュアンスの言及はあるけれども、再構築プロジェクトそのものの難しさ、要求／仕様抽出の困難性や人的要因（「わかる人がもういない」）は失敗トレンドの変化に越境を強く与えているのではないか。まぁ、あくまで感覚論なのだが。

なぜ、システム開発は必ずモメるのか？

ポジティブな客先常駐システム開発を考える

株式会社アクシアさんのブログで、常駐開発バッシング(?)記事が最近掲載されている(http://axia.co.jp/2017-08-01)ことについて考えている。指摘されているような「不適切な常駐開発」というのは確かにあるのだろうけれども（ちなみにあまり目撃したことはない）、適切に運用すればポジティブな常駐開発も有りえるはずだし、自分は一応そうやってきたと思っている。じゃあ、注意すべきところは何だろうか。

なれる！SE7 目からウロコの？客先常駐術 (電撃文庫)

何が問題なのか？

常駐や多重請負が問題なのではなくて、請負という形態において受注者が「裁量を持っているか」というのが最大の論点だと思っている。例えば以下のようなもの。

• 作業プロセスについての裁量（やり方を一定の範囲で自由に決定/変更できる）
• スケジュールについての裁量（マイルストーンまでの進め方を自由に決定/変更できる）
• リソースについての裁量（目標達成に必要なリソースを自由に決定/変更できる)

これらが制限された時に批判されるような不適切なプロジェクトになるのではないだろうか。逆に言えば、裁量の範囲について受発注者が事前に合意出来ていれば、ポジティブな常駐開発が実現できるのではないかと考えている。

もちろん多重請負の構造において、特に途中段階の契約会社がポンコツだった場合は裁量を維持するのは相当な努力を要するだろう。「発注者が＊＊と言っているのでその通りにしてください、反論は受け付けません」という契約関係は論外である。もちろん請負側も「すべて指示してください、自分たちでは考えられません、教えてください」というスタンスではいけないのは言うまでもない。

ところで非常駐開発は常駐開発に比べて上記の裁量を得やすいというのは事実だと思う。
ただし、非常駐開発が裁量を得られているのは非常駐開発が優れているからではなく、顧客に対して透明性が無いからにすぎない。

• 客から見えないから、作業プロセスを変えてもいいだろう
• 客から見えないから、スケジュールを変えてもバレないだろう
• 客から見えないから、リソース変更してもOK

はたしてこれが、常駐開発より優れているのかというと疑問である。

ポジティブな客先常駐システム開発

適切な裁量が確保されているのであれば、あとは常駐開発を選択するかはメリット／メリットの比較だと思う。

メリットとして最も大きいのはコミュニケーション効率化である。利害関係者が一箇所に集まって開発に従事することを、「缶詰」（組織パターン）や、「ウォールーム」と呼ぶのだが、このメリットは非常に大きい。またファシリティコストのメリットもあるだろう。

組織パターン

一方でデメリットとしては、最初に紹介したブログ記事にも書かれている通り、顧客の拠点を間借りするためにドレスコードや勤務時間などの制限を受けることはあるだろう（交渉次第だと思うけれど）。また見える場所で作業していることから余計な割り込みの問合せ、コミュニケーションが発生するということもある。

このあたりを冷静に比較して、どのような形態でシステム開発するかは判断すればいい。
というわけで、どちらにしろ常駐開発＝悪というのは、ちょっと違うのではないかと考えたのだった。

Fireタブレットだけでゼロから学ぶDeep Learning

ちょっと思うことがあって、Amazon Kindle Fire HD8で「ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装」(電子版はAmazonではなくOreillyから購入)を読みつつ、Fireタブレット上にPythonの実行環境を作ってコードの実行までやってみた。出来ないことも多いが、意外と戦える。実質的にFire 7980円＋電子書籍2938円で意外と面白い勉強環境を構築することができる。

View this post on Instagram

A post shared by Kent Ishizawa (@agnozingdays)

Fireタブレットで出来ることと、出来ないこと

Fire HD 8 タブレット (8インチHDディスプレイ) (第7世代) 16GB

先に結論から。

• 簡易的なLinux環境を作り、各種ソフトウェアを導入してデータサイエンティスト向けのPython実行環境Jupyter Notebookをスタンドアロンで動くようにする
• Jupyter上で一定の計算量までのコード実行や計算結果のグラフ表示などを行う
• どこまで出来るかというと「 ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 」の第3章までは楽勝。4章でニューラルネットワークのバッチ学習処理あたりから、計算途中でストップしてしまう（計算量の少ない誤差逆伝播法でも無理）。
• PIL(Pillow)はうまく導入できない（同書の第3章で使っている画像関連のライブラリ)

なお今回はFire HD8でやってみたが、他のFireやAndroidタブレットでも同じことができると思う。

どうしてそうなった

• 家にもデスクトップPCはあるのだけど、家族共用なので長時間占有しにくい事情あり。コドモがマイクラやり始めたので状況悪化！
• 社用のノートPCもあるけど環境を汚したくない。
• クラウドに学習環境を構築してタブレットから接続することも考えてたが、ローカルで戦えることがわかったので試してみたら意外と出来た！

FireでPython実行環境構築

• 実施環境はKindle Fire HD 8(第7世代)+FireOS 5.4
• termuxというandroidアプリをインストールしてlinux環境を構築、Python及び必要なライブラリをセットアップ、Jupyter Nootebookまで導入する
  • Termux
  • ほとんど次のページに記載の通り:Running Jupyter and the Scipy stack on Android | Leonardo Uieda
  • FireはGoogle Playが利用できないのでapkファイルをES File Explorerなどを使って直接インストール
  • numpyの最新版はインストール失敗してしまうため、1.12.0を指定するのが良さそう（現在最新は1.13.0）

$ packages install clang python python-dev fftw libzmq libzmq-dev freetype freetype-dev libpng libpng-dev pkg-config git
$ LDFLAGS=" -lm -lcompiler_rt" pip install numpy==1.12.0 matplotlib pandas jupyter

• 「ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装」のサンプルコードをgithubからクローンする。

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

$ git clone https://github.com/oreilly-japan/deep-learning-from-scratch.git

• Jupyter notebook起動

$ jupyter notebook

• 表示されるURLにSilkブラウザでアクセス
• ノートブックを作成してレッツコーディング
  • 参考：Jupyter Notebook を使ってみよう – Python でデータサイエンス
• Jupyterの終了はtermuxのコンソールに戻ってボリュームダウンのハードキー+cを押して終了確認のプロンプトを表示させ、yを入力

うまくいかない事

• 冒頭にも書いたけれど、Jupyterから計算量の多いバッチ処理を実行すると termux自体が死んでしまう。具体的には第4章にあニューラルネットワークのバッチ学習処理のサンプルコード「train_neuralnet.py」はJupyterからは実行できなかった
  • おそらく原因はJupyterからの非同期コード実行プロセスにある印象。ipythonから実行すると物凄い遅いが、誤差逆伝播法の処理は実行できる。
• まぁ、こいつはあくまでおもちゃの類なので、ちゃんとしたスペックの環境を別途構築しようかとは思っている(とりあえずCloud9に環境を建てて試し始めているところ)

スクリーンショット

具体的にはこのような感じになる。動く、動くよ！

2017年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書)

昨年に引続き、2017年1月～6月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2017年上半期に読んだ本を並べてみた

2017年1月～6月に最後まで読み終わった本はこんな感じ。

1. [asin:B01MA4TKKN:title]
2. 自分を立てなおす対話
3. 一流の育て方―――ビジネスでも勉強でもズバ抜けて活躍できる子を育てる
4. AIと人類は共存できるか?
5. 考えない練習 練習シリーズ
6. フェルドマン博士の　日本経済最新講義 (文春e-book)
7. 想像ラジオ (河出文庫)
8. 実践ドメイン駆動設計
9. 紙の動物園 (新☆ハヤカワ・SF・シリーズ)
10. 日本企業の社員は、なぜこんなにもモチベーションが低いのか？
11. 仕事に追われない仕事術 マニャーナの法則・完全版
12. 職場の問題地図 ～「で，どこから変える？」残業だらけ・休めない働き方
13. エターナル・フレイム (新☆ハヤカワ・SF・シリーズ)
14. 世界一速く結果を出す人は、なぜ、メールを使わないのか　グーグルの個人・チームで成果を上げる方法
15. よくわかる人工知能　最先端の人だけが知っているディープラーニングのひみつ
16. 東京どこに住む？　住所格差と人生格差 (朝日新書)
17. レガシーソフトウェア改善ガイド
18. サイエンス・インポッシブル　ＳＦ世界は実現可能か
19. ストーカー (ハヤカワ文庫 SF 504)
20. いつも彼らはどこかに（新潮文庫）
21. 動物園にできること──「種の方舟」のゆくえ（第３版）
22. サマー／タイム／トラベラー１
23. サマー／タイム／トラベラー２
24. 〈インターネット〉の次に来るもの　未来を決める１２の法則
25. 草間彌生わが永遠の魂
26. 数学者たちの楽園: 「ザ・シンプソンズ」を作った天才たち
27. 人狼城の恐怖　第一部ドイツ編 (講談社文庫)
28. Cloud First Architecture 設計ガイド（日経BP Next ICT選書）
29. ジョイ・インク 役職も部署もない全員主役のマネジメント
30. GIGAZINE 未来への暴言
31. 人狼城の恐怖　第二部フランス編 (講談社文庫)
32. [asin:B01M4J5B5X:title]
33. 仕事の問題地図 ～「で，どこから変える？」進捗しない，ムリ・ムダだらけの働き方
34. アイデアのちから
35. 人狼城の恐怖　第三部探偵編 (講談社文庫)
36. ピクサー流　創造するちから
37. 人狼城の恐怖　第四部完結編 (講談社文庫)
38. 会社を変える会議の力 (講談社現代新書)
39. DevOps教科書
40. サピエンス全史　上下合本版　文明の構造と人類の幸福

オススメ文芸書編

月並みだが、世界的なベストセラーである「サピエンス全史　上下合本版　文明の構造と人類の幸福」は素晴らしかった。単に面白いというわけではなく、読書から得られた知識と刺激によって、自分自身に変化を感じるレベルである。

サピエンス全史　上下合本版　文明の構造と人類の幸福

うちには小学校低学年の子供がいるのだが「これはなぜ？」の類の質問に対する解答力が本書を読むことで上がった。本書を読む前と読む後では答えが違っていると思う。
手に取るか迷っているのであれば以下などを参考に

• ユヴァル・ノア・ハラリ: 人類の台頭はいかにして起こったか？ | TED Talk
• “幸福”を探して 人類２５０万年の旅 ～リーダーたちも注目！世界的ベストセラー～ - NHK クローズアップ現代＋

オススメビジネス書編

読んですぐに実務に活かせるという意味で圧倒的なパフォーマンス感を感じたのはこの2冊。

職場の問題地図 ～「で，どこから変える？」残業だらけ・休めない働き方

仕事の問題地図 ～「で，どこから変える？」進捗しない，ムリ・ムダだらけの働き方

どちらも、職場でよく議論される問題（いわゆる「あるあるネタ」）を扱っているのだが、ダイアグラムを用いて非常によく整理されているのが参考になる。というか、わたしはダイアグラムの多くを写真に収めてすぐにスマートフォンで表示できるようにしているのだけれども、これで相当に捗るようになる。

オススメ技術書編

先日書いた記事でも紹介しているが「レガシーソフトウェア改善ガイド」は良かった。あまり話題になっていない印象があるけれど・・・

レガシーソフトウェア改善ガイド

• 情報システムの再構築戦略についての現時点の理解整理 - 勘と経験と読経

この本のスコープは欲張りなもので、放置されたレガシーコードベースを、あなたの組織に価値をもたらす保守が可能で十分に機能するソフトウェアへと変身させるのに必要なことを、すべて伝授しようというのです。
ただし、この本に技術的な内容がないというのでは、まったくありません。本書は、Jenkins,Findbugs,PMD,Kibana,Gradle,Vagrant,Ansible,Fabricなどといった、広範囲なツールを扱います。数多くのリファクタリングパターンを詳細に取り上げ、モノリスからマイクロサービスにいたるさまざまなアーキテクチャにおける関連メソッドを論じ、コードをリライトするときにデータベースを扱う戦略も見ていきます。
レガシーソフトウェア改善ガイド

ビジネス的な理由から最近はDevOps関連書籍を読み始めている。「DevOps教科書」は読み終わって、様々な関連話題を統合するという意味では良かった。次は「The DevOps ハンドブック 理論・原則・実践のすべて」を読む予定（Kindle版が発売されれば・・・）。

この半期の振り返り

写真を見ればわかるけれど、先月からFire HD 8タブレットを利用し始めるようになった。

Fire HD 8 タブレット (8インチHDディスプレイ) (第7世代) 16GB

読書に利用するメイン端末は引き続きPaperWhiteが主力で、タブレットは自宅ダイニングで本を読むときに利用する程度。あと通勤途中で混雑している時にはスマートフォンのKindleアプリで読書の続きをすることもあるといった状況である。FireタブレットはPaperWhiteに比べればパワーがあるので快適なのだけれども重いので、読書はやっぱり専用端末が便利。ただ、技術書の類だとKindleストア以外(例えばオライリー)で購入するものもあって、PDF販売の場合はタブレットで閲覧するほうが便利（というよりPaperWhiteでPDFを読むのは非現実的）。というわけでなんとなく棲み分けはできている感じ。

なお決して強くオススメはしないけれど、世界最長の推理小説と言われている「人狼城の恐怖」は読み切る自信があればオススメ。もうトリックお腹いっぱいになれる。

過去の読書ふりかえり記事

• 2014年に読んだ68冊からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
• 2015年上半期に読んだ本のふりかえり - 勘と経験と読経
• 2015年下半期に読んだ本のふりかえり - 勘と経験と読経
• 2016年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
• 2016年下半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経

情報システムの再構築戦略についての現時点の理解整理

1月に公開されたIPA/SECさんの「システム再構築を成功に導くユーザーガイド」と、最近読んだ「レガシーソフトウェア改善ガイド」を踏まえて情報システムの再構築戦略について再整理してみる記事。再構築における、リファクタリング／リアーキテクティング／リライト／リホスト／リビルド／リプレースなどの各戦略について考えてみたことなど。

• システム開発における上流工程の課題を解決するユーザガイドを公開
• コードがレガシーになる原因のほとんどは、人間に関係している～『レガシーソフトウェア改善ガイド』より (1/2)：CodeZine（コードジン）

レガシーソフトウェア改善ガイド

再構築戦略の再整理

実際にはこれ以外にも手法があるのかもしれないけれど、「システム再構築を成功に導くユーザーガイド」と「レガシーソフトウェア改善ガイド」を元に頭の整理をしてみると、再構築戦略というのはだいたい以下に分類できるような気がする。資料や書籍、記事によって言葉の定義が異なるので以下オレオレ定義に則って記載。

• 現行システムを活かすパターン
  • ①HW更改(ハードウェアのみ交換して延命)
  • ②追加的技術要素で、現行コードを新アーキテクチャで稼動させる(リホスト)
  • ③コードレベルで少しずつ書き換えを行う(リファクタリング)
  • ④サブシステム単位等でアーキテクチャから見直す(リアーキテクティング)

• 現行システムを廃止して新たなシステムを構築するパターン
  • ⑤現状のソフトウェア設計(もしくはコード)を前提として、新たなプログラミング言語で書き直す(ポーティング型のリライト)
  • ⑥現状の要求仕様を前提として、設計から見直しを行いシステムを書き直す(リビルド又はビッグリライト)
  • ⑦出来合いのパッケージなどに置き換えを行う(リプレース)

この整理で各戦略について考えてみたい。

①HW更改

主な情報ソースは「システム再構築を成功に導くユーザーガイド」。

• 原則としてハードウェアの変更のみを実施する。派生的にOSおよびミドルウェアのバージョンアップがされる場合がある
• 原則としてアプリケーションの修正を行わないが、OSやミドルウェアの変更にともなって修正が発生する場合がある
• 品質保証はアプリケーションの修正箇所を除き、疎通確認や新HWでの動作確認のためのサイクルテストなどを中心に実施

いわゆる最もお手軽な再構築の類。一方で過去に見聞きしてきた経験から次のような落とし穴はあるような気がする(実はあまり経験が無い)

• 開発資産と本番環境が適切に管理されていないため、本番にしか存在しないコードや設定がある
  • 新規ハードウェア上に想定手順通りに環境を構築しても動かない等
• OSやミドルウェアのバージョンアップの影響調査にヌケモレがあり追加的な修正が発生する
• バージョンアップ後のOSやミドルウェアに潜在的なバグが存在することが発覚し、回避のための修正が発生する
  • 例えばこんな事件も昨今あったわけで・・・(リリース直前にHWを最新のものに変更してトラブルになったと記憶)
  • ニュース - ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン：ITpro

というわけで、追加的に発生する問題対応の期間バッファとリソースバッファをしっかりと確保するのが重要という認識

②リホスト

主な情報ソースは同じく 「システム再構築を成功に導くユーザーガイド」。

• ハードウェアの変更を行うが、技術基盤の活用によりアプリケーションの変更を極力回避する。
  • 例えば仮想化基盤を利用することにより調達不可能なハードウェアを擬似的に構成しその上で既存アプリを稼動させる
  • 例えばメインフレームCOBOLをオープン系COBOLに移行するなど、現行ソースも極力そのまま活用する
• 「アプリケーションの変換の確からしさ」「アーキテクチャ変更に伴う非互換の対応」「OSやミドルウェアの機能差異を補完する追加の作りこみ」という観点で、現新比較テスト（正しく変換されたか）とサイクルテストなどを中心に品質保証を行う。

一時期はこの手法が「レガシーマイグレーション」という呼び名でもてはやされた時期もあったような気がする。成功すれば費用対効果の高い更改になる再構築の手法ではある。特にホストからオープンシステムに移行する際にはよく検討される印象。一方で、「システム再構築を成功に導くユーザーガイド」でも記載されている通りHW/SWの老朽化対策としては有効だが、維持コストの削減効果はほとんど無い(保守性が改善されるというような効果は無い)というのが最大のデメリットだろう。

また、そもそも論で「アプリケーションがどの程度の歩留まりで変換移行できるか」がキモであり、歩留まりが想定より低かった場合大炎上もしくはプロジェクト失敗となるので、変換移行のフィージビリティを事前に十分に確認するというのがポイントだと考えている。「こうすればできるはずだ」ではダメで「ほとんど完璧に移行できるが、念の為テストをしなければいけない」くらいのレベルでないと戦えないと考えている。

③リファクタリング

他の再構築手法と並べて比較するのがちょっと違うかもしれないが、情報ソースは「レガシーソフトウェア改善ガイド」。もちろんリファクタリングについて論じている書籍は有名どころをはじめとしていろいろあるが割愛。

• リファクタリングそのものは、ビッグバン的なソフトウェアの再構築を回避するための施策である。なおここで言うリファクタリングは手元のコード改善で行うものとは区別される必要がある。

親身に忠告するのだが、リファクタリングは常に、組織の目標を念頭に置いて行う必要がある。言い換えると、誰があなたに給料を払っているのかを忘れてはいけない。リファクタリングは、それがビジネスに長期的な価値をもたらすと、あなたが証明できるときにだけ行うべきだ。
レガシーソフトウェア改善ガイド 第3章 リファクタリングの準備、より

ちょっと観点は違うけど、以前に本ブログでリファクタリングの目的について取り上げた事もある。目的が明確で、利害関係者から承認されていないリファクタリング＝芸術品作り、にならないように注意する必要もあるだろう。

• 「工業製品」としてのソフトウェア - 勘と経験と読経

たとえリファクタリングの直接的な結果として、何も新しい機能が生じないとしても、ビジネスにとって何の価値も生みださないということにはならない。しかし期待されるビジネスの価値を、プロジェクトが始まる前に、できるだけ明白に、かつ具体的に示すことが重要だ。たとえば、あなたが示す価値の提案は、次のようなものになるかも知れない。
このリファクタリングプロジェクトの目標は、

• 新機能Xを、将来は実装できるようにすること
• 機能Yの性能を、20%向上させること

これは、ただ単にリソースを割り当ててもらうため上役たちを説得する材料になるだけではない。プロジェクトの範囲を定め、あなたとあなたのチームが、所定の軌道から外れないようする基準としての役割も果たすだろう。
レガシーソフトウェア改善ガイド 第3章 リファクタリングの準備、より

• 同書では上記の計画のための「調査的リファクタリング」の実施と、合意形成について触れているので参考になる。

④リアーキテクティング

こちらも情報ソースは「レガシーソフトウェア改善ガイド」。コーディングレベルではなく、ソフトウェアの構造を見直す(メソッドやクラスよりも高いレベルで行う)リファクタリングのことを指す。たとえば同書で挙げられている例は次のとおりである。

• モノリス的なアプリケーションを複数のモジュールに分割
• Webアプリケーションを複数のサービスに分散する

こちらも基本的にはビッグバン的なソフトウェアの再構築を回避するための戦略なのだけれども、一方で「リアーキテクティング＋リライト」という作戦に展開することもあるので注意が必要。

⑤ポーティング型のリライト

主な情報ソースは戻って「システム再構築を成功に導くユーザーガイド」。あと 「レガシーソフトウェア改善ガイド」では「ブラックボックス的リライト」と書かれていたりもする。

• 機械的に行うか人海戦術でやるかは別として、既存の設計ドキュメントやソースコードをインプットに割と機械的に新規言語に焼きなおす戦略。ソースコードレベルでは全て刷新となるが、ソフトウェア設計は現行のものを踏襲する点がポイント。
• 設計作業は原則として行わない為、要件定義や設計といった工程工数の発生を抑制できる。
• 実装作業のインプットとしては、既存の設計書を元にする方法と、既存のソースコードを用いる、および両方を使用する戦術が取れる。ソースコードをインプットとする場合、既存の設計書が存在しない、または適切にメンテナンスできていない場合でも再構築を実施することができる。
• 振る舞いがまったく同じソフトウェアを完成させるのがゴール。極端に言えばバグも移植されるのが正しい状態である。
• テストは通常のソフトウェア開発と同様に実施する必要があるが、特に現新比較テスト（正しくポーティングされたか）が重要である。

高難度な再構築戦略なのだけれども、既存システムの保守状況に問題があっても（理論上）実行可能という点と、リビルドに比べるとコストが低減できるかもしれないという点で、割と消去法で選択される印象がある。あと、うまくやれば人海戦術で対応できる場合がありオフショア開発などを活用して大幅なコスト削減が出来るというのもメリットだろう。
ただ、見聞きする範囲で以下のような事態が発生すると、際限なくトラブル化していく傾向があるような気がする

• 同じものを作るのではなく、同時に機能改善やレベルアップを実施しようとしてしまう
  • システムや業務に対するノウハウ蓄積が不十分で、修正方法や影響範囲の検討が出来ずに炎上。
  • また改修することによって現行システムと挙動比較をすることによって品質保障することが出来なくなり、何が正しいのかわからなくなってしまう罠。
• 再実装やテストの段階で根本的な現行システムの誤りを発掘してしまう
  • ベンダーとしては発見した誤りを見過ごすことは出来ないが、利害関係者が「どう直せばいいのか」を策定することが出来ずに爆発。

とにもかくにも、「現状と出来るだけ同じもの」を目指すべきであり（それすら100点を取るのは難しい）それ以外のゴールを設定した瞬間、めちゃくちゃにプロジェクト難易度が増加してしまう点については注意したいところ。

⑥リビルド／ビッグリライト

「システム再構築を成功に導くユーザーガイド」におけるリビルド、「レガシーソフトウェア改善ガイド」ではビッグリライトと書かれているもの。要はイチからシステムを再構築する最もハイコストになる戦略である。加えて最も難易度は高い。成功すれば様々な現行システムの問題を解消できるハイリスクハイリターン戦略。

あなたが「大いなるリライト」（The Big Rewrite）に挑戦するなら、他の選択肢をすべて試した後のことだと思いたい。あなたはコードベースのリファクタリングを試みたが、行き止まりに達した。レガシーソフトウェアをサードパーティ製ソリューションで置き換える方法についても、実現可能かどうか調べたが、あまりにも多くのカスタマイズが必要になって、ゼロから書くより仕事の量が多いことが分かった。リライト（書き換え）から逃れる手段はないと、あなたは結論を下した。それは鳥肌が立つような状況だ。
レガシーソフトウェア改善ガイド 第6章 ビッグ・リライト、より

• 設計工程も含めて、ソフトウェアを完全に作り直す戦略のこと。一般的には、要件定義や設計作業も含めて再度実施し直すこととなる。
• リライトではないソフトウェア開発プロジェクトと異なり、最初からカバーするスコープ範囲が非常に広い点が問題となりやすい。「既存システムがカバーしていた範囲すべて」＋「既存システムで解決できていない業務上の問題点」＋「既存システムの保守・アーキテクチャ上の問題点」の解決を図ろうとするため、通常のソフトウェア開発よりも難易度は高い。およびゴール設定を慎重に行わなければ、完成させることも難しい。
• 通常のソフトウェア開発に加えて、考古学的なアプローチが必要になる。要求を発掘して、推測して、確定する能力がいるのだ
• 関連して、作り直しという観点ではJoel on Softwareの「あなたが絶対すべきでないこと PART I」が非常に良い考察になっているのでオススメしたいのだが、とりあえずはこの記事「はてなは「絶対すべきでないこと」をやらかしたのか？」を参照するのでも良いかも。はてながダイアリーの作り直しで炎上した時の議論に関するものである。「絶対にすべきではないこと＝プログラムをスクラッチから書き直すことに決める」という話である。
• もちろん、作り直さなければいけないときもある。とはいえ高難易度プロジェクトであることを認識し、通常のソフトウェア開発よりも慎重に計画を実施し、リスクを特定しながら推進する必要がある。という意味では冒頭紹介の IPA/SECさんの「システム再構築を成功に導くユーザーガイド」をしっかりとチェックして推進すべき。無料だし。

あと 「レガシーソフトウェア改善ガイド」でさらっと書かれているチームのモチベーションに関する点も重要なポイントだと思っている。要は、チームのモチベーション維持が難しいのだ。

これによってプロジェクトが停滞するだけでなく、しばらく続けていると飽き飽きしてしまうのだ。もちろん開発者は、たいがいコードを書きたくてしょうがないのだが、リライトの場合、その仕事の大部分が、レガシーソフトウェアの謎めいた振る舞いを解き明かし、それをどう扱うのが最良の策かを議論するために費やされてしまう。
レガシーソフトウェア改善ガイド 第6章 ビッグ・リライト、より

⑦リプレース

これは再構築を論点にしたドキュメントでは当然触れられていないのだけれども、きちんと考えるべき戦略のひとつ。システムを捨てて、コモディティ化したパッケージソフトウェアなどに変更してしまうというもの。

• こちらの記事などをまずは参考に。ＥＡのメリハリと実装ソリューション by 中山 嘉之
• もちろんオーダーメードなシステムに比べると様々なところがレベルダウンすることになるので、利害関係者との調整がポイント
• 「以前は出来た」「前はこうだった」の切捨てをどこまで出来るかが成否の要となる
• 一方で大いにコスト削減が実現できるチャンスでもある。再構築そのものはビジネス的な価値を生みにくいので、コスト削減を旗印に攻めていくのが定石ではある

で、どの戦略をとるべきなのか

そもそも、どのような再構築戦略を検討する方法そのものがIPA/SECさんの「システム再構築を成功に導くユーザーガイド」に細かく論じられているので、これを確認するのが一番よいだろう。結論ありきで雑に再構築戦略を選択すると死にやすいので、戦略ごとのメリットとデメリット、リスクと対策を通常の情報システム新規構築よりも慎重に整理すべきだ。とりあえず複雑骨折または炎上してから手元にやってくるのが一番悲しい……

あと再構築後は、もう再構築しなくて良いようなアーキテクチャを目指すべき（参考：リフォーマブル・プラットフォーム・アーキテクチャ｜株式会社メソドロジック、あとマイクロサービスアーキテクチャの文脈でも語られているような形とか）という話もあると思うのだが、それはまた別の機会に。

Kindleでケヴィン・ケリーの近著やSOFT SKILLSを始め技術書籍が50%オフ

久しぶりに割と広範囲にテクノロジー関連書籍が50%オフセールになっている模様。というわけで気づいたものを中心に紹介。

〈インターネット〉の次に来るもの　未来を決める１２の法則

技術エッセイの類だが非常に興味深く、オススメ。本書については本ブログの以下記事で触れているので参考まで。

• 音楽の所有をやめたことと、ケヴィン・ケリー〈インターネット〉の次に来るもの - 勘と経験と読経

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

一般的なビジネス啓蒙書（7つの習慣とか）をあまり読んでいないエンジニアにはオススメだけれども、その手の本を読んだことがある人にはいまさら、という微妙な本なのだけれどもたくさんの情報が詰め込まれている事は確かなので、セールは手に取るチャンスかも。

ヘネシー＆パターソン　コンピュータアーキテクチャ　定量的アプローチ 第5版

現在読んでいるところ。高価なのでセールはチャンスだけれども、当然万人向けではない。教科書の類。

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

こちらも名著の類。高価なのでセールはチャンスだけれども、最近は本書を読むよりリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)を読むほうが良いという評もあるようだ。

エリック・エヴァンスのドメイン駆動設計

名著の類。こちらは現在も読むといろいろと示唆があると思っている。時々読み返している。

Cloud First Architecture 設計ガイド（日経BP Next ICT選書）

あまり手が動かないタイプのいわゆるSIerに所属しているエンジニアなどが最初に読む本としては、いろいろと詰め込まれていて便利な印象。最近よく人に勧めてる。

音楽の所有をやめたことと、ケヴィン・ケリー〈インターネット〉の次に来るもの

ポエムの類。最近音楽の所有をやめたことと、最近読み終わったケヴィン・ケリー「〈インターネット〉の次に来るもの　未来を決める１２の法則」について考えたこと。同書で語られるテクノロジートレンドは、割と実感に即しており、いろいろ考えさせられる。

音楽の所有をやめるまで

これを書くと歳がバレるのだけれども、高校生まではCDとWALKMAN類、学生時代と社会人数年間はMDが主な音楽の所有手段だった。で、社会人になって数年経ってデジタルオーディオプレーヤーが発売され、早い段階から使い始めてた。

最初に使い始めたのはHyperHyde ExrougeというMP3プレーヤーの名機で、すごく使い勝手が良かった。片っ端からCDをリッピングしてデジタル化しながら聞いていた。ただ容量が小さく持ち歩ける量はアルバム3-4枚程度。でも手軽さが何より素晴らしかった。それまでに溜め込んでいたカセットテープとMDはデジタル化出来ないので全部捨てたのもこのあたり。

ちなみにちょっと話がそれるのだけれどもMP3の誕生から普及に関する想像とは異なるドラマについて書かれた「誰が音楽をタダにした？　巨大産業をぶっ潰した男たち (早川書房)」はドキュメンタリーとしてめちゃくちゃ面白いので、この時代にCDをリッピングしてきた世代の方は一読をおすすめしておく。

• 「MP3は死んだ」海外が報道 えっ、どういうこと？

次に買ったのが確かiPod Shuffleの第1世代（512MB）。最初は単に容量が大きい点が嬉しかったのだけど、この時点で蓄積された大量のデジタルオーディオからランダムな楽曲を転送して聞くことの楽しさがあった。音楽のライブラリ管理をitunesに移行したのもこのあたりのタイミング。

そして2007年くらいに世の中に遅れてiPod Classicを購入。たしか容量は80GBだったが、当時保有していた全てのデジタルオーディオを全て持ち歩けるようになった。振り返ると、このあたりが自分の音楽所有のピークだったような気がする。

その後スマートフォンを利用することになってiPodはいつの間にか使わなくなり、つい最近まではiPhoneに1GBくらい音楽を入れて持ち歩いていたのだけれども、先日ついにこれをやめた。音楽ファイルの同期をやめた。

で、今は何で音楽を聴いているのかというと

• radiko.jp
• Amazn Prime Music

である。
自宅の母艦PCのHDDには約60GBのデジタルオーディオの蓄積があるけれども、今後これにアクセスする頻度はどんどんと下がっていくような気がする。

〈インターネット〉の次に来たもの

最近読んだ本でとても面白かったのが、ケヴィン・ケリーの「〈インターネット〉の次に来るもの　未来を決める１２の法則」である。同書は技術そのものの持つ特性を考察することで、インターネットの次にどんなことが起こるのかを論じている。
たとえばこんな感じである。

所有することは昔ほど重要ではなくなっている。その一方でアクセスすることは、かつてないほど重要になってきている。
〈インターネット〉の次に来るもの　未来を決める１２の法則 5.ACESSING、より

高度に進んだテクノロジーのおかげで、こうした魔法のようなレンタル店が実現する。それこそ、インターネットとウェブとスマートフォンの結び付いた世界だ。このバーチャルな棚は無限だ。この最大のレンタル店では、ごく一般的な市民がまるで自分が所有しているかのように、即座に商品やサービスを利用できる。これを利用する方が、自分が持っているものを地下室から探し出すよりも早い場合もある。しかも、商品の品質は自分で所有している場合と同じだ。アクセスする方が所有するよりも多くの意味で優れているので、それが経済を最優先で牽引している。
〈インターネット〉の次に来るもの　未来を決める１２の法則 5.ACESSING、より

〈インターネット〉の次に来るもの　未来を決める１２の法則

そして今まさに自分は音楽を所有するものから、アクセスするものに変えようとしている。その理由は同書に書かれているものとほとんど同じだ。

• ローカルのライブラリを維持するのが面倒。頻度は高くないけど機器をリプレースする度にデータ移行しなければならない
• 利用するのにローカルのライブラリにアクセスするのが煩わしい
• 物理的なメディア（CDなど）の取扱いは面倒の極み。取り込んだ後の保管や廃棄など
• デジタル音楽についても購入手続きが面倒→定額視聴最高
• 新譜や話題の音楽に出会うための活動も省力化したい→radikoのタイムフリー視聴でチャート番組や好きなDJプレイを視聴

といった理由を考えて、思い切ってPrime Musicに移行したのだけれど今の所は不満なし。他の定額サービスに比べてレーベルや新譜のカバー範囲に制限は多いのだけど、自分の興味の範囲がそこに無いので問題なしだ（それでも聞きたい新譜があれば楽曲単位で購入すれは済むし）。

ちょっと悩ましいのは、所有からアクセスに方針を切り替えると、利用する際にはネットワークが前提となってしまうところである。まあモバイルという観点では最近は電波圏外も少ないし、WiFi利用可能な場所も多いから問題ないか・・・この間静岡から東名を走りながらPrime Music利用してみたけれども、まったく問題は無かった。

もちろん災害などでネット断絶など起こればアクセスできなくなっちゃうのだけれども、その時はその時だなぁと。以前の震災（いわゆる311）の際に計画停電などにより数時間の停電も経験したけれども、まぁその時には電池で動くラジオがあれば十分だった。

次は何がおこるのか

「〈インターネット〉の次に来るもの　未来を決める１２の法則」を読むといろいろな事が予想されているのだけれども、それが遠い世界の物事ではなく実感できる生活レベルで経験できるというのは非常に面白いと思う。また、これを実感として楽しめるのは現代に生きている世代の特権な気もする。本記事で取り上げた「Accessing」というキーワードだけでも、音楽だけでなく、どこまで「所有」から「アクセス（権）」に移っていくのか考えるのは興味深い。