天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

XP祭りのスライドまとめ

XP祭りのスライドをまとめました。

スライド漏れていたら、教えていただけるとありがたいです!

Takeshi Kakeda - XPの旅 〜 そして全体性へ

confengine.com

www.docswell.com

note.com

amix edcolor - 学生が考える、属人化防止のためにできること

confengine.com

keita yanagwa - エンジニアが新規事業に取り組むところから始めPdMとしてプロダクト開発に向き合う組織を作り続けるまで

confengine.com

www.slideshare.net

Shigeru Tatsuta - アジャイル開発におけるクラフトマンシップの重要性

confengine.com

www.slideshare.net

平鍋健児 - コードと組織の不吉な匂い

confengine.com

Akira Kobori - 本当はむずかしい「計画」のはなし

confengine.com

speakerdeck.com

関連のQiita記事は以下

qiita.com

qiita.com

Kazuki Mori / Takahiro Kaneyama - XR(エクストリームレトロスペクティブ)祭り2022

confengine.com

Yuhei Koito / Junya Miyake - いいチームを作りたい!!〜関係の質を改善するために私たちがやったこと〜

confengine.com

Toshiaki Koshiba - 55チーム・16事業をまたいで高アジリティな活動知見を交換する社内コミュニティ「t-agile」事例と社内コミュニティ作りのキーポイントを解説します

confengine.com

bash0c7official.fanbox.cc

Takaki Sumita - 不確実性に向き合うために、チームのアジリティを高める開発タスクの切り方

confengine.com

speakerdeck.com

Shigeki Morizane - アジャイルな経営(組織運営)のために必要な3つのこと

confengine.com

www.slideshare.net

Eiichi Hayashi - 組織をアジャイルにする共創戦略とは

confengine.com

www.slideshare.net

Tsutomu Yasui - ボードゲーム「チームで勝て!(仮称)」

confengine.com

Eiji Ienaga - XP祭りの中でxUnit Test Patterns の勉強会!!

confengine.com

twop.agile.esm.co.jp

※参加レポートになります

seko satomi - リモートワーク第一世代の若手SE女子がアジャイルマインドで時代の変化を乗り越えた話

confengine.com

やすよ おおの - QAエンジニアが、アジャイルな業界への転職をしてみた(QMファンネル活用の一例)

confengine.com

Tomonori Yamagoshi - 初心者スクラムチームが陥っていた、間違ったスクラムの見積もり方法とそれに対するカイゼン

confengine.com

speakerdeck.com

Masaru AMANO - 日本におけるアジャイル開発の認知度の変遷を情報処理技術者試験の問題から考察してみた

confengine.com

www.slideshare.net

tera hide - 和服を普段着にするようになって気づいたアジャイルの心

confengine.com

www.slideshare.net

Kaori Tobe - 営業職からプロジェクトマネージャーになったら大事にしてたことが全部アジャイルにあった話

confengine.com

Hirano Yusuke / Kei Ogane - スクラム初心者が自分のチームのスクラムに違和感を感じたので頑張った話

confengine.com

Daichi Kushihara - 創業146年の日系大企業でアジャイルを推進するためにボードゲームを作ってみた話

confengine.com

Yamato Naka - to the begining -コミュニケーションスキルを使う前に-

confengine.com

speakerdeck.com

Fumihiko Kinoshita - アジャイルな働き方の本質 〜ドラッカーとXPからの考察〜

confengine.com

speakerdeck.com

Ken Takayanagi / Arata Fujimura / Sakano Nao / Sugii Msakatsu / Takeshi Fukasawa / yasuyuki kamitokusari - 週刊スクラム御意見番:クラスメソッド版 XP祭りスペシャ

confengine.com

dev.classmethod.jp

登壇内容をまとめたブログになります

Junichi Kobayashi / Fu-ga kkbn - オンライン時代のペアプログラミング

confengine.com

speakerdeck.com

Takefumi Iseki - プロジェクト開始時点からテストを考えることの勧め

confengine.com

Masahiro Sato - KPTに慣れたチームが、よりよい振り返りを行うために、K / P / T のそれぞれにフォーカスをあてた考察(それぞれは、何でないかの考察も添えて)

confengine.com

speakerdeck.com

takashi matsuyuki - オーナーシップを持ち自己組織化するチームに必要な、Engineering Program Managerという役割

confengine.com

speakerdeck.com

Ryosuke Sugiyama - 小さなユーザーストーリーのすゝめ ~的確な進捗把握~

confengine.com

speakerdeck.com

Yuta Yasugahira / FUJITA kazuhiro / Sho Kurogi / Takashi WADA / Takayuki FUJITA - 両方読んでみてわかった!XP初版と2版からの学び

confengine.com

speakerdeck.com

Akiya Mizukoshi - エンジニアからPdMになって苦労している話

confengine.com

上記プロポーザルの中にスライドへのリンクが貼られています。

Sakano Nao - プロダクトオーナーの消失

confengine.com

Yasuhiro Kamoshita - プロダクトのドキュメント更新をチームに根付かせる

confengine.com

speakerdeck.com

Yoshiki Sugiura - 新人エンジニアは3ヶ月でスクラムマスターになれるか? とある企業のスクラムマスター育成レポート

confengine.com

Yuta Yasugahira / FUJITA kazuhiro / Sho Kurogi / Takashi WADA / Takayuki FUJITA - 古くて新しい本の読み方"会読"を体験しよう!XP会読会 出張版 in XP祭り2022

confengine.com

Koichi ITO - 組織のアジリティを向上させるエンジニアリングマネージャーの仕事

