よしたく blog

ほぼ週刊で記事を書いています

じぶん Release Notes 0.30.01

5月1日〜31日のあいだの出来事がリリースされました。

5月の感想

今月はweb1weekという1週間でwebサービスをリリースするというイベントに参加しました。 業務外で取り組んだこともあり大層なものは作れませんでしたが、自分の実力と何が足りていないかがわかっていい機会となりました。 他にも空いた時間を有効活用するために語学学習を取り入れて、それが継続できているので非常にいいと思っています。 実際に海外のカンファレンスの発表を聞いても聞き取れるようになってきているので効果を実感できています。

技術・開発関連

取り組み

技術面での取り組みは以下の通りです。

  • Nuxt.jsと使って個人開発をした

イベント

個人的なこと

読んだ

ブログ

リリースノートを除き、次のエントリを書きました。

PV数

5月は3939でした。

5月の目標結果

  • MOTHER2クリアする
    • 達成
    • なにか新しいことを始めて達成してみようというライトな目的だった
  • 英語で技術ブログを書く
    • 達成
    • 英語学習が習慣化できてきたので、もっと広い人にアプローチができればと思って始めた
    • まずは最初の一歩が踏み出せてよかった

スマホで気軽に「草」を生やそう「Pixela」「Pixela UI」を使ってみた

初めは慣れなかったWork From Homeも一ヶ月以上が経ち慣れてきた。 自分をはじめWork From Homeに慣れた人の中には通勤時間として使っていた時間を有効活用して、新しく何か始めた人も多いはずだ。 自分も空いた時間を使ってリングフィットアドベンチャーで体を動かしたり語学系のYoutubeを見て今までやれなかった活動を取り入れてる。

現時点ではどれもうまく継続できており、いい気分転換にもなっている。 もちろん楽しいから続けていることではあるが、より自分のモチベーションを高めて維持していく目的として目に見える形で管理できるようにしたこともある。 例えば、プログラムを書くことを習慣化したいプログラマにとってはGitHubの草システムはとても良い働きをしているはずだ。 個人の習慣や継続の「見える化」として、色々探していたときに出会ったのが「Pixela」と「PixelaUI」だ。

Pixelaとは

まずはPixelaの説明を公式サイトより引用する。

Pixelaとは、 あなたの頑張りや継続を記録し、育てたい。 そのすべてを、APIで。 Pixela はAPIサービスです。このサービスを使えば、あなたの日々の様々な活動量を GitHub のような鮮やかなグラフで表現できます。 そのすべての操作を、APIで。もちろん、無料です。

GitHubの「草」の形でグラフが表示され、自分がおこなったことを可視化できる。 次のURLは自分が習慣化し、毎日記録しているものだ(ちなみに中国語はお休み中…)。

pixe.la

使い方も簡単でグラフの作成やグラフへの記録はWeb APIでおこなえる。

https://docs.pixe.la/

例えば次の3行だけで「yoshitaku_jpユーザを作成」「ring-fit-adventureグラフを作成」「ring-fit-adventureグラフにコミット」を実行し使い始めることができる。

curl -X POST https://pixe.la/v1/users -d '{"token":"YOUR_TOKEN", "username":"yoshitaku_jp", "agreeTermsOfService":"yes", "notMinor":"yes", "thanksCode":"ThisIsThanksCode"}'
curl -X POST https://pixe.la/v1/users/yoshitaku_jp/graphs -H 'X-USER-TOKEN:YOUR_TOKEN' -d '{"id":"ring-fit-adventure","name":"ring-fit-adventure","unit":"commit","type":"int","color":"shibafu","timezone":"Asia/Tokyo","isSecret":true,"publishOptionalData":true}'
curl -X POST https://pixe.la/v1/users/yoshitaku_jp/graphs/ring-fit-adventure -H 'X-USER-TOKEN:YOUR_TOKEN' -d '{"date":"20200527","quantity":"1","optionalData":"{\"key\":\"value\"}"}'

個人的にPixelaに感じていたハードル

実はPixelaは以前から知っておりすごくいいサービスだと思っていたが、なかなか実際に利用する機会がなかった。 Web APIが提供されているので、作例にあるような「デプロイの回数を記録する」などは非常に相性が良さそうに思える。 しかし、個人的な習慣の記録をメインで使うのはどうにかしてWeb APIを叩かないといけないことが心理的なハードルとなっていた(個人的に自動化のシステムを上げて組み上げている人はすごい!)。

