勘と経験と読経

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

KindleでPoEAA(エンタープライズアプリケーションアーキテクチャパターン)が28%オフのセール中他

GW後半からKindleで広範囲な20%ポイント還元セール中になっているのだけど、PoEAAについては値引きもあわせて28%ほどの割引になっている模様(10%値引きに対して20%ポイント還元なので)。技術書としては古典だけれど、未読で興味のある人はチャンスかも。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

古い本だけれど、固定レイアウトではなくて普通の電子書籍として読める(今読んでいるところ)。

あとこれも値引き+ポイント還元で27%くらいオフかな。こちらは未読。

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

他の本は20%ポイント還元のみだけれど、購入予定の高額技術書はチャンスかも。個人的なオススメは以下。

セールは突然終わることもあるので、値引き状況はリンク先でご確認ください。

最近のSIer論に想うこと

ここ数年、定期的にソフトウェア業界で盛り上がるのがシステムインテグレーター(SIer)のビジネスモデルに対する批判の話題である。いろいろと議論されるのは良いことだと思うのだけれども、自分の周りで不必要に不安を感じている人が多いのでいったん現時点での私見をまとめておく。最近よく面談で聞かれる「SIerってどうなんですか」「SIerに所属することについて不安を感じんですけど」という質問に対する2016年前半時点での答え。

Towel dna.jpg
By Ammit - selber Fotografiert, パブリック・ドメイン, https://commons.wikimedia.org/w/index.php?curid=247724

気をつけるべきこと

本論のSIer論とは全然関係ないのだけれど、先の震災の時に糸井重里氏が書いたこのコメントを紹介しておきたい。

このコメントは震災の後、デマを含む様々な情報がネットで飛び交っていたときに発せられたもの。文脈は異なるけれど、昨今話題となるSIer論についても様々な立場の人やメディアが、いろいろな立場で、いろいろな形で情報を発信しているので注意したほうがよいと思うのだ。そしていたずらに不安を感じるのはやめたほうがいいと思う。

ギーク向けには以下の書籍もおすすめしておきたい。

