レガシーをぶっつぶせ。ゆうしのはてなスマートフォン用の表示で見るゆうしのはてな2019-12-15レガシーをぶっつぶせ。「インプット<アウトプット!」の参加レポートレガシーをぶっつぶせ。「インプット<アウトプット!」の一部と二部に参加してきました。過去に多くの勉強会に参加してきましたが、その中でも特に学びを得られた強い実感がありました。間違いなく上位に入る満足度です。学んだことを反芻して、記憶やスキルとして定着化を図らねばもったいないと感じたのでまとめたものを記事に残しておきます。全体的に期待していたことDDDは(軽量かもしれませんが)自分なりにいろいろと実践してきており、実践と内省のループから考え方がなんとなく固まってきたので新しいブレイクスルーを得るために他の人の考え方を取り入れたいと思って参加しました。自分の考え方があっているかの答え合わせができればそれはそれで自信が持てるといいなとも期待して参加しました。1システム設計の中でのドメインモデルの役割を体感するこのセッションの内容とされていたこと公式のタイムテーブルより引用します。それらの変更がどのように伝搬するか、という全体の繋がりに焦点をあてます。モデルに対して付箋で変更を加えながら体験していただく予定です。自分たちのチームで実際の業務を対象にして試していただけるようにしたいと考えています。この説明文を読んで私は『業務分析からそのモデリングまでの一連の流れや手法が知れること』と『それを現実に近い例で訓練できること』を期待して参加しました。その期待はドンピシャでした。実際にやったこと以下のようなことでした。カスタマージャーニーに似ているらしい手法(一般に通じる名前はつけられてなさそう)を用いながら、現状の業務をヒアリングしフロー図に落とし込む。そのフローで出てきた単語(概念)や操作(振る舞い)を概念モデルとして図に表していく。これだけ書き出してみると単純かつ簡単な工程で大した意義がないように思えますが、フロー図作成で得られた気づき・見落としをモデルに反映する、あるいはその逆というフィードバックループが存在しており、概念モデルに現実の例を当てはめても通用するような表現力が育っていくような印象を持ちました。2また、そんな印象を持てるほどの表現力を持ったモデルであれば、その後の実装はだいぶ楽になるだろうとも思いました。感覚的な話ですが、『気づいていなかったことに気づく、それが可視化される。それが単純に楽しい/嬉しい』という成功体験が『他にも同じようなものを見つけてアハ体験したい』というモチベーションに繋がり、正のループが回っていたように思えます。今まで業務でやってきたことを振り返る私は今まで業務分析では開発チームでドメインエキスパートにヒアリングし、その中でそれぞれが構築したメンタルモデルを(何らかの方法論を用いて共有しあう事をすることなく)それぞれがすぐにコードに落とし込む、というようなことを繰り返してきました。フロー図とモデル図に表すことでタンジブルにし、他の開発メンバーの意見を聞きながら足りていなかった「何か」を相互に教えあい、それぞれの図に反映していくことでコードを書くよりも低いコストで先に合意に達しておく手段があるとしることができました。それが現実的にも可能そうな感触を得られることができました。これに気づけたのはとても有意義なことでした。今までは、フロー図やモデル図を書けるほど具体的なイメージが持てているのであれば、動かせるコードを書いてそこからフィードバックをもらったほうが早いと言う考えでしたが、図を用いてチーム内で合意を形成していたほうが認識のすり合わせコストが減り時間的トータルコストとしては下がるのかもしれない、また他人の力を借りてより高速に正解に近いメンタルモデルを構築できるのではないかという考え方に変わりつつあります。3概念モデル/ドメインモデルは実装に素直に落ちるらしいところで、『概念モデルとドメインモデルは実装に素直に落ちる』4という意味にとれる説明がセッションの冒頭にありました。これは私が仮説として持っている考え方だったので聞いたときは『お、おおぉっ?おまおれ?やっぱそうなんや!』と嬉しくなった瞬間でした。こと図の作成のための議論の中で自分が持つメンタルモデルと他の人が持つメンタルモデルは当然ながら違うという再認識ができたそして、概念モデルの時点でもなかなか合意に至らないのに、それをやらずにコードを書いてしまえばそりゃみんなバラバラな書き方するよなと納得した概念モデルなどの図を作るコストを払ったほうがいきなりコードを書くコストを払うより低く済む可能性を感じられた概念モデルがうまく構築できていれば実装にも素直に落とし込めるという考え方を持っている人が他にもいることが知れたその他の振り返り的なことあとから考えて面白かったのはかなりクラス図に近いものをドメインエキスパートに見せながら、多重度の話をしたり、関連の線をつなげたりして認識合わせをしていたことです。今回私のチームの担当をして頂いた方はデザイナさんでしたが、デザイナである彼にこういう話し方が通じるのであれば完全なビジネスサイドの人にも教育すれば同じやり方が出来るのではないかという可能性を感じました。一緒に仕事しているビジネス側担当者はPlantUMLを書いてみちゃうくらいこっちよりの感覚がある方なので、ぜひこれも試してみたいと思いました。アクションプランフロー図とモデル図を試す(元になっているかもしれない)カスタマージャーニーを研究するこのワークショップでやったことも踏まえて(1)を実践する(必要性を感じたら先にカスタマイズもする)。現場で試す(3)で得られたフィードバックを元に、辞めるかカスタマイズ(を繰り返しながら)して運用を継続する。〜割り勘ドメイン編〜このセッションの内容とされていたことこれも公式のタイムテーブルより引用します。会計時の割り勘をテーマにモデリングワークショップを行います。支払合計金額を人数で割る「割勘」は単純です。上司なら比率多め、後から来た人や学生なら少額といった多少面倒な計算が伴います。幹事は負担ゼロか、同様に支払うのかのオプションもあります。今回はこういった具体例でモデリング力を鍛えることが目的です。実際には、想定しているユースケースに対してドメインモデルを考え、すぐにコード上の型を作り(処理は後回し)チームメンバーと議論し、ワークショップを体験していただきます。対象言語は時間的な都合で効率的にサポートできるJavaに限定させてください。Javaの言語的なサポートはスタッフが行います。不明な点はスタッフに確認してください。当日はお題の公表と共に、モブプログラミング形式で5チームに分かれていただきます。その際にJavaが分かる方がドライバーとして必ずチームに含まれるように調整しますので安心してください。当日利用するテンプレートプロジェクトは運営側で用意したものを配布させていただきます。お題とひな型となるソースコードはこちらです。詳しくはREADME.mdをご覧ください。当日は2時間しか時間ないのでできれば事前にドメインについて考えてきてください。※スタッフのほうでもPCは持ち込みますが、ワークショップ参加予定の方々はPCはご持参ください。"この説明文を読んで私は、書かれていること通りに『モデリング力を鍛える』体験が得られることを期待して参加しました。期待したそのものではありませんでしたが、『モデルと実装を行き来することでモデルもコードも育つ』ことが現実にあることだという実感を得ることができました。この強烈な体験が余韻として残っています。実際にやったこと以下のようなことでした。想定している割り勘の文脈を登壇者よりざっくり教えてもらう(1)をもとにチームで用語(概念)の洗い出しと相互の関連やそれぞれの属性と振る舞いを洗い出す(2)を見ながら実装するちなみに、(3)のフェーズではドライバーを務めました。『お前ファシリテータか?』と思われるくらいコードを書きながらペラペラ喋ってしまいました。役割に徹することができず、ちょっとでしゃばっちゃったなと少し反省しています...けど楽しかったですw今まで業務でやってきたことを振り返る一部で書いたことと重複しますが、図で示す前にコードを書いていました。コードを書いている途中で当然新しい気付きはありましたが、それを図にフィードバックしていなかったため、新しい概念を獲得したことを強く実感することなく、それにより別の箇所を改善できる可能性にきづけることもなく5コードをひたすら書いていた気がします。モデルで可視化&共有し合うことを知ったため、コードで得られた気づきをモデルに反映する、あるいはモデルで得られた気づきをコードに反映する、そういったそれぞれで得た気づきを反映し合うループを試しつつチームで共有する有意義さを体験できました。成果物ドメインモデル二部成果物ソースコードgithub.com得られたことモデル図とコードを行き来することでそれぞれの足りないところを補完できる、それを複数人で実施することで足りない観点を補え合える、という体験ができたモデリング時には見落としていた概念が、実装の中で浮かび上がってくるという体験ができたモデルとコードを行き来する価値や醍醐味を知ることができたアクションプラン開発チームでモデル図を作成するコードを書いてフィードバックが得られればそれをもう一度モデル図に反映するまとめ今回の開催意図である『アウトプットをするほうが学びになる』の通り、ワークショップでアウトプットすることで学びとその強烈な体験を得られました。個人的には、他の人の考え方を取り入れたい、あるいは答え合わせをしたいという期待で参加しましたが、そのどちらも満たせました。学んだことを研究しつつもなるべく素直に現場で実践して行きます。具体的なことは特に触れませんが、どちらも達成できました。印象だけの話で現実ではこの短い時間だけでは足りず、どう少なく見積もっても2倍か3倍の時間は要するだろうと、振り返りながら思っています。↩そして二部でコードによるフィードバックの体験を得て、相互に行き来することが最強という結論に至ります。↩あとで質問しに伺ったところ、言い切ってしまうと少々語弊があり、実際はいろんな実装手段があるだろうと訂正されていました、私は実装を連想しやすいという意味で「素直に」という言葉の選択は間違ってないと思います。10:20レガシーをぶっつぶせ。Configを調べて検証コードを書いてみました。BootでMVCを自己署名証明書(オレオレ証明書)を使ってHTTPSでListenさせる方法ReactとVueのどちらを採用するかレガシーをぶっつぶせ。月別アーカイブ参加グループプログラミングはてなブログをはじめよう!kogayushiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。