勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

情報システムの障害状況ウォッチ(2017年前半)

SEC Journal50号で2017年後半の情報システム障害状況まとめが公開されたので読んでみる記事。単なる野次馬なんだけれど、勉強になるので続けている。

過去に書いた関連記事は以下の通り。

SEC Journal最新号の入手はこちらから。

情報システムの障害状況ウォッチ(2017年前半)

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。なお今期は割と注意して日経コンピュータ記事を読んでいたので、前期よりは情報は充実しているつもり。また4桁数字は元ネタ記事にあるトラブルNo.である。

数が多すぎて、調べるのも一苦労。

失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)

おすすめ
ZERO BUGS シリコンバレープログラマの教え

ZERO BUGS シリコンバレープログラマの教え

まだ読めていない

上司・部下間のコミニュケーションのKY問題

最近コミニュケーションに関するいくつかの問題が身近にあって、いろいろと考えたことを書く記事。上司部下間のコミニュケーションの問題には階層があって、いちばん改善すべきなのは部下側ではなく上司側の問題だと思っていることについて。なお、顧客との(もしくは受発注者間の)コミュニケーションの話はまた別。
AIR!

「コミュ力」の問題はだいたい上司の問題説

あくまで主観的なものだけれども、いわゆる「コミュニケーション能力(いわるゆコミュ力)」の問題の多くは実際には上司(情報の受取り手)の問題で、部下(出し手)の問題は小さいと思っている。

最近読んだ本だと「職場の問題地図」がこの問題を非常に明快に示していた(ちなみに同書はとてもおすすめ)。

  • 3丁目 報連相できていない
    • 部下の伝えるスキルが低い
      • 報・連・相のやり方がなっていない
      • 適切なタイミングで報・連・相していない
    • 上司の受け止めるスキルが低い
    • 報連相をする場やルールがない
      • 上司が忙しすぎて、部下が話しかけるタイミングがない
      • 報・連・相のフォーマットがない

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

「部下の伝えるスキルが低い」と書かれていると部下の問題のようにも読めるけれども、適切な報告の仕方を指導教育していないという意味ではこれも職場や上司の問題である。同書でオススメしている指導フォーマットは次のようなもの。

  • 所用時間を示し相手の都合を確認する
  • まず「報」か「連」か「相」かを伝える
  • 結論を伝える
  • 論点を数で示す(ナンバリング)

「小松課長、いま5分間お時間よろしいですか? 決算早期化プロジェクトの進め方について、ご相談が2点あります。キックオフの日程と、会場についてです。まず1点目の日程について。日程は延期すべきと思います。なぜなら・・・・」
職場の問題地図 ?「で,どこから変える?」残業だらけ・休めない働き方

こういった情報の受け止め方、どういう形で吸い上げるのかという業務プロセス設計上の問題を無視して、「アイツはコミュニケーション能力が低くて、情報が上がってこないんだよな」などと言ってはいけないという話だと思っている。

部下/メンバーに空気を読ませる時点で負け

報告の仕方というテクニック的な側面もあるとは思うけれど、むしろ問題の根っこには、雑なアサインメントやプロセスの組み立てによって、部下やメンバーに「空気を読ませすぎている」ことだと考えている。もちろん問題にはグラデーションがあって、どこまでやれば正解で、どこからが不備という線引きはできないのだろうが、

  • 責任範囲が不明確
  • 裁量の範囲があいまい
  • やっていいことと、いけないことの線引きがあいまい
  • 上司や組織の意思決定が場当たり的で一貫していない
  • 過去の意思決定の精度が不明なので踏襲していいのか常に不明

などが原因となって、なにをどこまでコミニュケーションすべきか常に空気を読みながらやらなければいけない状況が発生して、非効率やコンフリクトが発生しやすくなるのではないだろうか。

ではどうするか。いろいろ考えてみたのだけれどもまずは空気を読ませないために、個々人の役割を具体的かつ明確にするのが良いかと思っている。たとえばちゃんと職務記述(Job Descriotion)を書けばいいのではないだろうかというのが現時点での個人的な結論だ。

ひょっとしたらうまく対応できている組織や現場も多いのかもしれないが、割と日本企業の多くはこういった形で個々人の職務内容を明確化しないのが一般的じゃないかと思っている。

  • マネジメント側が組織やプロジェクトへのアサイン完了した段階で思考停止しまう
  • 何をすべきかを「考えることからが仕事だ」といってしまう、組織設計不備の責任転嫁

というあたりが根っこにあるのではないだろうか。

つまり、「空気読めよ」という批判はどれも他のフレーズに言い換えることができるわけだ。「空気読め」と言って個人を批判すれば、自分の考えや意向、思っていることを明確に言葉にする必要がないので、話者のコミュニケーションの怠慢とも言えなくはない。自分を含めた“周りの意向”を非常に曖昧な「空気」という言葉で表現し、空気にそぐわない個人へ責任転嫁しているだけの話である。

なぜ「空気読め」が日本人のコミュニケーションをダメにするのか? 「空気読めない人」に対する海外の反応

ただし、これはあくまで組織内の話でである