Useful case examples · a-know/Pixela Wiki · GitHub

スマホでPixelaが使えるPixelaUI

ここで登場するのがPixelaUIだ。 スマホで手軽にポチポチしてPixelaに記録したいなと思い調べていたら、知らないあいだに出ていたiOSの「PixelaUI」アプリに出会えた。 Pixelaを作ったa-knowさんのブログより引用の形でPixelaUIの紹介する。

そして今回いよいよ、有志の(そして、会社の同僚でもある)方・id:yutailang0119 の手によって、Pixela iOS/iPadOS クライアントが爆誕しました!!その名も、PixelaUI! この PixelaUI は、「公式」(僕が作った)というわけではないですが、id:yutailang0119 とは繰り返しやりとりをしながら作っていってもらったので、「公認」、というかんじの位置づけでぜひたくさんの方に使っていただけたらな、と思っています。サービスのトップページにもはやめに掲載したい。

blog.a-know.me

「まさにこれだ」という感覚であり、自分が求めていた手軽さが体現されていて今では「Pixela」と共に愛用している。

PixelaUI

PixelaUI

  • Yutaro Muta
  • ユーティリティ
  • 無料
apps.apple.com

使ってみよう

ユーザ作成

ユーザ作成もアプリで実行することが出来る。

f:id:yoshitaku_jp:20200527205703p:plain

グラフの作成

IDとNameは記録したいことに関係する値を入れる。 例では電車に乗った回数として「train」、健康管理の目的として「weight」とした。

Unitには単位を入れる。 trainはいい単位が思いつかなかったのでデフォルトの「commit」、weightは「kg」とした。

Typeには管理する数値を整数とするか小数点まで入れるか選べる。 trainは回数なので「int」、weightは小数点まで入れるので「float」とした。

colorは気分に合わせて「緑」「赤」「青」「黄色」「紫」「黒」の6色から選べる。 今回は見慣れている「草」でやってみたいので緑色にした。

TimeZoneは何も選ばなければUTCとなる。東京に合わせたいときは「Asia/Tokyo」としよう。

Self Sufficientは、グラフを開いたときに自動的に値を入力するかどうかを選べる。 trainは入力を手間を省くために画面を開くだけで加算される「increment」、weightは手入力したいので「none」とした。

設定する際の参考になれば。

f:id:yoshitaku_jp:20200527205749p:plain

f:id:yoshitaku_jp:20200527210027p:plain

コミット

train

trainは一覧画面を開くと画像のようになり、自動入力の設定をしたので画面を開くたびにコミットが増えていく。 右上の記入アイコンをクリックすることで手動入力することも出来る。

f:id:yoshitaku_jp:20200527210127p:plain

f:id:yoshitaku_jp:20200527210143p:plain

weight

weightの一覧画面は開いてもコミットは増えていかない。 右上の記入アイコンで小数点まで記入することも出来る。

f:id:yoshitaku_jp:20200527210103p:plain

f:id:yoshitaku_jp:20200527210114p:plain

まとめ

記録・モチベーション管理として使っている「Pixela」「PixelaUI」を紹介した。 家にいることが多くなったが、この状況をを逆手に取って習慣化が上手くいる人もいるはず。「Pixela」「PixelaUI」を使うと、見慣れたGitHubの「草」で可視化しモチベーション維持できてオススメ!

Design It! 輪読会 5章 「アーキテクチャ上重要な要求を掘り下げる」

5章はアーキテクチャを検討していく上で大切な要求を定義する方法が述べられていた。

www.oreilly.co.jp

この章で伝えたいことを整理する

アーキテクチャを考える上重要な要求を(Architecturally Significant Requirement : ASR)と呼びます。 これはアーキテクチャを選択する上で強く影響する影響のことだ。 ASRを明確にしていくはアーキテクトの責任であり、明確していく過程で4つの分類に分けて考える必要がある。 その4つとは「制約」「品質特性」「影響を与える機能要求」「その他の影響を及ぼすもの」であると述べられていた。

制約は変更ができない設計判断のことを言う。 そしてこの制約はほぼすべてのソフトウェアシステムが持っている。 制約には良い面と悪い面があり、良い面は課題を単純化アーキテクチャ設計を簡単にしてくれる面がありますが、悪い面は制約が厳しくなることでアーキテクトにとって選択肢が減ることだ。 制約は一度決めると変更ができないものなので、慎重になり出来る限り時間を掛けて決めたいと感じた。

