技術書典6でシステム設計・モデリングの本「もくもくモデリングの森を旅するチビドラゴンの軌跡」を頒布します

4/14(日)開催の技術書典6にてシステム設計(モデリング)の本「もくもくモデリングの森を旅するチビドラゴンの軌跡」という本を頒布します!

イベント情報はこちら
techbookfest.org

本について


モデリング技術向上に悩む新米エンジニアたちが一念発起。「もくもくモデリング勉強会」という自分たちだけの勉強会を始めました。
みんなで学び議論しあうこの勉強会は、モデリングの楽しみを教えてくれました。
これからモデリングを始めるすべての人へ、私たちの2年間の軌跡を捧げます。

・勉強会の進め方
モデリングの過程で作る図やドキュメントの作り方、解説
モデリングの観点、考え方
・よくある失敗モデルの事例
・勉強会向けのお題集

技術書典 サークル詳細より
techbookfest.org



システムの設計ってどうやればいいのかわからない、モデリングってどう勉強すればいいの?と悩む新米エンジニアたちによる社内勉強会が立ち上がる過程と、そこで2年間学んで得た成果と知見をまとめた本です。
これからモデリングを勉強してみたいと思っている方、初心者でも手に取りやすい、読みやすくわかりやすい本を目指しました。

勉強会をどう進めるか?という部分に関して、メンバー間の意識合わせやスケジュールの組み方を紹介したり、モデリングのプロセスと図やドキュメントといった成果物の作り方をなるべく簡単に、かつ具体的に説明しています。
また、モデリングをする際の観点や考え方といった部分についても、実際に勉強会で用いた例題を取り上げながら考察しています。
自分たちが迷ったり悩んだりした経験を元に、うまくいったことだけでなく失敗したことや今もまだ悩んでいることも交えながら書いています。これからモデリングの勉強を始めたり、歩き続けていくための後押しになる本でありたいという思いを込めて作りました。

会社名義での制作・頒布となります。本文の執筆はわたしが担当しています。装丁、レイアウト、挿絵、スケジュール管理などなど本文以外のすべては会社のみんなに助けてもらいました。というわけで本そのものの出来栄えも素敵に仕上がっています🙌

当日は か11「yagitch.com」さんのスペースに委託させていただきます。
おしながきはこちら〜↓

スペースでは委託先のyagitchさんのアウトプット本と、同じく委託でKOS-MOSさんのTerraform本が頒布されてます。

明日はよろしくおねがいします!

チームリーダーの呪いに苦しむ新米リーダーへ

eri-twin.hateblo.jp

「チームリーダー」になれなかった頃。上の記事で書いたプロジェクトが始まった頃から、およそ一年が経ちました。振り返れば良い経験で、記事に書いた思いは今も変わっていません。

それでも、最近、新たにチームリーダーを任されるようになった後輩などを見ていて、新米リーダーの思考を縛る「チームリーダーにならなきゃ」という呪いの強さを改めて感じています。

チームリーダーにならなきゃと思って、なれなくて、そんなことチームメンバーにも相談できなくて、孤独に悩み続ける日々。同じような悩みを抱えている方や、一年前の自分自身へ、いまの自分から伝えたいことを書いてみます。

「なんでもできるすごいリーダーになる」のを諦めること

会社においては「なんでもできるなんかすごい人」がリーダーをやっていることがままあります。こういう人を見て育ってきた新米リーダーは、"自分もこうならなければ"と思ってしまう。

これがすべての始まりです。

弊社にもすごいリーダーたちがいて、彼らを見てると「リーダーたるもの、彼らのようになんでもできるようにならなきゃ」って考えてしまう。

だけど、こうして悩みにぶつかる人は、おそらくそのような「なんでもできるなんかすごい人」ではないし、きっと同じようにできないから悩んでいるのだと思います。

もしも自分がすごいリーダーになれるなら素敵だ。けれど去年ブログに書いたように、わたしは、決してそれが唯一にして理想のリーダー、ではないと思っています。*1

すごいリーダーになりたいと願っても、今すぐにはなれないし、いつなれるかもわからない。そんな不確かなすごいリーダーを目指すよりも、自分がすごい人じゃないことを受け入れて、「今の自分がなれるリーダーになること」を考えた方が、きっと楽です。

「理想のリーダー像」は、チームの状態によって異なるのだと知ること

