ふと思い立って始めた
自転車で東京→大阪へ560kmの旅。このブログはその３日目（2017/4/30）の旅日記になります。
１日目、２日目のブログはこちら↓
自転車で東京→大阪へ560kmの旅 GW１日目自転車で東京→大阪へ560kmの旅 GW２日目３日目のスタート
３日目は浜松のホテルからスタートです。
１号線沿いに西へ約20kmほど進むと、浜名湖に到達しました。
浜名湖の写真を撮ろうと思ったんだけど、隣を走ってる電車線路を覆う壁が邪魔で、湖の写真は無し。
湖岸に弁天島駅があります。
橋を抜けると湖西市。
ここから北上し愛知県豊橋市へ向かうのですが、いったん左折して４１７号線から１号線に合流しておけばよかったと後悔・・・
↓は私が通ったルートです。それに対し、１号線は大きく太平洋側を迂回してます。
１号線が最短ルートを取ってないのは、地形に何かしら理由があると考えた方が良いです。
峠があったり、ド田舎だったり・・・
私が通ったルートがまさしくコレで、峠あり、田んぼ地帯ありの田舎ルートでした・・・
これまでもそうでしたが、ここでも痛感したことが１つ。それは
教訓１： Google Map先生が指し示す最短ルートを過信してはならないッ！ということ。
Google Map先生が「１号線よりも１時間早い」という最短ルートを提示したとしても、１号線を進んだ方がよいことが多々ありました。
静岡のバイパス地獄回避の際も然り。
でも、まぁ今回はこれで良かったかな、と。
というのも１号線、普通の道路すぎて、あんまり観光ポイント、無いのよね。
別に今回、到達スピードを競ってるわけでもないし。
それよりも田舎ロードを驀進することで、その土地特有の生活風景を楽しむことができました。
・・・実は少し心細かったなんて。
なんとか３号線に合流することができたときは、正直ホッとしましたね。
そして３号線沿いに豊橋市の入り口が。
ようやく静岡県を抜けました。静岡県、横にデカ過ぎ！
３号線から１号線に復帰し、豊橋市を抜けて豊川市へ。
１号線沿いに、東京の日本橋から300km地点を示す標識がありました。
私の出発地点は日本橋ではなく品川ですが、それでも一応、旅程の半分は超えたっぽい。
更に北上し、岡崎市へ到達。
１号線沿いにある岡崎公園。
安城市、刈谷市を抜け、ひたすら北上して名古屋市を目指します。
道中、目が辛い。昨日も今日も。
目がずっと風に晒されるから目が乾くせいなんだろなー、と最初は思ってたんですが、どうやら違う。
４月とはいえ気温は２５℃くらいまで上がり、直射日光は強く、強く紫外線が降り注ぎます。
どうやら、サングラスが必要そうだ、と気づいた私は、１号線にある眼鏡屋さんに入りました。
２５００円くらいの臨時出費ナリ。
「東京から自転車で来たんだけど目が辛くてね～」と店員さんに話すと、相変わらずびっくりされた。
顔と腕には道中のコンビニで買った日焼け止めクリームを塗っていたんですが、目まで辛くなるとは予想外でした。
教訓２： ライダーは４月と言えども、日焼け止めクリームを塗りサングラスを用意せよ！そして遂に名古屋に到達。
だいぶ遠くまで来た感ありますね。
ここから西側へ向かい、名古屋市港区に跨る太い河川を何本か超え、三重を目指します。
・・・が、ここでまたしてもGoogle Map先生の罠が。
先生の導きに従い橋へ向かうと、
自動車専用道路（バイパス）になっており、自転車が渡れない！ここでも自転車が渡れる橋を探すのに苦労しました。Google先生、勘弁してください・・・
名古屋大学は今回のコースから大分遠いので、寄るのは諦め。
子供の頃の思い出の大半を占める春日井市は、さらに遠い。みんな、元気かな・・・
逆光で標識が見えない・・・。
２３号線に沿い、広大な木曽川と揖斐川を渡ります。
左には名古屋市民、愛知県民にはおなじみ、ナガシマスパーランドが。
揖斐川を超えると桑名市、そしてさらに進むと遂に四日市市です。
今日の目的地、JR四日市駅に到着。
今日も約130kmほど走破しました。
今日のルート。静岡県浜松駅を出発し、愛知県を抜け、三重県四日市市へ。
JR四日市駅のすぐ北に近鉄四日市駅があります。
こちらの市街地の方が栄えてるので、今日の宿泊地はそこに。
例のごとく自転車と荷物をホテルに置き、市街地に夕食＆散歩しにいきました。
近鉄四日市駅は、学生の頃、名古屋から大阪に近鉄電車で帰る際に必ず経由してた駅なのです。
近鉄特急アーバンライナーは新幹線に比べ半額程度で、貧しい学生の強い味方でした。
で、停車駅の１つが近鉄四日市駅なのでした。当時、降りることは無かったけど、今回こんな形で降り立つとは。
明日は遂に最終目的地、大阪府箕面市を目指します。
４日目の日記へ続く
ふと思い立って始めた
自転車で東京→大阪へ560kmの旅。
このブログはその２日目（2017/4/29）の旅日記になります。
１日目のブログはこちら↓
自転車で東京→大阪へ560kmの旅 GW１日目
http://makopi23.blog.fc2.com/blog-entry-236.html２日目のスタート
２日目は沼津のホテルからスタートです。
ちなみに１日目のホテル（4900円）のコインランドリーで、全身の衣類は洗濯＆乾燥済み。
１号線沿いに20kmほど進むと富士市に到着します。
東海道新幹線の窓から見慣れてはいるものの、やっぱ窓を通さず、早朝の澄んだ空気の中で見るのは良いですね。
さらに進んで富士駅に到着。
静岡を抜けるルートについて。
基本は１号線を進むのですが、静岡は
バイパス地獄 になっており、自動車専用区間に何回も出くわします。
そのたびに迂回ルートを探さねばなりません。
一番苦労したのは富士由比バイパスの回避です。
↓は自分が進んだ経路をGPSで記録するツールですが、２９番から少し進んだあたりで富士由比バイパスに差し掛かり、迂回を余儀なくされました。
↑を見ると分かる通り、３０番あたりで迷子になってます・・・
大都市とかと違って、左側に抜けられる道路って実質、１～２本しかないんですよね・・・
地図上では抜けれそうに見えるのに、抜けそうで抜けないッ！
迂回ルートを見つけるのにあちこち彷徨う羽目になりました。
他にも４～５回、バイパス回避のため迂回ルートを探索する必要がありました。
静岡を自転車で抜ける方は、事前にルートを下調べしておいたほうが良いと思います。
人様の庭先でスマホの地図とにらめっこしてると、家主のおじいちゃんが出て来て
「どこまで行くのかね？」と聞いてきました。
んで、「東京から来て、大阪へ向かってます」と答えると、とても驚かれてました・・・
「頑張って！」との応援に「ありがとう～」と応えて再度出発。
旅先で出会った人々との何気ない会話、けっこう好きです。
あと、早朝に田んぼのあぜ道をおじいちゃんと孫とワンコが一緒に散歩してる姿とか見ると、あぁ、この地でも当たり前の暮らしがあるんだなぁ、と。
そんなこんなで富士由比バイパスをなんとか迂回し、由比駅へ到着。
由比駅のちょと前に由比本陣公園がありました。
興津川を抜けると左手に駿河健康ランドが見えてきます。温泉、浸かりたい・・・が先へ進む。
清水駅。サッカーで有名な土地かな。清水エスパルスとか。
清水駅から更に12kmほど進むと、静岡駅があります。
静岡市は政令指定都市だけあって、駅前の市街地はとても栄えてました。
あと、ちびまるこちゃんの舞台の地らしく、こんなのとか見かけます。
駿府とかは徳川家康ゆかりの地でもあるので、家康像が駅前に。
そしてこの旅の中ボスとも言うべき、金谷峠へ。
昨日抜けてきた11号線の鷹ノ巣山ルートよりはマシなものの、かなり堪えます・・・
自分の足で旅してつくづく感じるのは、日本は本当に山国なんだなぁと。
峠を抜け、浜松へ向かう。途中、雷雨に遭遇。
２０分ほどで雷雨は通り過ぎ、その間、今日泊まるホテルとかをスマホで探してました。
そして、ようやく浜松に到達。
浜松に入っても、浜松駅まではけっこう距離があるので、頑張ってペダルを漕ぐ。そして
今日は約140km走りました。昨日の人生記録を更新。
浜松駅でホテルを取ろうとするも、近場でジャニーズのイベントがあるらしく、すぐには予約が取れませんでした。
ただ自転車なのでフラッと街を探索しつつ、お手頃なホテルを確保することに成功。
ホテルに自転車と荷物を置き、今度は歩いて街を探索しに行きました。今日は自転車はもういいから、歩きたい・・・
つーか俺の足って、かなり健脚な部類に入るんじゃないだろうか。
足より、サドルに揺られっぱなしのケツの方が痛いの。
３日目の日記に続く
今年（2017年）のGWに
自転車で東京→大阪へ560kmの旅をしようと思い立った。
毎年、２〜３回は42.195kmのマラソンを走っており、３カ月前の１月にも
館山若潮マラソンを完走してきました。
マラソンの次のチャレンジとして、今度は
自転車で長距離にチャレンジしてみようと思った次第なのです。
ちょうど実家が
大阪府箕面市ということもあり、GWに帰省も兼ねて東京→大阪の自転車一人旅をしちゃおう、と。
もちろん、全国一人旅、というのはいつかやってみたいという思いは昔からありました。
学生の頃にやってた
AIR という神ゲーの影響もデカい。主人公がさすらいの一人旅をしているのです。
ちなみに毎日シティサイクル（＝ママチャリ）で自転車通勤してるのですが、５月GW開けから勤務地が少し遠くなるのです。
最初はママチャリで旅やってやろうか、と思ってたんですが、どうせこれからも通勤で毎日自転車乗るんだから、
この際、自転車もいいやつを買っちゃおうと。ママチャリだと帰りの新幹線に積めないしね・・・
そんなわけで、今回makopi23の旅を担う自転車は、これ！
CENTURIONの
CROSS LINE 30 RIGID。5万円くらいと、入門者向けのスタンダードなクロスバイクです。
前カゴが付いてるのは、通勤用なので。。。
ちなみに
自転車で長距離、と聞くとどんなイメージを持たれるでしょうか？
たぶん、こんな感じでは。
それに対しmakopi23のガタイはこんな感じです。
0.1トンを軽く超える体重。
しかも足元はシューズではなく、サンダル・・・
服装はTシャツ（サイズは
5Lである！）＆ 綿の短パン。
どっから見ても、
ゴツいオッサンがコンビニへちょっとビールとツマミを買いに行くような恰好です。
だが、これで東京→大阪 自転車の旅を決行するっ！
スタート
出発は2017/4/28(金)の早朝。
自宅のある品川区から出発し、すぐ近くを走ってる第一京浜沿いを進みます。
横浜を過ぎていきなり道を間違う！
１号線を進むはずが、左に大きくそれて、桜木町の方へ行ってしまいました・・・
１号線に復帰するまでに３０分くらいかかりました。
その他にも何回か道に迷って、合計１時間くらいはロスしてます。
スマホのGPSがあれば迷わない、なんてことはありません・・・
小田原を目指して１号線を進み、茅ヶ崎を無事通過。
さらに１号線を行くと、こんな標識が。
これは行くしか無い、ということで左折。
すると、真っ青な湘南の海が！
湘南国際マラソンを走ってる最中、この自転車道に立っている人々から声援をずっと受けます。
こんな形で今回この場所に立つとは。
自転車道を抜けまっすぐ１号線を進むと、小田原城の近くで分岐の選択を迫られます。
そのまままっすぐ１号線を進むと、箱根駅伝５区でおなじみ、箱根峠を進むルート。
１号線をここで左折して熱海方面へ向かうと、１１号線の鷹ノ巣山を進むルート。
どちらのルートも
凄まじい峠を越さねばならないのですが、標高的に熱海ルートの方がまだマシ、ということで、
今回は小田原から左折して海沿いを南下し、熱海ルートを取ることにしました。
ここから熱海駅まで約20km。
左は熱海の綺麗な海、そして右は田舎風景が続きます。
熱海へ向かい南下する道中にて。どういうことなの・・・
小田原の分岐から約20kmを海沿いに南下し、無事、JR熱海駅に到着！
熱海駅の近辺は坂が凄かった・・・。
駅前に足湯があったので浸かります。ここで
サンダルの恩恵が活きる！
熱海を過ぎ、三島・沼津方面に抜けるために11号線へ。
地獄の峠越えポイントの直前にある来宮駅のベンチで栄養を補給。
そして１１号線を上がる。
恐ろしい傾斜の坂が数km続きます。これでも箱根峠よりはマシだそうな・・・
この日は快晴で直射日光も強く、熱中症になるかと思いました。
峠の途中でこんな看板が。
弊社のグループ会社！マジここで休ませてください・・・
そして鷹ノ巣山トンネルをくぐる。全長1268mと長い。
暗いトンネルの中、凄い速度のダンプカーやタンクローリーが右スレスレを走り抜けていきます。
一歩よろめけば、撥ねられてあの世行きィ！
動画で見るとこんな感じ
頂上からは三島・沼津方面へひたすら急坂を下ります。こんな田舎風景が続きます。
下り坂を駆け下りるのは自転車の神髄ですね。人力なのにすごい速度が出ます。
急カーブをミスればあの世行きだがな。
峠をひたすら下って三島方面に向かい、そして17時半くらいに、無事、沼津へ到着しました。
それなりに疲れましたが、42kmのマラソンに比べれば楽ですね。
この日は約133km。マラソンの３倍以上。人力で人生最長。
明日は沼津から出発し、130kmほど離れた浜松を目指す予定です。
無事、辿り着けるといいなぁ。。。
２日目の日記に続く
2017/4/18 (火) 「DDD Alliance! ドメイン駆動設計 RDRA for DDD ワークショップ！」に参加してきました。
connpass
https://ddd-alliance.connpass.com/event/54308/先日、「DDD Alliance! ドメイン駆動設計 RDRA Night!」」というイベントがありました。
そんとき書いたブログはこちら。
今回はその続編ということで、ワークショップを通じて実際に手を動かしてRDRAの勘所を体験する、というインベントです。
ブログを書いてネタバレにならないか、と神崎さんにお聞きした所、「問題ない」とのことだったので、自分の復習用にメモを書いてみる。
RDRAワークショップ
ワークショップをやる前に、RDRAの概要について説明がありました。
前回イベントでも
ブログに書いたけど、今回もさらっとメモ。
要件定義には何を定義すればいいのか- 要件定義を「システムだけでなくシステムをとりまく環境」まで考える。
要件定義の構造を定義する- 何が定義されていないといけないのか。４つの視点で構造化する。
- システム価値、・・・ 価値を与えているものは何かを見る。人と外部システムをとらえる。価値は人がきめるので、誰がかかわるのか決める。
- システム外部環境 ・・・ どう使われるのか。システムの外部環境は、業務フローか、書けないならシーンを明確にする。
- システム境界 ・・・ 人と外部システムとの連携部分。
- システム ・・・ 機能とデータとドメイン構造を書く。
- RDRAでは、モデルも状況によって使い分けするが、４つの視点は変わらない。
- 視点ごとに作るモデルを省いたりする。
要件分析の枠組み- RDRAでは、４つは依存関係が大事。依存関係があるから要件が早く決まる。
- 「システム」を決めるためには「システム境界」が決まってないといけないし、「システム境界」は「システム外部環境」が決まってないといけない。
- 外側に視点をずらしていく。
- 外側がWhyになっている。なぜ、はすべて外側にある。
コンテキストモデルからシステム境界まで- イベント ・・・ 外部システムとどういうやりとりをするのか
- プロトコル ・・・ 状態遷移図
- 「６．外部システムとのプロトコルを整理」では、はビジネス上認識しているユーザの状態を整理する。
- オブジェクト指向のクラスではまだ見えてないので、それに対する状態遷移図ではない。
- 「未出荷リスト」を出してくれ、という要求に対して、「未出荷」という状態を捉える。
- 「７．ユースケースに関わるユーザーインタフェースを洗い出す」では、業務フローからユースケースが出てきて、それに画面をひっつけてインタフェースを出す。
- 画面のレイアウト考えましょう、という話ではない。
- 必要に応じて画面のラフスケッチを書く。
- 「８．ユースケースを実現する機能を洗い出す」で、RDRA for DDDでは「機能モデル」はほとんど書かない。
- 「９．アクションを機能に対応付ける」で、イベントを機能に結びつける。今回は機能はないのでやらない。
- 「１１．機能とデータを突き合わせる」で、機能とドメインを結ぶ。
RDRA for DDD- RDRA for DDDは深く分析する部分をdddにまかせている。
- 「システム境界」は、ユースケースを中心に画面とイベントとアクターがくっついてる。
RDRA for DDD システム地図- 今回のワークショップでは、システム地図を作成する。１枚で全部書く。
- システム地図を使って１枚で全部書くのと、RDRA for DDDで４領域を分けて書くのと、あんまりかわらない。
- ４領域を全部ひっつけるとシステム地図になる。今回は時間がないので、システム地図を書く。
グループ演習：システム地図を作る
今回は、実案件よりは簡単な題材でRDRAを実践してみるとのこと。
纏まったドキュメントを作る、というよりも、２時間で要求定義として形をまとめることが目的。
繋げてものを考えると、ある程度形になることを経験する。
今回は「RDRA Map Maker」というツールを使いました。
参加者にはツールのURLが公開され、３人１チームで、各チームにPC１台、このツールをインストールしました。
お題
- 「会議室.com」という、会議室を貸したい人と借りたい人をつなぐサイトを作りましょう。
- 貸会議室を営む会社から開発依頼を受けた想定で、マッチングビジネス用のサイトを開発する。
- アクターに対する利用シーンを繋げて、情報まで洗い出すところまでやって完了。
ホワイトボードの左にあるとおり、「アクター」から「情報」まで順に洗い出していきます。
- アクター
- 要求
- 利用シーン
- ユースケース
- 外部システム
- イベント
- 画面
- 情報
「アクター」と「要求」
うちのチームは「アクター」と「要求」は以下のように洗い出しました。
アクターの洗い出しは比較的すんなりいったけど、ステークホルダーをどこまで考えればよいのかは気にする必要ありそう。
あと、「要求」は別画面に洗い出すように、との指示でした。この理由は後述の質疑応答にて。
「利用シーン」と「ユースケース」
利用シーンは「どういうふうに使えると嬉しいのか」を書くとのこと。
が、これが案外、難しい。どのチームも「利用シーン」を出すのに苦労してたようです。
というのも、この次の「ユースケース」との違いがわからなくて・・・ウチのチームも苦労しました。
神崎さん曰く、「利用シーン」より先に「ユースケース」を考えても問題ないとのこと。
「ユースケース」が安定すれば「利用シーン」はいらなくなるとのこと。
というわけで、うちのチームも「ユースケース」と「利用シーン」を同時に考えるように進めました。
一番左が「アクター」、真ん中が「利用シーン」、一番右が「ユースケース」。
「外部システム」と「イベント」
次は外部システムを洗い出しました。
うちのチームでは、「認証システム」と「決済システム」を外部システムとしました。
次に、外部システムとユースケースをイベントで結びます。
「イベント」は「入金」と「認証」としました。
赤枠が「外部システム」で、青枠が「イベント」。
「画面」と「情報」
最後に、「画面」と「情報」を分析します。
こんな感じで出来上がり。四苦八苦しながらもなんとなく形になりました。
発表
今回、3人チームで5チームあったので順に発表していき、随時、質疑応答がありました。
ピザとビールが届いたので、美味しく戴きながらの発表ｗ
質疑応答や意見交換で出た、神崎さんや増田さんや参加者からのコメントメモ。
図示する効果- 要求は網羅できない。なので、重要なやつだけ覚えておいて図にする。
- 図を作ってるといろいろ見えてくる。
- そうすると、「こうしよう」と決められる。
「要求」だけ別タブで設計した理由- 「要求」に戻って、「～～できること」と決める
- 「要求」だけ違うシートに書いたのは、その要求でコントロールするため。
- 要求を出していって、それでコントロールする。
オブジェクトを繋げる線ユースケース- 「利用シーン」と「ユースケース」の違いがしっくりこないという意見が多い印象。
- 「予約をする人」と、「その予約を見ている人」は別のユースケース。
イベント- RDRAはシステムを使った仕事の単位で考える。
- 「入出金」は入金と出金の両サイドあるが、自社の立場でどちらになるのかを考えるほうがよい。
- UML的には外部システムをアクターと捉えることもあるけど、RDRAでは外部システムとアクターを分ける。
- 「バッチ処理」とかは「手段」なので、RDRAの地図では表現しない。
- 外部システムがイベントに繋がって、そのイベントがユースケースに繋がる。
- イベントは外部のシステムの何とつながるのか、の「何と」を表す。
アクターとユースケースの間に利用シーンを挟むのは？- アクターとユースケースを直でつなぐのはあり。
- ユースケースが安定してるなら、利用シーンはいらない。
- ユースケースは「システム境界」。
- れがまとまらないなら「システム外部環境」を置きましょう。それが利用シーンになる。
- ユースケースを利用シーンより先に考えるチームが多い。
- そのあとロジック洗い出しをする。計算ロジックとか判断ロジック。
- ここまでに機能と情報は洗い出せてる。
- どういうロジックが独自性なんだ、と探していく。
DDD- DDDはコアのロジックを探していく。
- DDDはシステム全体をどうつくるか、というのにはフォーカスしてない。
- RDRAで全体地図を作り、どこから攻め込むかを広く浅く見て、コアの部分をDDDで攻める。
情報- 最後に洗い出した「情報」は、DBテーブルやクラスではない。
- 業務的な情報のこと。イメージは伝票。階層構造。
付箋の使用- 付箋で出すと発散方向に向かうので、どう収束させるか考える必要がある。
- 線で結ぶ。
- 粒度を決めたらそのままうまくいくか、というと、うまくいかない。
- なのでとにかく出してみて、「このくらいの書きっぷりだね」と感じ取る。
網羅性- 画面中心だと、網羅しているか、とかわからない。
- そいういうのをもうちょっと網羅してるとか、タイミングがどうあればいいのか、とか考え始めるとユースケースとか考えないと見えてこない。
シーケンス図ではダメなのか- シーケンス図とRDRAは対比できない。
- シーケンス図はあんまり書かない。なぜなら、網羅してないから。
- シーケンス図を書くくらいなら、状態遷移図を書くかな。
まとめ- 「画面」と「ユーザーストーリー」の関係を結びつけてみると、いろいろわかる。
- とにかく繋げてみる。違う視点の要素をつなげてみる。
- それをチェックするのはSIでもWebサービスでも価値がある。
- 今回伝えたかったのは、「繋げると議論ができる」という点。
- アクターとか利用シーンはシステム境界の外で、価値に関わる。
- ユースケースとかはシステム境界。
そんなこんなで発表や質疑応答が22:00まで続きました。19:00開始なので、たっぷり3時間。
懇親会
発表会終了後、更にお菓子やおつまみも追加され、23:00頃まで懇親会。
美味しくいただきながら、神崎さんや増田さんといろいろ会話させていただきました。
感想
先日の講演ベースのイベントに加え、こーゆうワークショップが別に設けられ、手を動かす機会があるのは凄く良いですね。
短い時間ではありましたが、手と頭を使ってチームで意見交換しながら１つの成果物を作るのは良い経験になりました。
RDRAは初めてだったのでシステム地図の作成には四苦八苦しましたが、議論を重ねつつとりあえず書いてみると、いろいろ見えてきて、更に議論が活性化される。
線で繋ぐと異なる視点間の関係性が見えてきて、更に議論が活性化されます。
あと、図書館で本を借りてきました。
神崎 善司
秀和システム
売り上げランキング: 165,064
体系的に学ぶのと復習を兼ねて、読んでみたいと思います。
関係者の皆様、ありがとうございました。
2017/4/12(水) 「DDD Alliance! ドメイン駆動設計 RDRA Night!」に参加してきました。
connpass
https://ddd-alliance.connpass.com/event/53449/Togetter
https://togetter.com/li/1100299DDDの勉強会、立て続けですね。先日の勉強会もブログにメモ書いたところでした。
DDDは読書会や勉強会にいろいろ参加したりと、それなりに知識あったのですが、RDRAというのは今回が初見でした。
以下、自分の復習用メモ。
ドメイン駆動設計：分析しながら設計する
増田さんのDDDの講演は何度も聴講させていただいてますが、今回は
DDD + RDRA + ICONIXという新しい切り口が登場していました。
私も最近までICONIXの読書会に参加してましたので、この３つの並びは新鮮でしたね。
DDDとICONIXはそれなりに知識がありましたが、RDRAは今回が初めてでとても興味深いのでした。
そしてまさかのドラクエ（笑
RDRA for DDD 「開発をリズミカルに回すための安定した要件出し」
RDRAは「ラドラ」と発音するそうな。
以下、スライドに書いてない口頭説明を中心にメモ。
RDRAができた背景- ガンドチャートを書くと、時系列の左側にタスクが圧縮されて、膨らんでしまう。
- ガントチャートを書くと誰が何をやればいいのか早くわかるので、それで早い段階から個人ワークが始まってしまう。
- それで、どんどんドキュメントができていき、変更できなくなる。
RDRAとドメインモデルの関係- RDRAは全体を俯瞰する。地図を書く。
- RDRAは外から攻め、DDDは中から攻める。
RDRAで枠組みを決める要件定義には何を定義すればいいのか- 「システムを取り巻く環境」と「システム」の２つ。
- 「システムを取り巻く環境」についても定義しないと、細かい設計ができない。
要件定義では何が定義されていないといけないのか要件定義の構造を定義する- システム価値
- システム外部環境
- システム境界
- システム
- ４つの視点で、何を定義すればいいかが決まってくる。
要件分析の枠組み 構成要素- RDRAのキモは、依存関係がある点に着目すること。
- 決め方が決まってないと早く決まらない。依存の関係性を使って決めていく。
- システム境界の認識がぶれてるのにシステムの話をしてもぜんぜん意見はまとまらない。
- なのでシステム境界から話しましょう。
- 依存の方向を内側から外側へ、Whyを辿る。
- 依存性を辿ると、なぜそれが必要なの？がわかってくる。
コンテキストモデルからシステム境界まで- １．対象業務に関わる人や連携システムを把握する。
- ２．ステークホルダーの重要な要求を掴んでいるかが重要。細かな要求はそれほど整理しない。
- ３．業務フローは時間かかるので、まじめに書かない。ざっくり書く。
- 業務改善を目的にしてるなら業務フローをしっかり書くかも。
- そうじゃなければ、どうシステムが使われるかが分かるくらいでよい。
- ４．ユースケース図を書くにはツール使うことを想定している。
- ５．外部システムとのイベントを捉える。外部システムと何をやるのかを整理する
- 例えば、バッチプログラムの一覧があった時、それらを「バッチ」と一括りにしないこと。
- あのバッチはシステム連携をやってるんだ、とちゃんと認識すること。
- ７．ユースケースはシステム境界と捉える。ここで言うユースケースは、UMLのユースケースとはちょと違う。
- ９．プロトコル＝状態遷移
- システムのふるまいをhowでなく業務として、何によって遷移するのかを考えていく。
- 未出荷→出荷、は遷移で表現される。
- １０．データモデルはER図とかとは違う。データモデルを一番最後に作るわけではない。
- １１．機能複合モデルは必ずしも書くものではない。
すべの情報をつなげる- つながっていることが重要。依存関係がある。
- ぜんぶ繋がってる。この分析を短期間に回す。
- まったく新規のシステムでもない限り、全てをつなげた図をざくっと直すのはそれほど時間かからない。
- いったん形を書いて、おぼろげでも全体像をつかむ。つながっていることがすごく大事。
- １個１個を完成させるアプローチはとらない。
- 既存システムの場合は、左から右へ、ではなく、できるところから積み上げていったりする。
- プロジェクトの状況にあわせてボトムアップに埋めることもある。
各要素がつなげる- 各構成要素は繋がってる。膨大な情報を扱っているわけではない。
- すべての情報をつなげて、網羅性と整合性を確保する。
RDRA for DDD- 普通のRDRAに比べ、定義するものがぐっと減る。
- 「システム価値」から「システム境界」までをRDRAでやる。「システム」より先はDDDにまかせる。
- 「業務フロー」か「利用シーン」のどちらかで「システム外部環境」を書く。
- 「システム境界」でユースケースを置いて、イベントなどを紐付けていく。
- 「システム」のとこはビジネス的にいうと「伝票」。構造化もしない。構造化はドメインモデルにまかせる。
- なので「システム」のとこは書いても書かなくてもいい。
要求側と開発側でのモデルイメージ- 上の要求側のモデルは、俯瞰する形ですらっと作る。広く浅く分析するためのモデル。
- 下の開発側のモデルは、深く分析するためのモデルで、DDDと役割分担する。
要求側と開発側の関わりイメージ- 深いことやろうとすると業務側の知識が必要となる。
- 密にコミュニケーションしてドメインモデルを作成する。
- 要求側と開発側でスキルセットは違う。
- RDRA自体は開発方法を規定していない。Howは使わない。
- 「システム境界」までははっきりさせて、あとはDDDで回しましょう。
変化に耐えられる軸- DDDとRDRAで役割分担する。
- RDRAは要件定義の軸をずっと維持する。ブレない軸として使っていく。
- 開発の軸はドメインモデル。DDD。
網羅はすべてを洗い出すことではない- RDRAの網羅は、重要なものをほぼぼぼ捉えたら、網羅されたものとする。
- モデルを書きながら重要なものを識別する。
- イテレーションで回していくので、全体を俯瞰してどういう分割になるのか、なんらかの分割単位が見えて、どこから攻めればいいかが見えることが大事。
頭の中を可視化- メンバーの頭の中にあるものを可視化する。
- 図におこして議論しましょう。
- 一覧を作って１行１行を担当者に振り分けて作業する、というWBSの常道をやると、詳細が埋もれてしまう。
- それで、全体像を誰も説明できない、という状態になる。個人の頭の中やドキュメントに散在してしまう。
- RDRAは広く浅く、早くまわしていく。
RDRAの弱点- RDRAはシンプルに表現できるけど、ビジネスルールやデータ構造は、つぶつぶの中に内包される。
- ビジネスルール等の具体的な複雑度がみえにくい。
- ビジネスルールの抽出はモデリングするだけではキツイかな、と思ってる。
Q&A- Q：コンテキストモデルとは？
- A：このシステムに登場するのは誰で、どんなシステムとつながるんですが、を表現する。
議論しながら先に進める。少人数で決めて進めていったほうが早い。
人を増やして局所的にWBSの１つを振っていくのは、全体像がわからないので結局うまく考えられない。
モデルが導く要件定義、文章が導くプログラミング
ソフトウェア開発戦略- トレースは非常に大事。ばらばらの情報ではトレースできない。
基本的なワークフロー- まず「コンテキストモデル」を作る。さっとつくる。完璧は求めない。
- 「要求モデル」もまとめる。
- この段階で荒いけど「ドメインモデル」を書き始める。
- この３つで何をしたいかというと、スケジュール感や費用感を出したい。
- ソフトウェアの価値は、ここまでの分析の段階で既に認識されている。
- 見積もりをして全体計画に落とす。
- ここまでが静的。そのあと動的な「業務モデル」を作っていく。
- 問題領域には「もの」と「こと」があって、「動的」と「静的」な側面がある。
- ①～④の４つの象限を、対応するモデルにあてはめる。
- 常にトレースすることによって整合性や網羅性を確保する。
- 究極的にはユースケースモデルを作る。ここにはユースケースシナリオも入る。
- ユースケースがそろうとロバストネス分析まで組み込む。
- ぐるぐる回しながら広く浅く進めていく。RDRAの基本的な考え方を使う。
- モデルだけじゃよくわかんないので、コードを書いちゃう。プロトタイプを作る。
- ざっくりコードを書いて検討する。そのコードは開発に使っていく。こんなかんじで上流工程を回す。
コンテキストモデル- コンテキストモデルを使い、どういう利害関係者がいるか、関係ない人もはっきりさせる。
ドメインモデル- 初期のドメインモデルには、大きな四角もある。スケッチの段階。
- コンテキストモデルとドメインモデルをスライドに表示しながらユーザと話すと、いろんな話ができて、業務知識を吸収できる。
- 業務フローだとユーザは混乱する。条件分岐ばっかで、どのくらいの頻度で起きるのかが分からない。
- ユースケースの「晴れの日シナリオ」をユーザと話すべき。余計な条件分岐をユーザに考えさせない。
- 議論を重ねるとユーザの頭の中が整理できるので、そのあと業務フローに入っていく。
モデルで導く要件定義（あるいは上流工程）だと、何がいいの？- 縦軸が抽象度。抽象度は人によっても集約されていく。経営者、マネジメント層、現場、で抽象度は違う。
- プレイヤーに応じた抽象レベルを使い分けて説明することが大事。
- 抽象的なものを具体化していく変換作業が必要。
- 抽象度が高いものはモデルが得意。逆に、具体的なものを語るには文章が得意。
- モデルと文章の使い分けが抽象度のコントロール。
- 抽象レベルはできるだけ合わせたほうがいい。
文章が導くプログラミング- 業務の言葉を日本語化したまま、プログラミングする。
- 「ドメイン＝知識」だと思っている。業務の中に知識がある。知識は言葉で語られる。
- その言葉を共有し話ができれば素晴らしいソフトウェアができると思ってるので、言葉が大事だと思っている。
- 日本語だとタイポが増えそう。文字も長くなる。Visual Studioだと日本語でもインテリセンスが効く。
感想
DDD、RDRA、ICONIX、RDRA for DDD、文章が導くプログラミングと、RDRAを中心に多岐にわたるネタでした。
特にRDRAは初だったのですが、ワークショップも今度あるようです。こちらも参加予定。
やっぱやってみないとわからないところもあるので、座学とワークショップがセットになっているのは良いですね～
関係者の皆様、ありがとうございました。
2017/3/28(火) 「JSUG勉強会 2017年その3 ～ ドメイン駆動設計 powered by Spring」に参加してきました。
DoorKeeper
https://jsug.doorkeeper.jp/events/58637DDDやICONIXの読書会に参加しつつ仕事でSpringを触っている私にとって、このイベントはとてもピンポイントで、とても楽しみでした。
増田さんの講演は何回も聞きに行ってますが、毎回新しい発見があります。
以下、講演中に取った自分復習用のメモ。
講演：ドメインロジックに集中せよ
モデルに基づき設計する- モデルを使わない開発プロセスの場合、バックログ（機能一覧）に沿って消化していく。木をブレークダウンしていく。
- これはドメインモデルの考え方ではない。
- 開発プロセスにモデリングを１つ入れると、全体の見通しがよくなる。
- モデルが無いと、羅針盤・地図が無い状態で開発することになる。
- モデルを使うことが複雑さに立ち向かうことに効果がある。
- モデルを作ればドキュメントがいらなくなる、ということではない。
インクリメンタルに開発する- 開発メンバは情報収集から分析、設計、実装、運用まで全部やる。
- day-1のうちからとにかく動かす。Spring Bootを使えばすばやく立ち上げられる。
アンチパターン- プレゼンテーション層やデータ層にロジックがはいる。
- ドメインロジックは３層にばら撒かれがち。
- これもSpringの１つの使い方ではあるが。。。
ドメインモデル- ドメインモデルはPoEAA（エンタープライズ アプリケーションアーキテクチャパターン）から来ている。
- ドメインモデルは、振る舞いとデータが一緒にある。
- 巷のOOはgetter/setterだけを持ったデータクラスとか設けるほうが一般的だが、DDDはそうじゃない。
- ドメインモデルの利点は、変更が楽で安全になること。
トランザクションスクリプト- 機能一覧を作って分担して各自作り込めば、どうしてもロジックが重複しがちになる。
- 変更を考えると、どこに何が書いてあるか探すのが大変。
ドメインロジックの置き場所- 値オブジェクト
- コレクションオブジェクト
- 区分オブジェクト
値オブジェクト
コレクションオブジェクト区分オブジェクト- これだけでもJavaを使う価値がある。
- 区分オブジェクトのEnumに振る舞いを持たせちゃう。
ドメインロジックのモジュール化- トランザクションスクリプトのモジュール分割は、部品化の切り口が不明確になりがち
- 例えば、受注登録の中のロジックをどう切り分けるかが難しい
構造化：記述レベルの階層化- 記述レベルをレイヤーで構造化する。
- 「ドメイン固有API」を３層の間に入れる。ここを相当考える。
- JavaコアAPIだけでも行けること多いが、１つ上にドメイン固有APIの層を入れる。
- アプリ動かすだけならドメイン固有APIの層は明らかにオーバーヘッドだが、この層を入れることによりドメインを扱いやすくなる。
ドメインロジックの自己文書化- ドメインロジックの文書化はソースコードでやる。
- ドメインオブジェクトを参照する３層にもドメインの型が入り込んでくる。
- これにより他の層のクラスも、ドメインロジックとどう関係してるか語られるようになる。
- これが変更容易性に直結する
- 業務マニュアルとか利用者ガイドはすごく重要。必ず作る。保守マニュアルになる。
- ドメイン側の知識として非常に重要。可能なら開発と平行で作って欲しい。
ドメインを隔離する- Springのアノテーション（@Controller、@Service、@Repository）を付けたところにはドメインロジックを入れない。
- ドメインモデルにはSpringのアノテーションは入れない。
- 自然にこうなるはず。
- ドメインモデル以外は、データの入出力。
- 「データの入出力」と「ドメインモデル」と、関心事が大きく２つ分かれる
- 関心事が反対側に埋め込まれないことが、ドメインロジックに集中するということ。
プレゼンテーション層とドメインオブジェクト- テンプレートにドメインオブジェクトをマッピングする。
- DTOとかFormオブジェクトを別に設けることは原則していない。
- プレゼンテーション層にちょっとしたif文とかも書かない。可能な限り書かない。
- そこまで徹底することで、ドメインオブジェクトにロジックをどんどん入れていく。
- 変更があったときに、どっちが変更の範囲を閉じ込めやすいか、という観点でドメインオブジェクトに徹底的に抜く
- Beanスタイルのバインディングは使わない。
- Thymeleafにドメインオブジェクトをそのまま渡して参照させる。
- ビューにもドメインを語らせたい。
- (PRGパターン、という用語が出てきたのでググってみた： TERASOLUNA：PRG(Post-Redirect-Get)パターンについて）
Direct Field Access- gette/setter全く関係なく直接フィールドを読む。
- getter/setterをなくすことで、ドメインロジックにすごく集中できる。これはやってみないとわからない。
- @haljik さんが #kanjava でこの件について相当いい資料をあげている。
アプリケーション層とドメインオブジェクト- 記録/参照はリポジトリパターンを使う。データベースの都合をドメインオブジェクトに持ち込まない。
- プレゼンテーション層とデータソース層の間のやりとりはアプリケーション層が仲介する。
- 業務ロジックはドメイン層が担う。
- サービスクラスに@Validatedを付けておくと、バリデーションロジックが賭けちゃう。「契約による設計」
- Bean Validationを使えると、そうとう細かいところまでチェックできる。
- リポジトリを@AutowiredでDIする。
- データソース層がドメイン層に依存するようになる。
- ドメイン層にsave()とかregister()を持たせるのか、持たせないのかは議論の余地がある。
データソース層とドメインオブジェクト- オブジェクトとテーブルはまったく別という扱い。
- 異なる世界は手作業で明示的にマッピングする。自動マッピングさせない。そのほうが変更に強い。
- データ保存の概念と業務の分割の概念は必ずしも一致しない。なので手作業で明示的にマッピングする。
- テーブルは徹底的に正規化する。テーブルには参照制約とか一意性制約とかは入れまくる。
- <resultMap>のtype属性にドメインオブジェクトを指定し、明示的にマッピングする。
- SQLがどのドメインに関心があるか、自己文書化させる。
トークセッション「ドメインロジックの実装方法の選択」
モデレータはJSUG会長の長谷川さん。
トークは増田さん、Grailsの綿引さん、TERASOLUNAの池谷さんの３名でした。
Q： DDDをやりたいけど、どうしてもトランザクションスクリプトになってしまう・・・どうすれば？
どうしてもトランザクションスクリプトになってしまう原因は、トランザクションスクリプトに実績があるから。
なのでDDDは浸透してない。しかもアジャイルじゃない。どうすれば？
---
増田さん：- 変える気ありますか？
- トランザクションスクリプトの仕事は受けないくらい気概で行ってる。
綿引さん：- DDDの案件で増田さんと一緒に仕事をしていたが、増田さんがリードしないと無理だな、と感じた。
- まず変わりたい、という時に、リードする人いないと難しいと思う。
Q： リードする人がいないとDDDできないなら、1000人規模のプロジェクトではDDDできないのでは？
池谷さん：- 数百人にDDDの本を読ませてできるようにするのに、１ヶ月とか掛かってしまう。
- なのでトランザクションスクリプトに落ち着くのが現実。
- 難しい点として、共通化を図ると、それがクリティカルパスになるところが出る。
- 共通化して開発したいところだが、共通化でネックになることがある。
増田さん- 経験者を作るのは相当ハードル高い。
- でも、トップレベルのエンジニアを作らなくても、１ヶ月DDDを教育することによるメリットは相当ある。
- 消費税計算とかだけドメインオブジェクトを作るとか、段階的にDDDにするのはけっこう出来ると思う。
- if文の巣になってるとこを見つけてそこから直していくとか。
- ヤル気があればできるところってけっこうある。
- ２００人規模ならDDDをやる、って責任はとれないけど、１０人くらいなら責任もてると思う。
Q： オブジェクトを共通部品化すると配る必要があるが、大規模プロジェクトだと大変・・・・どうすれば？
増田さん：- ドメインは最初から全部は分からないので、最初に全部を部品化するの無理がある。
Q： ウォーターフォールでDDDは無理か？
増田さん：- 資料でも、あえて「アジャイル」とうい言葉は使っていない。
- ウォーターフォールでも行けると思っているが、伝言ゲームはダメ。
- ウォーターフォールでフェーズがあっても、同じ人間が最後までやるならDDDできると思う。
- NTTデータさんがすこしDDDに舵を切るだけでも、世界はだいぶ変わる。
池谷さん：- DDD本を全部やるのではなく、できるところかやるなら行けると思った。
増田さん：- 現場のリーダーの裁量の範囲くらいで、できる範囲からやっていってほしい。
Q： やったことない分野でドメインオブジェクトをどう抜きだせばよいか？
増田さん：- その業界のオンラインヘルプ見たりとか、あとは書籍とかから抜く。会計なら、初心者向けの会計本とか。
- 最初はぜんぜんわかんないけど、目次とかから拾っていく。
- 最初はぜんぜんわかんないけど、まず触れることが大事。
- さすがにイテレーションのday-1には全部できないけど、１イテレーションの最後にはできてないとダメ。
Q： 言葉の持ち主は誰？
増田さん：- 持ち主はエンジニア。業務用語はお客さんが持ち主。
- 業務用語集とかを作ってお客さんに渡したりはしていない。
- メンテをかけるのはエンジニアなんだから、エンジニアがメンテしてドメインにマッピングする。
Q： 日本語だと、業務用語とプログラム変数名に差異が出てしまう。
綿引さん：- 日本語を英語にすると、変数名がめちゃくちゃ長くなってしまう。
- エリック・エヴァンスににどうすればいいか聞いてみたら、「なんで日本語で書かないんだ？」と言われた。
- 変数名を漢字で書くと、複数形とかが表現できない。あと、メソッドとフィールドが区別できなくなったりする。
増田さん：- enumの区分名は日本語にしている。
- プロダクトコードで名称を日本語で書くのは一度やったことがあるけど、違和感があった。
池谷さん：- 英語の変数名から母音を抜いて、子音だけで変数名を作るとかある。
Q： DDDをやる上で何かコツはあるか？
増田さん：- 値オブジェクトがコツ。
- オーバーヘッドでめんどくさいなぁ、と最初は思うけど、やってみると良さを実感する。
- DBってカラムたくさんあるけど、だいたいすべて同じ型だったりする。
- なので、値オブジェクトを組み合わせることできたりする。
Q： ORマッパーは、MyBatis以外でもDDDできるか？
JPAでも出来ると思っている。
Q： 実行順序性の制御はどうすれば？
増田さん：
オブジェクトが独立して組み合わせてできないかな、と思ってる。
順番に処理することを無くしたい。ばらばらに呼び出しても、辻褄が合うようにしたい。でも難しい。
順序依存性があるときは、アプリケーション層に制御を持ち込んでいる。ドメイン層には持ち込んでいない。
感想
DDDって抽象的な議論になりがちだけど、こーゆうコードありきで説明いただけると大変助かります。
Springを使ってる身としては、ピンポイントで参考になりました。
増田さんの「ドメインを隔離する」のスライド、４層を縦に並べず、ドメインモデルを３層から分離してその横に書いてますよね。
ドメインモデルが３層から分離され、３層から呼び出されるような図になってます。
この表現の仕方はとても良いと思いました。
というのも、DDD本の４章でレイヤー化アーキテクチャの図が出てきますが、４層が縦に並んだ図になっていて、ドメイン層が分離されている、というイメージが沸かないんですよね・・・
説明の表も縦に４層並んでるし。最初DDD本読んだ時、4層の関係が掴めずにモヤモヤしたもんでした。
あと、会場提供のPivotalさん、懇親会でピザやビールを無料で振る舞ってくださるのも凄いなぁと。
おいしく戴きました。感謝！
あと、こちらもよかったらどぞー
関係者の皆様、ありがとーございました。
-->