次に品質特性だが、これはシステムが外部から見える特性と、システムの運用に対する期待が反映されるものだと書いてあった。 最後に書いてあった一文が刺さったので引用する。

様々なアーキテクチャで同じ機能セットを実装することは可能だ。昨日だけでは、ソフトウェアシステムを設計するのに十分な情報とはいえない。アーキテクチャに関する意思決定を左右するのは、アーキテクチャ上重要な要求(ASR)特に品質特性だ。 ここまで読んで品質特性について自分の中で少し腹落ちすることが出来た。 システムを利用する際のユースケースを組み立て、そのユースケースの中でシステムに負荷がかかる部分などを特定することのように感じた。 他にも「品質特性は非機能要求のことか」というコラムを読むことでも理解が深まった。

次に機能要求についてだが、これはシステムの振る舞いを定義するもので、「なにをして」「どうなっていなければいけないのか」を定義するものだと感じた。 いくつか振る舞いを定義していく中で、アーキテクチャの同じ要素に分類されるものをまとめたり、分類が難しければより詳細な機能要求に分解をおこなったりもする。 また、実装が難しそうなものを特定したり、優先順位付けなどもアーキテクトの仕事とされていた。

「制約」「品質特性」「機能要求」以外のものに目を向けることも重要であると書いてあった。 それはいま世の中に出ている技術のトレンドだったり、チームメンバーが出来る技術領域であったりと言ったことだ。 またコンウェイの法則によってチームとアーキテクチャは関係づけられてしまうので、いいソフトウェアを設計したいときにはチームの編成から考える必要があることも述べられていた。 コンウェイの法則は次に引用する。

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")

Design It! 輪読会 8章 「意味のあるモデルで複雑さを扱う」

今回は8章をおこないました。8章は「意味のあるモデルで複雑さを扱う」と題された章で、ソフトウェアシステムが成長・拡大していく中で複雑化していくものをコントロールする方法を学ぶ章でした。

www.oreilly.co.jp

この章で伝えたいことを整理する

今までの章からアーキテクチャは要素と要素同士の関係から成り立つものであると学びました。 そして、この要素たちをうまく使っていくと複雑化していくアーキテクチャを見通すのに役立つと述べられていました。

1つの方法として、複雑していくアーキテクチャを抽象化することによって、細かい部分を考える必要がなくなりアーキテクチャそのものを見通しやすくなります。 しかし、正しく抽象化しないとメンバに共有しても理解を得られないことがあり、抽象化しアーキテクチャのモデルを作成する際には注意しなければならないことも述べられていました。 優れたアーキテクチャのモデルには次のような4つの利点があります。 「設計の語彙を確立する」「関心を持つべき細部に注意を向ける」「品質特性やその他のシステム特性を見通せる」「アーキテクトの意図を記録できる」といったことが挙げられていました。

本の中で書かれていた「メタモデル」は輪読会の中でも理解が難しいポイントになっていました。 自分の答えとしては、「オブジェクト指向プログラミングにおけるインターフェイスのようなもの」と言いました。しかし、改めて読むとそれはモデルが役割として担っているのでメタモデルの答えとは適切でなかったように感じます。 現時点での解釈では、その後の章の「新しい概念を固定化する」「アーキテクチャの芽となるパターンを選ぶ」「矛盾を調整する」「良い名前を使う」の流れだけを追うと、プロトタイプを作成するような流れに感じます。 例えば、新しいモデルを作成するに当たりいくつかの概念を固めていき、その中から核となりそうなものを取り出します。 次に核と周辺の概念を調整していき最終的に適した名前をつけていくといった流れです。 プロトタイプでも、まずはSNSECサイトなどの作ってみたいものを定義します。 その後、システムの核となる部分を見つけ出し、ECサイトだとユーザが購買する流れを定義します。 次に、商品の一覧画面や詳細画面、それらをどうカードに持っていくかを調整していき、最終的にそれぞれが特徴となる名前付けをおこなっていくのではないかと思いました。

その後の章では、作成したモデルをコードとして表現していくときに、乖離がおきないように足並みをそろえていくことが大切と書かれていました。 コードをモジュールやパッケージに合わせて整理したり、自ら定めたルールに頼るのではなく、言語の特性などを生かして矯正させる方法を使うことも大切だと述べられていました。 コードが関わってくる部分では、クリーンアーキテクチャなどの文献が役立ちそうです。

