Global Day of Coderetreat 2023 参加記〜forとifがなくてもライフゲームは実装できる！〜
イベント概要
↑こちらのイベントに参加してきました。
Coderetreat（コードリトリート）とは、ソフトウェア設計と開発の基礎に焦点を当て、丸一日かけて集中的に練習することを目的としたプログラマのためのイベントです。"retreat"には「避難所」「保養所」といった意味合いがあり、「期限内に完成させなければならない」というプレッシャーから離れて純粋にプログラミングや設計を練習することに集中できます。
11/3, 4は世界中でこのCoderetreatが行われます。（世界各地の開催場所は以下のサイトで確認できます！）
当日の流れ
09:00 - 09:30 開場
09:30 - 10:00 趣旨説明、準備
10:00 - 11:00 セッション#1
11:00 - 12:00 セッション#2
12:00 - 13:00 ランチ
13:00 - 14:00 セッション#3
14:00 - 15:00 セッション#4
15:00 - 15:30 おやつ
15:30 - 16:30 セッション#5
16:30 - 17:30 セッション#6
17:30 - 18:00 クロージング
くじ引きでペアを組み、45分間ガーッと実装し、15分間休みつつふりかえりをしつつ次のペアを決める。これをひたすら繰り返します。
予め決まっているルールは以下の4つのみです。
当日その場でメモを取るのを忘れていたのでうろ覚えのところがありますが、私が参加させていただいたペアはだいたい↓こんな感じです。（使用言語 - アクティビティ）
- Java - 5分交代でペアプロ
- まずはライフゲームのルールの1つである「誕生」を実装すべく、タイマーを設定して交代しながら実装しました。1セッション目だったのもあり、全然終わる気がしなかったですが、達成感はものすごくありました。
- TypeScript - 1人がテストを書き1人がコードを書くTDD
- TypeScriptのコンソール出力で手間取ってしまい、実装完了はおろかTDDもできていませんでした笑。が、ペアで困難を乗り越えてルールを実装できた時は嬉しかったです。
- Python - for文禁止
- TypeScript - if文禁止
- ライフゲームを愚直に実装すると、①フィールドの境界値判定と②4つのルール判定の分岐にif文やswitch分が現れるのですが、①はトーラスにする（剰余演算でフィールドの端っこを繋げてしまう）のと②は配列の"生存セルの個数番目"に次のセルの状態を保持することで実現できました。
- Ruby - マウス使用禁止
- Python - 絶対完成させる！
参加して得られた学び
- セッションごとに違う言語で実装することもあり、必ずしも自分が慣れ親しんでる言語で実装するわけではないので、お互いに情報を噛み砕きつつ、でも置いてけぼりにしないようなペースで進める必要があります。そのため、かなりコミュニケーション能力が問われるなぁ〜と思いました。
- お互い知ってるお題で知ってる言語だとしても、進め方の違いも出てきます。いろいろな考え方があることを学べますし、勇気と信頼を持って部分的にタイピングの主導権を委譲することで、自分が想定していなかった成果が得られると思いました。
- 3, 4セッション目はお題に慣れてきたのもあってやや難しめのアクティビティ（for文やif文禁止）を取り入れたのですが、最初はできるか不安しかなかったところからペア間の閃きをうまく融合させてなんとか制約下での実装を実現することができました。ゲームの完成よりも制約下で実装できることを実証するほうに重きをおいて一部の実装を諦める方針にしようと最初に合意したうえでちゃんと達成できたのが良かったです。お題はあくまでお題であって、ペアで楽しく実装することが一番の目標！
次のアクション
今回のイベントは自分自身ももちろん大いに楽しめましたし、知り合いにこうしたイベントの楽しさを共有できたので、とても満足のいく1日でした。普段の仕事だとなかなか楽しさに振り切ったプログラミングはできないので、積極的に同僚とかを誘って参加したいと思いました！
評価する人もモブワークに含めたらいいんじゃない？
最近感じた評価に関する違和感
いち会社員として仕事をしていると、定期的に（例えば毎年）評価を受けることになります。
評価のプロセスは会社によって異なるでしょうし、正直僕自身は自分の会社の評価方法について詳しく知りません。（いや知っとけ？）
とはいえ理解してる範囲だと、上司が僕のパフォーマンスとやらを見て、①どうプロジェクトに貢献したのか、②何ができるようになったのかを自らの観察や私へのヒアリングを通してまとめ、評価材料としているようです。
まあ...ここまでは良いんですが、一つ気になることがあります。
それは評価基準が①私個人としてプロジェクトにどう貢献したのか、②私個人として何ができるようになったのかを評価している点です。
②は何ら違和感ありません。個人としての成長を評価する。
私が違和感を抱いているのは①のほうで、プロジェクトへの貢献の仕方が個人単位だということです。ここでいう個人単位というのは、「あなたはどういうポジションで活躍しましたか」「あなたはどのチケットを担当しましたか」を見られてる点です。
上司としては至極当然の評価の仕方だと思う一方、モブワークなどでコラボレーションしている間は評価しにくいことになってしまいます。上司目線では、集まって何かやっているようだが進捗しているのは1つのチケットだという認識になってしまうからです。
これは詰まるところ、積極的にモブワークをすると「あなたはいつも他の人の手を借りている状態なので、個人としてプロジェクトに貢献しているのであると評価しづらい」と上司から言われることになります。
それなら評価される側として次に取る行動は、「できるだけコラボレーションをせずに自分一人で仕事をする」です。だって、その方が評価してもらいやすいのですから。
VUCAの時代なんて言われる昨今、コラボレーションが重要視されるのにこの選択は明らかにおかしいと思います。
モブワークをしている当人たちは誰が何をやっているのか理解している
一方でモブワークをしている当人たちから見ると、モブワーク中に誰が何をやっているか、誰のどのアクションが良い影響をもたらしていたのかは認知できています。「Aさんがファシリテーションしてくれて進んだ」「Bさんのインサイトによって詰まってるところが解消できた」「Cさんの技術的なサポートが助かった」などなど。
つまり、モブワークすると誰が何をしているかわからないのはモブの外から見た話で、モブを構成している人は理解できているのです。（ちゃんと観察すればね）
それなら評価者も一緒にモブワークすれば良いのでは
そうなると出てくる仮説としては、「評価する上司も一緒にモブに参加して作業すれば良いのではないか」というものがあります。
モブに加わればメンバー間でどういう相互作用によってコラボレーションがなされているのかわかり、評価に繋げることができるのではないでしょうか。
そうは言うものの「そんな時間がどこにあるんじゃい」とツッコミが飛んできそうなので予め言っておくと、常にモブワークをする必要もないし、全てのモブワークに上司が参加する必要もないと思います。
主張したいのは、「詳細がわからないから評価できない」とただ突っぱねるだけだとコラボレーションを抑制しかねないので、評価者側から歩み寄る選択肢があっても良いかもしれないですね、ということです。
『テスト駆動開発』モブ写経読書会参加記〜みんなで写経するの楽しいぞ！〜
イベント概要
『テスト駆動開発』という書籍をみんなで順番に音読しながら、コードが出てきたら写経する、ということをしました。
使用ツールは下記のとおりです。
- 音声チャット：Zoom
- メモなど：miro
- 開発環境：Replit
当日の流れ
初参加の人が僕だけだったこともあり、開始時刻になったら全体説明も程々に読み始めました。イベント自体は2時間枠で、最後の10~15分でふりかえりをしました。
順番にドライバー（=音読する人）を回しながら、きりの良いところ、だいぶ読んだなってところで次の人に交代します。今回は23章〜24章を読みました。
事前に書籍の全ページがmiro上に貼られており（出版社から許可を得ています）、読み進めながら適宜気づいたことや感想などを付箋に書いて好きなところに貼っていきます。
気づいたこと&感想
miro上に感想を書いていく進め方がとても良き
メモや感想をScrapboxやmiroに章ごとに書いていくやり方自体はよくありますが、書籍の中身をmiroに貼ることで電子書籍をみんなで共有してるかのような体験を得られました。あとからふりかえったときにみんなの着目点がわかりやすいし、書籍中の文言と感想や関連知識がビッタリ紐づいていて良いなーと。
また、1冊を画面共有してみんなで読むのとは違って、miroだと特定のユーザーの視点を追従する機能があるのが読書会というスタイルに合っていました。同じところを読みたいときは追従し、感想を書くときや読み返すときなど1人で動きたいときは自由に動く。miroの素敵な使い方をまた1つ学んだ気がしました。
運営+常連参加者(?)のファシリテーションが心地よかった
miroにチェックインのための情報が親切に書かれており、初参加でも迷わず事前準備を行えました。また当日も、イベント冒頭から全てを説明するわけでなく、進行の上で必要な情報を非常に良いタイミングで適宜提供していただいたり、会話の中でコンテキストの補足が必要なときにすかさず「今のはこういう背景があってね」と誰かが一言挟んでくれたり、終始置いてけぼりな時間がなかった印象です。もちろんこういうのって感じ方に個人差があるので、真似するときは慎重にやりたいです。
初参加かつ皆さんの話を聞くのが面白かったので僕自身はあまり発言していなかったですが、むちゃくちゃ楽しかったです。
TDDyyχその38参加記〜RでFizzBuzzってどう解くの？〜
イベント概要
下記イベントに参加してきました〜
今回も紀尾井町にあるヤフーさんのLODGEにて開催されました。
当日の流れ
ざっくりこんな感じです。
- TDD、モブプロの説明
- 自己紹介 & チーム決め
- チームに分かれて1回目のセッション
- ふりかえり & 休憩
- 2回目のセッション
- ふりかえり
TDD、モブプロの説明
特徴的なのは、前の人が書いたテストコードをパスするように実装を書いてリファクタリングして、次のテストコードを書いたら次の人にバトンタッチする、これをグルグル繰り返してTDD+モブプロを実践してることです。
あとはワイワイ会の名の通り、テストが通ったり、想定通りテストが失敗したらみんなで拍手して喜ぶ！ワイワイする！
1回目のセッション
全体で8人だったので、4人×2チームに分かれました。
私が参加させていただいたチームではRでFizzBuzzの問題を解きました。「知らない言語」×「知ってるお題」の組み合わせパターンです。
cyber-dojoを使ったので環境構築が不要だったのはとても楽でした。
お題自体はもう何度も解いているものなのですぐに実装を書きたくなってしまう衝動にかられてしまいますが、そこはグッと我慢。TDDのプラクティスである「仮実装」「三角測量」「明白な実装」でステップ・バイ・ステップでテストを書きながら進めました。
Rは大学の講義でちょろっと触った程度なので全く文法などは覚えておらず、チームメンバーの誰一人としてRのことを知らなかったので、みんなして「どうやってfor文書くんだ？」「returnは文じゃなくて関数なのか！」と調べつつ四苦八苦しながら進めたのが面白かったです。
ドライバーとナビゲーターの交代が2周くらいするとチームのリズムができてきて、自然とワイワイするようになってきました。
お題自体は、
をテストできたところで時間切れになりました。「表示すること」のテストまではなかなか到達しなかったです。。。
中間ふりかえり
一旦みんなで集まってふりかえりをします。
感想や気づいたことなどを言い合うのですが、プログラミング言語・お題・TDD・モブプロ・運営・もし自社に持ち帰るなら...などいろんな視点での感想が聞けて面白かったです。
ふりかえりをしたら、少し休憩。各々ご飯を食べたり飲み物を買ってきたり談笑したりしていました。
2回目のセッション
2回目は自分たちの好きなタイミングでゆるゆると始まります。チームは変えても変えなくても良いのですが、私たちは1回目と同じチームでやりました。
次はGoでBalanced Parenthesesのお題を解きました。「知ってる言語」×「知らないお題」パターンです。私自身はGoはほとんど触ったことがないですが、チームメンバーに1人有識者がいるので採用しました。
と、ここでアクシデント発生。cyber-dojoが急に重たくなって、ユニットテストがタイムアウトし始めました。言語やテスティングフレームワークを変えてもだめ。
仕方なく他の開発環境に移ることにしました。今回選んだのはReplit。
テストを実行するために少しだけ環境構築をする必要があり、一瞬苦戦するシーンがあったので、やはりcyber-dojoはTDDyyχで使う上で最適なサービスと感じました。補完もシンタックスハイライトもしてくれないけど。
そんなこんなでお題に取り掛かり始めたのですが、仕様をTodoリスト=テストケースに起こす段階でやや苦戦しました。お題の内容からしてすぐに「（Stackで実装して...）」なんてことを想像できてしまうがゆえに、ステップ・バイ・ステップの最初の一歩をどう記述するかに頭を悩ませました。
結局、Parameterized Testにて [ "(", ")", "()", "()()", "(())" ] あたりをテストしたところで時間切れ。カッコも1種類にしか対応できていませんが、なんとなく序盤のTodoをどう書けばよいのか、その触りの部分の感覚を掴めたとは思います。
1日のふりかえり
またみんなで集まってふりかえりをします。1人1枚ずつ紙にコメントを書きました。
全体の感想
3〜4回目の参加になりますが、毎度違う学びが得られるのでとても楽しいです。
同じ会社のエンジニアリングマネージャー・スクラムマスター・開発者で一緒に参加されている方々もいて、良いな〜とほっこりしました。
TDDもモブプロも大手を振って自チームに導入しようとするとその意義や費用対効果、リスクなどの説明を用意しないとできなさそうなので、自分一人でできる範囲から導入したり、TDDやモブプロという言葉を使わずにしれっと段階的に開発作業に組み込んだりしていきたいです。
スクラムフェス大阪2023参加記〜態度と言葉がチームを良い方向へ促進する〜
参加したイベント
6/30(金), 7/1(土)の2日間オンライン上で行われたスクラムフェス大阪に参加しました！
去年は存在を認知していたものの参加機会を逃してしまい悔しい思いをしたので、今年は早めにチケットを取って絶対に参加すると意気込んでおりました。
セッションスケジュールはこちら↓
Scrum Fest Osaka 2023 - Program Schedule | ConfEngine - Conference Platform
初日は都合がつかずキーノートを聴けていないので、アーカイブを楽しみにしています。
各地方で開催される他のスクラムフェスとは一線を画しているのが、"オンライン限定"という点なのですが、プロポーザルを各スクフェス実行委員のドラフト会議によって決めたり、当日は各地域にサテライト会場が設立されるところがあったりと、始まる前からワクワク楽しかったです。
視聴したセッション
デザイナーの帽子をかぶりながら、チームとの関わり方を考えつづけている話 by ひろみつさん
ひろみつさんのデザイナー像と他のメンバーから期待されている（=前任者の）デザイナー像にギャップがあったので、守破離の守に立ち返ってチームとの関わり方を改善していったというお話をしてくださいました。
- 自分の普段の作業を配信する
- スプリントレビューでは実際にプロダクトを触ってもらう
- チームで同じ本を読む
- リリース後にプロダクトが使われている様子を実際に見る
といったことを通して、段々とチームやユーザーとの距離を縮めていったそうです。
私も今デザイナーチームとの距離について悩んでいるところがあり、「そういえばデザイナーの人たち普段どんな感じで作業してるのか知らないなぁ」と思っていたところだったのでとても興味深かったです。
お互いの歩み寄り大事！
Scrum Fest Sendai 2023 & Scrum Fest Mikawa 2023のプロポーザルを見ながらYYする会 by 及部さん
スクラムフェス仙台と三河にプロポーザルを出した方々に、そのセッションで伝えたいこと、背景にあるストーリーなどをお話してもらいました。
「なんでこのプロポーザルを出そうと思ったんですか？」と直接訊くとプロポーザルを出すに至るまでのとても面白い・しかしプロポーザルに書かれていない魅力的なストーリーが出てくる、というプロポーザルYY会あるあるを観に来ました笑
一番面白かったのは、運営というか話を回す側の方々もいざ自分のプロポーザルについて話すと同じ現象になることです。わかっていてもついついプロポーザルに書けていない部分が出てきてしまうので、やっぱりプロポーザルを一度書いたら他に人に読んでもらって感想を聞いたり色々質問をしてもらうのが良いなって思いました。
観察から対話へ 〜人類学の知恵を借り、よりチームに、自分に向き合おう〜 by Emiさん
人類学とは"わかろうとする活動"である。
例えばチームメンバーや顧客についてよく知ろうとすると、どうしてもまず観察をすることから入ってしまいがちです。しかし、観察ではいつまでも「自分↔理解したい相手」という構図のままなので、時にはどっぷりと相手の普段の日常に浸ったり、ひいては相手の生活や文化について知るとより一層解像度が上がります。
また、誰しも人間は何らかのフィルター=価値観や偏見を通して物事を見ているので、まずは自分にかかっているフィルターがどんなものなのかを理解すると、世界の見え方も変わってくるのかなと思いました。
個人的に↓このページが印象的でした。。。
みんなで試そう！自分やチームの本領発揮を引き出すペップトーク！ by J.Kさん
激励のショートスピーチ、ペップトーク。
- ポジティブな言葉で
- 相手の状況を受け止め
- ゴールに向かうように
- 短くわかりやすく
- 人をその気にさせる
ような言葉がけのことを指します。最近だとWBCの決勝で大谷選手が「憧れるのをやめましょう」と言ったのが記憶に新しいですね。
上手にペップトークをするためのステップとして以下の4つがあるそうです。
- 受容：事実の受け入れ
- 承認：とらえかた変換=ポジティブな側面を見つける
- 行動：してほしい変換=否定語ではなく行動を促す言葉にする
- 激励：背中のひと押し
切羽詰まったとき、ここ一番気合を入れたいとき、日常の何気ない瞬間にポジティブな言葉を投げられるようにしたいなと思いました。
どうする計画駆動型スクラム by Hiraiさん
いわゆるウォータースクラムフォールでは、価値ではなくタスク消化を重視してしまい、プロダクトの方向性の検討や保守性の話をしなくなり、次第に疲弊していくという事態に陥ってしまいます。
そんな状態から脱却するためのステップとして以下のようなことを提案しています。
- スクラムで開発することを関係者全員で合意する。その際に、解こうとしている問題の特性を定性的に評価することが重要です。
- 計画を立てる。具体的には、ユーザーストーリーマッピングやTシャツサイズによる見積もり、バーンアップチャートや3点見積もりをなどのプラクティスを利用します。
個人的には1.の合意のステップをどうやっているのかもう少し具体的に知りたいと思いました。コンテキストに大きく左右される部分だと思うので、もし自社だったらどういうふうな会話になるのか、非常に興味があります。
セッションの前半で計画駆動型スクラムあるあるを話しているとき、参加者の共感がすごくて面白さ半分悲しさ半分のなんとも複雑な気持ちになりました笑
全体の感想 & 明日からの自分にどう活かすか
初めてのスクフェス大阪、完全オンラインかつ各地域に実行委員がいるという特殊なイベントでどう進行していくのか気になっていましたが、川口さんをはじめとする実行委員の皆さんの連携と盛り上げにより、スムーズな進行とともに臨場感を味わえるとても楽しいイベントになっていました！
振り返ると、相手を知る・相手とコミュニケーションを取ることに関連するセッションを中心に観ていたなと後から気づきました。表面的にはプロダクト開発やソフトウェア開発の話をしていても、突き詰めると人間と人間の話に帰着すると思うので、態度とプラクティスの両面から日常をブラッシュアップしていきたいです。
ふりかえりカンファレンス2023参加記〜味変するなら味見しよう〜
イベント概要
4/8(土)にふりかえりカンファレンスがオンラインにて行われました。
今年のテーマは「ふりかえりに味変を」。
ベーシックなふりかえり手法にひと工夫加えたり、自分たちのコンテキストに合わせたやり方に変えたらどうなるかという話をたくさん聞けました！
↓セッション一覧はこちら↓
特に印象的だったセッション
どのセッションもとても良く、終日学びの雨を浴びているような感覚でした。
（休憩時間さえもタイムテーブルに「ふりかえり&休憩」と書いてあるように、マジで1日ふりかえりっぱなしでしたw）
その中でも自分的に強く印象的だったセッションを取り上げます！
『ふりかえり変幻自在』 by やっとむさん
↓発表コンテンツは以下のMiroボードです。↓
Miro | Online Whiteboard for Visual Collaboration
（一部チラ見せ）
ふりかえりとは全く異なる別のものと照らし合わせて因数分解してみたり、どこをどのように味変するか考えたりと、やっとむさんの普段の思考をDeep Diveしているように思わせる、そんなキーノートでした...!!
お話の中で自分にとって印象的だったのは「味変したら必ず味見しましょう」というフレーズです。ここでいう味見とは、ふりかえり手法の一部を改変してみたら必ずその効果を評価し、次にどうするか決めるということです。
まず手法をそのまま実践してみて味見する。そして自分たちのチームとしてどうしたらふりかえりをより良い時間にできるのか吟味して味変する。ほんでまた味見する。その繰り返し。
たしかに料理をするときに味見ってとても重要なことですが、レシピ通り作って満足してしまうときってありますよね。（少なくとも私はそう。味見しようね自分。）
ふりかえりそれ自体をふりかえることって改めて重要だよなと再確認できました。
『こうしてふりかえりは終わってしまった〜ふりかえりが停滞するメカニズムと息を吹き返すためのいくつかの方法〜』 by 小田中さん
confengine.com↓発表スライドはこちら↓
KPTなどのふりかえりで出てくる課題とそれに対するアクションを痛みと効果の2軸でマッピングしたとき、コスパの良い領域（痛みが少なく、効果が大きい）ばかりであることが多く、ふりかえり手法を変えるなどの工夫をしないとそれ以外の課題が出てこないという見解でした。
ふりかえり手法の特徴を分類するだけでなく、課題の方も分類するという視点が私にとっては完全に盲点で、はっと驚かされました。
（加えて、ふりかえり手法がプロジェクトのタイムラインに直結しているかという視点も私にはなかったので思考材料に加えたいと思いました。KPTとかは直結していて、熱気球とかはしていない認識です。）
あともう1つ良い視点だと思ったのは、ふりかえりを健康診断に例えるというもの。セッションを聴く前から私は「停滞したふりかえりは無理に再開させなくても良いのでは？」という疑問を抱いていました。私はふりかえりを継続したい派ですが、それをチームメンバーに打診するほどではないのかなぁと。しかし、はっきりとふりかえりは規模を小さくしてでも継続すべきだと感じました。「病気が治ったからもう健康診断は必要ありません。」って人がいたらマジかよwって思いますよね。
いやぁ、自分がモヤモヤ思っていたところにバシッ!!と活を入れられたような気分です。。。
『誰もが大嫌いな「振り返りと名付けられたアウトプットのない儀式」をhackした』 by African Grayさん
confengine.com
（スライドは公開サービスにアップロードされていないため割愛します。）
報告書として提出するために"儀式"としてふりかえりをしてほしいPL vs プロジェクトをより良くするためにふりかえりをしたいGrayさん、という構図です。
（別に戦っているわけではありません、立場の違いだと思っています。念の為。）
何が印象に残ったって、「あぁ...私もこういう困難を乗り越えていくことになるのだろうなぁ...」って半ば絶望したことです。
大きく分けたら似たような立場にいると私は勝手に想像していて、そのため親近感が湧くセッションタイトルだったので気になって当日聴講したら、当初の想定通り絶望しました。笑
しかしGrayさんはただ嘆くだけでなく、自分がリードを務めるチームからまず変えていく、できる範囲から手を付けているという点がすごいと思いました。
私も自分ができる範囲を見つけて、行動に移します...!!
自分のアクションとしてどう繋げるか
- ふりかえりはこれからも継続し、停滞してると感じたら味変する。
- ふりかえり自体をふりかえり続ける。味見大事。
- （早くマネージャーになって自分がハンドリングできる範囲を広くする。）←将来的に
上記3点は必ず取り入れます！
あと、セッションは2パラだったので裏番組をまだ観れてないです。。。アーカイブが公開されたら追いかけます！
TDDyyχその36参加記〜モブプロやっぱり楽しいわ〜
概要
東京ガーデンテラス紀尾井町のLODGEにて、第36回TDDyyχが行われました！ TDDyyχとは、モブプロでTDD（テスト駆動開発）を行い、わいわいする会です。（意訳）
参加した人がブログ書かない問題について
当イベントの（主に運営に携わる人の）疑問の一つとして、「参加者がブログを書いてくれない」ことが挙げられます。（そんなこと思ってるのは一部だけかもしれませんが。） 非常に楽しいイベントですし、どの参加者からも好意的な感想が出てくるので、甚だ謎ではあります。
個人的には、TDDの楽しさ、モブプロの楽しさ、ワイワイする楽しさなど、楽しさの要因が複合的なので参加者がおすすめしようにもわかりやすく面白さを言語化するのが難しいのでは…と思っています。
自分が今日得た学び
今回組んだチームでは「JavaでFizzBuzz」、「Javaで自販機」の課題を解きました。 その中で、JavaのRecordクラスとValueSourceアノテーションを新しく学びました。
また、メンバーの雰囲気を感じ取りながらどこまでを“三角測量”し、どこからを“明白な実装”をするかを意思決定できたのが良かったと思います！
次やること
自社のメンバーを連れて来たい。。。 この楽しさをぜひとも分かち合いたい。。。