リーダーの呪いにかかり、「すごいリーダーのようにできない」と帰り道で落ち込む毎日。そんな中で、先輩のすすめを受けて「エラスティックリーダーシップ」を読みました。*2

この本では3つのリーダーシップが紹介されています。

  • サバイバルモードのチームに対する、指揮統制型のリーダー
  • 学習モードのチームに対する、コーチのリーダー
  • 自己組織化モードのチームに対する、ファシリテーターのリーダー

要は、チームの状況を見て自分がどのスタイルのリーダーになるのが良いかを見極めよう……っていうのが内容なんですが、ここにシンプルな気づきがあります。

少なくともこの本の中では、3つのリーダー像が提示されている。つまり、理想のリーダー像はひとつではないということです。これをもし知らなかったのなら知ってほしいです。わたしは知らなかったので目からウロコでした。

わたしがこの本から得た学びは、「漠然と自分の中にあった理想のすごいリーダー像」はただの妄想だったということです。理想のリーダー像なんてチームの状態によっていくらでも変わるのです。

リーダー像の妄想を捨てたら次は「リーダーの仕事」という妄想も捨てること

前述のように、当時はリーダーになるなら「なんでもできるすごいリーダー」を目指さなければいけないと思っていました。 自分がコードを書く時間が取れなくとも、調整や打ち合わせや面倒なあらゆることを引き受けて、メンバーがなにも気にせずコードを書けることがリーダーの役割だと考えていました。

ですが、振り返ってみると、チームメンバーからはわたしが何をやっているかわからなかったはずです。コードも書かないから、仕事をしていないように見えたと思います。一方で実装以外の問い合わせも打ち合わせもわたしのみが知っている状態で、常にわたしが情報のボトルネックでした。

これは単純に情報共有をしていないだけではなくて、コーディングのみを丸投げしているのが問題でした。そもそも前提となるサービス仕様や要件を知ってもらおうとしてないため、たとえ打ち合わせの情報を共有したところで、メンバーはどうしようもなかったのではないかと思います。

そんな日々が続いて、自分は好きでもない調整ばかりで楽しくコードを書く時間がない。チームメンバーとも対立して、チーム全体の雰囲気は悪くなる一方。とても苦しかったです。

結局、打ち合わせはメンバーにお願いしてもいいし、もちろんリーダーがコード書いててもいいです。誰か一人にしかできない仕事なんてそんなに多くないし、それが新米リーダーならなおさらです。チームなんだからチームの誰かがやれればいい。

チームに求められているのは、チーム全員で、期待されている分のアウトプットを出すこと。そのためにチームを見て、チームが必要としている役割を自分が果たすこと。その点においては、メンバーもリーダーも同じなのだと思います。

自分が理想のリーダーになるのではなく、みんなで理想のチームを目指すこと

原点に立ち返って、リーダーがなんのために必要とされるのかを考えるなら、それは「チームのため」であるはずです。であれば、リーダーの仕事はリーダーをすることではなく、良いチームを作ることです。

だから別に、自分がリーダーだから、なんて背負い込む必要はありません。むしろその思いは過剰すぎると呪いに転換して、こうして苦しい思いをすることになります。

チームを作ることは難しいけれど、一方で、実はすごく面白いことでもあります。でも呪いにかかっている間はそんな考え方はできなくて、それが一番もったいないのかもしれません。

毎日変化して成長していくチームをみんなで作っていくの、すごく楽しいんですよね。

そのうちいいチームを作れた実感が持ててきたり、チームの解散が心から惜しかったり、次のチームではどんなふうにやってみようかな〜なんて考えるようになれたら、もう大丈夫です。

おわりに

わたしも自分自身にかけてしまって苦しんだチームリーダーの呪い。この記事が、少しでも早く解き放たれるための一助になれば幸いです。

*1:むしろ「なんでもできるすごいリーダーになる」こと、つまり超人になることを目標にするのは、自分を過大評価しているとすら思う

*2:今回あんまり書籍の内容に触れてないですが、普通にチーム作りにおいてためになる内容が書いてある良い書籍です。読みやすい本なので、悩んでいるなら悩む代わりにその時間で読んでください。

平成最後のあけおめ

新年あけましておめでとーこざいます。
のんびり帰省させていただいてるのでまだ仕事始まってません。

2018年のふりかえり