Design It! 輪読会 7章 「パターンで土台を作る」

今回は7章をおこないました。7章は様々なアーキテクチャを紹介する章でした。

www.oreilly.co.jp

この章で伝えたいことを整理する

6章とのつながりがある章ではありましたが、この章だけ切り取って個別に見ても成り立つ章ではありました。 まず、特定の問題に対する何回でも使える解決策として「アーキテクチャパターン」という言葉を紹介していました。解決したい問題に適しているパターンを選択することで、0から考えるよりも速く楽に解決できます。また数々の先人が踏んできてた厄介な問題が回避されているものとして完成させられているので、そういったことも避けられていると書かれていました。すでに完成させられていることで広く知れ渡っていることもあり、他の技術者と会話するときにコミュニケーションが円滑になると言う利点もあります。

7章では次のアーキテクチャが紹介されていました。

  • レイヤー
  • ポートとアダプター
  • パイプとフィルター
  • サービス指向アーキテクチャ
  • パブリッシュ・サブスクライブ
  • 共有データ
  • 多層
  • コンピタンスセンター
  • オープンソース型の貢献
  • 巨大な泥団子

個別の要点は記事にしませんが、ソフトウェア自体とは少し離れているものも紹介されていたのが面白かったのでそれにだけ触れます。コンピタンスセンターとオープンソース型の貢献は、ソフトウェアを組み立てる上でのアーキテクチャではありませんが、チーム運営の形として紹介されていました。巨大な泥団子は設計の時間を犠牲にして開発スピードを高めるものとして紹介されています。ソフトウェアを組み立てる組織の背景にもよりますが、最終的に設計をしなかったことに対する負債はいつか返済しなければいけないので、適切なタイミングは見誤らないようにしたいです。

Design It! 輪読会 6章 「アーキテクチャを選ぶ(君がアーキテクチャに選ばれる前に)」

今回は6章をおこないました。6章はアーキテクチャを選ぶというタイトルで話が進んでいきますが、個人的にはこの副題が大切な気がしました。注意して読むと「アーキテクトに選ばれる前に」と言う、任命される前にという意味ではなく「アーキテクチャに選ばれる前に」となっており、振り回されず能動的に管理していこうというニュアンスがあるように感じたためです。

www.oreilly.co.jp

この章で伝えたいことを整理する

先の7章を読むと個別のアーキテクチャの詳細な話が展開されており、この6章では前段として個別のアーキテクチャを選択する注意ポイントやどう選択していくかという話がされていた。

まず、アーキテクチャ上何が必要かを広い視点から探求するために「発散」「探求」「収束」と言う手順が取られていた。これはアイデア出しでも使われるブレインストーミングに近いものだと捉えた。アーキテクチャの観点から見て珍しいと思ったのはデプロイの方法についても探求してみるという点であり、システムを組み立てるだけでなく今後の継続的な観点からも必要なものであると感じた。

発散させ収束していく中である程度の自由もありながらもやはり制約というものも必要になる。ここでは技術的な面とビジネス的な面が取り上げられていた。技術的な面はPythonで組み立てることになったのでJavaフレームワークは使えないと言った制約であり、ビジネス的な面は今月末にリリースをしなければいけないため、使い慣れている技術だけでリリースを使用(=新しいものは取り入れないでやろう)と言ったことであった。最終的にアーキテクチャを選んでいくに当たり、各アーキテクチャの特徴を比較して選択していく。

分解した要素1つ1つが自分のやらなければいけない責務をもっているかチェックする必要もある。そういった時の確認方法としては要素責務カタログを作成すると有効であることも書かれていた。

最後にはアーキテクチャは組んだら終わりではなく、組んだ後の変化にも対応しなければならないことが書かれていた。そういうときのために判断をできる限り遅らせたり、クリーンアーキテクチャで学んだSOLID原則をアーキテクチャにも対応させることが重要であることが書いてあった。そうすることで柔軟性をもたせることができる。

じぶん Release Notes 0.29.12

f:id:yoshitaku_jp:20200501223316p:plain

4月1日〜31日のあいだの出来事がリリースされました。

技術・開発関連

取り組み

技術面での取り組みは以下の通りです。

  • Terraformを使ってAzureのリソース管理
  • Write-Blog-Every-Weekのサイトリニューアル
  • Write-Blog-Every-WeekのAPIサーバリニューアル

