ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。

ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。

ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交えながらジェネラリストとしてソフトウェア開発に貢献する方法をお話します。

J. Richard Hackman著の書籍Leading Teamsによると「安定したチームほど良いパフォーマンスを発揮する」とあります。

まったく異論はありません。

ただ、嬉しくもあり、残念でもあるのですが、チームでの活動がうまくいった結果、プロダクトが成長し、ビジネスが成長すると、どれだけ今のチームが素晴らしくても、チームを大きくする力がどうしても働き始めます。

そうすると、いつまでも安定したチームで居続けられなくなるのもまた事実です。

安定したチームがよいパフォーマンスを発揮するとはわかっていても、なかなか許してもらえない。

そんな状況を受け身になげくのではなく、それを受け入れ、不確実な状況に適応するために、積極的にチームや組織をダイナミックにリチーミングすることはできないでしょうか？

 Heidi Helfand 著の書籍Dynamic Reteamingより、チームをダイナミックにリチーミングするための５つの方法を、実際に現場でチームと関わるなかででてきた事例とともにご紹介します。

もうリチーミングは、怖くない！

すべてがフィードバック、なんでもフィードバック - Feedback is Life

フィードバックは、会社の中のコミュニケーションだけでなく、家族間、学校内、などなど、コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。

しかしいざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。そのときに、ワインバーグ先生の『What Did You Say? The Art of Giving and Receiving Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない！と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。

そして1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。

• すべてがフィードバック、なんでもフィードバック。
• テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。
• フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。またフィードバックは受け手の話ではなく、与え手を表現することです。そしてフィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。
• フィードバックでは自分自身を大事にすることが大切です。
• フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。
• 「フィードバックください！」とよく言ったり言われたりしますが、実は……

みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。

本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。

ぜひ、楽しい時間を皆さんと分かち合いましょう！

スウォーミングとは、ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するという意味合いになります。私が所属しているスクラムチームでは、最も優先順位が高いタスクを最速で完了させることを目的にスウォーミングを実施しています。

スウォーミングの手段の1つにモブプログラミングがあります。私たちのチームも結成当初は、フロー効率最大化のためモブプログラミングで1つのタスクに群がっていました。しかし、開発が進みタスクの不確実性が下がってくると、開発メンバーは「フロー効率重視の開発スタイルを維持したままリソース効率を高めていきたい」と考えるようになりました。

そこで、Swarming: One-Piece Continuous Flow** のキャプテンの仕組みを参考に、ソロプログラミングを主とした開発でもフロー効率が下がらない方法を編み出し、チームに適用しました。私たちはこの仕組みをキャプテン制度と名付けて運用しています。

本セッションでは、スクラムチームで実践しているスウォーミングの紹介、キャプテン制度の策定の背景、得られた効果についてお話ししたいと思います。また、私自身スクラムマスターとエンジニアを兼務している立場であるため、スクラムマスター、エンジニアそれぞれの立場で、キャプテン制度を運用してみた所感についても共有させていただきたいと思います。

クラスメソッドのCX事業本部には、スクラムマスターが組織横断で緩くつながる目的で結成した、『スクラムマスター向上委員会』という非公式グループがあります。

今回スクラムマスター向上委員会のメンバーが、CX事業本部内の各スクラムチームのスクラムイベントを順に見学し、われらが御意見番が、厳しくも愛のある、ご存じ『喝!』に加え、吟味に吟味を重ねたスーパープレーに与えられる『あっぱれ！』ってことをやりたいと思います。

例えば‥

• プランニング
  • POがたくさんいる！
  • ベロシティなんて見なくていい！？
  • スプリントゴールが難しい
• レビュー
  • Doneより開発効率のほうが大事？
  • デザイン大変問題
• レトロスペクティブ
  • ウォーターフォール的な圧力にスクラムマスターはどう立ち向かうのか
  • 潮目を読むスクラムマスター

「スクラムチームにスクラムマスターは本当に必須ですか？」