confengine.com

speakerdeck.com

aki matsuno - extreme blogging〜680日ブログを書き続けている理由と継続して得たもの〜

confengine.com

speakerdeck.com

Yasunobu Kawaguchi / Yuki Hattori - InnerSource : 内製化の一歩先を見つめるコードの共同所有の取り組み

confengine.com

Taku Fujii - ついに邦訳が出ましたマネジメント3.0のモデル超入門+議論

confengine.com

Hiroaki Matsunaga - 紙飛行機を作らない紙飛行機ゲーム ~人はなぜ反復するのか~

confengine.com

Ken Takayanagi / 蜂須賀大貴 - 公開実験!中埜先生があなたの組織課題に対するフィアレスチェンジの使い方を教えます!

confengine.com

Masataka Mizuno / Makoto Takaesu / Takao Kimura - ゾンビスクラムから回復しよう~継続的改善編~

confengine.com

docs.google.com

Shinya Nakajima / Shin Oymd - ゆるふわTDDモブ

confengine.com

Tatsuya Sato - これが私のXP 〜 eXtreme Punning 〜 変化をウケろ

confengine.com

speakerdeck.com

Keita Watanabe - カオスな状況でぼくを救ってくれた1つのツールと2つの思考法

confengine.com

www.docswell.com

Yukie Kushida - アジャイルを全く知らない人にKPT(A)をやってもらってわかったことのいくつか。

confengine.com