というわけで、組織やプロジェクト内部で部下に「空気を読ませる」ことは悪手だと思っている。が、顧客や発注者に対しても同じ論法が通じるかというと、それはまた別の話だろう。「空気を読ませるようなRFPを出す発注者が悪い」と言ってはいけない(もちろん限度はある)。この場合は「空気が読める」ことは付加価値だからである。このあたりはまたどこかで考えてみるつもり。

一流の人は空気を読まない (角川oneテーマ21)

一流の人は空気を読まない (角川oneテーマ21)

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

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

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

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

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

Campfire

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

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

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

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

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

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

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

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

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

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

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

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

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

三大リスク③開発失敗編

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

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

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

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

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

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

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

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

何が問題なのか?

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

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

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

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

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

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

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

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

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

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

組織パターン

組織パターン

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

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

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

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

https://www.instagram.com/p/BVmvoLgAYIH/

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

Fire HD 8 タブレット (Newモデル) 16GB、ブラック

Fire HD 8 タブレット (Newモデル) 16GB、ブラック

先に結論から。

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

どうしてそうなった

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

FireでPython実行環境構築

$ 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

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

  • Jupyter notebook起動

$ jupyter notebook

うまくいかない事

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

スクリーンショット

具体的にはこのような感じになる。動く、動くよ!
f:id:kent4989:20170704225237p:plain:w200f:id:kent4989:20170704225249p:plain:w200f:id:kent4989:20170704225259p:plain:w200

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

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

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

2017年1月~6月に最後まで読み終わった本はこんな感じ。
https://www.instagram.com/p/BOwViOSgTAu/https://www.instagram.com/p/BPFnWiyARVF/https://www.instagram.com/p/BPfM-goAPOJ/https://www.instagram.com/p/BPfN2LigGrM/
https://www.instagram.com/p/BPpmiHKg0jQ/https://www.instagram.com/p/BPsO3XBgka2/https://www.instagram.com/p/BP1rxgMghOK/https://www.instagram.com/p/BQK4qMyAknP/
https://www.instagram.com/p/BQQQ6g1ghOn/https://www.instagram.com/p/BQVPYdFAc4b/https://www.instagram.com/p/BQnP2t0Av3e/https://www.instagram.com/p/BQ9wYYUACAL/
https://www.instagram.com/p/BRGMDUSguum/https://www.instagram.com/p/BRN6LNfAs_r/https://www.instagram.com/p/BRYVvjzg8pv/https://www.instagram.com/p/BRa49QkA848/
https://www.instagram.com/p/BRlHLtwAJR4/https://www.instagram.com/p/BR0CCOwgJp4/https://www.instagram.com/p/BR1plNWAMxy/https://www.instagram.com/p/BR-4tLLAf6v/
https://www.instagram.com/p/BSXaXI0Avui/https://www.instagram.com/p/BSi-e3VAF_9/https://www.instagram.com/p/BS03f6zgZQv/https://www.instagram.com/p/BS7VszFgZJ5/
https://www.instagram.com/p/BTKsidzAE2s/https://www.instagram.com/p/BTRNAScgswV/https://www.instagram.com/p/BTWdShoAjkb/https://www.instagram.com/p/BTwFm9SAvSU/
https://www.instagram.com/p/BTwJObcgbO7/https://www.instagram.com/p/BTxM1C7AT1b/https://www.instagram.com/p/BT6UqeJAmV5/https://www.instagram.com/p/BT6U8xng3Kt/
https://www.instagram.com/p/BUTzm3wAEbR/https://www.instagram.com/p/BUZZnz8ANAg/https://www.instagram.com/p/BUng1tug5qH/https://www.instagram.com/p/BUwtFCAA7Af/
https://www.instagram.com/p/BU68sJrAQFq/https://www.instagram.com/p/BVe2xQYgWQ-/https://www.instagram.com/p/BVmpoqCgVOI/

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

オススメ文芸書編

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

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

オススメビジネス書編

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

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

オススメ技術書編

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

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

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

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

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

この半期の振り返り

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

Fire HD 8 タブレット (Newモデル) 16GB、ブラック

Fire HD 8 タブレット (Newモデル) 16GB、ブラック

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

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

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

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

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

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

再構築戦略の再整理

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

  • 現行システムを活かすパターン
    • ①HW更改(ハードウェアのみ交換して延命)
    • ②追加的技術要素で、現行コードを新アーキテクチャで稼動させる(リホスト)
    • ③コードレベルで少しずつ書き換えを行う(リファクタリング)
    • ④サブシステム単位等でアーキテクチャから見直す(リアーキテクティング)
  • 現行システムを廃止して新たなシステムを構築するパターン
    • ⑤現状のソフトウェア設計(もしくはコード)を前提として、新たなプログラミング言語で書き直す(ポーティング型のリライト)
    • ⑥現状の要求仕様を前提として、設計から見直しを行いシステムを書き直す(リビルド又はビッグリライト)
    • ⑦出来合いのパッケージなどに置き換えを行う(リプレース)

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

①HW更改

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

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

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

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

②リホスト

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

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

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

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

リファクタリング

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

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

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

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

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

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

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

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

④リアーキテクティング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⑦リプレース

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

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

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

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

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