スクラムマスターがいるのに、成果が出ていないチームもあります。

スクラムマスターがいなくても、成果が出ているチームもあります。

「その真髄はどこにあるのか？」

異なる立場で向き合う3人のスクラム実践者と紐解くセッションです。

我々3人が見てきた様々なスクラムマスターを紹介します。

• 専任
• PO兼任
• 開発者兼任
• マネージャー兼任
• SM無し
• ペア
• 複数チームのSM
• プロパー
• 社外のメンバー
• 新社会人
• 開発未経験者
• 開発経験者
• サイレントSM

様々なスクラムマスター・チームを見てきた3人が今考えていることはこのような感じです。

• SMの人数とチームの成長は必ずしも相関していない
• SMの役割を他のメンバーに分散しても良いのでは？
• 明示的にSMのラベルを貼らなくても良いのでは？
• SMの役割が多すぎるので1人でやるの難しすぎるのでは？
• SMのスキルが必要なのはスクラムだけじゃないのでは？
• SMの練習はスクラム以外でも出来るのでは？
• SMの勉強だけしていても良いSMになれないのでは？
• SMのゴールや幸せとは？
• SMのキャリアはアジャイルコーチが多いけど他に何があるんだろう？
• SMを長期間継続している人がいないのはなぜだろう？
• あらためて、SMとは？

このセッションでは、上記のようなテーマを3人と一緒に考えてみる時間です。

皆さんも一緒にスクラムマスターの価値を大解剖しましょう！

私は大学でenPiT等でアジャイルなプロジェクト型学習（AgilePBL）を担当したりいくつかの講義を担当しています。enPiTを通してアジャイル開発を学びPBLに導入してから、一般講義での教え方も変容してきました。

「授業や試験中の相談やパクリってなんで授業ではダメなんだっけ」って根本から問い直して学生の最大利益を追求するように工夫してみたり、自分が教える知識・技術だけでなく学生達の問いや知識と合わせて相乗効果で学びを得ていったり、そういう授業を作っていこうと思うようになりました。

アジャイル開発の考え方やコミュニティでのみなさんの活動に刺激されて取り入れてきた、みんなでワイワイしながら支え合う講義づくりについてお話ししようと思います。

eduScrumなどのような、フレームワークやプラクティスを授業に当てはめてみたというではなく良い授業について根本から考えて改良するようになったと言う話をする予定です。

あじゃてく（Agile Tech Expo)のみなさんと発行した「ぼくのアジャイル100本ノック」
めでたく8月に発行に至りましたが、結果的に100章、400ページ超の本になりました（予定）。

本書の内容は、
「アジャイルの具体例を知りたい」「成功例も、失敗例も、困ったことも」「実体験を！聞きたい！」
「スクラムやってみた」「JTCでスクラムって無理じゃね？」etc…
参加者の経験、体験、知見のぎっしり詰まった、パワーのある本になりました。

アジャイルに関する色々をまとめるという本企画を通じて、
・参加者が得た体験
・コミュニティが得たこと
・本がもたらした成果、届いた先　という観点でお話しします。

普段とは違う「アウトプット」をして、参加者（寄稿者）が得た体験、
自分の知識の棚卸や整理ができたといった大きなメリットがありました。

コミュニティで本を作るということの意義の点では、
活動記録としての本という媒体、そしてコミュニティで発行することにより、
パワーのある本を作り、広く届けることができました。
また、コミュニティがそのスキームを獲得・経験することで、次回企画にも活用できます。
約60人の参加者がゆるく、でも一つのテーマについて考える機会にもなりました。

「本の執筆」という形のアウトプットの意義と、それがもたらす効果、ブログや登壇との違いをご紹介します。
インプットも重要ですが、知識・経験をアウトプットしてみましょう。
それが、聞いてくれた人の背中を押すことになれば最高です。

また、本書をはじめいくつかの技術同人誌を持ち込んで、
現地で頒布もする予定ですので、ぜひ見てみてください。