イベント

個人的なこと

読んだ

ブログ

リリースノートを除き、次のエントリを書きました。

PV数

4月は3603でした。

4月の目標結果

  • 多くの人とコミュニケーションを取りたい
    • 未達
    • どれもあと一歩という感じだった…
      • ブログのPVを4000にする
        • Vue.jsについて2記事書く
        • Djangoについて2記事書く
        • Azureについて2記事書く
      • Twitterのフォロワを700人に増やす
        • Desin Itの輪読会をおこない学んだことを発言していく
        • エリック・エヴァンスのドメイン駆動設計で学んだことを発言していく
        • 趣味の分野についての発言を増やす
    • 1日30分英語を勉強する
    • 1日30分中国語を勉強する
  • 健康を維持する
    • 達成

5月の目標

考え中

TerraformでAzureDataWarehouseを作成するときにDWUを指定する方法

TerraformでDataWarehouseを作成するときにDWUを指定する方法がドキュメントを見た限りではわからなかったので調査しました。

www.terraform.io

docs.microsoft.com

ファイル全体像

dataWarehouseを作成するTerraformファイルの全体像を書きました。今回初めてTerraformを触ってみたが可読性が高くて非常に使いやすいです。

provider "azurerm" {
    version = "~> 2.1.0"
    features {}
}

resource "azurerm_resource_group" "rg" {
    name     = "sample"
    location = "japaneast"
}

resource "azurerm_sql_server" "sql" {
  name                         = ""
  resource_group_name          = azurerm_resource_group.rg.name
  location                     = azurerm_resource_group.rg.location
  version                      = "12.0"
  administrator_login          = ""
  administrator_login_password = ""
}

resource "azurerm_sql_database" "sqldw" {
  name                = ""
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  server_name         = azurerm_sql_server.sql.name

  requested_service_objective_name = "DW100c"
  edition = "DataWarehouse"
  collation = "Japanese_XJIS_100_CI_AS"
}

設定値を変更する方法

今回の主題である「TerraformでDataWarehouseを作成するときにDWUを指定する方法」は、azurerm_sql_databaseリソース内部のrequested_service_objective_name部分となります。

requested_service_objective_nameのドキュメントを確認すると次のようになります。DeepLを使った翻訳結果も載せておきます。

requested_service_objective_name - (Optional) The service objective name for the database. Valid values depend on edition and location and may include S0, S1, S2, S3, P1, P2, P4, P6, P11 and ElasticPool. You can list the available names with the cli: shell az sql db list-editions -l westus --edition Standard -o table. For further information please see Azure CLI - az sql db.
.

requested_service_objective_name - (オプション) データベースのサービス・オブジェクト名。有効な値はエディションと場所に依存し、S0, S1, S2, S3, P1, P2, P4, P6, P11, ElasticPoolが含まれます。利用可能な名前を cli: shell az sql db list-editions -l westus --edition Standard -o table でリストアップすることができます。詳細はAzure CLI - az sql dbを参照してください。

Azure Resource Manager: azurerm_sql_database - Terraform by HashiCorp

DWUについての記述はないため戸惑うかもしれませんが、この部分を変更することでDWUの値を変更することが出来きます。ちなみに、requested_service_objective_nameはオプション項目であり必須ではないので、DWUを指定しなかった時はDW100cが設定されます。しかし、このデフォルト値がいつ変わるかわからないので明示的に指定したほうが安心かと思います。

DW100c

画像は一部の表示ですが、DW100cに設定したときです。 f:id:yoshitaku_jp:20200430163527p:plain

DW200c

画像は一部の表示ですが、DW200cに設定したときです。 無事に反映されています。

f:id:yoshitaku_jp:20200430163558p:plain

参考

このissueが助けになりました。

github.com

Design It! 輪読会 4章 「ステークホルダーに共感する」

今回は4章をおこないました。4章はソフトウェアに対して関心のある人達であるステークホルダー(利害関係者)に対して焦点を当てています。

www.oreilly.co.jp

この章で伝えたいことを整理する

この章で伝えたかったことは、主体は「ソフトウェア」ということではないかと自分は思った。「○○に関わるステークホルダーを考えてみましょう」という言葉を聞いたときによく間違えを起こしやすいのは、自分を中心としてソフトウェアを介してステークホルダーを考えがちだが、そうではなくここでの中心はあくまでもソフトウェアであると言いたいように思えた。ここに気がつくためではないが、「ソフトウェア・ファースト」をたまたま同時並行で読んでいたため、そのようなところに気がつけた可能性もある。

