Open92

アドベントカレンダーネタ

1日スプリントが良さげな話

2週間くらいやってみたけど、
デイリーをただ強化しただけって印象が強かった。

でもプランニング自体はうまくなった感じはある

前回のふりかえり

  • すごい効果がでたか、というと、そうでもなかった、という意見が多めだった
    • プランニングのタイムボックスを縮めれば精度はまあ上がりますよね、みたいな話なんですが、それが効果が出たな、とおもっている
    • 頻繁にプランニングという未来に目を向けるタイミングを作ったことで、暫定のスケジュールを立てることができた、とおもっている
  • 特に期待していた、「方向転換のしやすさ」に効果がでていない(タイミングがなかったかもしれない)

今回

  • あんまり効果がでていない(1週間も、1日もあんまりかわらない)となった場合、1週間に戻す、とかを選択肢に改めて入れる

@jnuank
お! これは気になる話!

ふりかえり

1日スプリントによって、作業の合流のしやすさが出た。

なかじまが、月〜水が有休や研修でいなかったときに、木曜日から、スプリントレビュー&プランニングですぐに合流ができるようになっている

  • 無理やり、会話をスプリントレビュー&プランニングという時間を1hほど設けているので、それが良い習慣になっているのかもしれない

  • プランニング自体がうまくなった気がする

あまり、TODO、READYの使い分けができていない。

image

2020/12/17 ふりかえり

  • 1日スプリントは良さげだった
  • 問題点はある(上期にも出てたことも含む)
  • レビューする時間があんまり取れてない問題
  • TODOとReadyがDONEに動かない問題
  • TODOとREADYの使い分け問題
    → 1日スプリントならば、Readyのものをのせるべきなのでは

(知っている人であっても)他の人の連ツイには乗っかりにくいけど、zennのスクラップはわりと乗っかりやすい気がする話

Event Stormingが集約を探すのに良い話。

  • 集約を見つける時に、コマンドとイベントが前後で定まる。
  • ということは、集約が果たすべき振る舞いと、イベントがわかっている状態
  • その振る舞いを満たすための、集約の境界の内部は何か、と考えていく材料が出せている状態

RDRA + Event Storming + よくあるドメインモデル で、コーディング時の視点の切り替えができている話

Python + Django でのDDDの案

ペア勉強会を俯瞰してみようの話。なんで面白いのか謎。

お小遣い帳のQueryServiceの話とドラゴンアーキテクチャ

時刻系の話とMagi系の話を書いて欲しい話

輪読会の意義

  • 難解な本をマルチコアで読み切ること
  • 自身の経験談と結びつけてアウトプットできるようにすること
  • そのアウトプットを聞いて、他の人の自身のアウトプットの助けとなること
  • 本をただ読むことより、他人の本を通じて出てきたアウトプットを訊きたい

Application層のメソッドでは、プリミティブな値を使うのか、値オブジェクトを使うのか。
コードで見比べて、それぞれの良さを書いてみる

Repositoryの場所をユースケースに置くか、ドメイン層に置くのか
図を交えながら、それぞれの良さを書いてみる

勉強会が1年続いた話。そしてこれからも続く話。

  • 「決める」と進む
  • コアメンバーを決める
  • Discordとかmeetとかの周辺ツール
  • 最初のめんどくさいことは決めた
  • テーマを決めていた
    • モデリング
    • 言語化