会の参加者むけにPDFで展開。(会の参加者は#登壇資料・参加ブログなどのチャンネルで閲覧可能です)

Ikuo Odanaka - おいしいドッグフードの食べ方

confengine.com

speakerdeck.com

Kei Ogane - 話を引き出す技術

confengine.com

speakerdeck.com

Akihisa Furuhashi - エクストリーム人間観察

confengine.com

www.docswell.com

Abe Yoshinobu - プライベートに振り返りを導入してみよう!

confengine.com

speakerdeck.com

Masanori Kawarada (Mark Ward) - 品質文化試論と『LEADING QUALITY』

confengine.com

speakerdeck.com

※資料は公開されていませんが、発表の初版にあたるスライド(スクフェス新潟で話をしてくれた際のスライド)は残っているので、添付しておきます。

Yusuke Suzuki - サービスブループリントによるシステム設計手法の紹介

confengine.com

www.slideshare.net

Takahiro Kaneyama / Eisuke Tomita / Emi Kobayashi / eroccowaruico ®   - The Ajitama ~パワポカラオケにおいて味玉につなげる技術 ~~

confengine.com

Youichi Takigawa / Toshiaki Koshiba / Tsutomu Yasui / Yotaro Takahashi - ハジメテノアジャイルはなんでしたか?

confengine.com

miro.com

※発表資料ではありませんが、裏で使っていたMiroボードが展開されています。

Shigeki Morizane / Itsuki Morizane - (当時)5歳の初心者YouTuberがみせた経験学習における圧倒的人間的成長について

confengine.com

www.slideshare.net

Hideo Kashioka - オフショアメンバーのいるスクラムで気をつけていること

confengine.com

www.slideshare.net

Takuya Futatsugi - 実践と価値を行き来して理解を深めるXP 〜ストーリー・計画づくり篇〜

confengine.com

LT

資料の順番は適当です。(発表順になっていません)

speakerdeck.com

www.agile-studio.jp

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

スクフェス三河 #scrummikawa のプレゼンを同時視聴したり、アジャイル系の相談したりに参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。

RSGTのプロポーザルをフィードバックしてみる

RSGTにプロポーザルを出したいという方がいたので、その方のプロポーザルを皆で見てフィードバックをしていきました。

すごくいいプロポーザル(ぜひ聞いてみたいプロポーザル)だったので、なかなかフィードバックするのは難しいなあと思いながら聞いていたのですが、会の参加者の皆さんが色々なフィードバックをしてくれて、非常に勉強になりました。
以下、内容は少しぼかしていますが、プロポーザルであったフィードバックを書いていきます。

  • 主語の大きさや単語が指す意味とプロポーザルの内容があっていない
  • タイトルは補足できないので、特に上記のことは意識した方がいい
  • YOWを用いて内容を整理してみると、起きたこと/やったことを混同しているかどうかがわかる
  • 願望を書くなら、願望であることがわかるように書く
  • 新卒や学生という単語は世間に響くのでプロポーザルが通りやすい
  • 会社に発表することは知らせておくべき。もし何かあった時(例えば情報漏洩など)は、取り返しがつかないことになる可能性があるので。

プロポーザルの内容にまつわるフィードバックはもちろんありがたいのですが、会社名を出す/出さない、事前に会社に知らせておく/知らせておかない、あたりの話でも、勉強になるフィードバックが多数あって、自分自身がめちゃくちゃ勉強になりました。

内容に関するフィードバックや、「どんどん話しなよ!」という感じで後を押してくれるコミュニティは多いし、分散アジャイルチームもそういった性質を持ち合わせていますが、適切なところでブレーキを掛けてくれているのはさすがだな、と感じました。

及部さんのXP祭りのLTを見ていく

続いて及部さんのLTを聞いていきました。

至る所で話を聞きたいという方がいらっしゃるので、既に聞くのが5回目なのですが笑、チャットもバンバン盛り上がっていて、セッションをリクエストしてくれたHideさんからも、「及部さんの話をもっと聞きたい」とコメントしてくれていました。

全体を通した感想

その他にも、大人になるとは何か?という話や、生き抜くための戦略の話(主語を大きくしたり、他の生物と比較する...)や自責/他責の話など、深淵な話を多数聞くことができました。

温もりがあって素敵なコミュニティだなあというのを改めて感じました!

アジャイル開発における、さまざまな立場でのリーダーシップに参加してきた

sansan.connpass.com

こちらのイベントに参加してきたので、会で印象的だったことと感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

アジャイル開発」をテーマに、エンジニア、プロジェクトマネージャー、プロダクトマネージャーがそれぞれの立場で実践から得た知見を共有します。  アジャイル開発に関わる方が、自分と同じ立場や異なる立場からのさまざまな視点を得て、明日からすぐご自身の業務に活かせるような発表の場にしたいと考えています。

会で印象的だったこと

LT1〜1on1から始める組織作り〜

Nulabに入りたての中道さんから、自己組織化が進み個々のレベルが非常に高い状態でマネージャ職になった際にどんなことをしていったのか?というお話を聞いていきました。

問題の発見と信頼の獲得をまず最初にしたいと考えた中道さんは、タイトルの通り最初に1on1をしていったということですが、1on1の議事録を(もちろんメンバーの合意を取った上で)組織全体に公開するというかなりチャレンジングな取り組みをされていたので、その結果起こった話を聞けたのは面白かったです。

自己組織化された組織では共通の課題がメンバーから出てくる可能性は低いという話や、メンバーが見つけられていないような大きな課題を探すのが大事だという話は、非常に納得感がありました。

LT2〜越境による、価値を届ける自律的なチームづくり〜

エンジニアがPOへ越境*1することで得られるメリットや、具体的な越境の実装方法を聞いていきました。

実装方法としては、ディスカバリープロセスをリードする「epic大臣」を置く方法を紹介してくれていたのですが、POの負担を減らせつつチームの自己組織化を進める&プロダクトへの当事者意識が高まるような取り組みになっていて、印象的な内容でした。

epic大臣の取り組みも含め、one teamで機能開発ができる大切さ(自己組織化したチーム編成をすること)を改めて実感する発表でした。

LT3〜必要なのはリードであってリーダーシップではない〜

15年以上ウォーターフォールで開発していた大道さんが37歳でアジャイル開発に出会ってリーダシップについて考えたことを聞いていきました。

SanSan(Bill one)では3L(プロダクトリード, テックリード, アジャイルチームリード)という3種類のリーダを立候補制で選んでいるということだったのですが、その中でもアジャイルチームリードに立候補したそうで、アジャイルチームリードで得た経験と学びを聞いていきました。

なかなか話しにくいリアルな失敗談をベースにしながら、ウォーターフォールにガッツリ浸かったからこそ戸惑いがあった部分の話を聞くことができて、元々ウォーターフォールを経験していた自身にとって共感が強い内容になっていました。

Q&A

思惑通りプロジェクト運営ができず終わってしまった場合はどうするか?

中道さん/坂口さん/大道さん御三方ともふりかえりを活用するということで、定期的にふりかえりをしてうまくできなかった問題を分析していくということでした。

(大道さん向け質問)リーダー制が重複した場合は?

チャレンジ精神が多い&周りをサポートする文化が形成されているということで、チーム全員が大道さんのチームではリードに立候補したそうです。

こうした時は、チームの中で誰をリードにするか話し合いをするそうですが、一度落選したとしてもリーダーの道が閉ざされるわけではなく、実際大道さんも2度目の立候補でリードになったそうです。

POやPMに権限が集中しすぎないようにするための施策は?

横串チームを形成しているということです(例えば認証チームなど...)

1on1のメリットや必要性を周囲に伝えるためには?

説明するのではなく、許可を取らずにもう実施する。やってみれば必ず賛同者は現れるはずだと思っている。

ディスカッション

以下、出ていた話を箇条書きで書いていきます。

アジャイル開発で苦労したこと
  • チームの人数がスケールした結果、議論が活発に起こらなくなってきていること。少人数でスクラムイベントが回せるようなチーム体制を敷くようにして対策をしている。また、チーム間の関係性が希薄になってしまっているので、チーム間の1on1を実施している。
  • 人数が増えると、分割していくのにものすごくエネルギーがいる。
  • 正しいチームのあり方が何かわからない。(自己組織化が進んでいる状態だからこそなおさら)
  • 5名->50名に人数が増えたこと。
アジャイル開発のリーダーに必要な資質
  • 何かを決めて動くこと
  • (プロダクトマネジメントの文脈で)何かを決めること
  • 課題を見つけるという意味では、協力関係を築いていく姿勢が大事だと思っている
  • 1on1

会全体を通した感想

バックグラウンドも組織規模なども全然違う御三方の視点からリーダーシップについて話を聞くことができて、楽しかったです。

アクシデントもちょこちょこありましたが、スムーズに運営されていて、参加していてストレスがないイベントでした。運営/登壇者/参加者の皆さん、ありがとうございました。

*1:POの領域とされているディスカバリープロセスからエンジニアが参画する、エンジニア全員がユーザと顔を合わせて会話

【製造業アジャイル勉強会】オンラインOSTに参加してきた

beyond-hardware-agile.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の様子

森さんにXP祭りの自分のセッションの感想を聞く

森さんに、XP祭りで自分が話したセッションの感想を個人的に聞きたかったので、同時視聴を一度した後、色々感想を聞いていきました。
以下、聞いた話を書いていきたいと思います。

  • 惰性と継続していることの違いがある。例えば筋トレでは、「筋肉を意識していると効果が上がるよ」という話がある。(筋トレで一回一回使っている筋肉を意識しているのと、ただ機械的に筋肉を動かしているのでは全然効果が違う)
  • 例えば人の歩行は人によって癖が全然違う。歩くのが綺麗な人は膝から力を入れているが、惰性で歩いている人は歩くのがガクッとなってしまう。どれだけ意識を持って(歩行の例なら膝から力を入れることを意識して)続けられているかが継続の質に大きく関係してきそう。
  • 本当の意味の継続は一度一度の試行錯誤ができていることなんじゃないか、と思う。そうじゃない場合は惰性になるのではないか?と思う。
  • やり始めた時の気持ちを今日もやれているか?とか問いかけてみるといいかもしれない。
  • ゲームはコツを掴めると一気に上手くなるが、一度掴んだコツを維持したままやってしまうと本当の上手い人にはなれない。コツを手放さずにやり続けられる人はゲームを継続しているのではなく、惰性になってしまっている。
  • Zoomの照明が逆光になっていて、映画だと悪役を撮るシーンになっている。
  • 上から下に覗き込んでいるので、カメラは上からではなく斜め上くらいから見れるようにしたほうが良いかも。
  • プロのカメラマンからアドバイスを受けている人の顔の写り方を参考にすると良いかも(プロのゲーム実況者など)
  • 参加者にいきなり期待値を聞くと、ただ聞くだけモードだった参加者が切り替えにくい。もしコメントを瞬発的に書いてくれたとしても、無理矢理捻り出すような形になりそう。(参加者に事前に練習してもらうのが良いかもしれない)
  • 映画のトレーラー(予告編)はいきなり見どころシーンが爆発するので、経緯とか話す前に、参加者に今日のセッションの見どころを伝えると思う。参加者に火を吹き込むようなイメージ。
  • スライドがシンプルになる分、話している内容とスライドのGapが出てくる。このGapには良いもの/悪いものとある。スライドがシンプル+言葉量が多いので聴覚処理が得意ではない人だと、聞いているけど内容が頭に入ってこないとかあるかもしれない。(オンラインだと特に起きがち)
  • キーワードっぽい言葉がするっと抜ける(あまり詳しく説明されない)感じがある。キーワードというのは普段は聞きなれないような言葉。例えば今回なら「写経」とか「紐帯」(専門用語)。話を聞き流しする癖がプレゼンの中でついてしまう。
  • 主題と副題にこだわらず、メインで話している内容を大きくしたほうがいい。今回の「ブログを継続してきた工夫」なら副題を大きくしたほうがいい。
  • 引用する際は、前後に自分の考えを入れておかないと引用の要件を満たしていない。(speakerdeckにはスライドしか表示されない)
  • 敢えて使わないなら「個人的特性」という言葉でなくてもよかったかも。「個人的特性」だと発表者だけの特性が強すぎる。または、抽象化したあるある話(なかなかものって覚えられないですよね。みたいな)
  • 謙遜は入れない方がいい。自己肯定感がない人には嫌味に捉えられる。極端な話、「登壇してるじゃん。もう十分あなたはすごい」となってしまい、話に対する共感が途切れる。
  • 盛り上げるなら、話すコンテンツでというよりは話のペースや抑揚でコントロールしたほうが、聴覚処理が苦手な人でも聞きやすいプレゼンになる。
  • 表紙の上に画像を載っけると、卑屈な人だと「本を踏んづけている」と捉えられかねないのが気になった。
  • まとめを入れてもいいかも。
  • ちょっとしたテクニックの一つだが、自分の話をフォントで考えてみるといいかもしれない(今はこういうフォント(書体)でしゃべっている。今はこの文字の大きさでしゃべっている...)

会全体を通した感想

OSTバイネームで指名して話をするというのは初めてだったので、テーマに出していいのかというレベルで躊躇しましたが、贅沢に話を聞くことができて、楽しかったです。(結果的にもはやなんのイベントに出たのかがわからないww)

人に自分のセッションに対する感想を聞くことができるのはすごく貴重な機会ですが、森さんに聞けたということもあって、期待を遥かに凌ぐフィードバックがあって、とても学びになりました。
森さんどうもありがとうございました!

大人のソフトウェアテスト雑談会 #127【運】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

コーチからのフィードバック

Ryoさんがアジャイルコーチをやり始めた時のエピソードを聞いていきました。

Ryoさんはアジャイルコーチで現場に入った時、あまりにもひどい状況だったそうで、100個以上指摘しようと思ったことがあったそうですが、その時に、ペアコーチで入っていたアジャイルコーチからフィードバックの数を絞る重要性を教えてもらい、今では100個指摘したいことがあるなら2個だけフィードバックする、というのを始めたそうです。

お悩み相談

チームメンバーからフィードバックをされるものの、サンドバックにされているような感覚があり、なかなかしんどい状況になっているという話を聞いていきました。*1

以下、出ていたアドバイスの一部を記載していきます。

  • 期待値のすり合わせをした方がいいかもしれない。自分はXXXが苦手なのでXXXのようにしてくださいとか。できるようになるまでの期間の調整とか。
  • COIN(Context / Observation / Impact / Next)をはじめとしたフレームワークを活用して、言いたいことをフィードバックする
  • 「〜できないといけない」のような言葉は思考放棄にも繋がってしまうし、自身を追い込んでしまう可能性もあるので、ゲームをするなどして、そういうワードが出てこないようにする。*2

Tommy神(!?)

Tommyさんのアドバイスポジティブ心理学の概念を参考にしているのでは?という話が出ていたのですが、Tommyさんはポジティブ心理学という単語を知らず、概念を作った方だというのが判明し、ポジティブ心理学の始祖なのでは?という話が出ていました。

Tommyさんはケントベックの師匠だという話が定期的に出ていますが、XP祭り中にeroccoさんがその話をした時も、意図的に話をぼかされた*3ということで、純粋に神なのでは?という結論になりました。

話のつながりは自分で書いていてもよくわかりませんが笑、Tommyさんが葛飾で壮大な思考実験をされていることと、葛飾の皆から愛されていることはよく理解できました。

全体を通した感想

今日はお悩み相談会がメインでしたが、eroccoさんやRyoさん、KENさんやTommyさんなどを中心に、様々な経験をされてきた方が色々な視点でアドバイスをしている様子を見ることができて、しんみりしつつ学びも多い会でした。

また、Tommyさんがポジティブ心理学の始祖だというのは今日初めて知ったのですが、やはり数々の場所で功績を残されている方はすごいな、と改めて感じました。

*1:途中から入ったので、正確に条件を聞き取れていない可能性は高いです

*2:NGワードを決めておき、そのNGワードを話したらポイントを積み、一定ポイントに至ったらビールを奢るなど軽い罰ゲームをする

*3:「おしえていた」の「おし」までしか言わない

XP祭りで話すかもしれなかったこと

先日の記事で書いたように、XP祭りで登壇をしてきました。

aki-m.hatenadiary.com

当日はインタラクティブに話せればいいなあと思っていたこともあって、当初予定していた話とは少し異なる話をする場所も多かったので、元々予定していた話をブログで公開しておきます。(自己紹介とかは省いて、スライドのP5〜から書いていきます)

スライド

speakerdeck.com

ブログとの出逢いと継続に至るまでの流れ

まず、ブログをなんで書き始めたか?という部分ですが、これは、ブログを書くことを漠然と検討していた時に、ブログを書くことを大きく後押しされる出来事があったためです。
ブログを書くことを漠然と検討していた理由は、二つあります。

一つは、オキザリスチームというチームがアウトプットを多数していて、それに刺激されていたということ。もう一つは、スクフェス札幌2020に参加した時に、アジャイル札幌のコミュニティの皆さんに心をうたれ、こういったコミュニティになんらかの形で貢献したいと思っていたのが理由です。
そうしてブログを書くことを漠然と検討している中で、どうしても参加したかった「スクラムガイド2020を読み解いてみよう」というイベントに、ブログを書く枠でないと参加できないという状況が発生して、ブログを書き始めることを決意しました。

そうして書いた最初の記事を投稿したのですが、この記事に対してイベントの主催者や参加者の方々が反応をしてくれました。
特に、イベントの主催者でありオキザリスチームのメンバーであるびばさんやKANEさんが喜んでくれたのがすごく嬉しくて、もしブログを書く枠で参加しなくても、ブログにイベント記事を書く取り組みは是非今後とも続けていこうと思いました。
そうしてブログを書き始めた自分ですが、コミュニティに対して何らかの貢献をしたいという想いは、次第に強くなっていきました。  
これは、コミュニティに参加する頻度が上がったというのもありますし、コミュニティで学んだことが自分が働いている現場で活かされることで、次第にいきいきと毎日が過ごせる実感が自分の中で持てるようになったからです。

また、こうしてブログを書くうちに、スライドに書いたような好循環が回るようになりました。
コミュニティに参加する→ブログを書く→ブログの記事を見ながら次の日からの仕事にどう活かせそうか考えて仕事で使ってみる→(何回かに一回は)仕事で成果が出る→より学びたくてコミュニティに参加する→ブログを書く...というサイクルが回り、学びを提供してくれるコミュニティへの感謝が深まると共に、自分の行動を変容させるための一つの道具として、自分自身の手で書いたブログの存在意義が次第に上がっていったのです。
また、これとは別の軸で、書いたブログが他の人に喜んでもらえたというのも自分にとってはブログを続けるモチベーションになりました。  
雑に書いているので稚拙な記事も多いですが、「参加したかったけど用事があって参加できなかったので記事が残ってくれてよかった」「参加したけど内容を一部忘れてしまったので、忘れていた内容を思い出せてよかった」「イベント主催者側として、参加した人から楽しんでいる様子やどんな感想を持ったのかが文章に残してもらえてありがたい」...ありがたい言葉をたくさんいただけて、すごく嬉しかったです。
このような変化が重なり、自分の中でブログを書くことへの抵抗は薄れていきました。  
ブログを書き始めた当初は、いつまでブログを続けられるのか?ブログを続けることになんか意味はあるのか?ブログを書く時間があったら別のことをした方がいいのではないか?などと考えることも多かったですが、今は自分がブログの意義を感じられる+他の人にも喜ばれるということで、一切そうした悩みも抱えることがなくなりました。

どんな記事を書いているのか?

大多数の記事が、イベントやカンファレンスの様子を綴ったレポートになっています。
それ以外にも、読書記録だったり、自身のふりかえりをするような記事を書くこともたまにあります。

いつ記事を書いているのか?

イベント参加レポートの場合は、99%以上の確率で、イベントに参加しながら書いています。
イベントに参加しながら書くことで、できる限り記憶が鮮明なうちにブログを書くことができて効率がよくなりますし、イベント参加後に一息ついてブログを書くモチベーションが下がる事態を避けられます。
個人記事の場合は、気が向いた時に書いてストックを貯めておき、イベントに参加する予定がない日にストックから自動でランダムに投稿されるようにしています。

どんな風にブログの記事を書いているのか?

イベント参加しながらブログを書いている時は、事前に構成を決めて下書きの形で雛形を書いておき、別で個人用に取っている記録メモから、印象的だった部分をコピペで移していきます。この個人メモは、イベントで話されていることをひたすら写経しているもので、そこからここはブログに書いても大丈夫そうだな、という部分を移していきます。

その上で、最後に感想を一言だけ書いて、公開することが多いです。(感想に時間をかけると、自分の気持ちがどんどん加工されてしまう感覚があるので、短い時間で一言だけ書くことで、思ったことをできる限りそのまま書くようにしています)

ブログは、丁寧に書こうと思えばいくらでも書けてしまうため、タイムボックスを区切る目的で、特定の時間(イベント終了後+0~10分)に自動で投稿されるようにしています。  
目標時間より早ければ、そのまま公開しますが、記事を一部移し切れなかった場合は自動で書きかけのものが投稿されてしまうので、時間を意識しながら、いつ投稿されてもいい状態にはしています。

ブログを書くときにこだわっているポイント

ブログを書く時にこだわっているポイントは、3点あります。いずれも、イベントやカンファレンスの参加レポートを書く際に、特にこだわっているポイントになります。

まず一つ目は、ログのようなブログを書くということです。
なるべくありのままに近い情報を加工せずに残すことで、自分自身も含め、イベントに参加していた人がイベントのことを思い出しやすくなるようにしています。
同時に、忙しくてイベントに参加しなかった人にとっても、なるべくイベントの様子を感じ取れるようにしています。
たまに、「参加したいイベントがあったんだけど、aki.mさんがいたから後でブログ見て終わりにしようと思った」という話を冗談っぽく言ってくださる方がいらっしゃるのですが、こうした感想を言ってもらえたりして、とっても嬉しいです。
また、ログのようなブログを書いているのは、moriyuyaさんが書かれている1on1大全という本の影響もあります。
この本では、人の話を聞く際のテクニックとして、人の話を一言一句逃さないつもりでメモに残すことで自分の判断を挟まないようにする、というテクニックが挙げられているのですが、この練習をする場として活用するために、ログのような形でイベントの記録を残しています。

二つ目は、書く書かないの線引きをすることです。
上に書いたように、基本的にはログのような形でブログを残すのですが、書いたことを文章として他の人が読んだときに、イベントに関わった方が少しでも嫌な思いをされる確率がほんのわずかでもあるなら、書かないようにしています。
具体例で言うと、たとえばプライベートな話だったり、元々の関係性や以前からのコンテキストをしらないと誰かを傷つけていると捉えかねない話、有料の記事で書かれているような話、と言うのは、あまり書かないようにしています。
ただ、たとえばイベントの発言者をぼかしたり、コンテキストを意図的に省くことで他の人が文章として読んだ時に嫌な思いをしないように書き換えられそうであれば、積極的に書き換えることで記録に残します。

3つ目は、1000文字以上は書くと言うことです。
書き出す時から、1000文字以上は記事を書くことを意識して、もし1000文字以上書けるような内容がない場合はブログには残さないようにしています。
ブログを継続することだけが目的になってしまった結果、ブログを書くためにイベントに最初とか最後の方だけちょろっと参加して、数行感想を書いて終わり、のような記事を書いてしまうような状況になるのが嫌で、そうした状況になることを防ぐための制限として、基本的には1000文字以上を必ず書くというルールを設けています。

ブログを継続するために継続してきた工夫

以下、「エクストリーム・プログラミング」の書籍の文を引用しながら、自分がしてきた工夫を記載していきます。(「エクストリーム・プログラミング」を読んで思いついた工夫ではなく、やってきたことを無理矢理「エクストリーム・プログラミング」にこじつけるとこうなるなあという話だと受け取ってもらえると幸いです)

サポートしてくれるコミュニティーの存在は、ソフトウェア開発の偉大な資産である

まずは、関係性を広げることを意識してブログの記事を書くようにしています。
具体的にいうと、継続的に参加するイベントと、普段は交わらないような参加者層がいるイベントを織り交ぜるようにしたり、ブログで発信する内容に興味を持つであろう層を様々な層に分散させるような内容に意図的にしています。
こうして関係性を広げていくことは、自身が学ぶ対象の範囲を広げることになって、様々な気づきを得られるようになります。

生産性や自信はコーディングや仕事だけでなく、仕事場の人間関係とも結び付いている。成功には、優れた技術力と良好な人間関係が必要だ。

次に、自身をつけるということです。
具体的な取り組みは2つあるのですが、一つ目に紹介するのは、記事を書くハードルを上げすぎないということです。
ブログの記事は、時間をかけて書こうと思えばいくらでも時間をかけられてしまうため、極力時間をかけないようにしています。先ほど説明した、イベント時間中にブログを書くというのもハードルを上げすぎないようにするための一環ですし、その他にも、記事にもよるのですが記事の見直しを投稿前にしないようにしたり、装飾を最低限に抑えたりしています。
今日も継続できた!と達成感を味わうことは自信につながり、この自信が次の記事を産むので、このようにハードルを上げすぎない活動は重要な意味を持っています。
2つ目は、フィードバックでもらったコメントをじっくり読むというのも、自分の中では大事にしています。
SNSやdiscordなどでいただけたフィードバック、特に感謝のフィードバックについては、じっくり読むようにしていて、ものによっては自分が別で用意しているノートに転記することもあります。
じっくり読むのは結構恥ずかしい想いもあるのですが、流して読むよりも、丁寧にフィードバックを受け止めてその場で湧き出てくる感情を味わった方が、後の原動力になる感覚が自分の中ではあるので、大切にしている活動ですし、こうしたフィードバックをくださる皆さんには、心から感謝しています。いつもどうもありがとうございます。

エクストリームになるというのは、それぞれの問題を個人の成長、人間関係の深化、ソフトウェアの改善などの機会に意識的に変換することでもある。

次の工夫としては、動機づけを多数することが挙げられます。
ブログを継続し続けて起きたことで、自身のニーズとのつながりが見られるものは、ブログを書き続ける動機として判断し、メモとして残しておくようにしています。
もちろん全ての動機が毎回記事を書くたびに満たされるわけではないのですが、ブログを継続すると何が起きるのかを言語化してまとめておくことで、ブログを書くメリットを意識し続けられるようにしています。
ここまで紹介してきたのも多くありますが、動機としては、たとえば以下のようなものを持っています。

  • フィードバックをもらえるから
  • アウトプットが目に見える形になって評価がもらえるから
  • たくさんの人と繋がれるから
  • キャラが作れるから
  • 言語化能力に繋がるから
  • イベントやカンファレンスに貢献できるから
  • イベントやカンファレンスの経験を文字として残しておけるから

こうしてブログを書く動機づけを多数することで、ブログと様々な機会とのリンクを貼ることができます。貼られたリンクは何かしらの機会に変換されるため、ブログの意義に自覚的になり続けられ、継続する強いインセンティブになります。

成功に向けて準備しよう。前へ踏み出すこともせずに、自分から成功を遠ざけてはいけない。ベストを尽くし、その結果を受け入れよう。それがエクストリームだ。自分をさらけ出すのだ。

最後の工夫は、ブログに書いた記事を積極的に発信することです。
Twitterハッシュタグをつけたり、外から見れる履歴書や自身のプロフィールにブログ記事を貼り付けすることで、外部から常に見られ得る状況を作り続けています。
外部から見られることで、自分自身の学びや自身が歩んできた過程をさらけ出し、その結果得られるフィードバックを受け入れることで、前に進み続けようとしています。
継続をやめたくなるポイントの一つには停滞感があります。停滞感を感じてしまうと、どうしても自分は継続を諦めたくなります。
そんな停滞感を打破する一つの工夫として、外部に学びや過程を公開し、公開したからこそ得られるフィードバックを活用しているのです。

ブログの継続に寄与した要因(個人の特性が大きいもの)

「自分は頭がいいんだから、ひとりで上を目指せばいい」などという未熟な思い込みを克服することだ。

ちょっと卑屈に感じられるかもしれませんが、他の人よりも物事をキャッチアップするスピードが遅いことを信じ込んでいるということです。
すごい単純化した雑な表現をしてしまうと、自分は自分の頭がとても悪いと信じ込んでいます。
自身は小さい時から、幾度となく自分が理解するスピードの遅さ、物事に習熟するまでの遅さに悩まされてきました。
例えば、他の人が数回書けば覚えられる漢字が、自分の場合は100回くらい書かないと覚えられなかったり、プログラミングを学び始めた時にfor文の規則が何日たっても何回説明されてもわからなくて、同じタイミングで学び始めた人と比べて100倍以上問題が解けるまでの回答が遅かったりしたことが挙げられます。
こうした体験もあって、他の人よりも物事をキャッチアップするスピードが遅いことを信じ込むようになってからは、何かを習得したい時は他の人と同じ時間やっていてもできるようにはならないと思うようになって時間が必要なことが割り切れるとともに、自分一人で成果を出そうとしてもまるで成果が出ないから他の人に助けを求めよう、他の人と相互関係を紡いでいこうという発想が強くなりました。

ソフトウェア開発にはムダが多い。これらのムダの根幹は、我々が行っていることよりも、信じていることや感じていることにある。

また、圧倒的なことに憧れがあること。そして、仮に多少効果が見られないと思ったとしても、継続することが大きなイノベーションを産むことを信じているというのもあります。

自分は圧倒的なことが好きです。例えば、過去に一度ポケモンにハマり、世界一位になるまで対戦を続けたことがあります。
その際に大きな壁はいくつもあったのですが、最も大きな壁となったのは、100位を超えてくるような最上位層との戦いの中でした。最上位層と戦うに至るまでに対戦の研究を2000時間は重ねてきましたが、そこから一位になるまでの10000時間以上の研究がさらに必要でした。
そして、研究を継続し続けて、一位になるための最後の一歩になったのは、自身が数年間勝率を下げると考えて否定し続けていた戦術を自身の戦術に融合させた時でした。
自分が信じていることや間違いないと感じていることを捨て去るのは、少なくとも自分にとっては本当に難しいことです。信じていることや間違いないと感じていることにそぐわない事象が数回、いや数十回起き、もしかしたら数百回起きたくらいでは見方を変えることができません。
バイアスによってそもそも事象自体を見過ごすかもれしれないですし、これまで信じてきたものを支持する根拠や事象の膨大な数と比較して、例外ケースだと棄却してしまうかもしれないです。
自身が信じていたことを疑い、今当たり前だと思っている固定観念を本当の意味で捨て去るには、膨大な時間の投資と膨大な試行錯誤の数が必要だと思っています。
この膨大な時間の投資と膨大な試行錯誤の数には、継続的な取り組みが不可欠だと思っています。

ブログを書き続けて得たもの

効果的なソフトウェア開発には、多くの人の視点が注ぎ込まれなければいけない。

ブログを書き続けて得たものとして最初に挙げられるのは、ブログという形で他者が話していたことや学びを記憶できる装置が増えて、疑似的なコミュニケーションができるようになったということです。
自分はそんなに記憶力が良くないのですが、あの時なんかこんなことを言っていたなあと思い至ることがあった場合、キーワードやイベントの登壇者などでブログをgrepすると、話していたことがヒットして、すぐに思い出せるようになりました。
また、ただ話を聴いている時よりも、聴いた話をブログに残している時の方が、記憶に定着しやすいので、もちろん完全ではないにしろ、インデックスレベルでの記憶は残りやすいです。
こうしてインデックスが貼られた使いやすい記憶装置が誕生した結果、自身が困ったときには、イベントで登壇してくれた方や参加者の方と、疑似的にコミュニケーションが取れるようになりました。
ソフトウェア開発は難しいです。難しい問題に立ち向かう時には他人の力がどうしても必要になります。
そうしたとき、勿論職場の人は頼りになりますが、ブログを始めたことによって、これまで職場にいなかった様々な分野のエキスパートの方々も自身の問題解決に加わってくれたのです。

変更は不安を伴う。不安を伴えば、人間は変更をすばやくやろうとする。

また、ブログを継続して毎日書くことで、ベイビーステップを踏めていることを実感できるようになりました。
現在の自分の姿と自身が理想としている姿までの距離は遠いものです。遠い理想に向かって変化をするのは、非常に不安ですし、遠い理想に早く近づきたくて、どうしても大きな変化をしたくなります。
ブログを始める前の自分は、遠い理想に近づくために色々なことを大きく変えて、失敗し続けていました。
しかし、ブログを始めたことで、毎日小さな単位で変化をすることができるようになりました。
昨日ブログで書いたこの部分だけ変える、という風にすることで行動単位を小さくし、うまくいかなかった時のロールバックも容易にできるようになりました。
小さく素早く行動を変化させることで、小さな成長や小さな成功体験を積み重ね、いつの間にか数年前の自分には想像することのできない、大きな成果を出せるようになったのです。

ブログの継続はソーシャル・チェンジである

そしてこれが自分にとって何よりも重要なことなのですが、イベントを記事にすることをコツコツと継続してきたことで、色々な方々と繋がりを持つことができました。
イベントに参加して記事にしたことで、イベントに携わった方から認知をしていただけるようになり、お話をする機会に恵まれたのです。
そうしてできたつながりは、言葉では言い表せないほどの素敵な機会との出逢いにつながり、自分が進みたい方向へ進むのを助けてくれました。自身の環境が一変して、ある種のソーシャルチェンジが実現したのです。

その他、時間の関係もあって今回は紹介できなかったのですが、イベントで起きたことをまとめる過程で情報を整理する速度が上がったり、ブログを継続するためにインプットの量が自然と増えたり、こうして今登壇することなどを含めてアウトプットをすることに対しての抵抗が少なくなったりと、数えきれないほどのいいことがありました。

今回登壇の機会をいただいてこうして改めて考えてみると、自分の中では、ブログを継続していたことが人生を変えてくれたと言っても過言ではないのかな、という気もしています。

アジャイルカフェ@オンライン 第20回に参加してきた

agile-studio.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

木下さん天野さん家永さんのお三方が、参加者からの質問に答えていく会です。  
今日の質問は、「スクラムマスターにとって最も大切なことはなんですか?」でした。

会の様子

今日は質問が、「もっとも」大切なものを挙げてほしいという質問だったので、議論の中で出てきたものを挙げていきます。

議論の進み方としては、最初に家永さんが「これは一番大事だ!」と思ったことを挙げてくださり、その後に家永さんが出したことよりも(or家永さんが出したものと同じくらい)大事だと思ったことを挙げていくというスタイルで進みました。

そのため、時系列で上から順に挙げていくとともに、それがなぜ重要だと思ったのか?というのを記載していきます。

  • アジャイル(スクラム)に関する基礎知識
  • チームや人との関わり方に関するスキル。アジャイルスクラムに関する基礎知識があっても、それをチームに伝えられなければ意味がないから。
  • 弱みを見せられること。スクラムマスターはスーパーマンではないし、上に書いたようにチームと協力する必要があるが、その際に大事なのは自身の弱みを見せられることだと思っているから。(弱みを見せることができないと、依存されてしまうor反発されてしまうことが多い)
  • 笑顔があって新しいことへのチャレンジを後押ししてくれる安心感があったり、チームの基準を引き上げてくれるような人平鍋さんの姿から想像される大切なこととして挙げたい。
  • スクラムマスターだけに言えることではないかもしれないが、自分が責任を引き受けるという覚悟。人のせいにしない。
  • 真面目で一生懸命で明るくて、自分の組織が好きな人。稲盛さんがリーダーを選ぶ基準として挙げていたため。

最終的には、御三方それぞれ、以下がもっとも大切なことだという結論になりました。

家永さん...チームの成長に全力でコミットすること。チームへの愛。

天野さん...スクラムチームのステージによって変わると思うのだが、チームが立ち上がるタイミングでは、笑顔で常に励ましてくれるようなスクラムマスターが必要だと思っている。

木下さん...笑顔もそうだが、弱みを見せてくれたりとか、人(チームメンバー)から話しかけられやすい人。

会全体を通した感想

今まで一度もない、「もっとも」を選ぶ回で、とっても面白かったです。

このイベントに限った話ではないのですが、経験や知識がある方が選ぶ「もっとも」は、重みがあるし、なぜ「もっとも」だと思うかのストーリーにも重みがあるなあと感じました。