本書では市のサービスを構築する仮想プロジェクトmpステークホルダーマップというものを作っていた。これはステークホルダー同士の関係を相関図のようにして書き起こすものだった。本の中での図で驚いた点2つあり、1つは開発チームと市長と市民だけではなく、市長に対して方針を投げかける市議会や市の部署、はたまた契約に対する弁護士まで記載されている点、また2つ目はこれが図の一部であると述べられている点だった。おそらく自分が作るとしたら、開発チームと市長と市民だけになってしまいそうだったのでもう少し想像力を働かせようと思った。

ソフトウェアは目的を達成するために構築されるものであるため、ビジネス上の目標を見つけまそすれを記録するといったことも書かれていた。自分の経験としても、なんのためにこの作業をやっているのかが明確になっていないと身が入らないものがあったり、自分個人の目標としても適当に作ってしまった目標はいつの間にか優先度が下がっていってしまうことがあった。今回はステークホルダーとの目標を明確にするためにPOV Madlibというものを使うといいと書かれていました。POVは point of viewで視点、Madlibアメリカで生まれた穴埋め形式のゲームのようです。わかりやすいように日本語で当てはめましたが、次のような穴埋めを行います。「(ステークホルダー)は、(ステークホルダーのニーズ)をする必要がある。なぜなら、(気づきを得るもの)があるからだ。」このような形式にすることで、ニーズを覚えやすい形でまとめることができるようです。POV Madlibについてまとめられている記事があったので貼っておきます。

medium.com

iec.co.jp

Design It! 輪読会 3章 「デザイン戦略を立てる」

Design It!を輪読して2回目になります。前回は1,2章を輪読しまして、今回は3章をおこないました。3章はソフトウェアシステム開発の中のアーキテクチャ設計に対するリスクを取り上げる章で、この章から部も変わり第2部ということで「アーキテクチャ設計の基礎」の話に入っていきます。

www.oreilly.co.jp

この章で伝えたいことを整理する

この章で伝えたかったことはリスクとうまく付き合っていくことの大切さと、その方法について述べられている章に感じました。 はじめに「時間・コスト・スキル・知識などの面から生まれる障害によって完全性のある合理的な設計はできない」ことが述べられており、そういった中でもソフトウェア開発においてアーキテクチャは組まなければいけないし、また合理的な設計ができない中でも適当なアーキテクチャを組むようなことはしてはいけないことが述べられていました。本の中でのおすすめは自分たちが解決したい必要最小限のアーキテクチャをゴールとしてそれだけに集中したほうが良い事が書かれていました。

ソフトウェアのアーキテクチャ設計にかけていい時間と、規模に応じたアーキテクチャ設計をするメリット・デメリットについても丁寧にまとめられていました。他にも実際にアーキテクチャ設計をしたあとの成果物の確認や設計をとめる時の条件といったアーキテクチャ設計について話されるタイミングで見落とされがちのことについてもまとめられていました。

疑問になった点

この章で疑問になった点は、「上位リスク」という言葉で、この言葉は48Pで初めて出てきました。本文中に出てきた説明を引用します。

リスク駆動の設計アプローチを採用しているので、設計計画には上位リスクを組み入れよう。リスク一覧は、ソフトウェアシステムの寿命のあらゆるタイミングで見直す必要がある。特に、前払いのアーキテクチャ設計を行っている間には、あらゆるタイミングで見直そう。*1

自分はこの説明を読んでも理解できず、輪読会にて参加者の意見を聞いてみたかった点でした。

輪読会の中では、「ソフトウェアを作るということはビジネス活動としてなのでビジネス側のリスクも考慮に入れないと、より詳細な部分が崩れていく」という結論に至りました。改めて精読すると、文章中の「ソフトウェアシステムのあらゆるタイミング」という記述から、ソフトウェアライフサイクルで取り上げられる「開発・運用・保守」といったタイミングで見直されるべきものであると考えられ、「要件定義レベルで決められるべきものが変化してしまうようなリスクを考慮しておこう」のような注意喚起に聞こえてきました。自分としては、このあたりも踏まえて輪読会での解釈の方向性は間違っていないと考えました。

*1:Design It!プログラマのためのアーキテクティング入門 48Pより