先日、大阪で開催された「エンジニアの輪」というイベントに東京からはるばると駆け付けました。
というのも、若干１年目わたしとほとんど業界経験年数が変わらないながらも
SOLID原則とか含めて、とても設計に対して熱い熱を持った素晴らしき方がいたので、
実際にお会いしてどのように普段学習をされているのか聞いてみたかったからです。

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

受託開発の大変さ

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

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

自分のVP開発と見比べてみて

この方の開発PJではテスト文化もなかったために、とても苦労されたそうですが、
今自分がやっているVPでは、ドキュメントとして
各ユースケースに登場するドメインのクラス図、
ユースケースシナリオの把握のためのアクティビティ図、
事前事後条件チェックなどのテストのためのシーケンス図やロバストネス図
をすべて管理しているために、
テストコードをまだ書いてないけどそれらの図を見れば、
どんなテストが必要かはすぐわかるようになっています。
なので、テストを後に書くなら必ず上記のような誰もが意図やプログラムの流れを把握できるような図を残してあげるべき。
テストファーストで必ずテストが書かれている場合は、図は最低限でいいってことなのだろうなと感じました。

ユビキタス言語の大切さ

わたしの直前にLT登壇されていた方が、ちょうどDDD、TDDでの開発をされている
フリーのエンジニアさんだそうで、この言語の揺れについての発表をされていました。

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

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

自分のVP開発と見比べてみて

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

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

ADRについて

これはこの日初めて聞いた内容でした。
https://blog.studysapuri.jp/entry/architecture_decision_records
https://qiita.com/fuubit/items/dbb22435202acbe48849
このあたりがわかりやすいのではないでしょうか？
私自身まだこのADRを使ったことはないのですが、
どうやらアーキテクチャ記述を管理しやすいドキュメントツールのようですね。

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

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

自分のLT登壇

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

議題のうち１つは、
すでに東京のエンジニアの輪で発表したことのあるものをリアレンジした
「モデリングを使って己と向き合う」という自己分析の内容と、
もう１つは自己紹介を最後に持ってくるという参加者と対話形式の「本質の探究」
というタイトルの議題。

発表を始める前に参加者の皆さんに多数決をとって決めてみると、
ほぼ全員の方々が後者を選んでくださいました。とても嬉しい限りです。

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

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

この３つをベースに持ったうえで、
①. 1つの対象を多視点からの立体的観察
②. ①の整合性の随時チェック
③. 目的との照らし合わせ
④. 必要とあらばいつでも補正
を行っていく、という解説をしたのちに演習ワークショップに移行しました。

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

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