作中に登場する(本当の)銀河ヒッチハイクガイドにも、表紙には親しみやすい大きな文字で『あわてるな』(Don't Panic、パニクるな)と書いてあるぞ。

自分のキャリアとビジネスについて再考する

現在も進行中だし、今後もSIerを中心とするIT業界は大きな変化が起こっていくだろう。
ただ、いたずらに不安を感じて安易に船を乗り換える行動をするのは乱暴すぎるし、リスクも大きい。
というわけで、個人的にはPanicになっている人には以下のアドバイスを行っている。

  • SIerというと将来は明るくなかったり不安を感じたりするかもしれないけれど、もう一歩踏み込んでソフトウェア開発業務に従事しているという立場に立ち返って、ものごとを考えた方が良い
  • SIerはあくまでビジネスモデルの一形態である。課題は多いが、ビジネスモデルの良し悪しは本来は技術者のキャリアパスとは直接関係ないはずだ。ビジネスモデルとキャリアパスを一緒に考えるのは筋が悪い
  • ソフトウェア開発のプロフェッショナルとして仕事をすることに立ち返って、自分自身のキャリアパスを考えるべき。そして、そのキャリアパスを実現するためにどう行動するか、が重要
  • 5年後くらいまでのキャリアの見通しを考える。見通しが立たないのであれば情報不足か検討不足だ。まず見通しを立てるべき
  • 10年後くらいに業界それを取り巻くビジネスモデルがどうなっているかなんて、誰にもわからない。ソフトウェア開発技術者としてのキャリアをしっかりと構築しよう
  • 現在のアサインメントに不満があるのであれば、それを改善するために何ができるのかを考えよう。プロジェクトなんて千差万別だし、移ろい変わるものなのだから(特にSIerにいれば)
  • ソフトウェア開発を行う場所としては、SIerは選択肢(プロジェクト)を固定せず、うまく渡り歩く事でいろいろなキャリアを構築しやすい。その特性を有効活用できないか考えてみるといい
  • 職場文化は自らが創るものであると考える
  • 仕手士になるな。中抜きの仕事で満足するな

キャリアデザインについて考えている人におすすめの本は以下の2冊。前者は若手向け。

現時点でのSIerに所属する自分の考え

  • 勝負はこれからだ
  • キャリア構築は長期戦だ。いま何の仕事をやってるか、短期的な役割は割とどうでもいい
  • 自分の市場価値が低下しないように、自己学習投資は怠らない
  • 20年後も、現場の中堅・若手と競争できるようにするにはどうすればよいかを考える
    • 国内の労働者数は今後減少していく。健康で、競争力があれば老いても仕事はある(ということを最近先輩諸氏が示してくれている)
    • 働きつづけることは普通になる

未来の職業生活に向けて準備するのは、刺激に満ちた経験だ。今後数十年の間に、仕事の世界で多くの変化が起き、キャリアや働き方に関する古い常識が次々と葬りさられる。
ワーク・シフト ─孤独と貧困から自由になる働き方の未来図<2025>

みなさんのお父さんやおじいさんは――お母さんやおばあさんは仕事をもっていない場合が多かったでしょう――生涯を通じて一種類の仕事を続けるのが普通でした。でも、みなさんは六〇年以上、働き続けることになります。生涯の間に、いろいろなタイプの仕事を経験するケースが増えるはずです。最初の仕事に就いてから二〇年たって、別の道に移る人もいるでしょう。あるいは、四〇年たってから進路を変える人もいるかもしれません。まず学校に通い、その後で仕事に就き、それから引退生活に入るというシンプルな道のりを歩んで人生を送るケースは珍しくなります。複雑なモザイクのように、人生のさまざまな段階に教育や能力開発の要素を織り込むようになるでしょう。
ワーク・シフト ─孤独と貧困から自由になる働き方の未来図<2025>『子どもたちへの手紙』

  • 2045年まで生き延びて、シンギュラリティを突破を目指すのが目標
    • ここまで生存できれば技術的特異点の出現(超AI、不老不死技術など)によって、様々な問題が解決するはず

おまけ

ただし、古代ではあまり広くは使われなかった。当時、「メメント・モリ」の趣旨は carpe diem(今を楽しめ)ということで、「食べ、飲め、そして陽気になろう。我々は明日死ぬから」というアドバイスであった。ホラティウスの詩には「Nunc est bibendum, nunc pede libero pulsanda tellus.」(今は飲むときだ、今は気ままに踊るときだ)とある。

まだまだ踊りたい

IPA/SEC情報処理システム高信頼化教訓の2016/1~3の更新点を読む

IT業界(?)のトラブル情報を収集して、そこから教訓を抽出して公開するという取り組みをIPA/SECが行っている。わりと惰性でやっている感はあるのだけれど、2016年1月から3月までにいくつか教訓が追加されていたので目を通して感想を書いてみた。

前回記事はこちら

2016/1~3に追加された教訓

今回読んだのは以下のもの。

ID タイトル 教訓
T20 パッケージ製品の機能カスタマイズに関する教訓 パッケージ製品の機能カスタマイズはリスクを認識し、特に必要十分なチェック体制やチェック手順を整備して進めること
T21 運用保守で起きる作業ミスに関する教訓 作業ミスを減らすためには、作業指示者と作業者の連携で漏れのない対策を!
T22 バッファプールの管理に関する教訓 隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること
G10 システム動作の疑義問合せがあった場合の対応に関する教訓 関係者からの疑義問合せは自社システムに問題が発生していることを前提に対処すべし!
G11 システムの運用・保守に関する教訓 システムの重要度に応じて運用・保守の体制・作業に濃淡をつけるべし
G12 キャパシティ管理のマネジメントに関する教訓(その1) キャパシティ管理は、業務部門とIT 部門のパートナーシップを強化するとともに、管理項目と閾値を設定してPDCA サイクルをまわすべし
G13 キャパシティ管理のマネジメントに関する教訓(その2) キャパシティ管理は関連システムとの整合性の確保が大切
G14 キャパシティ管理のマネジメントに関する教訓(その3) 設計時に定めたキャパシティ管理項目は、環境の変化にあわせて見直すべし

[教訓T20]パッケージ製品の機能カスタマイズはリスクを認識し、特に必要十分なチェック体制やチェック手順を整備して進めること

微妙な事例。新規構築したコールセンタ受付システムにて、顧客向けにカスタマイズした箇所に不具合あり業務影響が出てしまったというもの。該当の不具合は事前のテストで検出することが難しいものだったということだが、そもそも顧客に「カスタマイズしている」ということを十分に説明していなかったという点が問題だったと言いたいようだ。

おそらく「このシステムは他社でも多数利用実績のある品質の高いパッケージです」という売り文句で導入したものの、いきなり不具合が出て「品質高いんと違うのか?」「そこだけは御社専用のカスタマイズ部分でした。本体品質は問題ありません」「そんなこと事前に聞いてないし、わかるかい!」という揉め方をしたのだろうと思う。

ちなみにIPA/SECでは「ソフトウェア品質説明」というキーワードで品質説明力(?)を高める検討をしているようで、以下の資料も興味深い。

[教訓T21]作業ミスを減らすためには、作業指示者と作業者の連携で漏れのない対策を!

わざわざ教訓にする必要があるのか、ちょっと悩ましい印象をもつ事例。あいまいな作業指示+結果を作業指示者がちゃんとチェック検証していないでやらかしてしまったトラブルである。TPSにおけるポカヨケを考える必要がある印象。

[教訓T22] 隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること

こいつも微妙な事案。後方にあるキューが溢れて、業務全体を管理するキューまで溢れて全業務停止、といった内容。これは単純に運用設計の漏れな気がするのだけれども・・・。

[教訓G10]関係者からの疑義問合せは自社システムに問題が発生していることを前提に対処すべし!

一部の接続先通信業者から接続異常の問い合わせがあったにもかかわらず、自システムの障害の可能性に気づかず相手先の問題として切り捨ててしまったために、問題発覚が遅れたという事案。ある意味、インシデントの切り分けに課題があると思うのだけれども、保守体制にある程度の余裕がないと実運用で改善するのは難しいのではないだろうか。ただ、この事案は頭に入れておいたほうが良い気がする。

[教訓G11]システムの重要度に応じて運用・保守の体制・作業に濃淡をつけるべし

複雑で難しい事案。複合的な要因(製品不具合、リカバリー作業時の保守作業ミス)で重要なシステムが停止となったとのこと。教訓に書かれている通りでもあるのだけれど、システムの重要性を鑑みてレベル分けを行い、最重要システムはそれなりにコストをかけて障害対応訓練を行うべきだろう。防災訓練と同じで、スムーズな初動は訓練によって生み出されるものである。また教訓には書かれていないけれどシステムコンティンジェンシープラン的なものをきちんと策定し、毎年ちゃんと見直すような活動も重要だと思う。

[教訓G12]キャパシティ管理は、業務部門とIT 部門のパートナーシップを強化するとともに、管理項目と閾値を設定してPDCA サイクルをまわすべし

想定取引データ量の急変によりシステムが停止したもの。その後、IT部門と業務部門が連携してキャパシティ管理するようになったらうまくいったというベストプラクティスの共有となっている。

この教訓では「キャパシティ」というKPIについて議論がされているが、近年脚光を浴びているDevOpsに通じるものもある。システムという重要なビジネスリソースを最大限活用するという意味では、開発、運用、業務の三位一体での合意形成が必要という話があるが、まさにその一例であったという印象。2013年の夏のデブサミの基調講演でもそういった話があったことを思い出した。

[教訓G13]キャパシティ管理は関連システムとの整合性の確保が大切

次に紹介する教訓G14も含めて、単一の事例(どこかの会社からの報告)からいろいろと読み取って掲載しているようだ。この事例では、システム群全体のキャパシティを見極めるために、システム間の連携を台帳管理しながら関係者で頭を付き合わせて管理をするというプラクティスを紹介している。
このアプローチに似たものは何回か見聞きしたことがあって、確かに有用なのだけれども、台帳を維持する労力がバカにならないので、強い統制を効かせないと実行は難しいと思う。また、システム間連携管理台帳を「データディクショナリに登録して管理する」というのは考え方として違和感を感じる。マスタデータ管理と、トランザクション管理は別のスキームだと思うのだけれども、どうだろうか。

[教訓G14]設計時に定めたキャパシティ管理項目は、環境の変化にあわせて見直すべし

これも教訓G12,G13と同じ事例から抽出された教訓の模様。キャパシティをPDCAサイクルで維持管理しつつ、見直した内容を適切に次期システム検討のインプットに継承しましょう、ということが書いてある。その通りだし、異論は無いのだけれども現行システムの運用保守に、次期システムの考慮も同時に実施させるというのが現実的なのかどうか疑問を感じた。次期システム検討時に、きちんと非機能要件を検討分析すれば漏れないような気もするのだけれど。

Kindleで大規模セールで安くなった目ぼしい技術書リストアップ

Kindle技術書の定点観測結果より。30%~70%くらいの範囲で割引セール中の模様(ポイント還元を含む)。対象はこれからも変動あるような気がしている。割と高額な「エンタープライズアプリケーションアーキテクチャパターン」「ソフトウェアシステムアーキテクチャ構築の原理 第2版」「Code Complete」「エリック・エヴァンスドメイン駆動設計」「実践ドメイン駆動設計」「アジャイルソフトウェア要求」「ディシプリンド・アジャイル・デリバリー」あたりが狙い目な印象(未購入なら)。
あと、わりと新しい本であれば「The DevOps 逆転だ!究極の継続的デリバリー」あたりが安い。

アーキテクチャ構築の原理 第2版を読んだ

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」を読了した読書メモ。なお書籍版だと898g、616頁の大著をKindle版で手軽に持ち運べるのは有難い(もちろん、必要に応じてPCでも閲覧できる)。今後、何度も読み返すような本である。

ソフトウェアシステムアーキテクチャ構築の原理 第2版

ソフトウェアシステムアーキテクチャ構築の原理 第2版

最後には監訳者である榊原さんのあとがきが。

本書の真骨頂は、ビューポイントとパースペクティブのカタログ化にある。十二分なボリュームの書籍でもあり、生真面目に最初から600頁を読み進める必要はない。まずは第30章から読み始めてみるのもいいかもしれない。どこでどのテクニックを使うのか、インデックス的な使い方をするのも本書を有効に活用する1つの手だ。
ソフトウェアシステムアーキテクチャ構築の原理 第2版

すいません、生真面目に読み進めてしまいましたorz。というわけで、これから読む方は監訳者あとがきから読むことをまずオススメする。上記だけでなく、本書の読み解き方についてアドバイスがしっかりと書かれている......

なお、30章は「ソフトウェアアーキテクトとして仕事をする」である。この章では規模(小規模/アジャイル/計画駆動/大規模)や形態(社内システム/製品開発/エンプラシステム/既存エンハンス/パッケージ/ネット対応/廃止)ごとにアーキテクトとして検討する事項と、どの章を読むべきかがとりまとめて記載されている。第1部、第2部と読んだあと、自分の置かれている状況に応じて第30章を読み解き、ガイダンスに従って残りの章を読むのが良いかと思う。

ますます重要になるアーキテクチャ

現代では、いろいろな要因からソフトウェアの仕様はますます変化し易くなり、固定化や文書化が難しくなってきている。

  • ビジネス側の要請により、要求されるデリバリーサイクルが非常に短くなった
  • 慎重に計画・検討して構築するのではなく、迅速に構築して試行し、結果評価をすぐに再反映するような開発プロセスや基盤技術が実用的になった
  • 取り扱うニーズが高度化、複雑化したことにより、「作らずに仕様を決定する」ことそのものが困難になった。「作りながら考える」ことが必然となった

このような状況で「要件」や「仕様」をきちんと文書化するのは難しいだけではなく、無駄にもなりがちだ。最近見聞きするプロジェクト事例だと、専用の要求管理ツールやチケットシステムで管理することも多くなっているようである。アジャイル開発プロセスの文脈だと「ストーリー」とか「フィーチャー」と呼ばれるものが管理する対象である。

では、随時登録/更新される「ストーリー」のリストをインプットにソフトウェアは開発できるのかというと、そうではない。土台として必要となるのが開発の軸としての「アーキテクチャ」である。

最近、グローバルでアジャイル開発を啓蒙している組織の事例を見聞きする機会があったのだけど、やはり「アーキテクチャ」はきちんと文書化して共有し、その上で随時変化する要求を管理ツールで共有しながら順次開発していると聞いた。

思うに古き良き滝の時代に時間をかけて作成していた「要件定義書など」はある程度アーキテクチャの記述や表現を含んでいたんじゃないだろうか。しかし、時代の要請で「要件定義書」は失われ、別の形に変化してしまった。そこで、これまで以上にアーキテクチャを分析し、明確化する重要性は高まってきているのではないかと考えている。

アーキテクチャ構築の原理

さて、本書に何が書かれているかだけれども、詳細な目次は以前に新旧版の比較をした際の記事を見ていただきたい。概観としては以下の通りである。

  • 第1部 アーキテクチャの基本
    • アーキテクチャの概念についての整理。本書を読む上でも重要な「ビュー」「ビューポイント」「パースペクティブ」の関係について論じられている。
    • 第5章に「核となる概念間の相互関係」がモデルとして提示されているので、それを中心に読んでいくと良いと思う。
  • 第2部 ソフトウェアアーキテクチャのプロセス
    • どのようにアーキテクチャを検討し、最終的にアーキテクチャ記述(AD)に落とし込んでいくか、について記述されている。
    • 第13章で、サンプルとしての具体的なアーキテクチャ記述(AD)の章立てが提示されており、これと5章の「核となる概念間の相互関係」の関係を意識すると分かりやすい印象。

手書きの整理をしてみた。
https://www.instagram.com/p/BCLABITnEKC/

  • 第3 部 ビューポイントカタログ
    • ここからはアーキテクチャ検討において具体的に活用する観点のカタログである。
    • 「ビューポイントカタログ」はアーキテクチャ検討上の重要点が書かれているので、目を通して損は無いような気がする。

ビューポイントと、それぞれで作成する主要なモデルの関係を手書きで整理してみた。
https://www.instagram.com/p/BCVP6I9nEPF/

  • 第4部 パースペクティブカタログ
    • ここは、必要に応じて閲覧すればよい印象
  • 第5部 すべてを1つにまとめる
    • ソフトウェアアーキテクトとしてどのように取り組むべきか、についての論考。
    • 冒頭で紹介した監訳者あとがきにある、第30章はここに含まれている。

体力が許すならば第1部~第2部までは通して読んで、その後第5部を読んでから、必要に応じて第3部と第4部を読むのが良いような気がする。とはいえ、通読するのも非常に勉強になる、今後も何度も立ち返っていく教科書のような本であった。

ソフトウェア要求、The DevOps他がKindleで50%以上オフ以上のセール中(対象じわじわ拡大中)

定点観測したところ、ソフトウェア要求が50%オフ、The DevOpsが50%オフ+20%ポイント還元のセール中の模様。ちなみにどちらも自分でKindle Paperwhiteで読了済。特に支障なく読めます。
3/16追記:デマルコのデッドライン、ワインバーグさんの本、ソフトウェアテスト293の鉄則、ソフトウェア見積りもポイント還元あわせて50%以上オフになっている模様。ロジックがよくわからないけれど…
さらに追記:よくわからないけど1日2-3冊くらいずつセール範囲が拡大している。発見したものは末尾に追加。
3/17追記:デマルコの熊とワルツが追加された。じわじわ感。

ソフトウェア要求 第3版

ソフトウェア要求 第3版

↑上流工程に関する課題はこれ一冊でかなりカバーできている印象。第3版でアジャイル開発プロセスへの考察も追加されている。

The DevOps 逆転だ!究極の継続的デリバリー

The DevOps 逆転だ!究極の継続的デリバリー

↑「ザ・ゴール」のような小説形式で学ぶソフトウェア開発プロジェクト最適化の話。根底には、制約理論(TOC)とリーン開発が含まれている(アジャイル開発プロセスへの言及はあまりない印象)。

MSでDevOps普及の活動をされている牛尾さんも推薦しているようだ。

追記

以下の本もセール中の模様。

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

↑50%オフ。この本は開発プロセス改善という観点でおすすめ。

↑古典的デスマ小説、というのは上段だけど、困難なソフトウェア開発のドキュメンタリーとして読んでおきたい一冊。

さらに追記

ロジックがよくわからないのだけど、デマルコのデッドラインも50%オフになってた。こちらもThe DevOps同様に小説仕立てでソフトウェア開発を論じる本、というか元祖っぽい気がする。

デッドライン

デッドライン

3/16さらに追記

以下もポイント還元込みで50%以上オフになってた。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

↑過去に以下の記事でもオススメしている良著。

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

↑こちらもとても参考になる良書。しびれる名言がたくさん書かれている。

プログラミングの心理学 【25周年記念版】

プログラミングの心理学 【25周年記念版】

パーフェクトソフトウエア

パーフェクトソフトウエア

↑こちらもソフトウェア開発の名著。

3/16さらにさらに追記

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

↑良い本だけど玄人向け。

↑確か未読。

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法

↑良書。

3/17追記

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

↑名著のひとつだが、実はちゃんと読んだことが無かったのでこの機会に購入した。

情報システムの障害状況ウォッチ(2015年後半)、ポストモーテム

SEC Journal44号で2015年前半の情報システム障害状況まとめが公開されたので読んでみる記事。
前回記事はこちら。

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

http://www.flickr.com/photos/7119320@N05/22856576053
photo by Sean_Marshall

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

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をニュース記事などとザックリ照らし合わせてみた。全般的にトラブル発生時の速報はあれど、原因や再発防止などが公開されていることはあまりないのが残念なところ。また、日経コンピュータさんがいろいろ取材されて深掘りされているようなのだけど、記事がほとんど公開されていないのはちょっと残念。ビジネス的な判断なのだと思うのだけど、公益性も鑑みてトラブル事例は公開していくことを検討して欲しいと思う。

注目事例

SEC Journal44号の紹介記事の中でも取り上げられているけれど、「長期間の不具合放置」関連の事例が目立っている(1524,1526,1530,1541など)。SEC jounal44号の記事では

以上の5件はいずれも、一見正常に運転されているにもかかわらず、実は重大な問題を抱えたまま運用されていた事例である。不具合によってシステムがダウンするなどの現象が発生すれば、誤りは直ちに検知されるが、この種の事故は開発段階での綿密なテスト計画の策定とその着実な実施という基本的な対策でしか回避の方法はない。
(SEC Journal44号 連載 情報システムの障害状況 2015 年後半データ より)

と書かれているのだけれども、ちょっと違う印象を持った。リスク管理の問題ではないだろうか。

  • 最終テストとして、何を確認して、何を確認していないのか明確にする
    • 例えば[1541]の緊急通報メール発信トラブルについては、システムと通信事業者間の疎通確認はやったけれども、通信事業者から利用者までのメール発信の疎通は(おそらく)実施していない。本番環境でのテストは実施しないという判断はあり得るが、テストしていないという事実をきちんと関係者間で共有していたのかというと、おそらくしていないのではないかと思う。
    • [1527]メタボ検診システムについても、実データでのテストは実施していないということを明確にしておくべきだったのではないかと。これもセキュリティ等の観点で、実データを利用しない判断があったとしてもこれは問題ない。しかし、何を「やっていないか」を明確にすべきだろう。
  • 実機で確認できていないことは、どんな代替手段でリスク軽減(検証)したのかをはっきりとさせる
    • 実機確認できないものについても、テスト環境で検証するか、それも困難であれば綿密な机上確認するなどによってリスクは軽減できるはずであり、それを検討すべきと考えている。
  • 残余リスクについて、そのリスクが消滅するまで継続監視する
    • システムの構造上、なかなか本番稼動しない機能はあると思う(1年に1回しか動かない、とか災害時にしか動かないとか)。とはいえ、本番稼動実績のない機能はリスクが残っている。こういったリスクは解消するまで(初回稼動が終わるまで)トレースしていかないと、思わぬところで足をすくわれる事になるのでは無いかと思っている。

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則