ADRが面白そうなので、試してみたい話(まだ特にやってない

  • すぐ捨てる話
  • でも、捨てにくい話

打ったら戻る真ん中へ。書いたら戻るモデル図へ。

ふりかえりの意義を感じられない、という人に対して、ふりかえりをターン制RPG(の、自分のターンが始まって、コマンドを入力する前)とたとえたらわかりやすいのではないか、というお話。

みんな、自分のターンの時には敵の体力や、自分のHP、MPを観察してからコマンド入力するはず。

自分のターンになるまでの時間が長ければ長いほど、予期せぬことは起きるし、予測がそもそもしづらい。だから、次の自分の行動を決める(コマンド入力)のも、時間が掛かるし、それが効果的かどうかもわかりづらい。

だからターン(スプリント)は予測可能な範囲で短くなると良いし、観察せずに(ふりかえりをしない)、突き進むと手痛いダメージ食らったり効果的ではない攻撃をしてたりすることになかなか気づけない

ダミーリポジトリのテストはしたが、本物リポジトリのテストをサボって、見事バグにハマった話

オンラインモブプログラミングのテクニック。やっていると当たり前だけど、意外と知見が公開されていないやつ。

  • ツール
  • ルール
  • いろいろ

Pythonで会議室予約ドメインをやったときに、結構いろいろやった話

  • PlantUMLですべて書いて、画像を共有する
  • OratorというORMを使ってみた
  • コミットメッセージが1000行超えていた

https://github.com/ModelingKai/meeting-room-python

Q. なんで1年続いているのか?
Q. なんで習慣になっているのか?

  • 決めてから終わる
  • みんな、人に決めてほしいと願っている

「決めると反対意見が減る」

  • 意思表明を明示的にする
  • 意思決定者を決める
  • 無責任に、人に振る(みんな決めてほしい待ち仮説)

勉強会に参加する人は、能力だったり、意識だったりが高いので、振るとなんとかなる話

日程がある程度固定化されるの大事。笑っていいとも

レギュラー放送は大事

「全員が同意する」は最初から捨てている。

  • 進め方が「上達したから」という話
  • 参加メンバーの代謝があった話
    • 1つのDiscordServerでやっていた
    • 別の勉強会からの流入
    • 代謝というか、外部からの刺激。つまりは、燃料補給

有志の会だからこそ、コアメンバーのパワーが重要

「学びがあった」で終わらない勉強会をつくりたかった。自然と言語化するように行動を変えたかった。

で、色々やってみたら、変わった!!!

これってすごくない?

変わった例

  • 自然とブログを書くようになった
  • 自然とツイートするようになった

など

「学びがあった」を打破したかった

勉強会に参加すると、感想をTwitterなどに書くことがありますよね。
あるいは勉強会の中で、アンケートだったりとか、ふりかえりを行うこともあるでしょう。

例えば、このようなツイートはよく見かけるし、自分も書いたりしています。

  • めっちゃ学びがあった!
  • いろいろ発見があった!
  • 参加してよかった!

いずれもポジティブな感想ですね。きっと参加してよかったのでしょう。

しかしながら、その先が気になるのです! その学びを、その発見を、その良さを聞きたいのです!

具体的な作戦

ひとことで「言語化しよう!」といっても、実際にどんな行動をとればよいかは意外とよくわかりません。

「言語化しよう!」 → 「学びがあった」では何も変わりません。作戦失敗です。

1. 主催者が実践する

言い出しっぺがやってこそ、でしょう。

2. 言語化の「量」を定める

言語化の「質」の定義は非常に難しいですし、「この程度の内容じゃだめだ!書き直そう!」となってしまっては、いつまでたっても出てきません。

そこで、思い切って「質」は捨てて、「量」で定義しました。

具体的には「3ツイートする」と決めました。

3ツイートは次を満たします。

  • 実践可能である
  • やろうと思えばかなりのことは表現できる
  • 「ツイートしているうちに思考が深まる」という現象も狙える
  • ハッシュタグをつくれる → #ModelingKai

3. タイムテーブルに組み込む

「言語化しよう!」から「3ツイートしよう!」になったわけですが、これでも不足です。なぜなら、「3ツイートして初めて完了だからです」

これは、アンケートなんかでもそうですが、「アンケートを書く時間」を明示的にとることで回収率は大きく向上します。

というわけで、ツイートする時間をタイムテーブルにいれました。
(※この、「3ツイートするをタイムテーブルに組み込む」は会がはじまってしばらくしてからは消えました)

1年間継続している勉強会について、自分の言葉でまとめていきます。

勉強会を1年継続している話

#ModelinKaiという勉強会を1年ほど続けています。

およそ1年前に企画して、まさかここまで続く(そしてこれからも続きそうになっている)とは思ってもみませんでした。

最近は「勉強会」というよりも「習慣」という表現のほうが近いかもしれません。

#ModelinKaiをキーワードでまとめる

この勉強会がどのようなものかを説明します。いろいろな挑戦を続けているのですが、次のようなキーワードでまとめることができると考えています。

  • テーマや方向性
    • 言語化する
    • 新しいことを試す
    • 積極的に失敗していく
  • 興味があるもの
    • モデリング
    • 設計と実装
    • DDD, RDRA, EventStorming
  • 勉強会の形式
    • オンライン勉強会
    • 1回2時間〜4時間、月2回くらいの開催
    • モブプログラミング

1年続けているなかでたくさんの興味がある。特に言語化!

この勉強会には土台となるテーマがあります。それは「言語化」です。

少なくともこの勉強会を立ち上げた2人(@mohira と @jnuank)には明確な意志がありました。

本稿では、勉強会における「言語化」をベースとした勉強会デザインについて考えていきます。

「学びがあった」を打破したかった

勉強会に参加すると、感想をTwitterなどに書くことがありますよね。
あるいは勉強会の中で、アンケートだったりとか、ふりかえりを行うこともあるでしょう。

例えば、このようなツイートはよく見かけるし、自分も書いたりしています。

  • めっちゃ学びがあった!
  • いろいろ発見があった!
  • 参加してよかった!

いずれもポジティブな感想ですね。きっと参加してよかったのでしょう。

しかしながら、その先が気になるのです! その学びを、その発見を、その良さを聞きたいのです!

1年経った今、実際に起きた変化に着目する

いかにして「学びがあった」を打破しようとしたか、どういった困難があったかについては一旦棚上げして、実際に起きた変化だけ書いておきましょう。

積極的に参加しているメンバーや私自身には次のような変化がありました。

  • 言語化の速度が高まった
  • 言語化の精度が高まった
  • 正しく議論できるようになった

より具体的に言えば

  • 勉強会の内容を積極的にツイートするようになった
  • ツイート内容の質が変化した。「学びがあった」で終わっていない。
  • ブログ記事のリリースが早くなった(1年後の未来に、この記事を書いていることもその変化の1つですね)

もちろん、この変化はこの勉強会だけが理由ということはないでしょう。しかし、十分に大きな変化が起きたと思っています。当初の目的であった「学びがあったの打破」も実現できていると思います。

あなたの副作用、どこから?

まずは細かいこと考えずに、入出力とビジネスロジックを分離すると見えてくるものがあるのではないか

エヴァンス本の10章、副作用のない関数のお話。

  • オンライン勉強会の参加の心構え
  • オンライン勉強会を開催の心構え

なんだったら、どっちかのターゲットにしたYoutube公開するような勉強会できるのでは?

オンラインのワークショップ形式みたいな感じで。
1on1ワークショップみたいに、話す2人組と、それを観察してフィードバックする人、1人みたいな

事業の変更はどこから来るのであろう。

ソフトウェア・システムアーキテクチャ構築の原理28章から読み解いていく

これはアドベントカレンダーというよりは個人ブログ行きになりそうかな

商品、単品、という言葉をひとまとめにするんじゃねぇよ問題。

おまえら、「商品」で一纏めにできると思うのか? から始めて、

データモデリングのお話

まとめようと思ったけど、まとまらないやつ

「勢いの勉強会」からの卒業を目指した話。

もうちょっと計画的に行きたかった話。

狙いがほしいんじゃ!

しかし、現実は、「なかじまさん任せ」だったかも

予算と自覚する話。

コインに変換して、没収するスタイル。

・他人の力を借りる
・モブプロAugmentation
・教育的効果
・しつけ
・言われる方もすごい、同じ相手に同じことを熱心に言いづける方もすごい

達人プログラマーはメモから生まれた話に感動した話

2種類の視点を取り入れたモデリング手法(または失敗の記録)

  • 伝えたいこととして
    • ユースケース図と概念モデル図を書いておけば、なんとかなると思ったけど、あんまりなかった

      • モデルが駆動してない、息してない
    • これ一本! じゃ、実は難しかった

    • 異なる切り口のモデルを2種類(もしくは、それ以上)組み合わせることによって、視点の切り替えがしやすいし、そのモデルの整合性を取ろうと努めておくと、ズレたときに違和感が覚えやすい。

まずは失敗の話して

Event Storming 単品で失敗の話

- 紫のHotSpotがよかった

RDRAとEvent Stormingを併用して、

- 違和感のセンサーが高まる

違和感センサーが高まったの?

  • 2種類のモデルをいったりきたり、そのところで整合性を保とうとした
    • モデルに立ち返る頻度も高まった

RDRAとEventStormingが絶対の解ではありませんよ

  • なんかおかしいな? とか、歪さを感じ取るためにの情報は、その時々で違いそう

    • 違和感の元
      • 各モデルの整合性が取れてない感
      • 重なりあうところが、変にズレっている
        • Aという図には、あるが、Bという図には出てこない用語とか。
      • コードに落とし込んだ時に、なんか違和感。
  • エンジニア第六感

  • その現場で最適なものをえらぶとよし

  • 紙に書いたときに、あっとなる

  • なぜ違和感を覚える頻度が高まったのか?
  • なぜ違和感を覚えた時、まず「モデルに戻る」という選択をするようになったのか?

・爬虫類脳(『達人プログラマー』p.246)
・知覚できない。しかし、見過ごしてはいけない
・違和感センサー

練習すると、うまくなる

  • ラーニングアニマル集団
  • 心理的安全性は個人の認識

IDDD本輪読会の辛さ

  • テキストにサマリーをしようとするのが辛かった

    • コードのコピペ
  • 質問を捻出するのが辛かった

    • あのときは感想、気付きだけはなかった。
  • Connpass募集してなかった

    • コミュニティ募集してなかった。
  • 意見を出すハードルを作る

    • ラジオスタイル
    • タイムキープ
      • 喋っている時に、時間を気にするのが大変
      • アナログタイマー大事
  • 縛りがなくなる

最低限こういう人がいると助かる

  • タイムキープ役
    • アナログタイマー
    • アラーム
  • 司会役
  • 書紀役

オンラインでのコミュニティでの広げ方

  • リアルタイムではTwitterに書いてある
  • でも、オンラインだとDiscordやZoomのチャットで閉じてしまうことが多くて、リアルタイムで外部SNSにタイムラインが流れるのが減ってしまう
    • 参加していない人にとって気づきにくい。
    • 閉じたイベントになってしまう
    • 今後の課題

各レイヤーの責務の捉え方の違い

モデルの不吉な臭いみたいなのを感じたいくつか

・名前
・関連線がめっちゃ引かれている
・1つのモデルに対して、めっちゃメモ、但し書きが付いているのが、ルール持ち過ぎじゃないかね。という話

Event Storming とか ユーザーストーリーマッピングとかの時系列系のモデリングでは、順番に口に出していってその間に抜けが無いかどうかをウォークスルーすることによって、違和感を抱くことができる。

違和感を覚える = 無意識下のモデルと眼前の様相の不一致を近くする、説で結構説明できそうな気がしてきている

無意識下で整合・統合されていると認識していたものが実は整合されていないと発見されたり、あるいはその整合・統合を成立させるルールが発見あるいは言語化されたり、という時にEvansの言う「ブレイクスルー」が生じるのかもしれない

無自覚のメンタルモデルと、思考上の自覚的な知識 (概念的モデル) と、強い制約下でそれを書き表したモデル図は、だいぶ違いがあると思ってて、その差異が大きかったり、重要なポイントの対応漬けがしにくかったりすると、違和感を感じるのでは

デプロイ済

どこで、不吉さの言語化。

ウォークスルーをする、という体。

デプロイ済み

リモートペアプロ インフラ編

たぶんいいたいこと

ペアプロは練習が必要! 練習すると、うまくなる(練習しないとへたっぴのまま)

でも、どういうフォーメーションがいいのかよくわからんよね。

なので、最初にやるときのフォーメーションを提示する

一番避けたいこと

練習が必須。何度か練習が必要。

そうしないと、ペアプロ体験の悪さから、「ペアプロは良くない」という思考になっちゃう。
(本当、ツールや環境、練習経験の少なさが原因なのに!)

フォーメーションというか、要素

  • ソフトウェア

    • 音 ← どのツールもあんま変わらん
    • 画面共有 ← 最重要! ソフトウェアの違いがでるところ
      • シングルシェア → Zoom
      • マルチシェア → Discord / GoogleMeet
    • チャット
      • Zoomは貧弱なのでアウト
      • Discord / Slack / Teams / GoogleDocs などはご自由に。
  • 交代手続き

    • Live交代 → VSCodeLiveShare
      • TODO: 動画貼る
      • Intelij の codeWithMe はまだまだこれから感
    • Push/Pull方式
      • おすすめ。交代がストレスになるなら、Liveにすればいい。
  • ハードウェア(物理的な環境?)

    • 安定したインターネット環境 ← もはやこれはリモート作業における前提
    • ディスプレイ ← かなり重要
    • そこそこ重要。いいものを使いたい。しかしながら、上記2つに比べればわりとなんとかなりそう。ノイズキャンセリングとかはソフトウェアパワーでなんとかなる感じの要素も多い。
      • マイク
      • イヤホンやヘッドホン
      • カメラ

具体的なフォーメーション

結局どうするのがいいの? という話。

★★★★★ Push/Pull パターン

やり方

  • 開発環境は各自のマシンで好きなものを採用する
  • 交代する際には、Push/Pull を行う
  • ドライバーの画面を共有しながら進める
    • GoogleMeet は 複数名の画面共有が同時にできるので非常に快適!
    • Zoomは共有される画面の切り替えが手間なので、おすすめできない(自分は耐えられなかった)

一言: 「交代するために Push/Pull が必要」はマイナスばかりではない

たしかに、Push/Pullするのはちょっとだけ手間と時間がかかる。きっとそれは、オフラインにおけるキーボード交代や、同時編集よりは手間。

でも、別の見方があるし、個人としてはむしろメリットだと捉えています。

それは「交代時に Commit が必要となる」から。絶対に Commit するので、振り返りの回数が自然と多くなる。

  • 「えっと、何をやったんでしたっけ?」
  • 「次は何をするんだっけ?」
  • 「○○という発見があったよね」

普段はあまり省みることが少ない(であろう)コミットメッセージさえもペアプロするのである!

ただし、万人にとって良いかというと、経験上は微妙なところ。

  • コミットメッセージを煩わしいというマインドセットだと、ただのマイナス要素になる
  • コミットログが多くなっちゃうのイヤ
  • 中途半端なコミットログが恥ずかしい感じがちょっとある(昔はあった

👼 各自の開発環境(IDEやエディタなど)が使えるのでストレスが少ない
👼 相手のツールの使い方を見て学べる
👼 GitHubに慣れていればスムーズ

👿 交代するのに少し時間がかかる(賛否あり)
👿 指摘がちょっと面倒なときがある(カバー可能)

🌏 GitHubが落ちてもGitLabやBitBucketで回避可能

★★★☆☆ LiveShare パターン

やり方

  • Visual Studio か Visual Studio Code を用意する
  • ソースコードを管理する人を決める(ホストとする)
  • ホストがテストプロジェクトを用意する(GitHub からクローン or 0からプロジェクトを作る)
  • ホストは LiveShare のリンクURLを発行する
  • ゲストに Discord でリンクURLを共有する
  • 交代するときはゲストが LiveShare したままコードを書く(=交代のコストが0)

👼 交代のコストが掛からない
👼 ナビゲーターもコードで示すことができる

👿 自分の使い慣れた環境ではないのはかなりのストレス(逆にいうと、揃えたら無敵)
👿 ホスト側の環境での作業になる
👿 たまに動きが怪しい時がある

🌏 実はLiveShareでの通話もできる
🌏 Follow機能がすごい

★★☆☆☆ ブラウザIDEパターン

👼 ブラウザがあればそれでOK
👼 交代のコストが掛からない
👼 ナビゲーターもコードで示すことができる

👿 IDEとしては貧弱なことが多い

🌏 将来的にはかなり強くなる予感
🌏 準備が少なく住むので、勉強会などでは活躍する

  • ブラウザIDEの例
    • AWS Cloud9
    • repl.it

ツールざっくり評価

Zoom

  • 基本
    • ビデオはかなり強い
    • チャット機能は貧弱すぎる(Slackとか使おう)
    • 画面共有の切り替えコストが高い
  • その他
    • そのまま録画できるのが強い
    • そのままYoutubeLiveができるのも強い

Discord

  • 基本
    • 音声の品質が高い(と思うけど、他のツールで困ったことはあまりない)
    • マルチシェアが強い
    • チャットもいい感じなので、開発環境以外はこれ1本でいい感じ
  • その他
    • 無料プランだと、解像度がきつい
    • 無料プランだと、画面共有への参加(ライブへの参加)人数の制限があるので、大人数のイベントには向かないかも

GoogleMeet

  • 基本
    • マルチシェアが強い。大きく表示できるのは1画面のみだが、見るほうが好きに選べるのはいいと思う
    • チャットは貧弱。
  • その他
    • 有料にすると、いいことがあるかも? わからん

ブラウザIDE

AWS Cloud9 https://aws.amazon.com/jp/cloud9/

  • AWSに慣れている人はいいと思う。
  • AWSの他のサービスとの連携も強いっぽいので、良さげ

repl.it https://repl.it/

  • そっこーで環境作れるので、はじめてのペアプロ勉強会みたいなのにはかなり向いていると思う

リモートペアプロ、初めてみませんか?

先日の勉強会(アートオブアジャイルデベロップメント読書会 #2 - connpass)

ペアプロ(ペアプログラミング)は、XPのプラクティスとしても有名です。近年では、モブプロ(モブプログラミング)もかなり広まっていますね。

この読書会のテーマは「アジャイル」です。そのため、アジャイル開発を実践したり、興味がある人が参加者の属性として多いわけですが、そのなかでもペアプロをやったことない人が多くいました(これは、とても意外!)。

ペアプロを始めるにあたって考慮すべきことはいくつかあります。

例えば、ペアプロのやり方やペアプロに必要な環境の構築方法、どうやって雰囲気を作るか、業務でペアプロを導入するための工夫などです。

どれも大切なのですが、この記事では、初めてペアプロ(特に、リモートペアプロ)をするときに意識すると良いことと具体的な構成について紹介します。

特に、これからペアプロを始めようと思っている方の支援になればと思います。

リモートペアプロ、始めてみませんか?

先日の勉強会(アートオブアジャイルデベロップメント読書会 #2 - connpass)

ペアプロ(ペアプログラミング)は、XPのプラクティスとしても有名です。近年では、モブプロ(モブプログラミング)もかなり広まっていますね。

この読書会のテーマは「アジャイル」です。そのため、アジャイル開発を実践したり、興味がある人が参加者の属性として多いわけですが、そのなかでもペアプロをやったことない人が多くいました(これは、とても意外!)。

ペアプロを始めるにあたって考慮すべきことはいくつかあります。

例えば、ペアプロのやり方やペアプロに必要な環境の構築方法、どうやって雰囲気を作るか、業務でペアプロを導入するための工夫などです。

どれも大切なのですが、この記事では、初めてペアプロ(特に、リモートペアプロ)をするときに意識すると良いことと、具体的な構成について紹介します。

特に、これからペアプロを始めようと思っている方の支援になればと思います。

伝えたいことは2つ

伝えたいことは次の2つです。

  1. ペアプロは練習すると、うまくなる。練習しないと、へたっぴのまま。
  2. インフラ環境への投資はとっても大切。(← 詳細は別記事で)

ペアプロは、とにかく練習です。同時に環境への投資も重要です。

それらをろくにせず「本番業務をすべてペアプロでやりましょう!」みたいなことをするのは相当にリスクが高いです。

さらに最悪なのは「ペアプロ自体が役に立たないもの」と思ってしまうことです。

ペアプロの練習不足やペアプロの環境不備 → ペアプロ体験が最悪になる → ペアプロが悪いものだと認識してしまう(練習と環境整備をしていればそうはならなかったかもしれない!)

3つの具体的なフォーメーション

練習をしましょう。しかし、実際にどのように練習すればよいのでしょうか。

ここでは、具体的な構成について説明します
(交代するタイミングや、ペアプロのコツなどについてはまたいずれ)

★★★★★ Push/Pull パターン

やり方

  • 開発環境は各自のマシンで好きなものを採用する
  • 交代する際には、Push/Pull を行う
  • ドライバーの画面を共有しながら進める
    • GoogleMeet は 複数名の画面共有が同時にできるので非常に快適!
    • Zoomは共有される画面の切り替えが手間なので、おすすめできない(自分は耐えられなかった)

嬉しさとツラさ

👼 各自の開発環境(IDEやエディタなど)が使えるのでストレスが少ない
👼 相手のツールの使い方を見て学べる
👼 GitHubに慣れていればスムーズ

👿 交代するのに少し時間がかかる(賛否あり)
👿 指摘がちょっと面倒なときがある(カバー可能)

🌏 GitHubが落ちてもGitLabやBitBucketで回避可能

ちょっと一言: 「交代するために Push/Pull が必要」はマイナスばかりではない

たしかに、Push/Pullするのはちょっとだけ手間と時間がかかる。きっとそれは、オフラインにおけるキーボード交代や、同時編集よりは手間。

しかし、個人としてはむしろメリットだと捉えています。

それは「交代時に Commit が必要となる」からです。絶対に Commit するので、振り返りの回数が自然と多くなります。

  • 「えっと、何をやったんでしたっけ?」
  • 「次は何をするんだっけ?」
  • 「○○という発見があったよね」

普段はあまり省みることが少ない(であろう)コミットメッセージさえもペアプロするのです!

ただし、万人にとって良いかというと、経験上は微妙なところです。。

  • コミットメッセージが煩わしいというマインドセットがある場合、ただのマイナス要素になる
  • コミットログが多くなっちゃうのイヤ
  • 中途半端なコミットログが恥ずかしい感じがちょっとある(昔はあった

★★★☆☆ LiveShare パターン

やり方

嬉しさとツラさ

👼 環境構築の負担がホストだけで済む
👼 交代のコストが掛からない
👼 ナビゲーターもコードで示すことができる

👿 自分の使い慣れた環境ではないのはかなりのストレス(逆にいうと、揃えたら無敵)
👿 ホスト側の環境での作業になる
👿 たまに動きが怪しい時がある

🌏 実はLiveShareでの通話もできる
🌏 Follow機能がすごい
🌏 IntelliJの公式プラグインもある → Code With Me EAP リリース – IntelliJ IDEA Blog | JetBrains

ちょっと一言: 実際に体験してみたほうがよい

  • これは実際にやってみてください(やってみないと分からない)

★☆☆☆☆ ブラウザIDEパターン

やり方

  • ブラウザIDEを使って
    • 複数人数での同時操作ができるサービスが多い
  • ブラウザIDEの例
    • AWS Cloud9
    • repl.it
    • gitpod
    • etc...

嬉しさとツラさ

👼 ブラウザがあればそれでOK
👼 交代のコストが掛からない
👼 ナビゲーターもコードで示すことができる

👿 IDEとしては貧弱なことが多い

🌏 将来的にはかなり強くなる予感
🌏 準備が少なく済むので、勉強会などでは活躍する

まとめ

本当にしつこいですが、ペアプロは練習が必須です。

リモートペアプロのフォーメーションもいくつか試してみましょう。きっと良いやり方が見つかると思います。

記事が長くなってしまうので、リモートペアプロにおいて利用するツールや特性については別の記事で書こうと思います。

コミュニケーションツール: Web会議ツールは何を選択すべきか?

代表的なものとしては次があると思います。

  1. Zoom
  2. GoogleMeet
  3. Discord
  4. MicroSoftTeams

MicroSoftTeams は ちゃんと使ったことがないので評価から除外します。

正直、3つのうちどれでも良いと思います。基本的な部分においては、そこまで大きな違いはないと思います。

使い慣れているのと、録画がとても便利なので、私はZoomを使っています。イベントのときはDiscordだったりGoogleMeetを使ったりという感じです。

特徴をまとめる

簡単に特性をまとめます。

複数人の画面共有 チャットが使いやすいか 録画が楽にできる
Zoom x x(Slackなどで代用) o
Discord o o x
GoogleMeet o x(Slackなどで代用) ^
画面共有の切り替えコスト

DiscordとGoogleMeetは同時に複数人が画面共有することができ、どの画面をみるかを自分で選べます。

例えば、「自分が見ている画面をちょっとだけ相手に見せたいとき」に便利です。Zoomの場合は、ちょっと切り替えが手間です。

1つのツールで完結するDiscord

Discordはチャットも使いやすいので、1つのツールで完結することができます。
このへんは好みの問題でもありますが、ペアプロのイベントするときになんかは「1つのツールで完結していること」の利点は大きいです。

お絵かきコミュニケーション

  • オフライン → ホワイトボード や 付箋 がつかえる
  • オンライン → 無理
  1. Miro → 付箋
  2. iPad → 1人しかできないが、やっぱり絵がかけるのは便利
  3. 他にもあるかも?

モデルの不吉なにおい

  • モデルに出てくる言葉と実装されているコードの言葉が違う
    • 乖離している
  • 名前に対する違和感
    • 時間帯って言葉、時間、時刻への違和感
  • 粒度が不揃いである
  • イベントとイベントのつながりを見出すことができない
    • Event Stormingやユーザーストーリーマッピングなどの時系列で表現する系のやつにつかえるやつ
  • そのモデルに対するふきだしへの違和感
    • 予約は、こういう振る舞いをする。こんなルールを持つ、など
  • ふきだしがいっぱいあることによって、ルールの複雑さ
  • 実装を始めたときのぎこちなさ
    • 予約自身が自分自身をキャンセルするのおかしくない?
    • 予約自身が自分自身を生成するのおかしくない?

おこづかい帳の話を書きたい。

コードが絡むと筆が重い。

「詳細」という概念の扱いがうまくなった。細かく見れるようになった話。

書いていくぞ

書きたかったけど捨てたこと

刺激の供給がつづいていること。刺激があるから飽きない。具体例は、かとじゅんさんとかhiroさんとかの存在。
なんで、この話を削ったかと言うと、そもそも土台があってこその話だと思ったから。刺激は受容体があって初めて意味を持つわけよ。

初期設計

モデリング会は1年続いた。これは紛れもない事実です。

勉強会が1年続くのはスゴいこと

エンジニア文脈での勉強会に限らず、きちんと継続するというのは凄いこと。
自主的な活動が1年も安定して継続しているのはすごい。

しかも、ただやっているだけじゃなくて、多くの実りがある。
具体的の収穫としてはアドベントカレンダー(当然、ほかにもある)。
DDD-Community-Jp Advent Calendar 2020 - Qiita

主張したいこと: 1年続いたのにはワケがある。

言語化がテーマの会において、この件を考えないわけにはいかない。

注釈: 他の考察はだいたいここにある。モブで書いたよ。 → 「1年間続いたオンライン勉強会」秘伝のタレを公開します - jnuank blog

今回の記事では、オレの意見な!

ポイントは2つ

  1. 初動でポイントを抑えていた
  2. 「情熱家」が存在していた(あるいは、生まれた)

1. 初動でポイントを抑えていた

  1. メインディッシュに集中するための外堀の意思決定を独断で決めまくった
  2. 勉強会それ自体の初期設計を行った

2. 「情熱家」が存在していた(あるいは、生まれた)

情熱家はそれを表に出さない。心に秘めている。それが生き方に表れてくる。粘り強さ、気概、真剣さ、すべてをなげうって没頭する姿勢といった情熱家の資質は、履歴書でははかれない。また必ずしもすでに成功しているとは限らない。何かに本物の情熱を抱いている人は、最初はうまくいかなくても努力を続ける。情熱家に失敗はつきものだ
エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル,ラリー・ペイジ. How Google Works (Japanese Edition) (Kindle の位置No.1817-1820). Kindle 版.

1. 初動でポイントを抑えていた

勉強会の初動が良かったと思っています。

具体的には

  1. メインディッシュに集中するための外堀の意思決定を独断で決めまくった
  2. 勉強会それ自体の初期設計を行った

1. メインディッシュに集中するための外堀の意思決定を独断で決めまくった

勉強会の初期段階は、決めなくてはいけないことが多いです。

  • 何を題材にモデリングをするか?
  • いつやるのか?
  • どこでやるのか?
  • タイムテーブルはどうするのか?
  • プログラミング言語は何を使うか?
  • ツールは何を使うか?
  • 連絡経路はどうするか?
  • などなど

ここが非常に面倒くさいのです。本当に面倒くさい。僕らはモデリングやプログラミングをやりたいだけなのに。

面倒くさいことは長続きしません(今までもそうでした)。しかし、これらの面倒くさいことは決めなくてはなりません

初期段階においてはお互いのこともよくわからないし、互いに牽制しがちです。そうなると、なんとなく黙っている時間が長くなったりします。要するに、決まらない。

そこで、どんなことを実行したかというか、独断での意思決定を繰り返しました。「独断です!」と高らかに宣言しながらバシバシ決めるのです。間違っているとかそういうことは気にしない。勘違いしてはいけないのは、ただの頑固とは違うところです。相手の意見も聞くし、取り入れる。前言撤回もいとわない。そのかわり、迷う場面ではガンガン決める。

意思決定をすると、先に進みやすくなります。なぜなら責任をとらなくていいからです。つまり、面倒くさくないのです。これなら気力も体力も消耗しない。だから、やりたいことにエネルギーを注げる。

2. 勉強会それ自体の初期設計を行った

過去を振り返ってみると、「○○を勉強したい」→「勉強会の開催だ!(参加だ!)」というパターンばかりでした。

つまり、「勉強会」ではなく「何を勉強するか」にしか興味がありませんでした。もちろん、これだけでも十分に価値はあります。しかしながら、同じパターンでは勉強会が継続させられないことは経験的にわかっていました。勉強会が長続きしないということは、継続によってのみ到達できる景色を眺めることができないわけです。

そんなことを考えながら、1日かけて @jnuankと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. 無責任デリゲーション (っ'-')╮ =͟͟͞(責任) ブォン
  • 迷ったら誰か1人に無責任に決断を委ねるべし
  • 多数決はスピードが出ないので、「◯◯さん、決めてください」と無責任に投げる(この委譲に関しては合意している)
  1. ワールドメーカー【俺がルールだ】
  • 誰かが提案したら、いいぞー!と称えるべし
  1. まずは負けてみる(ゴン・フリークス@天空闘技場)
  • 実験なので、率先して間違うくらいの気持ちでいくべし

情熱家はどこからきたのか?

これは最初から情熱家だったのかもしれませんし、途中から情熱家になったのかもしれません。そして、なぜ集まったかの理由はわかりません。偶然かもしれないです。どうやったら情熱家になれるかもわかりません。でも、とにかくそこに居ます。

デプロイ

https://mohira.hatenablog.com/entry/2020/12/21/235559
  • 2時間。4500文字。これは今までより1.5倍くらいの筆効率。
  • 書いててめっちゃ楽しかった。
  • 前日の、モブブロの効果がめっちゃあった。思考のピントが定まる感じだった。
  • いわゆる思考の深堀りができたと思う。頭のなかのイメージと、生まれた言葉の乖離がすくないのはめっちゃ気分がいい。
  • 論旨に関係ない(けど、重要なこと)は、アドベントカレンダーの引用ですべて解決した。
  • ツイートの埋め込みが一番むずかった
  • Zennのスクラップ機能は便利。というか、非常に馴染む。
  • 2時間。4500文字。これは今までより1.5倍くらいの筆効率。
  • 書いててめっちゃ楽しかった。
  • 前日の、モブブロの効果がめっちゃあった。思考のピントが定まる感じだった。
  • 論旨に関係ない(けど、重要なこと)は、アドベントカレンダーの引用ですべて解決した。
  • いわゆる思考の深堀りができたと思う。頭のなかのイメージと、生まれた言葉の乖離がすくないのはめっちゃ気分がいい。
    景色がみれた! のがめっちゃ嬉しい

つまり、1年前の目標を達成したと思う。副産物もいっぱい! 大漁じゃ!

Zennのスクラップが性に合うのは、文章の単体テストがしやすいから

zennのスクラップ機能は単体テストがしやすい。だから、性に合っている。

1500〜4500文字くらいの文章を書くときにちょうどよい感じ。

スクラップのスレッド(?)の1投稿の単位がちょうどよい。これはまるで関数?

ブラウザエディタを使っている場合、一定以上書くと書きづらくなってくる。それが、モジュール化のサイン。長すぎな記述を抑制してくれる。モジュール化を促してくれる。

1つ1つを個別に認識しやすい。1つ1つの投稿が関数という感じがある。

全体を眺めやすい

1つのページにすべてあるから、眺めやすい。ブラウザでの検索も使える(wikiとかBlogサービスだとここがむずい)

眺めやすいから、組み替えやすい。

デプロイした状態をすぐに確認できるのはよい

デプロイした状態をすぐに確認できるのはとても助かる。とにかく手間が減るから。

パーマリンクも便利

切り出しやすい。Discordとかで渡すときに便利

やっぱマークダウンが使えるのが重要

それはそう。もはや大前提。

もちろん、最終的な統合は必要

それはそう。これは他のツールも一緒。

あと、埋め込みとかマークダウン記法の揺れなんかはやむなし。でもそこまで大きな作業でもないし、まだいいかという感じ。それよりも中身が大事。

リアクションがもらえるので、加速する

このスクラップは2,3人で使っているけど、コメントやLikeがくるとブーストが掛かる。

ツイッターだと、フローによりすぎる感じ。

連ツイもスクラップ機能に似ているけど、Markdownという最終的なフォーマットで記述できない。プレビューもできない(=テストできない)。あと、変更もできない。1つ1つの投稿を意識できるのはツイッターのほうが強そう。

あと、他の人のツイートに目がもっていかれることがあるので、記述するときのエネルギーが吸われるかも?

でも、反応がもらえると、やる気出たり議論がふかまることがある。これはツイッターが強い。

esaだと、ストックによりすぎる感じ。

複数記事に分割すると全体が見えにくい。1ページがながくなると結局見れないのは同じだけど。

また、分割した場合、画面遷移が結構ストレス。時間もかかるし、ブラウザのタブがわけわかんなくなる。

ストックを意識したことを書いたり、複数名で使うには、esaはかなり良し! 特に、技術系の話は検索も便利(はてな は検索が厳しい)。

ログインするとコメントできます