チェンジビジョン モデリング事業部 工藤です。

先日、大阪で開催された「エンジニアの輪(*)」というイベントに、東京からはるばる駆け付けて参加しました。
というのも、今回の参加者の中には、よし たろうさんという、業界経験年数が若干1年目と、私とほとんど変わらないながらもSOLID原則(オブジェクト指向設計原則)も含めて、設計に対して非常に熱心な素晴らしき方がいたので、実際にお会いして、普段どのように学習されているのかを直接聞いてみたかったからです。

(*) エンジニアの輪とは：
ゆーきさん主催の現役エンジニアや今後エンジニアになりたい人たちとの交流を目指した、LTや雑談を通して横のつながりを築くことを目的とした雑談勉強会です。

今回のイベントは、参加人数32名と、大阪開催のエンジニアの輪イベントでは過去最多の人数でした。
その中から、LT登壇者は私も含めて計6名。
今回は、LTや他のお話の中で、非常に印象に残った内容を記事にしたいと思います。

受託開発の大変さ

「つやつや」さんによる「受託開発生存戦略」のお話。
ご本人から資料共有の許可いただきましたので、貼り付けます。(つやつやさん、ありがとうございます)

「とにかく納期が迫っているから要件もほとんど決まってないけど、とにかく実装！」いう悩みは、とてもよく聞く話ですが、酷いケースだと、MVCのレイヤーも全く分けられずに、すべてを１つのクラスに実装されているケースもあったのだとか…これはもう絶叫レベルですね。何もいえません💦

ですが、発表されていた方は、強制的に要件定義などをやらなくてはいけないはめになったがために、
結果的にものすごくスキルアップのために良い経験をされてらっしゃると思った部分もあります。

自身のバーチャルプロジェクト開発と見比べてみて

この方の開発プロジェクトでは、テスト文化もなかったために、とても苦労されたそうですが、
私自身が行っていたバーチャルプロジェクト(*)と見比べてみた時に、どんな気づきがあるか考察してみました。

(*) 簡単な宿泊予約管理システムをドメインモデル手法する社内のバーチャルプロジェクト。
このプロジェクトでは、ある旅館がコロナの中客足が遠のいており、過去の客足の多さを取り戻すための施策として、旅館全体への口コミおよび、各客室の種類への口コミにより、よい評判を広めて売り上げの回復をはかるということを考える内容です。

このプロジェクトでは、各ユースケースに登場するドメインのクラス図、ユースケースシナリオの把握のためのアクティビティ図、事前事後条件チェックなどのテストのためのロバストネス図、シーケンス図をすべて管理しているため、テストコードをまだ書いてなくても、これらの図を見れば、どのようなテストが必要かはすぐ分かるようになっています。

なので、テストを後に書くのであれば、上記のような誰もが意図やプログラムの流れを把握できるような図を必ず残すべき。そして、テストファーストでテストが必ず書かれている場合は、図は最低限でいいってことなのだろうなと感じました。

ユビキタス言語の大切さ

わたしの直前にLT登壇された方は、DDD、TDDでの開発をされているフリーのエンジニアさんで、「言語の揺れ」についての発表をされました。

たとえば、ある対象をこっちでは「顧客」って単語で、向こうでは「会員」って単語で表現していたら
「え？顧客と会員って違う概念なの？？」という認識の齟齬が起き、
ここで、その確認のために余計なコミュニケーションコストがかかってきます。
こういったことを防ぐために、ドメインモデリングしながら、ユビキタス言語を定義し、かつユースケースモデリングなどの別の視点からの考察をすることで、その名称をブラッシュアップしていくのが理想的です。

ただ最初から名称にめちゃくちゃこだわるのは、
いつまでもそこで作業が停滞してしまうため、あまりよろしくないです。
そのため登壇者曰く、
「いまは一旦ここにいる全員がしっくりくる名前だよね。でも後で変わるかもね」という精神で挑んだ方がよい。とのことでした。

自身のバーチャルプロジェクト開発と見比べてみて