できごと
1月 インフルエンザ
2月 就職以来心の支えだった作品が終わる
3月 チームリーダになりたくなかった
4月 米がマイ(米)ブーム
5月 推しが炎上
6月 OJTコーチが退職
7月 障害対応
8月 障害対応
9月 DDDアライアンスで発表した
10月 バレーボールの試合を見た
11月 今までで一番残業した
12月 虚無

今年は就職以来一番しんどい年でした。仕事始めてからは安定した気持ちで生きていたのですが、今年の前半でいろんな精神安定剤を失ったため後半のつらみがすごかったです。

アドベントカレンダー芸人のくせに12月はなにも面白いことが思いつかなくなり、内省しているうちに年が明けました。悲しい

あとは社内ブログを炎上させたり会社のBBQイベントに行ってお友達ができたりいろんな舞台を見に行ったりしたような気がします。楽しいこともたくさんありました。

よかったこと

  • チームリーダーやりました
  • チームビルディング楽しくなりました
  • 設計楽しくなりました
  • DDD面白いなと思うようになりました
  • DDDアライアンス後、社内の若手からDDDについて一言ある人みたいに見られています 騙されるな
  • たくさん迷惑をかけていろんな人に助けてもらいました、昨年度はありがとうございます。今年はもう少し落ち着きたいと思うのでよろしくお願いします

2019年

毎年おみくじの言うことを信じています。今年は末吉でした。あんまり気にいる内容でなかったので、都合の良い解釈をしていこうと思います。

目先にあることしかやりたくないしやりたいことはすぐ変わるので年間目標は立てませんが、健康と安定した情緒を得たいです。

あとはブログでもなんでもいいのでアウトプットを増やしたいと思います。去年は書きたいことがあってもなかなかブログを書ききれなかった。悩むより書く。

今年もよろしくおねがいします。

9/26のDDD Allianceにて発表しました

先日のDDD Allianceの勉強会にて、いま開発現場で取り組んでいるドメイン駆動設計の成果について発表させていただきました〜。

ddd-alliance.connpass.com

手前味噌。 発表資料。*1 他の登壇者の発表資料は上記イベントページのリンクからどうぞ!

www.slideshare.net

ためになる裏話とかは特にないのですが、せっかくなので感想など書いておこうかと思います。

DDDって注目されてるんだな〜という話

想像していたよりもずっと多くの方がドメイン駆動設計に興味を持っているのだと今回初めて知りました。(まずイベント公開からすぐにたくさんの申込があったので、当日までビビりながら資料作りしていました)
ディスカッションの場や懇親会でも、社外でDDDを実践している方々とお話しさせていただき、とても良い機会になりました。

イベント終了後、主催者・参加者の方々によるイベントレポート、感想ブログ等もたくさん書いていただきました。

dev.classmethod.jp togetter.com vermeer.hatenablog.jp hiroronn.hatenablog.jp

素直に、今回発表できてよかったな〜と思います。
資料作りは大変だったけど、それを十分に越える反響とフィードバックを貰えたのですごく満足しています。

改めまして、本当にありがとうございました。

バックグラウンドの話

イベント中ではさらっと流した部分でしたが、私は入社4年目、5年前から始まった弊社でのDDD開発が広まり出したころに参加しました。DDDネイティブ的な立場です。
新卒で入って研修を終えた6月頃、最初に書いたのがDDDのお題でした(イベントで最後に発表した奥野さんの資料の中で紹介されているお題です)。

javaを書いたことなくクラスの概念もわからない、そんな状態の1年目の私は、言われるがままにバリューオブジェクトを作りながら「javaってコードもファイルもたくさん作らなきゃいけなくて大変だなあ」と思っていました。

あれから約3年半の開発経験を経て、今回の発表。自分が理解できていなかった頃から続くこれまでのDDD実践の積み重ねから今のベストの実装に至るまでを振り返ることで、これまで自分が当たり前に使っていた仕組みのありがたみを実感することになりました。

DDDは面白い

私がDDD面白いなと思うようになったのは今年に入った頃で、結構最近の話です。ある案件をひとつメインで任されて、設計をじっくり考える時間をもらったのがきっかけでした。
ひたすらドメインモデルを考えて、実装してみて、うまくいかないところがあったら書き直し、サービス仕様がはっきりしてくる中で変えたいところがあったら書き直し、を繰り返す。 その中で(これはすごく感覚的な話なのですが)頭の中が開けるみたいにドメインがぱーっと理解できた瞬間がありました。これだー!という感覚。
ドメインがしっくりくるようになって、そのまま設計できて、その時にDDD面白いなもっと考えたいなと思うようになりました。

