運営スタッフとしてスクラムフェス仙台 2023 に参加したふりかえり
スクラムフェス仙台 2023 に実行委員として参加してきました。
楽しかったことや嬉しかったこと、感じたことのふりかえりをつらつら書いていきたいと思います。
去年は一般参加、今年は運営スタッフとして参加しました
去年のスクラムフェス仙台への参加を皮切りに仙台のITコミュニティのすくすくスクラムの運営メンバーになり、そのままスクフェス運営スタッフとして参加することになりました。
今回のスクラムフェス仙台は去年開催時のノウハウと天野さんを筆頭とした優秀な運営メンバーの方々のお陰で、当日までかなりスムーズに準備が進んできました。 お陰様で僕の仕事はほとんどなく、主な仕事は後述のウェルカムトークと当日のグラス洗い、メイントラックの見守り、でした。
週次の定例会に毎回時間を合わせることは少し大変でしたが、それ以外は準備期間も当日も含めて常に楽しみやワクワクを感じる余裕がある状態でいられたな〜と感じています。
そうして全期間的に楽しい状態でいることができたのは、運営メンバー・当日の参加の方々のお陰です。めちゃめちゃありがとうございました。
ウェルカムトークを担当して自分に少し自信がついた
今回、僕が運営スタッフとして受け持っていた仕事の中で最も大きい仕事はウェルカムトークでした。
基本的に僕はよく喋るだけで話が上手い訳ではないので、「やればきっと出来るだろう、だけど内心不安がある」という気持ちが大きかったです。
実際にウェルカムトークを終えてみると、もう少し公の場に適した言葉選びや作法を身に着けたいなと感じつつも、強い苦手意識を持つほどではいのかもしれないな〜、とも感じることができました。
自分の中では大きな変化だと思っていて、少し成長したかも？しれません。
スタッフTシャツを着てわいわいできたことが嬉しかった
個人的に「同じTシャツを着て誰かと同じことに取り組む」ということが素朴な夢だったので、とても嬉しかったです。
今回のスクラムフェス仙台のスタッフTシャツはたにさんがデザインしてくださったのですが、とても好きです。
やっぱり体感って大事だな〜、良いな〜、と思った
別に何か新しい情報を得るだけなら動画や書籍で十分ですが、オフラインの場で集中して聞いて身体で感じることって少し違うな〜と思っています。
例えば「コンフォートゾーンから出よう」って話は書籍や動画からでも得られますが、それと生の実践者のセッションを通して聞いて知る、ということはそれぞれ得られる体感や刺激が違うと思います。
なので、新さんのめちゃめちゃパワーに溢れたキーノートを聞きながら「あ〜、こういう学びや気づきに仙台の土地で出会えるって有り難いことだな〜」と思ったりしていました。
とても勇気を貰える基調講演でした。ありがとうございます。
来年も頑張るし、楽しみ
天野さんの note 曰く、来年もやるとのことです。
今回は「やる人がいないことがあれば率先してやる」「それ以外は元気で賑やかす」という受動的なスタンスで居たので、来年はもう少し能動的に価値を生み出せることにチャレンジしてみたいな〜と考えています。
きっと来年も楽しい日になります。
なので、開催された暁には是非初めての人も始めてじゃない人もご参加ください！
ソフトウェアアーキテクチャ・ハードパーツ読んでみた
大変だったけど、読んで良かった（小並感）
まだオライリー本を読んだことがまだ無かった＋難しい分厚い本もしっかり読めるぞ！という自信を得る為に最初から最後までしっかり読み切ってみました。
有名な本だし、特に書評とかはいらないと思うので、読書に際してチャレンジしたことや思ったことをまとめていきます。
無骨な読み方にこだわってみた
今回、全行を読み飛ばさずに黙読してみました。
「難しそうな本を最初から最後まで一度しっかり読む経験」が欲しかった次第です。
特に強い意図はなく、完全な自己満足です。
実際にやってみた感想としては、当たり前ですがとても大変でした。
後、普通に効率悪かったです。もう二度とやらん。
ただ、他の分厚い本達も「あ〜、別に気合い入れたら読めるな？？」と思える様になりました。
なので、やって良かったと思っています。
ただ、二度とやらん。
難しかった（小並感）
普段、関心の強いアプリケーションアーキテクチャよりも１つ上の視座の内容の話で、まだまだ知識・理解が足らんなぁと感じることが多くありました。
ただ、本書の大きなテーマであるトレードオフ分析の考え方やアーキテクトの振る舞い、マイクロサービスアーキテクチャとの向き合い方は少し知ることが出来た気がします。
Design it! やソフトウェアアーキテクチャの基礎辺りももう一度読んだ上で、２周目に入ってキーワードのマップみたいなものを作ったりして、深めていこうかなと思っています。
これからもたくさん読む
理解が及ばないということは基礎知識が足りないということだなぁと思った。
なので、引き続き地道に色々読んでいこうと思う。
開発者だけど「WACATE2022 冬 〜テストも品質もおもしろくてだいすきです〜」に参加してきた
「WACATE2022 冬 〜テストも品質もおもしろくてだいすきです〜 」に２日間参加してきました。
今回、初めて WACATE に参加させて頂き、とても良い体験・経験をさせて頂いたと感じています。
そこで、そうした良い体験・経験のアウトプットを公開することで、お世話になった運営・他の参加者の方々へ少しでも貢献できたら嬉しいなぁと思い、ブログを書くことにしました。
ゆるゆる書いていきます。
軽い自己紹介
軽い自己紹介としては、年次４年目のフロントエンド / バックエンドエンジニアをやらせていただいています。
明確にテストフェーズを置くような開発経験はかなり少なく、コーディングフェーズを任せられることが多い次第です。
テスト・品質に関しての関心は高めだとは思うのですが、まだ深い知見・経験は無いという状態でした。
参加の理由・目的
過去の TDDBC （２日間かけて TDD について学ぶブートキャンプ）への参加経験から
「２日間がかりのワークショップイベントは自分の思考・行動を変えるキッカケになるだろう」
「品質・テストに対する知見を深めるキッカケになるだろう」
と思い至り、WACATE へ参加することにしました。
近頃、自分のアウトプットや日頃の作業品質について課題感を感じており、その現状を打破するキッカケにしたかった、というところでもあります。
結論、本当に参加してよかったです。
参加してやったこと・思ったこと
というわけで、初参加して特に印象的なトピックや経験、思ったことをつらつらと述べていきます。
なお本編のセッション・ワークショップの詳細な内容については触れません。
その辺りに興味を持たれた方は是非、公式 HP の公開資料 を見てみたり、参加してみたりしてみてください。
WACATE について
「若手でテストに興味がある者」を主な対象とした様々なセッションやワークショップとのことです。
Workshop for Accelerating CApable Testing Engineers：内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ WACATE : 若手テストエンジニア向け勉強会・ワークショップ より引用
今回は諸々の兼ね合いでオンライン開催ですが、普段はオフラインで１泊２日で開催するそうでした。
詳しくは引用元の公式HPを是非ご覧ください。（ブログの文章量が爆発しそうなので割愛させてください）
本当に個人ワーク・グループワークがたっぷりだった
本当に２日間いくつもの個人ワーク・グループワークを通してテスト・品質について学ばせて頂きました。
またワークショップ以外にもポジションペーパーセッションという事前作成した自己紹介シートを基にした自己紹介のセッションなどもあり、あちこちにアウトプットやふりかえりの機会が設けられていました。
やっぱり手を動かさないと得られない知見・感覚があるなぁと感じましたね。
実行委員の方々に本当、多大な感謝です。（まじで準備大変だったと思います。）
プロセス化によるレビュー精度の向上
こちらはブロッコリーさんのセッションで「あ〜なるほど！！」と思ったことです。
原題は「テストプロセスを用いて、テストケース作成の思考を整理しよう」なのですが、テストに関わらないプロセス化という考え方と活かし方なのかなぁと解釈し、上記のように捉えた次第でした。
今回の #WACATE でのセッション資料を公開しましたーhttps://t.co/236GZOldzE
— broccoli (@nihonbuson) December 18, 2022
テストプロセスを意識したテスト活動に繋げるきっかけになると幸いです！
※一部のワークは参加者限定なので公開資料には載せていません
わかりやすさの為に話のスコープをレビューに狭めるのですが、 プロセス化することで個別のプロセスごとに見るべきレビュー観点が定めることができるのかなと。 そうすることによりレビュー精度が上がり、そのプロセスからのアウトプットの質が上げることができる、と理解しました。
他にも参加者限定のワークが目からウロコで「また今度どこかで実践してみよう」となりました。
落ち着いたらまた反芻したいと思います。
品質とは定義や立場によって変わる
これは２日目の中村さんの「品質とは何か？」というセッションや西さんの「スピードがなければ、生きていけない。品質が低ければ、生きていく資格がない。」という招待講演を通じて学んだことでした。
どうしても開発者なので品質というと「保守性・変更容易性」を連想しがちでしたが、そもそもQAロールの人から見た時に見るべき観点はまた別であったり、プロダクト性質によっても見るべき観点は変わるということは盲点でした。
またそれこそ「品質」や「価値」という言葉を普段使いますが、存外その言葉をわかっていないことにも気付かされました。
あ〜、これは面白いな〜沼なんだな〜と思いました。
これらの事柄以外にもたくさん学びがあった
他のセッション・ワークショップ・分科会（交流会）も含め、本当に情報量が多い２日間でした。
全部のプログラムに対して書きたいところなのですが、書き出したら到底読めないレベルの文章量になりそうだったので、大変申し訳無いですが割愛させていただきす。
ただ、ひとつ大きな気付きは
「今回得られた学び・気付きは、きっとただスライドを読んだだけでは得られなかっただろう」
ということです。
日々の業務での実践などで得られるかもしれませんが、ただ TL に流れてくるスライドを読むだけでは得られない学びだった様に思います。
こうした体験型の勉強会やセミナーなどの大きな特徴だと改めて気づきました。
それはそれとして開発者がほとんどいなかった
参加者のほとんどの方が QA やテスターに準ずる職務の方々でした。 本当、びっくりでしたね。
これ大丈夫かな〜と不安だったのですが、運営の方や他の参加者の方々も優しく、大丈夫そうでした。
個人的には、QA という別ポジションからプロダクトと向き合っている方々の話が聞けて、とても良かったです。
逆に出来る限りにはなりますが開発者ポジションからも会話させてもらったりもしまして、何か参考になったりしていたら嬉しいなと思っています。
まとめ
総じて参加して本当に良かったです。
僕は、QA・テスターの方に限らず開発者もテスト・品質は関心を高く持つべきことだと思っています。
短いイテレーション開発の中でより高速にリリースを重ねようとした時、そもそも最初からプロダクトを開発する開発者自身が関心を持っていた方が良い影響があると思います。
もしくは品質の低下だけではなくコミュニケーションロスなどによる全体的な速度低下などのデメリットにも繋がるのではないかと思います。
なので、これを見た開発者ロールの方も是非、WACATE に参加してみてくれたら良いのではないかなぁと思ったりします。 （開発者が少なくてびっくりしましたが！とてもよかったです！）
「来年から始めるスクラム in 仙台」に参加してきた #suc3rum
今回もすくすくスクラム仙台のお手伝いをしてきた
今回も今回とて運営メンバーとして参加してきました。
特に何をするわけでも無いのですが、オープニングトークをさせて頂きつつ、わいわいと初参加の人を賑やかしつつ過ごしました。
そんなこんなでイベントの雰囲気と印象に残ったことについてまとめていきたいと思います。
当日参加できなかった人には会の雰囲気が伝わるように、当日参加してくださった方々には感謝の気持ちとふりかえりのキッカケになれば幸いだなぁと思います。
今回は LT 会でした
今回は「来年もスクラムやるぞ！」というテーマのLT会でした。
発表内容はひとそれぞれで「スクラムに巻き込まれるな！」という話から「来年こそはしっかりスクラムやるぞ！」という振り幅がありました。
とても面白かったです。
本日もありがとうございました〜 #suc3rum pic.twitter.com/aTBKSPM1kq
— ama-ch (@ama_ch) December 14, 2022
僕もLTをしてきました
僕は今年得た知識を基にスクラムの概要を触るような LTをしました。
今回は何名かスクラムに詳しくない方が参加されることもわかっていたので、その人達向けにイベントに馴染みやすくする為の橋渡しになる様な話をしたかった次第です。
イベントの導入としてスクラムの全体像をさらうことで、少しでも場に馴染みやすくなるのでは？という試みでした。
良さげな反応を頂けたので、やってよかったかなぁと思っています。
今後も賑やかしながらも、そういった若手・ビギナーとコミュニティの繋ぎ目を少しでも担っていけたら良いなと思います。
ポスト・イットでのフィードバックとコミュニケーション
今回、初体験だったことが、LT に対するポスト・イットでのフィードバックでした。
LTを聞いた人達が感想や質問をポスト・イットに書き、最後に壁に張り出して内容について話し合うということをやりました。
LTをする側としては聴いた人からのフィードバックを受けれると嬉しいです。
また、聞いている側ももっと聞きたい！ということが質問しやすく、よい仕掛けでした。
またやってみたいなぁと思います。
現役のスクラムマスターから「スクラムはじめまして」の人までいた
参加者の中には全然スクラムを知らないという方にもご参加頂きました。
スクラム自体は開発に限らない良いプラクティスが詰まっているので、少しでも魅力が伝わったら嬉しいなと思います。
逆に現役のスクラムマスターやシニアエンジニアの方の話には学びが多く、イチエンジニアとして素直に参加してよかったと感じる部分でした。
スクラムに関する知識も職種もバラバラの中、ごちゃっとした感じでも全員楽しそうでしたので、スクラムの懐の深さを感じる会でした。
総じて学びと刺激のある「来年もやるぞ！」と思える会だった
単純に他の人の経験談を聞けることはもちろん、ビギナーの方と話すことで自分の理解が深まることもありました。
LT会本編と懇親会と含めイベントを通してトータルで得られた学びが多かったように思います。
来年の抱負
今年のすくすくスクラムは今回で終わりです。
来年は自己研鑽に励みつつ、コミュニティと若人達とのハブになっていけたら良いなと思いつつ、またお手伝いしていけたらなぁと思います。
ゆっくりスクラムをする会に参加してきた #suc3rum
ゆっくりスクラムをする会のスタッフをしてきた
特に何をするでもないのですが、スタッフとして参加してきました。
主催の天野さんやサムネを作ってくれたたにさんの様に何をする訳でも無いのですが、ぼけーっと立って受付をして、ぼけーっと話を聞いてました。
今回は合計１０人ほどの方々に集まっていただけまして誠に感謝ですね。
こんな雰囲気でわいわい盛況です🍻
— たに (@tuccaprog) November 16, 2022
中締めしてまだ続いています〜
[オフライン]ゆっくりスクラムの話をする会 https://t.co/5Bqrv4aVyd #suc3rum pic.twitter.com/GS4MHm8TJZ
ゆっくりスクラムの話を聞いてきた
１０人で一つの輪になって話していると、話す人と聞く人に分かれがちかもしれません。
でも、黙っていても大丈夫という雰囲気はそれはそれで心地よく、ヒゲをさわさわしながら楽しく皆さんのお話を聞き込んできました。
とても楽しかったです。
（ちなみに、次回開催の際はまた違った形式になる見込みです。）
たくさん話を聞く中で印象的だったトピックについてまとめていきたいと思います。
スクラムをちゃんとやることは難しい。でも、そもそもスクラムをやらないともっと大変。
「スクラムをやっていてよかった」という話に対して「スクラムをやっていて良かったという話は珍しく感じます」と発言したら、こういう話になりました。
言われてみればごもっともです。
スクラムを正しくやらずともスクラムのプラクティスがまったくないチーム開発（いわゆる朝会や振り返りのないチーム開発）を長期で行った場合、停滞していくことは想像に容易いと思いました。
個人的にスクラムの話題を見ていると「よりスクラムがうまくいくにはどうすればよいか」という改善の話を多い印象だったので「そもそもスクラムやらなかったらどうなるんだ、、？」という疑問があったので、とてもスッキリしました。
人事の文脈でもスクラムというキーワードが出るらしい
スクラムの一面として「実践・実験で得た経験を基にチームをよくしよう」という側面があると思いますが、実際にソフトウェア開発以外の文脈でも登場しているという話を聞いて驚きました。
試しに調べてみるとこんな感じの記事があります。（まだ読んでいません。後で読みます。） 人事チームでガチめにスクラム導入した話し｜tweeeety@メルカリ｜note
僕はスクラムの経験主義に基づいた思想・プラクティスのソフトウェア開発に限らない価値・魅力を感じているので、実際にソフトウェア開発以外の場で応用が効いている例の存在を知ることが出来て良かったなぁと感じています。
「1 on 1 on 1 」というパワーワード
チームマネジメント、コーチング、評価面談などなど色々なことが 1 on 1 という名で運用されているんだね〜という話をしている最中登場したパワーワードです。
1 on (1 on 1) なのか (1 on 1) on 1 なのか興味が惹かれるところですね。
そんな感じでとても楽しかったです
実地でスクラムをやっていらっしゃる方の経験談は面白く、またスクラムをやっていない方のお話も面白く、とても楽しかったです。
こうしたコミュニティの輪が仙台でも少しずつ広がると良いなぁと思います。
余談：ネパール料理の水牛の焼きそばが美味しかったです。
ビアバッシュ形式でフード・ドリンクを持ち寄りだったのですが、まさかのネパール料理の水牛の焼きそばが登場しました。
スパイシーで新感覚な味でした。美味しかったです。
写真があればよかったのですが、ありません。
是非、機会があったら食べてみてください。
後、ネパールの方々がパーティーをすることは文化・風習らしいです。 学びの多い日でした。
何故、相対見積もりをするのか、どうしてしっくりこないのか
いまいち相対見積もりがしっくりこない、という感覚があったので、しっかり理解しようと色々調べて考えてみました。
Relative Estimation
scrum.org が公開してくれている相対見積もりについての動画を見つけました。
この動画の内容を噛み砕いていく内に仕組みや意味の理解を進められたので、この動画を基にまとめていきます。
何故、相対見積もりをやるのか
動画内で明示的には言われていませんが、冒頭にて
相対見積もりは高速で絶対見積もりと同じ効果が得られると信じています
と述べられていました。
相対見積もりの仕組みと理論は後に解説されますが、もしも、
- （絶対見積もりよりも）高速
- （絶対見積もりと同じ様に）正確
なのであれば、相対見積もりを選ぶ理由はこれで十分だと思いました。
相対見積もりの仕組み
動画では絵に書いた水の入ったコップを基に説明されています。
ざくっと説明をすると、
- コップに入った水の量の実際に測ることが、絶対見積もり
- 基準となるコップを決めてそれに対してN倍大きいのかを測ることが、相対見積もり
ということになります。
仕事に置き換えると、
- タスクにかかる工数を正確に見積もることが、絶対見積もり
- 基準となるタスクに対して何倍の規模のタスクかを見積もることが、相対見積もり
ということになります。
あくまでも基準に対する相対的なサイズ感を見積もることが「相対見積もり」ということでした。
相対見積もりの結果はメンバーの入れ替わりやツールなどの影響を受けない。
新しいメンバーが加わった時、誰がやるかが重要になる。 なぜなら、新しいメンバーと既に居るメンバーの間ではかかる時間が変わるから。 そして、絶対見積もりの場合、もしも作業を高速化するツールが何か見つかった場合、すべてを見直さなければいけなくなる。 しかし、相対見積もりの場合はメンバーの違いもツールの違いも何も影響しない。
絶対値で見積もった場合、新規メンバーと既存メンバーではスキルに差がある為、タスクに対してかかる時間が変化します。 また、何か作業を高速化するツールが見つかった場合もタスクに対してかかる時間が変化します。 なので、絶対見積もりの場合は、そうした変化に応じて都度見積もりのし直しをする必要が発生します。
しかし、相対見積もりの場合は常に基準のタスクに対する相対的な規模を求める為、理論的には常に結果に変化が起こりません。
正直「相対見積もり自体が早いかは」はわかりませんが、正確な絶対見積もりをする大変さは想像に容易く、流石にそれよりは早いと思います。 人やツールの変化による見積もりのし直し、つまり手戻りが無くなると思うと、「相対見積もりは高速である」というのが理解できました。
ベロシティ・スピード・アウトプット量を測る
変わるのはベロシティ・スピード・達成した仕事の量をさばけるようになったかだけ。
これはスクラムのスプリント（もしくは何らかのタイムボックス）ごとの計測を前提にした言葉だと思いますが、凄くしっくり来ました。
相対見積もりの結果は変わりません。
そして相対見積もりは規模を見積もる為、対象のタスクに対してどれだけの時間がかかるかは測ることができません。
なので、「どれだけの時間がかかるか」ではなくスプリントのベロシティ平均、つまり実績ベースで「どれだけのタスクを消化できるか」を割り出していくのだと思いました。
見積もり自体は、結局どれだけ時間がかかるか・期間内でどれだけのタスクを捌けるかを測ることが目的の為、これで十分なのだと思います。
相対見積もりの結果が変わらないという特性も併せて「相対見積もりは高速かつ正確」であることが理解できました。 （実際には高速且つ正確に運用する為に、スプリント平均を出す、プランニングポーカーをするなどの手法が重宝されているんだなと思いました。）
どうしてしっくりこないのか
相対見積もりについて学んだ結果、しっくりこなさの実体は「慣れた絶対見積もりに対して相対見積もりは直感的ではない」ということに気づきました。
相対見積もりによるタスクの見積もりが正確さを発揮するまでには時間がかかります。
そして、絶対見積もりによる時間換算の方が圧倒的に経験した事が多いです。
なので、毎回「時間換算だったらこうだけど、、、？」の様な思考を挟むことになって、いまいちしっくり来ないんだなと思いました。
このしっくりこなさの原因は強い言葉を使うと「意図・意味の理解の欠如」だと思います。 また、よく見かけるストーリーポイントのインフレの様なアンチパターンの原因でもあると思いました。
そもそも日頃慣れた見積もりとは別なパラダイムであることを理解して、意図や意味の理解を心がけないとうまく相対見積もりは機能しないのだと思います。
正しく相対見積もりをするには、、、
色々書こうと思ったのですが、むらみんさんの記事の内容になりそうなのでリンクを貼らせてもらおうと思います。
t-and-p.hatenablog.com
スクラム周りの話、正しい知識と価値基準に至りがちですよね。
まとめ
「正しく学んで誠実に見積ろう！」というただ当たり前のことを書いてしまいました。
当たり前のことが常識じゃない、という言葉に甘えてこのまま投稿しようと思います。
引き続き、学んでいきたいですね。
RDRA 2.0 ハンドブックを読んでみた。
３連休にRDRA 2.0 ハンドブック を読んだのでさくっと感想を。
結論的にはとても読んで良かったな〜と思っている。
RDRA 2.0 とは
著者の神崎善司さんが考案されたリレーションシップ駆動要求分析（Relationship Driven Requirement Analysis ）という要求分析・要件定義を行う為の手法のこと。
要求・ステークホルダーを起点に複数のダイアグラムを作成して作っていくことで、開発に必要な概念やユースケースを洗い出していくことが出来る。
一番の大きな特徴は、全てのダイアグラムと構成要素の関係性が明示されている・できること、かな。
詳しい解説をしてしまうと本を買う意味が薄れてしまうどころか著作権とかアレだと思うので詳細については割愛。
（キーワード検索で引っかかる情報にあんまり良いものがなかったので、もし興味があれば８００円でこの本を買ってしまったほうが良いかも。）
読んだ感想
- DDD やモデリングの知識と相性の良い手法だった。
出てくる知識や考え方がDDDやモデリングの考え方に似ていて、１〜２日でサクッと読むことが出来た。
そもそも要件定義のプロセスや洗い出すべきことを構造化したものが RDRA だと思うし、DDD もモデリングもシステム化する対象をどう構造化して落とし込もうかということだと思うので、やりたいこともやり方も似通ってくるんだろうと思った。
ちなみに、こちらの動画で実際にRDRAで作成したダイアグラムと実際の実装を紐付けて開発している事例が発表されている。
RDRA で洗い出した業務・ユースケースや情報・状態の関係をそのまま
業務 > ドメイン境界 ユースケース > ユースケースサービス 情報・状態 > ドメインモデルなど
の様にパッケージングやクラス構成などに対応させて開発しているとのこと。
「あ〜、これこれ、こういうイメージ〜！実際に実装に対してマッピング出来るんだ！」と感動したので、本書と合わせて是非この動画もオススメしたい。
RDRA は実装に踏み込みすぎない様に意識されているので、実際には実装との乖離は発生すると思うが、良い感じに開発できるイメージが湧いた。
- 要件定義の全体像を学べた。
（本書が本来意図したことではないと思うけど）書き出してしまうと当たり前の、
「要求 > 業務 > 業務フロー > ユースケース > 関連するデータモデル」
の様な要件定義全体の構造と各概念の関係性を俯瞰して体系的に学ぶことができた。
これが出来るのは要求を基に必要な情報を洗い出すプロセスが構造化された RDRA だからこそな気がする。
元々、要件定義プロセスについて体系的に学んだことがなかったので、これだけでも読む価値があったと思う。読んで良かったな〜。
- （語弊があるが）自分でも出来そうだと思った。
本の中に書いていることをまとめると、大まかに以下のようなことが書いてある。
// 詳細を抜き出した状態の読書メモ
# RDRA の説明
- RDRA 全体のプロセスの説明、ダイアグラム間の関係
# 各ダイアグラムの説明
- ｛各ダイアグラム｝
- 概要
- {ダイアグラムの概要｝
- 目的
- ｛ダイアグラムで要求分析・要件定義上で合意・確認したいこと｝
- ダイアグラムの詳細
- 構成要素
- ｛ダイアグラムを構成する要素｝
- ゴール
- 書くべきこと
- ｛ダイアグラムに書くべきこと｝
- 書きたくないこと
- ｛ダイアグラムに書きたくないこと、書かなくても良いこと｝
- 作り方
- {実際の HOW の部分}
# RDRA の精度を上げるには
- 整合性、網羅性、妥当性を担保する方法
こうして一覧してみると、プロセス全体が構造化されているが故に「書くべきこと・考えるべきこと・正当性の検証方法」まで一通り定義してくれていると思う。
なので、大前提として細部にセンスや専門知識・練度が必要だけど「この軸に沿って考えていけば、そうそう外れたことはしなさそうだな〜」とも思ったし、「これならできそうだし、やってみたいな〜」と思えた。
機会があればやってみたい。
- 自分のねらいは間違ってなかったっぽい。
「キレイなコード、キレイなアーキテクチャはそもそもドメインから産まれる」とアタリをつけて、モデリングや要件定義や何らか業務知識に繋がる本を読み進めているけど、間違ってなかったな〜と思えたし、改めてそうだなぁと気づけた。
引き続き、頑張ろ〜。
まとめ
読んで良かった。
お求めやすい価格（kindle版：800円）且つモデリングやアーキテクチャ周りの知識があるとすんなりと受け入れられるので、興味ある方にはオススメですね。
