なぜ、実りのある勉強会が1年以上も継続しているのか？
この記事はDDD-Community-Jp Advent Calendar 2020 - Qiitaの20日目の記事です。
「モデリング会」という勉強会を1年ほど継続しています。端的に言って、勉強会が1年続くのはすごいことだと自負しています。 エンジニア文脈での勉強会に限らず、自主的な活動が1年も安定して継続している(そして、これからもきっと続く)というのは、やろうと思ってもなかなかできないことでしょう。
- 参考: そもそもモデリング会とは？ どんなことをどのようにやっているのか？ → モデリング会の1年をざっと見返す - Qiita
- 参考: 1年継続って実際にはどれくらいのペースなのか？ → Reservation2/モデリング会開催履歴.md at master · ModelingKai/Reservation2
しかも、ただやっているだけじゃなくて、多くの実りがある活動です。1つの例としてはアドベントカレンダーです。参加メンバーがこれだけ多くの考えを言語化していることは大変に素晴らしいと思います。
1年続いたのにはワケがある。それを考えたい
なぜ1年も継続しているのでしょうか？ 言語化がテーマの会において、この件を考えないわけにはいきません。
特に大切なのは次の2つと考えています。
- 初動での重要なポイントを抑えていたこと
- 「情熱家」が存在していること(あるいは、生まれたこと)
それぞれについて深堀りしていきましょう。
他の重要な考察については、「1年間続いたオンライン勉強会」秘伝のタレを公開します - jnuank blogにあるので、興味がある方はこちらも読んでいただけると良いかと思います。
1. 初動での重要なポイントを抑えていたこと
勉強会の初動が良かったと思っています。これには自信があります。
具体的には次の2点です。
- メインディッシュに集中するために、独断での意思決定を連発した
- 迷いを減らすために、勉強会それ自体の初期設計を行った
a. メインディッシュに集中するために、独断での意思決定を連発した
勉強会立ち上げ時には面倒なことだらけ
勉強会の初期段階は、決めなくてはいけないことが多いです。
ここが非常に面倒くさいのです。本当に面倒くさい(僕らはモデリングやプログラミングをやりたいだけなのに！)
面倒くさいことは長続きしません。しかし、これらの面倒くさいことは決めなくてはなりません。
初期段階においてはお互いのこともよくわからないし、互いに牽制しがちです。チームビルディングもコミュニケーションも何もありません。そうなると、なんとなく黙っている時間が長くなったりします。要するに、決まらないのです。
意思決定の高速化については、この記事をお手本しています。 konifar-zatsu.hatenadiary.jp
独断による解決
そこでどんな策を実行したかというと、「独断での意思決定」を繰り返しました。
「独断です！」と高らかに宣言しながらバシバシ決めるのです。間違っているとかそういうことは気にしない。意思決定をすると、先に進みやすくなります。なぜなら責任をとらなくていいからです。つまり、面倒くさくないのです。これなら気力も体力も消耗しない。だから、やりたいことにエネルギーを注げるわけです。
もちろん、独断で決めるには勇気が必要です。いろんな恐怖を乗り越えなくてはいけません。勇気だけでなく理屈や言葉も必要です。そのための対策は後述します。(b. 迷いを減らすために、勉強会それ自体の初期設計を行った」にて)
独断ではあるが、独裁ではない
勘違いしてはいけないのは、独裁ではない点です。相手の意見も聞くし、取り入れる。前言撤回もいとわない。そのかわり、迷う場面ではガンガン決めるのです。
b. 迷いを減らすために、勉強会それ自体の初期設計を行った
過去に主催した(参加した)勉強会を振り返ってみると、「○○を勉強したい」→「勉強会の開催だ！(参加だ！)」というパターンばかりでした。
つまり、「勉強会」ではなく「何を勉強するか」にしか興味がありませんでした。もちろん、これだけでも十分に価値はあります。しかしながら、同じパターンでは勉強会が継続させられないことは経験的にわかっていました。勉強会が長続きしないということは、継続によってのみ到達できる景色を眺めることができないわけです。
そんなことを考えながら、1日かけて @jnuankと2人で勉強会の設計をしました(彼がいなかったら間違いなく成立していませんでした)。思えば、この最初の行動こそが最も意義のある重要な選択でした。
今日の成果
— なかじま (@jnuank_) December 15, 2019
・勉強会をする意義について話し合い
・勉強会参加した人たちが、終了後にどう思ってほしいか
・モデリング会についての抽象度軸とかキーワードとかの出し
・お題を考えた
結論：脳が死ぬ#ModelingKai
モデリングの題材やタイムテーブルもその場で決めました。ここもしんどい部分でしたか、ペアワークによってなんとか明文化するところまでいきつけました。
モデリングお題「会議室予約ドメイン β版」つくってみた。https://t.co/mwXZMJGrTV
— おーひら (@mohirara) December 15, 2019
「現場でDDD！ 2nd」で得た刺激からのアウトプットじゃ！#ModelingKai
設計の効用は迷いが減ること
これは前述の主張と関連するのですが、バシバシ意思決定ができるのは、意思決定基準とそのプロセスがあるからです。
「決めよう！」と意気込むだけでは限界があります。決定を支える土台がないと簡単に迷子になってしまいますからね。
具体的にどのような設計にしたのか？
テーマや設計に関する詳しいことはこれらの記事をご覧ください。
2. 「情熱家」が存在していること(あるいは、生まれたこと)
つづいて、ポイントの2つ目です。前述までの具体的な話に比べると、やや曖昧な話ですが、情熱は間違いなく重要です。
モデリング会には多くの情熱家が存在します。この情熱家の存在が、継続のみならず、実りのある活動に大きく寄与しています。
情熱家とは一体なにか？
一言で言えば、「学びに対して、真摯な態度を貫く人」というイメージです。
とにかく面白がるし。我慢強さや粘り強さがある。失敗に対して寛容さを持ち、ある種の楽観さをもっている感じでしょうか。
少々わかりづらい部分があるので、次の引用を読んでみてください。
情熱家はそれを表に出さない。心に秘めている。それが生き方に表れてくる。粘り強さ、気概、真剣さ、すべてをなげうって没頭する姿勢といった情熱家の資質は、履歴書でははかれない。また必ずしもすでに成功しているとは限らない。何かに本物の情熱を抱いている人は、最初はうまくいかなくても努力を続ける。情熱家に失敗はつきものだ
エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル,ラリー・ペイジ. How Google Works (Japanese Edition) (Kindle の位置No.1817-1820). Kindle 版.
あるいは「ラーニングアニマル」と呼ばれるものかもしれません。
ただ、知力だけでも足りない。とびきり優秀な人でも、変化のジェットコースターを目の当たりにすると、もっと安全なメリーゴーラウンドを選ぼうとするケースはやまほどある。心臓が飛び出しそうな体験、つまり過酷な現実に直面するのを避けようとするのだ。ヘンリー・フォードは「人は学習を辞めたとき老いる。二〇歳の老人もいれば、八〇歳の若者もいる。学びつづける者は若さを失わない。人生で何よりすばらしいのは、自分の心の若さを保つことだ」と言った。グーグルが採用したいのは、ジェットコースターを選ぶタイプ、つまり学習を続ける人々だ。彼ら〝ラーニング・アニマル〟は大きな変化に立ち向かい、それを楽しむ力を持っている。
エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル,ラリー・ペイジ. How Google Works (Japanese Edition) (Kindle の位置No.1849-1855). Kindle 版.
情熱家の特徴が掟として明文化されている
この感覚は、モデリング会における「4つの掟」にあらわれていると思います。
論よりコード、論よりモデル:
- 口頭で議論するなら、コードや図を並べて議論すべし
無責任デリゲーション （っ'-')╮ =͟͟͞(責任) ﾌﾞｫﾝ
- 迷ったら誰か1人に無責任に決断を委ねるべし
- 多数決はスピードが出ないので、「◯◯さん、決めてください」と無責任に投げる(この委譲に関しては合意している)
ワールドメーカー【俺がルールだ】
- 誰かが提案したら、いいぞー！と称えるべし
まずは負けてみる（ゴン・フリークス@天空闘技場）
- 実験なので、率先して間違うくらいの気持ちでいくべし
情熱家はどこからきたのか？
これは最初から情熱家だったのかもしれませんし、途中から情熱家になったのかもしれません。そして、なぜ集まったかの理由はわかりません。偶然かもしれないです。どうやったら情熱家になれるかもわかりません。でも、とにかくそこに居ます。
まとめ
1年も継続している勉強会の理由について考えました。
- 初動での重要なポイントを抑えていたこと
- 「情熱家」が存在していること(あるいは、生まれたこと)
記事を書きながら改めて思考した結果、やはりこの2つはとても重要に思えます。
今回は初動の重要性が中心でしたが、継続は初動だけでは叶いません。変化も必要ですし、具体的なテクニックも必要です。その話については、ぜひ 「1年間続いたオンライン勉強会」秘伝のタレを公開します - jnuank blog をご覧ください。
リモートペアプロのコツ。まずインフラに投資すること
本稿は DDD-Community-Jp Advent Calendar 2020の15日目の記事です。
前回の記事(リモートペアプロにおける3つのフォーメーション - mob-mob-village)で次のようなことを書きました。
伝えたいことは次の2つです。
- ペアプロは練習すると、うまくなる。練習しないと、へたっぴのまま。
- インフラ環境への投資はとっても大切。(← 詳細は別記事で)
ペアプロは、とにかく練習です。同時に環境への投資も重要です。
それらをろくにせず「本番業務をすべてペアプロでやりましょう！」みたいなことをするのは相当にリスクが高いです。
さらに最悪なのは「ペアプロ自体が役に立たないもの」と思ってしまうことです。
ペアプロの練習不足やペアプロの環境不備 → ペアプロ体験が最悪になる → ペアプロが悪いものだと認識してしまう(練習と環境整備をしていればそうはならなかったかもしれない！)
今回の記事では、「インフラ環境への投資はとっても大切」について書きます。
リモートペアプロに必要なもの
「○○に投資しよう！」という話をする前に、そもそもリモートペアプロにおいて必要なものを列挙します。
- 前提となるインフラ観点
- 【超重要】 安定したインターネット環境
- コミュニケーション観点
- 音声コミュニケーション
- 画面コミュニケーション(画面共有)
- テキストコミュニケーション(チャット)
- お絵かきコミュニケーション
- ハードウェア観点
- 【超重要】 ディスプレイ
- PCスペック(メモリなど)
- マイク
- イヤホン / ヘッドホン / スピーカー
- カメラ
いずれも必要です。しかし、重要度も異なります。特に重要だと思う、ソフトウェアの選択肢はいくつかあります。 例えば、コミュニケーションツールとしては、ZoomやGoogleMeet、Discord、MicroSoftTeamsなどの選択肢がありますね。
絶対に投資すべきこと
【超重要】 安定したインターネット環境
インターネット環境の重要性は言うまでもないでしょう。より高速かつより安定な環境であればあるほど良いと思います。
【超重要】 ディスプレイ
大きいディスプレイもしくは、複数のディスプレイを用意するべきです！
これは投資している人にとっては「当たり前」ですが、投資したことない人は「え、それは別になくていいんじゃない？」という意見になりがちな印象です。
リモートペアプロする上では少なくとも合計2枚分の領域が必要だと思います。
ディスプレイはかなり安くなっていますし、とりあえず買ってみるのをおすすめします → Amazon.co.jp : ディスプレイ
あるいは、macOSを使っている人は、iPadがあれば追加ディスプレイとしてカンタンに利用できるのでオススメです。
参考
ちなみに私は、次の2枚体制を採用しています。
- 40インチのディスプレイ1枚
- 24インチのディスプレイ1枚(縦置き)
現状はこれがベストといった感じです。もう1枚追加したパターン(合計3枚)も試してみたのですが、かえって使いづらかったのでやめました。 ディスプレイが多くあるよりも、大きいディスプレイを分割するほうが性に合っています(同じような理由で、macOSのマルチデスクトップは使っていません)。
また、アプリは少なくとも次の4つを常時起動しています。
少ないような気がしますが、これははJetBrainsのIDEを使っているためです。ターミナルやGUIでのバージョン管理ツールなどに分解したらもっと多くなると思います。
余裕があれば投資したほうがよいこと
お絵かきコミュニケーション → iPadPro + ApplePencil(第2世代)
オフラインでペアプロする場合は、ホワイトボードやコピー用紙にお絵かきすることがあると思います。クラス図みたいなものだったり、自分の考えを表現する何かしらの概念図だったり。
リモートペアプロでは、こういった「お絵かきコミュニケーション」が難しいです。どのような対策があるかというと
- 紙などに書いて、それを画像として保存し、相手に共有する
- PowerPointなどでなんとか表現する
- ペイントなどで手書きで頑張る
どれもなかなか難しいです。というよりも、手書きに比べてストレスが非常に大きくなります。ストレスが大きくなると、あきらめたりごまかしたりしてしまいます。
そこでおすすめなのが、iPadProとApplePencil(第2世代)です。お絵かき系のアプリもたくさんありますが、Notabilityというアプリがいい感じです。
これはもう実際に使ってみてくださいというほかないです。ぜひお試しを！
オーディオ系
専門家ではないので細かい音質の違いはよくわかりませんが、投資すると良いと思います。
いくつかポイントを羅列しておきます
- マイクは物理的に感度調整ができると便利(すぐにミュートにできるので事故が防げる)
- イヤホンやヘッドホンは疲れないものがよい
- 無線イヤホンの場合は、2台用意しておく、充電が長持ちするものを利用するとよい
マイクについてはYoutuberの解説をいくつかみて、これを選びました。特に不満はないです。 → Amazon | FIFINE USBマイク
まとめ
リモートペアプロは、そのやり方も重要です。しかし、インフラはそれ以上に重要です。特に、インフラについてはストレスの原因になりやすいです。
まずは、インターネット環境とディスプレイに投資しましょう！ (インターネット環境は工事が必要だったりするので、まずはディスプレイを購入してみるのが良いと思います。)
リモートペアプロにおける3つのフォーメーション
本稿は DDD-Community-Jp Advent Calendar 2020の9日目の記事です。
先日、(アートオブアジャイルデベロップメント読書会 #2 - connpass)という読書会に参加しました。
当日のお題は「ペアプロ」でした。この読書会全体のテーマは「アジャイル」なので、アジャイル開発を実践したり、興味がある人が参加者の属性として多いわけですが、そのなかでもペアプロをやったことない人が多くいました(これは、とても意外！)。
ペアプロ(ペアプログラミング)は、XPのプラクティスとしても有名です。近年では、モブプロ(モブプログラミング)もかなり広まっていますね。
ペアプロを始めるにあたって考慮すべきことはいくつかあります。
例えば、ペアプロのやり方やペアプロに必要な環境の構築方法、どうやって雰囲気を作るか、業務でペアプロを導入するための工夫などです。
どれも大切なのですが、この記事では、初めてペアプロ(特に、リモートペアプロ)をするときに意識すると良いことと、具体的な構成について紹介します。
特に、これからペアプロを始めようと思っている方の支援になればと思います。
伝えたいことは2つ
伝えたいことは次の2つです。
- ペアプロは練習すると、うまくなる。練習しないと、へたっぴのまま。
- インフラ環境への投資はとっても大切。(← 詳細は別記事で)
ペアプロは、とにかく練習です。同時に環境への投資も重要です。
それらをろくにせず「本番業務をすべてペアプロでやりましょう！」みたいなことをするのは相当にリスクが高いです。
さらに最悪なのは「ペアプロ自体が役に立たないもの」と思ってしまうことです。
ペアプロの練習不足やペアプロの環境不備 → ペアプロ体験が最悪になる → ペアプロが悪いものだと認識してしまう(練習と環境整備をしていればそうはならなかったかもしれない！)
3つの具体的なフォーメーションの提案
練習をしましょう。しかし、実際にどのように練習すればよいのでしょうか。
考えるべきことはたくさんありますが、ここでは、具体的な構成について説明します。 (交代するタイミングやペアプロのコツ、失敗した話についてはまたいずれ)
1. Push/Pull パターン(おすすめ度: ★★★★★)
やり方
- 開発環境は各自のマシンで好きなものを採用する
- 交代する際には、Push/Pull を行う
- ドライバーの画面を共有しながら進める
- GoogleMeet は 複数名の画面共有が同時にできるので非常に快適！
- Zoomは共有される画面の切り替えが手間なので、おすすめできない(自分は耐えられなかった)
嬉しさとツラさ
👼 各自の開発環境(IDEやエディタなど)が使えるのでストレスが少ない
👼 相手のツールの使い方を見て学べる
👼 GitHubに慣れていればスムーズ
👿 交代するのに少し時間がかかる(賛否あり)
👿 指摘がちょっと面倒なときがある(カバー可能)
🌏 GitHubが落ちてもGitLabやBitBucketで回避可能
ちょっと一言: 「交代するために Push/Pull が必要」はマイナスばかりではない
たしかに、Push/Pullするのはちょっとだけ手間と時間がかかる。きっとそれは、オフラインにおけるキーボード交代や、同時編集よりは手間。
しかし、個人としてはむしろメリットだと捉えています。
それは「交代時に Commit が必要となる」からです。絶対に Commit するので、振り返りの回数が自然と多くなります。
- 「えっと、何をやったんでしたっけ？」
- 「次は何をするんだっけ？」
- 「○○という発見があったよね」
普段はあまり省みることが少ない(であろう)コミットメッセージさえもペアプロするのです！
ただし、万人にとって良いかというと、経験上は微妙なところです。。
- コミットメッセージが煩わしいというマインドセットがある場合、ただのマイナス要素になる
- コミットログが多くなっちゃうのイヤ
- 中途半端なコミットログが恥ずかしい感じがちょっとある(昔はあった
2. LiveShare パターン(おすすめ度: ★★★☆☆)
やり方
- 文字だとイメージしにくいので、ぜひこちらの動画を参考にしてください VSCodeLiveShare で ペアプロする方法(Mac編) - YouTube
嬉しさとツラさ
👼 環境構築の負担がホストだけで済む
👼 交代のコストが掛からない
👼 ナビゲーターもコードで示すことができる
👿 自分の使い慣れた環境ではないのはかなりのストレス(逆にいうと、揃えたら無敵)
👿 ホスト側の環境での作業になる
👿 たまに動きが怪しい時がある
🌏 実はLiveShareでの通話もできる
🌏 Follow機能がすごい
🌏 IntelliJの公式プラグインもある → Code With Me EAP リリース – IntelliJ IDEA Blog | JetBrains
ちょっと一言: 実際に体験してみたほうがよい
- これは実際にやってみてください(やってみないと分からない)
3. ブラウザIDEパターン(おすすめ度: ★☆☆☆☆)
やり方
嬉しさとツラさ
👼 ブラウザがあればそれでOK(アカウント登録などは必要)
👼 交代のコストが掛からない
👼 ナビゲーターもコードで示すことができる
👿 IDEとしては貧弱なことが多い
🌏 将来的にはかなり強くなる予感
🌏 準備が少なく済むので、勉強会などでは活躍する
まとめ
本当にしつこいですが、ペアプロは練習が必須です。
今回紹介した「リモートペアプロのフォーメーション」も実際に試してみると良いと思います。
記事が長くなってしまうので、インフラ環境への投資(リモートペアプロにおいて利用するツールや特性など)については別の記事で書こうと思います。
1年かけて「学びがあった」を打破した
本稿は、 DDD-Community-Jp Advent Calendar 2020の2日目の記事です。
1年間継続している勉強会について、自分の言葉でまとめていきます。
勉強会を1年継続している話
#ModelinKaiという勉強会を1年ほど続けています。
およそ1年前に企画して、まさかここまで続く(そしてこれからも続きそうになっている)とは思ってもみませんでした。
最近は「勉強会」というよりも「習慣」という表現のほうが近いかもしれません。
#ModelinKaiをキーワードでまとめる
この勉強会がどのようなものかを説明します。いろいろな挑戦を続けているのですが、次のようなキーワードでまとめることができると考えています。
- テーマや方向性
- 言語化する
- 新しいことを試す
- 積極的に失敗していく
- 興味があるもの
- モデリング
- 設計と実装
- DDD, RDRA, EventStorming
- 勉強会の形式
- オンライン勉強会
- 1回2時間〜4時間、月2回くらいの開催
- モブプログラミング
大きなテーマは言語化！
この勉強会には土台となるテーマがあります。それは「言語化」です。
少なくともこの勉強会を立ち上げた2人(@mohira と @jnuank)には明確な意志がありました。
本稿では、勉強会のテーマに「言語化」を採用した動機と、その実践結果について振り返ります。
動機: 「学びがあった」を打破したかった
勉強会に参加すると、感想をTwitterなどに書くことがありますよね。 あるいは勉強会の中で、アンケートだったりとか、ふりかえりを行うこともあるでしょう。
例えば、このようなツイートはよく見かけるし、自分も書いたりしています。
- めっちゃ学びがあった！
- いろいろ発見があった！
- 参加して良かった！
いずれもポジティブな感想ですね。きっと参加してよかったのでしょう。
しかしながら、その先が気になるのです！ その学びを、その発見を、その良さを聞きたいのです！
「ここをもっと引き出せるようになった方が面白くない？」ということで@jnuankと考えた結果、「言語化」を勉強会の土台に据えました。
結果: 1年経った今、実際に起きた変化に着目する
いかにして「学びがあった」を打破しようとしたか、どういった困難があったかについては一旦棚上げして、実際に起きた変化だけ書いておきましょう。
積極的に参加しているメンバー、特に、私自身には次のような変化がありました。
より具体的に言えば次のようになります。
- 勉強会の内容を自然にツイートするようになった
- ツイート内容の質が変化した。「学びがあった」で終わっていない。
- ブログ記事のリリースが早くなった(1年後の未来に、この記事を書いていることもその変化の1つですね)
もちろん、この変化はこの勉強会だけが理由ということはないでしょう。しかし、当初の目的であった「学びがあったの打破」も実現できていると思いますし、十分に嬉しい変化が起きたと思っています。
次回予告
本稿では、#ModelinKaiの重要テーマである「言語化」と「実際に起きた変化」について振り返りました。
勉強会に限らず、何らかの活動をする上でテーマは非常に大切だと思います。しかしながら、テーマがあれば継続するとは限りません。テーマがあるからといって学びがあるとは限りません。
この勉強会がなぜ学びがある活動なのか。この勉強会がなぜ続いているのか。なぜ「変化」が起きたのか。
次回以降はそれらについてもっと考えていきます。1年続いている勉強会にきっと何か重要なポイントがあると考えています。
ユースケースに対する2つの疑問とその答えを提示するICONIXプロセス
今日はこちらのオンラインセミナーに参加しました。
【8/21(金) 第３回 チェンジビジョンWEBセミナー】 ICONIXプロセスから学ぶオブジェクト指向モデリング
スピーカーは @hirodragon112 さんです。
自分の中の疑問がクリアになるばかりか、新たな課題を発見できてとても良かったです。なにより学ぶための勇気も湧いてきました。ありがとうございます。
ユースケースに対する2つの疑問
さて、ユースケースを学び始めて間もないわけですが、ユースケースに対して2つの疑問があります。
1. ユースケースから実装までの距離は大きい気がするけど、どうするんだろう？
ユースケースは最終的にソースコードで表現されると思いますが、その間の距離が非常に遠いと思っています。 端的に言えば、「(完璧な？)ユースケースだけあってもプログラムの実装はできない」ということです。
これは実体験に基づいています。仲間内で「モデリング会」や「モデリング&実装会」をやっていたりします。大抵の場合「ユースケースを考えよう」という流れで棒人間を書くのですが、なかなか実装まではいかない。あるいは、実装したとしてもユースケースの存在が消えてしまう。
(※ここでいうユースケースは、ユースケースモデルの場合がほとんど。ユースケース記述ではない。)
2. ユースケース自体を検証するにはどうすればいいんだろう？
ユースケースが大事そうなことは(なんとなく)分かりました。
間違ったユースケースや正しいユースケースがあることも分かりました。
ユースケースを使って次の分析や設計を進めていくことも分かりました。
しかし、それだけ大事なユースケースそれ自体の検証がよくわからないのです(自分の研鑽が足りないだけかもしれない)。
なんらかの方法でユースケースを検証できければ、洗練も何もないと考えています。ソフトウェア「工学」なのであれば尚更です。
ロバストネス分析が2つの疑問の答え(になりそう)
今日のセミナーおよびセミナー終了後の雑談タイムでのやるとりに自分の解釈をのせると、「ICONIXプロセスにおけるロバストネス分析はユースケースの検証および洗練に貢献する」です。
これで「疑問2. ユースケース自体を検証するにはどうすればいいんだろう？」は解決の兆しがみえてきました。
また、ユースケースと実装の間に少なくとも1ステップ加わるわけですから「疑問1. ユースケースから実装までの距離は大きい気がするけど、どうするんだろう？」の解決も前進です！
嬉しいポイントとしては、ロバストネス分析のやり方はICONIXプロセスとして手順化されている点です(しかも、それが日本語の書籍になっている！)。
実はロバストネス分析はOOSE本にも書いてある
さて、なんとなーく、「ICONIXプロセス最高！」とか「これから勉強するぞー！」という興奮状態ですが、ちょっとストップ。
ICONIXプロセスの生みの親は、Doug Rosenberg(ICONIX Software Engineering社の設立者) ですが、ロバストネス分析の生みの親は Ivar Jacobsonです(同時に、ユースケースの生みの親でもあります)。
Ivar Jacobsonが著した『オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』(以下、OOSE本)にもロバストネス分析は登場します。
OOSE本で提唱されているプロセスはだいたいこんな感じです。
- 要求仕様書
- 分析プロセス
- 構築プロセス
- 設計 → 設計モデル
- 実装 → 実装モデル(ソースコード)
- テストプロセス
OOSE本にちゃんと書いてありましたね(読む気力が湧いてきますね)。
ちょっと不思議なのは、ロバストネス分析という言葉が本文中にあまりでてこないことです。「ロバストネス(Robustness)」の日本語訳である「頑健」は出てくるのですが。
また、「ロバストネス分析」が索引にないんですよね。なぜだろう。
ロバストネス分析の元ネタはOOSE本(というか、Ivar Jacobson)
『ユースケース駆動開発実践ガイド』の序文にこうあります。
我々が3つの方法論(注: Booch法、OMT、Objectory)の最良の部分を集大成したもの(その数年後のこれらが結合されてUMLとなるわけですが)は、現在ではICONIXプロセスと呼ばれています。 (中略) 顧客に対してこの手法を教えることで経験を積んだ結果、ヤコブソンの手法(ユースケース図、ロバストネス図、シーケンス図)が正しく利用可能ということが明確になりました。
Rosenbergたちが、Jacobson(ヤコブソン)の手法を検証し、再現性のあるプロセスとして洗練させたみたいですね。
そう考えると、『ユースケース駆動開発実践ガイド』を読むことは、OOSE本の検証の理解を深めることにつながるわけですね。これは嬉しい発見。
セミナーに参加してよかった
セミナーは「ICONIXプロセス」が中心的話題でしたが、現在の自分の興味は「ユースケース(use-case)」です。
実は、セミナー参加の目的は「ICONIXプロセスを理解したい」ではありませんでした。本当の動機は「ユースケースを大事にしているICONIXプロセスなるものがあるらしい。では、それ理解すればユースケースのこと理解も深まるかもしれない」です。
今回のセミナーはこの目的を満たしてくれました。この記事を書いているのが何よりの証拠だと思います。
参考文献
- 『ICONIXプロセスから学ぶオブジェクト指向モデリング/ICONIX for Object-Oriented - Speaker Deck』
- 『ユースケース駆動開発実践ガイド』
- 『オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』
他の方のまとめブログ
- ICONIX を使ったオブジェクトモデリング | an Agile Way
- @hiranabeさんのまとめブログです
「ユースケース(use-case)」を理解するために、その歴史をたどる
「ユースケース」って言葉はよく見聞きしますよね。「まずはユースケースから考えよう」とか「ユースケースの洗い出しが甘いよね」とか「あー、あの棒人間と楕円をつないだやつね」とか。
しかし、どうもその実態というか意味がつかめていません。あるいは、ユースケースがもたらす嬉しさや悲しさもあまり体感できていません。ユースケースという言葉の解釈や使い方は、人によってバラバラな気がしてなりません。みなさんはどうでしょうか？
ユースケースはどうやら有用な考え方らしいのですが、どうもしっくりこないんですよね。一方で、これを理解することができたらとても嬉しい気がするのも事実です。ムズムズしてもどかしい。
というわけで、ユースケースについて勉強していくことにしました。まずは、その定義から。つまり、歴史をたどりましょう。
ユースケースの歴史をざっくり
提唱したのは Ivar Jacobson 名前がついたのは1987年
use-case という概念を提唱したのは Ivar Jacobson という人です。1939年生まれで現役バリバリです。
彼が1987年のOOPSLA 1987: Orlando, Floridaというカンファレンスで発表したことで正式に名前がついたようです。
なお、1987年以前から、ユースケースの概念はすでに世の中に知れ渡っていたようです。
World Wide Web の開始が1991年ということを考えると相当な歴史を持っている概念ですね。
1991 年 8 月 6 日の、 Tim Berners-Lee による alt.hypertext 公開ニュースグループへの 投稿 が、公開プロジェクトとしての World Wide Web の公式な開始日と考えられています。
どんどん発展している
Jacobsonの執筆した書籍(共著含む)を追ってみると、use-caseの考え方がどんどん発展していることがわかってきました(書籍以外に論文もたくさん著しています！)。
- 『Object Oriented Software Engineering: A Use Case Driven Approach』(1992年)
- 『Unified Modeling Language Reference Manual』(1998年)
- 『Aspect-Oriented Software Development with Use Cases』(2004年)
- 『The Essentials of Modern Software Engineering』(2019年)
それぞれ日本語版も出版されています。
- 『オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』(1995年)
- 『UMLによる統一ソフトウェア開発プロセス―オブジェクト指向開発方法論』(2000年)
- 『ユースケースによるアスペクト指向ソフトウェア開発 』(2006年)
- 『モダン・ソフトウェアエンジニアリング』(2020年)
それぞれの本をちらっと読んだ感じでは、ユースケース自体の概念を発展させていたり、ユースケースではカバーできないところは別の概念を使ったりしていました。どんどん強力になっていると思うのですが、より複雑になっているのではないかと思います。どういう経緯があるのやら。
逆に言うと、古い書籍は内容がシンプルな印象があります。より純度が高い印象です。
ユースケースを理解したいけど、どうする？
さて、本題は「ユースケースを理解したい！」です。
しかし、何をもって「ユースケースを理解した」と定義すればよいのでしょう。皆目検討がつきません。
そこで、「ユースケースとは○○である」というような文を書籍から拾ってきて並べてみることにしました。これは問題のすり替えでもありますが、現状は何がわからないかも言えないくらいわかっていません。まずは自分なりの解釈を作るところから始めるべきだと判断しました。
また、電子版がないので手作業での発掘ですが、それはそれで楽しいので少しずつ書き足していこうかなと思います。
1. 『オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』(1995年)
p.117
(略) ユーザがシステムを利用するとき、ユーザはシステムとの対話における動作に関する一連の処理を行う。われわれはこのような特別な一連の処理をuse-caseと呼ぶ。
p.142
(略) アクタはシステムの環境を規定し、use-caseはシステムの中で何が実行されるかを表す。
p.144
(略) それぞれのuse-caseはユーザの視点から見たシステムにおける事象の完全な系列である。
p.146
use-caseはシステムが持つ機能のある一部分を実行するための特定の手順である
p.147
アクタはuse-caseの実行を要求しているわけではなく、結果的には完結されるuse-caseの事象の系列を開始しただけである。
p.158 7.2.7 議論 は必見
use-caseを分割するかどうかの議論が載っている。
p.159
すべてのuse-caseは内部事象でなく外部事象から始まるので、(略)
2. 『UMLによる統一ソフトウェア開発プロセス―オブジェクト指向開発方法論』(2000年)
p.155
ユースケースは、システムが結果としてアクターに価値をもたらす機能の「かたまり」です。もっと厳密に言えば、ユースケースは、システムがアクターと相互作用することによって実行できる、代替となるアクションを含んだ一連のアクション（アクションのシーケンス）を指定します。
p.170
(中略) ユースケースが正常に実行された場合には、アクターが目的を達成するために必要な、何らかの価値がアクターにもたらされる必要があります。(略)
p.175 議論 は必見
『オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』のp.158と見比べたいところ。
ユースケースモデルを作成するときのトレードオフ、例えばユースケースを分割するか1つにまとめるか、の議論がある。
p.175
(中略) ユースケースは実行の最小単位であると考えられ、したがって、別のユースケースを開始する前に常に完了しなければならないからです。
参考文献
- 『オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』(1995年)
- 『UMLによる統一ソフトウェア開発プロセス―オブジェクト指向開発方法論』(2000年)
- 『ユースケースによるアスペクト指向ソフトウェア開発 』(2006年)
- 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』(2018年)
- 『モダン・ソフトウェアエンジニアリング』(2020年)
※ すべて翻訳版の出版年。原著はもっと古い。
以上
TDDBCオンライン#01 1人でふりかえり やってよかったこと編
TDDBCオンライン#01 よかったですね！
関わっていただいたみなさんありがとうございました。
運営のコアメンバーの1人として、とてもうれしく思います。
TDDBC初のオンライン開催としては成功と呼んで良いのではないでしょうか。
運営としての残りのお仕事
さて、運営のお仕事はまだ残っています。それは今回開催のふりかえりです。うーむ、どうしたものか。
いきなり集まって「ふりかえりしようぜ！」と宣言するのはカンタンなのですが、話題が散らかってしまったり、共感が集まるだけで、結局モノゴトが前に進まない予感がすごいです(それはそれで楽しいのだけど)。
じゃあ、何をふりかえりましょうか？
そこで考えたのは「次のTDDBCオンライン開催に役立つ情報を残すこと」です。 これは、運営のコアメンバーがやるべきことの1つだと思います。コアメンバーは運営に関する意思決定を行ったり、意思決定の場に同席する回数が圧倒的に多いわけです。意思決定の結果は残りやすいですが、過程の情報は失われがちですからね。
次につながることを書こう
というわけで、運営のコアメンバー1名の視点で、役立つ情報を書き記していきましょう。
記述内容は次の観点で絞りました。
- 「狙いがあってやったこと」を書く
- 狙いがあるということは、そこに1つの仮説があるわけです。仮説があるから、結果の考察により価値が生まれます。
- 「やってよかったこと」を書く
- 多少の改善余地はあるけど、そのまま継続したら良いと思うことを書く。
- 次回やるときに、「この記事にあることはやっておこう」というカタチで使いまわししやすそう。
他の話も書くつもりでしたが、書ききる前に心が負けそうになったのでやめました。 また、改善すべきところは記憶にも残りやすいので、あとからは考えやすいかなと。
というわけで、つらつらと書いていきます。
1. 環境構築会のための準備会を導入した(TDDBC Online は 2日構成 にした)
結論から言うと、絶対にやるべきです。間違いない。
狙いは「本編当日によーいどん！ で TDDペアプロができるようする」ためです。
TDDBCはTDDをペアプロで進めていくスタイルです。ペアプロする以上、環境を揃えたりとか、交代方法を決めたりする必要があります。何より、初対面の人とペアを組むことになるので自己紹介のレベルから始めないといけません。
オフラインの場合は何かトラブルがあったとしても、その場でなんとかできることが多いです。例えば、参加者のPCが壊れてしまっても、運営からPCまるごと貸し出すこともできます。
しかし、リモートペアプロはそうはいきません。マイクが設定とか画面共有の方法みたいなところから丁寧にやらないといけません。特にトラブルシューティングが鬼門です。相手の状況は相手にしかわからないので、時間がかかるし、何よりとてつもない不安感やストレスが襲ってきます。これはとてもつらいです。
「環境構築してたら時間がなくなってしまった。。。」というのはTDDBCの体験として最悪の部類です。それだけはなんとしても避けなくてはなりません。
そこで「環境構築をするだけの会」を設けたわけです。これはオンライン開催の移動コストや参加ハードルの低さのおかげでもありますね。
スライドを見ていただくと何をする会かイメージがつくと思います。 TDDBC準備会 - Speaker Deck
準備会では チェックシート(Googleスプレッドシート) を使って、ペアごとに環境を揃えてもらいました。 項目を見ていただくとわかりますが、「ペアの名前を知っている(発音もセットで)」や「Discordでライブへの参加方法を理解している(他の人の画面共有を見れる)」といったものも抑えています(本当につまづきが多いのです！)
2. 準備会でペアプロのデモをやった
これもやってよかったです。ぜひ続けましょう。
ペアプロのデモをタイムテーブルに追加した経緯はこんな感じです。
準備会でペアプロ環境を構築することに決めた！
↓
ペアプロ環境が構築できたかどうかは、ペアプロしてみれば明らかになる。(チェックシートだけだと検証として弱い可能性がある)
↓
でも、ペアプロ初めての人もいるから、やり方は伝えないといけないのでは？
↓
じゃあ、ペアプロのデモもやっちゃいますか！
↓
せっかくだから、基調講演でカバーしにくいところをやっていこう (※基調講演は主にTDDの話であり、「ペアプロ」の成分は少ないのです。というか、一人でペアプロはできないですからね。)
とても納得できる話だと思っていたし、「アイデアで終わらせてはならない」と思ったので、その場にいたとーます(@grimrose)さんとTakehiro Inoue (@i_takehiro)さんに依頼しました。おふたりとも歴戦の猛者です。TDDBCに関しても詳しく、情熱もあります(結果的に、この人選は大成功！)。
時間のない中、練習を重ねて、とてもクオリティの高いペアプロデモに仕上げていました。すごすぎる。 また、Discordでの意見や質問への回答も凄まじかったですね。とてもよかった。
デモをやる理由と、お題のリポジトリを貼っておきます。
grimrose/tddbc_online_demo_java_junit5: TDD Boot Camp 2020 Online #1 ペアプロデモ
## このデモをやる理由 TDDBCではペアプロで演習を行うことが多い。 ペアプロをやったことがない人が多いので、まずはどんな感じなのかみてもらう。 あくまでもデモなのでこんな感じに出来るといいよというのを伝える 当日はTAもいるのでそこまで不安に感じなくても大丈夫だと伝える ## ペアプロの役割の説明 ドライバーとナビゲーターがいます。 ### ドライバーがやること コードを書いていく。 書いているときに考えていることを口に出してナビゲーターに意図を伝える。 ### ナビゲーターがやること ドライバーがコードを書くのに必要な情報などを伝える 調べ物をしたり、気づいたことを伝える ドライバーからの意図を汲み取って、どのようにコードを書いていくと良いか考えてその意図をドライバーに伝える。 ### ２人でやること お互いが考えていることを口に出して意図を伝え合い、合意をとりながらすすめていく。 役割を切り替えるタイミングを予め決めておく。
ペアプロデモはとても素晴らしく、それだけで価値があるものでしたが、ここで私は最大のミスを犯します。
それは、アーカイブ(録画)しなかったことです。これは私が犯した最大のミスの1つです。非常に悔やまれます。 特に、準備会については、私が中心となって進めていただけに、悔しさはより大きいです。
アーカイブしなかった理由は1つ。それは、恐れです。
「困ったら安全側に倒そう」という意識があったのです。
ペアプロデモのライブ配信のアイデアが無いわけではありませんでした。 しかし、録画や配信の体制を追加することで、肝心のペアプロデモが破綻してしまったらどうするんだ？ という思考になり、アーカイブ案は私の中で切り捨てました。
このあたりは次回は改善できそうです。単純に練習を重ねるか、知見のある人の力を借りれば解決します。
3. リモートペアプロ環境は2つ準備してもらった
これもやってよかったです。ツールは変わるかもしれませんが、2つの手段を用意しておくべきです。 とにかく「ペアプロできなくなった！」という状況を避けるためです。
リモートペアプロの環境として主に3つのやり方があります。
- Push/Pullパターン
- LiveShareパターン
- ブラウザIDEパターン
詳しくは p.36 リモートペアプロの3パターン TDDBC準備会 - Speaker Deck をご覧ください。
また、VSCodeLiveShare で ペアプロする方法(Mac編) - YouTubeで、LiveShareパターンの実演をしているので見てもらうと良いと思います。
このうち、「1. Push/Pullパターン」と「2. LiveShareパターン」の両方を準備してもらいました(準備会で終わらなかったペアは本編までにやってもらいました)。
実際、これは正解でした。
当日に、あるペアのAさんの環境が壊れる事象が発生したのです。
現象をざっくり書くと、
Aさんの環境で、テストが回せない → ドライバー交代できない → もしかして、LiveShareならいけんるんちゃう？ → LiveShareで何か詰まった → どうしよう？ 困ったぞ！
その場での結論は次のようになりました(たぶん、5分くらいで決まったと思います)
- Bさんの環境だけを使う
- Bさんが、ドライバーオンリー
- Aさんが、ナビゲーターオンリー
判断基準は
- 環境構築に時間をかけるよりも、今ペアプロやれることを大事にする
- 役割は、後日入れ替えて楽しんじゃえばええやん！ → 実際に、現在予定しているようです！ すばらしい！ → 日程も決まって、みんなでやることになりました！ すごい！
4. 「2TA -> 3ペア」フォーメーションを採用した
これも良かったと思います。次回もそのまま採用して良いと思います。
オフラインとの最大の違いは、「なんとなく様子を見る」ってのができないことです。
オフラインであれば、画面を覗き込まなくったって色んな情報が手に入ります。例えば、
- 明らかに詰まっているっぽいワードがなんとなく聞こえてくる
- TAがつきっきりなペアがなんとなく視界に入る
- 全然コミュニケーションできてないのがなんとなく感じられる
- たのしそうに進んでいる感じがなんとなく感じられる
リモートの場合は、1度に手に入るのは僅かな情報であり、しかも積極的に情報をとりにいかないと分からないのです。
- 1TA -> 1ペア
- これは安定のパターン
- でも、もうちょっとTAを活用したくなる
- 1TA -> 2ペア
- 一応回せそうではあるが、リモートペアプロ練度に大きく依存する
- また、一方のペアでトラブルってしまうと、、、／(^o^)＼
- 2TA -> 3ペア
- ちょうどよさそう(未検証でしたが、実際やってみた感じでは機能していたと思う)
5. 参加人数はTAのキャパシティから決めた
これも継続採用で良いと思います。
今回の運営判断で重要視したのは、参加人数の最大化は目指していないという点です。
また、迷ったら安全側に倒すという意思決定基準も作用しています。
「もしかしたらもっと多くの人を参加しても成り立つようにできるかもしれないが、それよりも確実にカバーできる範囲でやっていきましょう！」と、なりました。
初のオンライン開催の負担は大きいものでしたが、続けていけばコストはきっと下がります。であれば、確実な開催を何度も何度もやるほうが良いと思ったというわけです。 (この記事もコストを下げるために書いています！)
6. 申込時段階で使用するプログラミング言語を固定した
これも継続で良いと思っています。
この決定をしたのは「ペア決めの煩雑さを避けるため」です。
この狙いは成功したと思います。 実際には、ペアの片方が欠席してしまい、別言語でのペアに組み換えということもありました。
却下となったアイデアもあります。 「第N希望まで書いてもらって、その後調整する」という方式です。これはオフラインでやっていた方式です。
オフラインはなんとかできるのですが、リモートは何とかならないのです
7. 申込みは申込日時を公開した上で、先着順での当選にした
ここも継続してよいと思います。
不採用にしましたが「抽選方式」というアイデアもありました。
抽選方式にすると、ペアが成立しなくなるか、ペア決めが煩雑になります。
ランダム抽選にした場合は、言語の偏りがでたり、TAでフォローできないパターンになる可能性があります。
ある程度介入した上での抽選みたいなこともできますが、これは結局、運営負担が増えるだけです。
こういった理由もあり、「申込日時公開+先着順」としました。
8. 参加費を有料(1000円)にした
1000円が高いか安いかの議論はさておき、次回も有料にすべきだと思います。
実は、今回の開催は0円です(当然、人件費を除きます)。
詳しい収支報告は松岡さんがきっと書いてくれます → tddbc/tddbc-online-earnings-call: TDDBC Onlineの収支報告を記録します
じゃあ、無料でもいいのでは？ という人もいるかも知れませんが、無料にすべきではないと思います。
理由は2つです。
- 無料にすると、キャンセル率が高くなりがちだから(申し込みコストが0になるので、とにかく申し込んだほうが得になってしまう)
- 今後、利用するツールを有料化する可能性があるときや、招待講演などをする場合にプールされている資金があると便利だから
9. 行動規範(CoC; Code of Conduct)を導入した
こちらも継続で良いでしょう。内容に関しては随時Updateしておけば良いと思います。 tddbc/tddbc-online-coc: オンライン開催におけるCOC(ConfcodeOfConduct: 行動規範)
参考とした資料もいくつかあったと思います。例えば、さいきょうのCode of Conductを求めて - ものがたりです。 (@nakasho_devさんに聞かなくては。)
CoCを担当していただいた @nakasho_dev さんの振り返りブログはこちら。
10. 自己紹介スライドを導入したこと
これもぜひやりましょう。
TDDBC online 1st自己紹介スライド - Google スライド
どこまで役立ったか測定が難しいところもありますが、やっておいて損はないところだと思います。 アイコンを1つのスライドにまとめたり、移動の指示がとても楽になります。
アイコン収集は @shibatea365さん と @消しゴムうまこ さんのおかげです。 (お二人には影で相当な協力をいただきました。これもいずれちゃんと書かねば)
11. YouTubeLiveでモデレーターを導入した
基調講演のかたちがどうなるかはわかりませんが、Live配信をするならやるべきアイデアだと思います。
基調講演のYoutubeLiveでは「モデレーター」という役割を @yattomさん と @PoohSunnyさん のお二人に当日お願いしました。 (より正確には、お二人の立候補です)
依頼内容は2つです。
- コメントでの質問で対応可能なものがあれば、コメントで回答してもらう
- 補足などがあればコメントしてもらう
(「モデレーター」と命名しましたが、「副音声」という表現がより良い感じがしています)
モデレーターの背景はちょっとややこしいので説明します。
まず、基調講演の配信構成は次のとおりでした。 (より詳しいフォーメーションは、別の記事で書きます。きっと。)
- TDDBC参加者は Zoomでの視聴 + Discordのチャットでワイワイ
- それ以外の人は、YoutubeLiveの視聴 + YoutubeLiveのコメント欄でワイワイ
また、事前の取り決めとして次を定めていました。
- 質問はコメントのみで行う(Voice参加はなし)
- 質問はベストエフォートで拾う(全ての質問への回答を保証しない)
- 拾い上げる質問は TDDBC参加者の質問(Discordでの質問) を優先する
カンタンに言うと、TDDBC参加者を優先したわけです。
しかし、YoutubeLiveでの視聴者も相当な数(500名以上)が見込まれていたし、YoutubeLiveでの体験をより良くできるならすべきだろうという判断でした。 (モデレーターのアイデアは、おそらく@t_wadaさんのアイデアだったと思います。忘れてしまった。)
これが経緯です。
結果、大成功。
一度動画を見た方も、コメントに着目してもう一度見てもらうと発見があると思います。 (TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング - YouTube)
#tddbc 当日はライブコーディングで手一杯で YouTube Live コメント欄の質問に対する回答は @yattom さんと @PoohSunny さんに全面的にお任せしていたのですが、動画アーカイブに残ったコメント欄のやりとりを見ているとお二人の回答が素晴らしすぎて目から汗が出てきます……
— Takuto Wada (@t_wada) 2020年8月3日
アーカイブされることを考えると、YoutubeLiveのコメント欄を盛り上げたり、より意義のある情報を残すのは良いと思いました(これは、あとになって気づいたことです)。
もちろん、Discordでのやり取りも大盛況でした。純粋なワイワイだけでなく、具体的な質問やその回答が行われていました。すばらしい。
まとめ
「次のTDDBCオンライン開催に役立つ情報を残す」ために「狙いがあってやったこと」のうち「やってよかったこと」を「11個」書き出しました。
狙ってやったけどイマイチだったことや積極的に改善したいこと、次回は止めたいことはまた別の記事で書きましょう。