そういうわけでとても最近の話なのですが、今回の発表を経て、また考えてみたい事が増えました。まだまだ飽きることなく、これからも試行錯誤、取り組んでいけそうです。

最後に

お約束ですが! こんなかんじで取り組んでます弊社のDDD開発に興味が出てきませんでしょうかどうでしょうか。エンジニア超!募集中です〜!ぜひに!よろしくおねがいしまーす!!

*1:発表当日に上がっていた資料には隠しスライドが入ってしまっていたためアップし直しました。失礼しました…

図:外部設計で作るべきドキュメントを考える 二期作

以下の記事で作った図をさらに俯瞰して、ドキュメント同士の前後関係を書く。

eri-twin.hateblo.jp

緑が↑で挙げたドキュメントたち。ユースケース記述とロバストネス図はいったん「機能詳細設計」でまとめ直した。
ピンクはinput、自分たちで書かないやつ

f:id:eri-twin:20180910164335p:plain

矢印の手前のドキュメントをインプットにして、次のドキュメントを作っていくイメージ。(図だけに)

ST仕様書だけは一応書いたんだけど、テスト向けのドキュメントについてはまだ考えられてないのでここでは掘り下げない。
まずは外部設計を開発用ドキュメントの一旦のゴールとして、それに向けてどういうものが必要かのまとめ図。

設計段階のいろいろを勉強したので、新しい案件やりたいな〜

図:外部設計で作るべきドキュメントを考える

eri-twin.hateblo.jp

結局どういうことかわかりにくいので
これを図にする

一般的なドキュメント-> 表現したいこと -> 開発的ドキュメント f:id:eri-twin:20180904165915p:plain

続きを読む

システム設計の基礎:外部設計で作るべきドキュメントを考える

システム設計の基礎を学ぶ研修に会社のお金で行かせてもらったので、成果を書きます。

今回のテーマ

外部設計で作るべきドキュメントとはなにか?

研修の内容を受けて、外部設計段階で作成する一般的なドキュメントをまとめました。
それに対し、自分の開発チームがいま作っている資料を一般的なドキュメントの内容と比較・対応させて、外部設計にどんな資料が必要なのか考えました。

設計の前に:要件定義の確認

要件定義のアウトプットとして作成されるドキュメントは以下のようなものがある。

  • データフロー図(DFD)
  • 業務フロー図

うちだと、要件を文章や図で書いたものと業務フロー図がサービス仕様書に表現されているはず。このサービス仕様書を最初のインプットとして外部設計を作成し、業務設計担当者との認識を合わせていく。

まずは要件定義の確認、サービス仕様書を読む。チームで読み合わせとかすると良い。足りていない部分があれば要件定義した人に聞いてみる。

特に非機能要件、性能やSLAは設計に影響するので注意。
要件に書ききれていない非機能要件を聞き出せるのが良いエンジニアとのこと。

外部設計資料の一覧(一般)

世の中にはいろんなドキュメントがある
研修で習った各ドキュメントの名称と、表現したいことを簡単にまとめる。

コンテキスト図
  • 開発領域、スコープ
  • 関連システムの洗い出し
システム階層図
用語(ドメイン)一覧
  • 用語の標準化
  • 用語の定義
論理データモデル
  • データ項目
  • データの関連性
システムフロー図
  • データと機能の関係
  • 機能の処理順序
機能仕様書
  • 機能の詳細(Input, Process, Output)
  • 人とシステムの区別
機能/エンティティマトリックス
  • 機能に対する各エンティティのCRUD
エンティティ仕様書
  • データ項目の属性、桁数、制約(NOT NULLとかUNIQUEとか)
非機能要求仕様書
  • 非機能要件の詳細

(うちのチーム的に)必要な外部設計資料とは

ここからがサビ
自分たちが作っているドキュメントと、研修で習ったドキュメントとを繋ぐ。

システム階層図 -> API・バッチ一覧

単純に実装する機能の一覧。
資料として明示的に作らない場合でも、チケット管理ツールのエピック等で表現されてるイメージ。

用語一覧 + 論理データモデル(+ ちょっとコンテキスト図) -> ドメインモデル