これは、とても共感する内容でした。
というのも自分の開発で作成していた宿泊予約管理システムにおいても
最初は【利用者】という名前にしていたモデルも、
他のモデリング作業などを通していくうちに、名前を【宿泊利用者】にした方が
しっくりくるときがあったからです。

この体験と、この方のLTを通して思ったのは、
少人数の開発現場において自分たちで要求～実装までのすべての工程を担当しているならば、すぐさま情報を共有できるだろうけれど、
大規模開発で、そもそも役割が分断されている場合、この伝達共有は非常に困難なことが容易に想像つきました。
よって、ウォーターフォール開発手法で分業開発を進める場合、
最初の要求定義をする場面で、命名に徹底してリスクを減らす工夫が必要に感じました。

ADR(アーキテクチャ・デシジョン・レコード)について

せっかくアーキテクチャの「なぜ」を丁寧にアーキテクチャ記述として残していたとしても、
それがチーム全体に周知されなければ意味がありませんものね。汗
そういった際にこういった
・なぜこのような設計に決定したのか
の記述がわかりやすく、かつ統一化されていると嬉しいですものね。

というわけで、自分の土日に開催している勉強会で取り入れてみることにします。

自分のLT登壇

今回は議題を2つ用意して、当日、参加者にその場で選んでもらうというスタイルをとってみました。
LT発表内容に多態性を用いてみるというちょっとしたおふざけです（笑）。

１つは、東京開催のエンジニアの輪で既に発表したものをリアレンジした
「モデリングを使って己と向き合う」という自己分析の内容と、
もう１つは、自己紹介を最後に持ってくるという、参加者と対話形式の「本質の探究」というタイトルの議題。
多数決で、ほぼ全員の方が後者を選んでくださいました。とても嬉しい限りです。

というのもこのテーマ、ちょっとした仕掛けをしておいたのです。
よくある発表は、冒頭に自己紹介がありますが、今回は議題に合わせて１番最後に自己紹介を持ってきました。
その旨を冒頭でご説明したのちに発表していきました。
それが結果的に吉と出たようです。
発表内容は、まずなぜこの内容にしようと思ったのか、
自分のついつい好奇心で本質を追求してしまう性格ゆえに味わってきた
つらい経験やそこからの転機をお話しした後に、
では本質ってなんなのか？
なぜ言葉で言うのは簡単でも実行できてないのか？
を最近自分がよくやってしまっていた【関心事の混在】というアンチパターンを用いて、参加者と対話形式にして進めました。

その後、自分なりの本質を捉えるための心得とHowの発表へ
・仮説の精神
・関心事以外を捨て去る精神
・最初からせっかちに本質にたどり着こうとしない精神

この３つをベースに持ったうえで

1. 1つの対象を多視点からの立体的観察
2. 1の整合性の随時チェック
3. 目的との照らし合わせ
4. 必要とあらばいつでも補正

を行っていく、という解説をしたのちに演習ワークショップに移行しました。

基礎演習ワークショップの内容は、
「わたしの図形思い描いているものってなんだ？」クイズをやってみました。
皆さんいい感じに夢中になってくれていて、対話形式を選んでよかったと心から思います。
そしてすべてのスライドを終えて最後に
「皆さんがこの私の発表を聞いたうえで、皆さんなりのいろんな視点からの私の見え方があると思います。その内側にあるコアなモノが私という人間、私の自己紹介になります。」と締めくくってきました。
ここ最近で自分が苦戦してきた、そして今も苦戦している関心事の分離、
そして目的(or要求)の探究といった内容を載せたお話で、
抽象度の高い部分もあったので、しらけるのも若干覚悟していたのですが、
「面白い内容だったし、非常に感動した。」というご意見を多々いただけて大変うれしく思っております。

今回東京からはるばる駆けつけた甲斐のあるとても有意義な交流勉強会でした。
参加者の方々、そして運営のよしたろうさん、ゆうきさんに感謝しております。ありがとうございました。