ドメイン名は見ればわかる名前、そのものの本質を表す名前をつけるようにしている。そのため、用語の意味はドメイン名によって表現される。
通常ドメイン名はなるべくサービス仕様書に記述されている言葉を用いるので、その場合はサービス仕様書内で意味も定義されているはず。
システム的な都合で作成されたドメインの場合など、業務に現れないドメインの場合は、外部設計仕様書に別途記載する必要がありそう。

データの関連性は、モデル中の多重度、依存関係で表現される。

関連するサブシステムとの結合もドメインモデル中に表現している。
これらを書くことで、開発領域も可視化できる。

システムフロー図 + 機能仕様書 -> ユースケース記述・ロバストネス図

要求の機能をより具体的に落とし込んだドキュメントとして同じ位置だと考えた。 ユースケース記述は、文章でユースケース単位のInput, Process, Outputを表現できる。(≒ 機能仕様書)

ユースケース記述はロバストネス図のインプットになる。図にすることで、

  • 人(アクタ)とシステム(エンティティ・コントローラ)の区別
  • データ(エンティティ)と機能(コントローラ)の関係
  • 処理順序

あたりが自然に表現できそう。
ユースケース記述とロバストネス図だと切り口がユースケースという視点になるけれど、 機能とデータと人、それぞれどう関係しているかを表す分には十分かなと思う。

もうちょいシンプルに機能とデータの関係を表した図をいつも書いていたけど、あれが何図なのかわからない (ずっとコンポ図と呼んでいたけど、ちゃんと調べたらなんか違う気がする…)。

機能・エンティティマトリックス -> 状態遷移表
  • 特定のイベントが起きた場合のエンティティの状態

研修中はこれが似たような位置だと思ったけど、社内で聞いてみたら設計思想によって使い分けた方が良さそうという話になった。

弊社はイベントドリブンで作ってることが多いので状態遷移表をよく書いてるけど、 CRUDは外部のサブシステムの機能から呼ばれた場合とかも書ける。
なにかのイベントが起きたことを検知して自分の状態が変わるのが前者、 このエンティティはこの状態になれ!っていうのが後者の考え方。 たぶん。

ほか、普段あんまり作ってないもの

  • 非機能要求一覧
  • コーディング規約

非機能要件の確認は冒頭に書いた上に、最近はデザインレビューの項目でもあるので、設計の初期段階で明確に検討するべきなのだと感じた。抜けがち。

コーディング規約はうちのチームは放棄…わりと察する系(つらい)。

  • エンティティ仕様書 -> テーブル設計(内部設計)

エンティティ仕様書は桁数とか制約も書くので、うち的にはテーブル設計だと思うんだけど、 このあたりまで外部設計の段階で書くものだとは思ってなかったので意外。
研修中でも物理データモデル設計は内部設計側にあるので合ってるんだけど、たとえばユニーク制約とか貼ったら、このデータはユーザごとに一意なんですとか、 そういうレベルの話は要求者側に認識してもらっても良いのかもな〜と思った。

まとめ:外部設計ではどんなドキュメントが必要なのか?

結論、これを作れば設計はばっちりのはずだ!

さいごに

この研修を受けた目的は、標準を知らない自分が、社外で標準的な開発プロセスを学んできた人と話せるようになることでした。

で、研修で世間の標準を学んでみてよかったことがあって、
「自分の中に標準があることの安心感、自信」
を感じられるようになったこと。

これまで外部設計も見よう見まねでこれがほしいあれがいるかもと付け足したり消したりしながら迷走していた状態だったのですが、
たとえば、これは外部設計で書くべきなんですか (開発チーム内部で共有できていれば十分な内容なのでは?)という問いに対して、前は答えられなかったけれど、研修を受けてからは 「これは自分が勝手に言っているだけのものではない」「要求元に確認したほうが良い内容だ」「こういう内容が必要だ」 という裏付けがある状態になったので、多少自信を持って話せるようになった。

ある程度の現場経験を積んでから理論を学ぶと、ここで言われてることって今までやってきたあれなんだ! というような気づきを得られるようになり、最近は読書もすごく楽しくなっているのですが、研修もとても良いインプットになりました。めちゃくちゃ忙しくて死ぬかと思ったけど本当に行ってよかった。

あと余談ですが最近ユースケース駆動開発実践ガイドを読んでるのでもろ影響されてる(ロバストネス図のくだりとか)。

以上、ここまでお読みいただきありがとうございました。
この内容に対する見解がありましたらぜひ教えてください。