開発者がテストをできない理由を考えよう

この記事はCalendar for ソフトウェアテスト | Advent Calendar 2021 - Qiita15日目の記事です。
昨日（14日目）は@RyomaMaedaさんのバグバウンティプログラムとは何か？3分で理解する | Test-Hack | 3分で理解するIT/テスト技術でした。

qiita.com

はじめに

TDDのように開発者が自動化された単体テストを作成し、できるだけ小さい単位で品質を高める開発手法（この記事では開発者テストと呼ぶこととします）が良く知られています。自分の関わるプロジェクトで開発者テストを普及させようとしましたが、最終的に上手く運用できませんでした。本記事は、その経験から今後に生かすために個人的なふりかえりをまとめたものになります。

できるだけ早く検証する

VUCAの時代*1といわれるとおり、昨今のビジネスは複雑化していて予め結果を予測することが難しくなっています。また、リーンスタートアップにおけるMVP*2のように、小さい単位で早期に作って検証のサイクルを早く回すことがVUCA時代におけるビジネスの成功パターンとして知られています。

ソフトウェア開発も同様に品質を高めるために、できるだけ早期にテストをする手法が広まっています。テストファースト／TDDに代表される開発者テストもソフトウェアの品質を高める手法として知られています。

背景

開発者テストをプロジェクトに導入しようと試みたときに、開発者テストに対して慣れていないメンバーも多いため、テストフレームワークを用いた実装方法をレクチャーしてサンプルも準備をしました。しかし、「できればテストを書くようにしたい」として進めていましたが、結果として開発時に十分なテストを揃えることができずに上手く回りませんでした。自身の反省も含めてうまく開発時にテストができなかった理由を考察したいと思います。

• テストデータをどう使えばいいか分からない

• 計画時間内では実装するまでで精一杯

• 何をすればいいか分からない

テストで使用するファイルをどう管理すればいいか分からない

状況

テストデータとして画像などのファイルを使用する場合がありますが、ファイルを用意した場合にどのように管理すればいいのかが分からない。

分析

開発後に行うテストの場合は別途テスト用ファイルの保管場所を用意しますが、自動化された単体テストに使用するテスト用ファイルはソースコードと同様に構成管理に含める必要があります。
テストコードは構成管理に入れることを想定していましたが、テスト用ファイルについては失念していました。また、テスト用ファイルはサイズが大きいものもあり、できるだけ使いまわしたいため、テストコードとは違った考えで管理する必要がありました。
そのため、テスト用ファイルが必要なテストケースを作成する場合、開発者はその管理方法について考える手間が追加されていました。

考察

準備をしていたつもりでしたが、実際に運用してもらうと事前に考えきれなかったところが負担になっている個所がありました。事前に想定しておければよかったですが、そういった運用上の負担をできるだけ早く拾い上げて改善していく必要があったと感じます。

計画時間内では実装するまでで精一杯

状況

作業計画では「実装に加えて、できればテストを書こう（開発者テストが定着していないので）」の方針で進めていたが、計画内では機能を実装するので精一杯であり、テストを十分に書く時間が取れなかった。

分析

「テストを書くための工数を十分に確保できなかった」というのも理由の一つとして明らかです。しかし、「開発者テストを十分にした方が最終的なソフトウェアの品質が高めやすい」という話を知っているにも関わらず、開発者テストを書くための工数を用意できませんでした。「マイルストーンが決まっており、それまでに動くシステムを用意する必要がある」のもありますが、「一連の機能が動くシステムを早く確認する」ために「時間をかけて開発者テストが充実した状態」よりも「最低限動く機能が早めに作れる状態」を優先した、と感じています。

考察

自分のなかでは「利用者に価値のあるものを提供する」を優先していますが「開発スキルとして開発者テストを拡げたい」という考えもありました。現実的なテスト方針に対して考えが浅いと感じました。

何をすればいいか分からない

状況

そもそも実装で何をすれば分からない部分が多く、テストまで考える余裕がない。

分析

新規要素が多く「どのように実装すればやりたいことが実現できるか」を考えるのに開発者は多くの時間を費やす必要がありました。その状態では、開発している機能の異常系について考えを巡らせることが難しく、実際に起こりやすい異常系ですら考慮されていないケースなども出てきました。適切なストレスがあると人間はパフォーマンスを出しやすくなりますが、今回のケースでは過度なストレスによりパフォーマンスが発揮できない状況だと言えます*3。

考察

開発者テストが定着していない環境において、新しく開発者テストを学ぶことは負荷になります。開発者テストも学んでほしいと思いますが、開発においても学ぶことが多い中で、チームとして優先することを定める必要性を感じました。

おわりに

開発者テストを普及させようとした中で、上手くいかなかった要因を探るために「なぜ開発者テストができなかったのか」に着目して分析をしてみました。「できない」がその人にとってどうだったのかを深掘りすることで、普及活動の課題や無茶筋を気付くことができたように思います。あくまで私の経験の一例なので、異なる環境であれば違った「できない理由」が見つかると思います。

*1:https://ja.wikipedia.org/wiki/VUCA

*2:Minimum Viable Product、実用最小限の製品

*3:https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%95%E3%82%A9%E3%83%BC%E3%83%88%E3%82%BE%E3%83%BC%E3%83%B3

12/19（土）、「すごいブレスト・体験ワークショップ（新刊記念の無料回）」に参加しました。

はじめに

アイデア創出の支援活動をしている石井力重さんの書籍「すごいブレスト」出版記念によるブレスト体験ワークショップに参加してきました。
peatix.com

私も「すごいブレスト」は読みましたが、ブレストに関する基本的な内容から応用的な考え方、実践における課題への対応など幅広く読み易い形でまとめられている印象を受けました。このワークショップも本で紹介されている内容を体験できるということで、とても楽しみにしていました。

使えるアイデアがあふれ出るすごいブレスト

booklog.jp

石井さんがアイデア創出を生業にしているだけあって、多くの工夫が感じられた会でした。ワークショップと運用について、気に入った点についてまとめます。

ワークショップ

「すごいブレスト」でも紹介されている「3人ブレスト」を体験してきました。すごかったです。

3人ブレスト

Zoomのブレイクアウトルームを使って、3人ずつのグループに分かれてのブレストを行いました。オンラインでは誰かが会話の主導権を持つと他の人が話しにくい印象を受けますが、3人くらいだと全員の意見を万遍なく聞けるため、活発に意見が言い合える場になるという印象を受けました。

「3人ブレスト」は8分を1回として、人をシャッフルして4回を実施しました。時間や回数にも意味があるとのことでした。

• 時間

8分という時間は、もともと対面での「3人ブレスト」は6分単位で実施していたのですが、オンラインだと議論が収束しにくかったそうです。リアルに比べるとオンラインは1.3倍時間がかかる傾向にあるらしく、6分×1.3倍≒8分、という時間計算になるとのことでした。

• 回数

4回という回数は1～2回だと意見が出し切れず5～6回だと多すぎてしまうことから、3～4回という回数を推奨している、とのことでした。私のグループでは、1～2回目は新しいアイデアを出すことができましたが、3～4回目は既存のアイデアを深める意見が多かったため、3～4回が妥当であることは体験とも一致していました。

アイデアの素描

「3人ブレスト」で出たアイデアをもとに、各人でアイデア案をスライド1枚にまとめました。Googleスライドを使って全員で同じファイルに対して作成していたため、時間が余ったときに他の人の作成途中をのぞき見してインスピレーションを受けたりして面白かったです。
休憩のデザインに関する話もあり、「個人ワークの後に休憩を挟むとじっくり考えたい人にも対応できる」と説明いただきました。私の体験として、別の勉強会でもワーク後の休憩時間で延長して考えることが良くあるため、すごく納得のいく内容でした。

アイデアへの星付け（投票）

各人がスライドにまとめたアイデアに対して、それぞれが良いと思ったアイデアに星付けを行いました。時間が無い中でもイラストなどで表現を工夫される方が多く、参加者の熱意を感じられる時間でもありました。

面白いと思ったのは、アイデアを投票数の多い順に並び替える作業を参加者たちが人力で行うことでした。共有ファイルを複数人で操作するとトラブルが起きる印象があったのですが、トラブル無く短い時間で並び替えが完了しました。石井さんのオンライン経験の豊富さからくる任せ方だと思いましたし、そういうやり方があるんだ！と感銘を受けました。

上位案へのレビュー

多くの投票を集めたアイデアに対して、案作成者からの説明と、それに対するレビュー（質問、感想）を行いました。

レビューは別に用意した白紙スライドに書き込む形式でしたが、同時編集により他の人の書き込みが見えるのが面白かったです。説明や他の人の書き込みにより、自身の創造力が刺激される経験ができました。

運営

運営方法でも興味を惹かれるところが多かったのでまとめます。

ビデオMix

オンライン会議システムでは「本人の映像」「発表資料」のいずれかを共有することが多いですが「本人の映像」について工夫がされていました。ただの「本人の映像」だけでなく「手元（のノート）の映像」をビデオMixして表示していました。ペンタブのように手書きをデジタル化するツールもありますが、ノートとペンによる手書きの映像が出てくることで「リアル感」「創造感」が強く、見ている側のテンションが上がるような工夫でした。真似したい。

オンラインツール

「すごいブレスト」でもオンライン対応を謳っているいるだけあって、オンラインツールの使いこなしが印象的だったワークショップでもありました。

オンライン会議システムへの映像はビデオMixしたものを使っていたり、スライドにはWindows / Macなど環境問わず安定動作しやすい「Googleスライド」、感想にはリアルタイムでアンケートを取れる「slido」を使ったりしていました。

また、ツールの選定だけではなく、使い方への工夫も多かったです。「すごいブレスト」でも工夫への言及はありましたが、石井さんの経験や準備を感じることができましたし、実際に使っているところを見れたのはとても勉強になりました。

• Zoomで「3人ブレスト」を行うときにブレイクアウトルームを使用するが、参加者のランダム性を高めるため、参加者氏名の前に好きな3桁の数字を何度か付け替えてもらう

• Googleスライドは複数のファイルを用意しておく。同時アクセス数が多いと、動作が重くなって作業に支障がでるため。

説明の動画資料

「3人ブレスト」の説明動画は石井さんのYoutubeチャンネルに上がっています。他の人と「3人ブレスト」を試したいときなどに使いやすくて助かります。

当日の説明も動画で行うことは意外にも思いましたが、一人でワークショップを運営するという激務において、準備に時間を指すための選択として十分に納得できると感じました。

youtu.be

おわりに

ブレストそのものも勿論良かったのですが、運営の上手さなども堪能できて、とても多くのことを学ぶことができました。「ほんとうに無料でいいんですか！？」と思えるくらい貴重な経験ができましたし、「3人ブレスト」の考え方は応用が利きやすいため、機会を作って試したい、と思いました。

12/5（土）、「1on1カンファレンス」に参加しました。

はじめに

1on1を扱ったカンファレンスに参加してきました。

1on1は特にソフトウェアエンジニアで広がっているコミュニケーション手法ですが、それに関連してカウンセラーや認知学者など、普段関わることが無い方からもお話を伺えて学び深い会でした。

career-update-org.connpass.com

講演の感想

1対1の対話について心理療法から考える

重宗先生による心理療法の観点についてのお話と、1on1との違いについてお話がありました。職業カウンセラーと職場の1on1では人間関係や目的に差異があるなど、カウンセラーから見た1on1の話がとても勉強になりました。また、カウンセリングのライブデモがあり、直接受けないと分からないカウンセリングについて深く知ることができました。カウンセリングのやり方は書籍などにもありますが、話しているときの間や雰囲気などは書籍ではイメージしきれないので、とても貴重な時間でした。

仕事のモチベーションをあげるための1on1の使い方

モチベーションを挙げるためのTipsについて、事前準備／お願いシーンごとに話す内容／注意点で分けてのお話がありました。全部で約30個あり、いずれも仕事でのシチュエーションが想像しやすく、実践に活かしやすい内容でした。発表時間20分に対してTipsだけで約30個あるので、発表は駆け足感がありましたが資料は公開されているので、あとでじっくり復習したいです。

speakerdeck.com

対話のカウンセラー的アプローチ

整理された形でのカウンセリングの考え方の話があり、1on1のワークもありました。1on1ワークは特徴的で、クライアントの発言に対してどんな回答を返すかを、Discordのテキストチャットに書き込むスタイルでした。人が多くても自分の回答を表現できるし、他の人の色々な解答を見ることができて、とても面白いと感じたやり方でした。

対話のカウンセラー的アプローチ for 1on1conf2020 from Taku Hasegawa

www2.slideshare.net

仕事のパフォーマンスとエネルギーマネジメント～みんなが自分らしくイキイキはたらける職場づくりを目指して～

産業保健師という立場から、ストレスについての知識についてをお話がありました。どんな時にストレスがかかるのか、ストレスを解消するのにはどうすれば良いかなど、ストレスと付き合うための考え方を学ぶことができました。パフォーマンスを出すためには適度なストレスが必要だと点になるほどと思ったのと、Discordでの他の参加者の方々のストレス話が印象的でした。

きっとうまくいく 理想と現実の差を埋める打ち手の導き方

リモート環境でのコミュニケーションに対する工夫と、1on1に対しての実践例についてのお話がありました。1on1の実践例は、理想と現実のギャップにはある程度のパターンがあるため、パタン・ランゲージをヒントに対策を磨いていくという方針が印象的でした。また、自社内で行っているワークショップで、部下と上司で立場を入れ替えて行っているという話は興味がありました。

わかるとは？ー認知科学から考えるー

認知科学の観点から、そもそも理解するとはどういうことか、について語られました。スライドなどの決まった内容ではなく、ラフな感じで語り拡げていく感じは凄いと感じました。簡単に見える問題でも、その認知のプロセスは人によって異なっているため、相手の回答が自分とは違うのであれば（同じであれ）、相手がどう考えているのかについて理解を深めることが肝要であると思いました。

運営の感想

準備／丁寧な説明

1on1カンファレンスは運営の準備／丁寧さについても学ぶところが多かったです。トラックには必ず運営がついて〇分前に説明を入れたり、Discordに講演の概要を都度記載するなど、参加者が迷いにくいような気配りが見受けられました。オープニングセッションではカンファレンスで使う各種ツールの動作テストを行ったり、講演中はスタッフも良くDiscordに書き込みを行うなど、参加者に不安なく講演に集中できるような配慮があったからこそ、活発な書き込み／質疑が実現していたのだと思います。

Ask the Speaker

カンファレンスでの質疑応答の時間は良くありますが、ショートセッションの講演者は二人まとめて質疑応答の時間を取る構成が面白く感じました。講演の間隔が短いためテンポも良く、質疑応答では講演者同士の掛け合いがあるなど、充実した内容だと感じました。

おわりに

1on1のカンファレンスは初めてとのことですが、とてもそうには思えない素晴らしい内容と運営でとても満足できる一日でした。ソフトウェアエンジニアとは違った職種の方の話を聴けたり、面白いスタイルのワーク／運営があったりと学びも深く、次回があればまた参加したいと思えるカンファレンスでした。

2020/11/27（金）、「専門書編集者の話が超面白かったからもうちょっと聞いてみよう!」に参加しました。

はじめに

日科技連出版社の鈴木兄宏さんから出版社編集者としての仕事に関する色々なお話を聞ける会に参加してきました。

www.kokuchpro.com

JaSST Review 2020での発表内容をベースにして、より詳細に掘り下げていく進行となります。

jasst.jp

会の中でも「深夜ラジオのノリ」と言われていましたが、MCの@kitanosirokumaさんと鈴木さんのやり取りが心地よく、深い話も多数出てきて、とても学び深かったです。たくさんのお話をお聞きしましたが、特に印象に残った点をピックアップして記載します。

• 自己流とは

• 相手に伝わらなければ意味がない

• 6つの立場で原稿を読む

自己流とは

ここでの自己流とは、やみくもな方法ではなく、自分にあったやり方のことを指します。

特に、自分にあったやり方を「自分がやりやすいやり方」ではなく「自分が成果の出しやすいやり方」としていたことが凄くしっくりきました。目標・目的を達成するという点に主眼が置かれており、そのために自分が何ができるかを模索していく姿勢が見習いたいところだと感じました。

そんな鈴木さんが例に出したリーダーシップ像は、近年注目を浴びているサーバントリーダーシップにも相当するものだとか。*1

相手に伝わらなければ意味がない

編集者として、校正・校閲時に著者へ向けて修正案を伝える必要があります。気になったことを伝えるだけでは著者に受け入れられない場合があるため、伝え方を良く考える必要がある、という内容でした。

文章の責任は著者にあるため、致命的なものを除いて、直す判断は著者が下すことになります。そのため、編集者が「こうした方が良い」と思った内容は相手が直したいと思えるように伝える必要がある、とのことでした。編集者自身が読んで理解したことを確認するプロセスで著者に改善の必要性を考えてもらう、といった実践的なテクニックについても紹介されていました。

6つの立場で原稿を読む

原稿を読むときの立場として、以下の6つの立場が挙がりました。

1. 編集者
2. 読者
3. 著者
4. 版元
5. 印刷会社
6. 書店・取次

自分が校正・校閲する立場だとしても「印刷会社」や「書店・取次」の視点は出てこない観点でした。出版側や読者側だけでなく本の製造・流通に関する部分にも観点を持っていることは、さすが編集者だと思いましたし、とても驚きました。機会があったら自分もそれらの観点を試してみたいと思います。

おわりに

鈴木さんは登壇経験はJaSST Review 2020が初めてとのことで、とても驚きました。編集者として身につけた様々な知識があるからこそ、初心者とは思えない素晴らしいプレゼンになったと思います。

予定2時間に対して約3時間半の会でした、できればもっと編集者としての話をお聞きしたい、と思えるぐらいとても楽しい時間でした。文章を書く機会は仕事でも避けられないため上手くなりたいと常々考えているので、文章を磨くための技術を本職の方からお聞きできた、とても貴重な会でした。

*1:https://twitter.com/YasuharuNishi/status/1332277858673127424

自覚のない評価基準に気を付けよう

はじめに

自分の評価基準を明瞭にすると決定力を鍛えられるよ、という話と、決定に使われる評価基準には自覚のないものがあって厄介ですよ、という話です。目次は以下のとおりです。

• 決定における評価基準とその優先順位
• 評価基準の優先順位を決める利点
• 暗黙の評価基準
• 暗黙の評価基準による問題
• 暗黙の評価基準にどう対応するか

この記事の内容は我流なので、「こういうもっと良い話があるよ」というものがありましたら紹介いただけると幸いです。

過去に書いた以下の記事の続きのようなものです。

toshimana.hatenablog.com

決定における評価基準とその優先順位

タスクの優先順位を決めるとき、「なぜそのタスクの優先順位は高い／低いのか」を判断する評価基準が存在します。例えば、業務タスクであれば「期日までにタスクを完了できる」や「自分の影響で他者を遅らせない」などが評価基準に当たります。

タスクが複数あるときは実施する順番である優先順位を決めることがあります。評価基準も複数ある場合がほとんどなので、評価基準についても優先順位を決めることができます。*1

持論ですが「すべての情報が揃っていれば、物事の決定は一意に決まる」というものがあります。あらゆる条件や候補が出揃っていて、決定のための評価基準やその優先順位が定まっていれば、誰でも同じ結論に到達する、という考えです。
もちろん、現実ですべての情報が出揃うことは有り得ないことではあります。ですが、業務で私が何かを決定するときは、可能な限り決めるための情報やその評価基準を用意して、他人にも再現できる状況を作ろうと努めます。*2

そして「すべての情報が揃っていれば、物事の決定は一意に決まる」という考えですが、別の考え方にも派生します。「決定が一意に定まらないのであれば、何かの情報が抜けているかもしれない」と探索的な思考に繋がります。条件や候補が抜けているかもしれないし、評価基準が出揃っていないかもしれない。もしくは、評価基準の優先順位がズレているかもしれません。

評価基準の優先順位を決める利点

優先順位の定まった評価基準の集まりは、ほぼ意思決定アルゴリズムといえるものだと考えています。この評価基準の集まりを明瞭にすると、利点として、以下が挙げられます。

• 他人に納得してもらえる

• 意思決定を改善できる

他人に納得してもらえる

ある決定に対して、どういう条件や候補があって、どんな評価基準をどのような優先順位で判断しているかが明瞭であれば、他人に納得してもらいやすくなります。もちろん、納得してもらえるのは「この方法でこの決定を下しました」という内容に筋が通っていることであって、「条件や候補の良し悪し」「評価基準の良し悪し」「評価基準の優先順位の良し悪し」に納得してもらえるかは別問題になります。

しかし、どのように意思決定したかを相手に理解してもらうことで、指摘箇所を具体的にすることができます。
「この決定は受け入れられない」から「この候補が比較に含まれていない」「こういった条件が考慮されていない」「我々はそれよりもこういったことを優先したい」のように認識がズレている個所を具体的にできます。

意思決定を再現できる

意思決定で期待した結果が得られなかった場合、どこに問題があったかを振り返り、改善する必要があります。意思決定アルゴリズムが明瞭であれば、改良点も明瞭になります。結果が出た後であれば、「評価のどこで問題がある決定に導かれたのか」「同じ入力があったときにより良い結果を得るためにどういった評価基準の変更を行えばよいか」が分かります。例えば「発注より別作業を優先したら、納品が遅れてスケジュールに影響が出た」のであれば、「スケジュールに影響がでないようにする」ために「他者に影響する作業」を優先的に対応することで同様の状況をより上手にこなせることが期待できます。つまり、評価基準の集まりを明瞭にすることは、意思決定を鍛えることに繋がると考えられます。

暗黙の評価基準

評価基準の認識が揃っているはずなのに、決定がズレる場合があります。「試験前日の学生」を例にして見てみます。数字が低いほど、優先順位が高いものとしています。

理想的な試験前日の学生のタスク想定

例えば、試験前日の学生は以下のような評価基準の優先順位を持っているものとします。勤勉そうですね。

1. 良い成績を納めたい
2. 万全の体調を確保したい

また、評価基準の優先順位に従うと、実施すべきタスクは以下のようになります。とても上手くいきそうに思いますね。

1. 勉強する
2. 寝る
3. 部屋を掃除する
4. 漫画を読む

実際に起こりがちな試験前日の学生のタスク想定

ですが、実際に実施しがちなタスクは以下のようになります。きっと徹夜に近いのに勉強は全く手つかずだったでしょう。

1. 部屋を掃除する
2. 漫画を読む
3. 寝る
4. 勉強する

自覚していない評価基準

評価基準の優先順位に従っているはずなのに、そうとは見えない決定をしている場合、自覚していない「暗黙の評価基準」が存在している場合があります。例えば、この学生の例では実際には以下のような評価基準や評価順位だったかもしれません。

1. （難しいことを考えたくない）
2. 良い成績を納めたい
3. 万全の体調を確保したい

暗黙の評価基準による問題

公にしている評価基準が「理想」に近ければ、暗黙の評価基準は「現実」に近いかもしれません。暗黙の評価基準で実際の決定が左右されている場合、「理想」と「現実」のギャップが起こりえているかもしれません。暗黙の評価基準があることで起こり得る問題として、以下が挙げられます。

• 暗黙の評価基準を隠すことに労力を使う

• うまく行かなかったときに改善が難しくなる

• 公になっている評価基準を満たしても満足しない

暗黙の評価基準を隠すことに労力を使う

例の学生の場合「試験前日はしっかり勉強するんだ」といっていたかもしれません。暗黙の評価基準は「公にしたくない評価基準」と言い換えらえる場合があります。暗黙の評価基準が公にならないように自分の行動に神経を割くため、公にしている評価基準に対しても注力しにくくなります。そのため、公にしている評価基準の達成も難しくなります。

うまく行かなかったときに改善が難しくなる

例の学生の場合「集中して勉強するために部屋を綺麗にする必要があったんだよ！」というかもしれません。暗黙の評価基準があると、暗黙の評価基準を避けるような問題分析を行いやすくなるため、自身の決定の何に問題があったのかの客観的評価が難しくなります。そのため、改善策が最適解から外れる場合があります。

公になっている評価基準を満たしても満足しない

暗黙の評価基準の優先順位が高い場合、「公にしている評価基準と本当に達成したい評価基準が別にある」状態だといえます。それにより、公にしている評価基準が仮に達成していたとしても、本当に達成したい評価基準が達成されていないために満たされない、という事態が起こりえます。
例の学生の場合「試験で良い結果が得られたけど、次の試験ではまた勉強やらないとなぁ、、、」となるかもしれません。

暗黙の評価基準にどう対応するか

暗黙の評価基準への対応方法は凄く難しい問題です。自覚がないことに加え、本人が公になることを避けたい問題であるから、そもそも「暗黙の評価基準が存在すること」自体、本人が否定したいことが多いです。

そのうえで「暗黙の評価基準を見つける方法」として挙げるのであれば、「下された決定から評価基準を予想すること」が挙げられます。本記事の序盤で述べた「決定が一意に定まらないのであれば、何かの情報が抜けているかもしれない」を元に、手持ちの情報で決定が再現できないのであれば、出揃っていない情報に目を向けるようにすることが、暗黙の評価基準を特定する方法の一つとして挙げられます。

また、「暗黙の評価基準」は可能な限り、自覚することをお勧めします。例えば「面倒だから」「大変だから」といった負の感情に基づくものでも、それに基づいて決定を下したことを受け入れると良いと考えます。それで良い結果が出なくても「自分はそういった感情で判断したのだから、仕方がない」と考えます。その結果を受け入れられるならいいでしょうし、その結果を受け入れられないのなら評価基準を改善していく必要があります。少なくとも、自身の評価基準と得られた結果のギャップは埋まるため、自分の決定に対する結果の納得感は得やすくなると考えます。

おわりに

「頑張っているのに成長しない」というのは色々なところから聞こえてきますが、自分自身がどのような考えに基づいて意思決定しているのかを客観的に知ることは、成長に必要な要素だと考えています。成長に繋がる決定を実現するために、私が意識していることをまとめてみました。

*1:評価基準の優先順位を決めるための評価基準もあって、どんどん人の根源的なところに関わってくるのですが、ここではそこまで言及しません

*2:大変なので、プライベートではそんなにやらないです。

2020/11/7（土）、スクラムフェス札幌2020（Day2）に参加しました。

オンラインでの「スクラムフェス札幌2020」の参加記録です。
www.scrumfestsapporo.org

Day0の参加記録は以下になります。残念ながらDay1は不参加*1でした。後でアーカイブ見ます。

toshimana.hatenablog.com

Day2はワークショップやOSTに参加して、リアルイベントに似た集中力で挑むことができました。私が参加したセッションは以下になります。

• アジャイルな組織を創っていくには？地銀で取り組むアジャイルな組織創り

• 未経験者中心のチームとベテラン中心チーム、Management 3.0のプラクティスはどう作用したのか？

• OST：OST１テーブルD「プロダクトオーナーの作り方」、OST2 : テーブルF「『考える力』『思考方法』について」

• 招待講演「Agile Sapporo: Learn from experience and continue to repair wholeness」

• クロージングセッション

アジャイルな組織を創っていくには？地銀で取り組むアジャイルな組織創り

RGST2020での発表の再演で、もともと45分の発表が20分に圧縮されて、さらに追加の話もあったりでした。内容は凝縮されていましたが、理解しやすく聞きごたえがありました。時間の都合で用意していただいた追加話が一部しか聞けなかったのが残念でなりません。

内製システムの作成していて、必要な作業時間に対して、開発にかかった総工数が2.7倍かかったことから、内製アジャイル開発がスタート。だけど、Web開発なのにWeb開発経験者が一人もいないぞ、ってところからのスタートという中々の状態で最初から度肝を抜かれました。

エピソードとポイントがまとめられていましたが、どれも等身大な問題で凄くグッとくる発表だと思いました。試行錯誤の様子がイメージできるようで、少しずつ成長して新しい問題に取り組む姿勢は見習いたい、と思いました。

speakerdeck.com

未経験者中心のチームとベテラン中心チーム、Management 3.0のプラクティスはどう作用したのか？

Management3.0のプラクティスを用いた改善事例と、プラクティスのワークショップがセットになったセッションでした。

事例紹介は「未経験者のチームに対して、プラクティスを試したらうまく行ったよ」と「ベテランチームはお任せしてたけど、噛み合わなかったからプラクティスで認識合わせたよ」というボリューム満点の内容でした。その状況に至る理由も納得しやすく、対応方法は凄く学びになりました。
特に、受け身なベテランチームに対して権限委譲のレベルを合意するためのツール「Delegation Poker」を適用したところ、想定以上にベテランチームが決める意思を持っていることが分かった例に感銘を受けました。実際に自分の環境でも起こりえそうな状況であり、対策方法は自分の手札にできるようにしたいと思いました。

ワークショップはManagement3.0のプラクティスの中から「Moving Motivatiors」と「Delegation Poker」を行うワークでした。
「Moving Motivators」は10個あるキーワードから、自分に合うものをTop3で選定する、というものでした。興味深かったのが、キーワードに対して人によって解釈が結構異なっていたことです。キーワードと合わせて深掘りしていくことでもっと相手のことが知れるようになる、と思いました。
「Delegation Poker」は「誰が、どうやって決めるか」の合意を取るツールですが、そのために「なぜそうやって決めるのを良いと考えているか」が議論の場に挙がってくることで、相手の考えに対する納得感が深まるように感じました。他のツールについても後で調べて試してみたい、と思いました。

speakerdeck.com

OST：OST１テーブルD「プロダクトオーナーの作り方」、OST2 : テーブルF「『考える力』『思考方法』について」

オンラインでのOSTは多分初めてでどういう感じで進むのかはドキドキしながら参加してました。

個人的目標である「一言以上発言する」は無事達成できましたが、題意に沿った話ができていたかは凄い不安ではあります。もっと頭を使わないと。

リアル開催と違って、オンラインOSTはどうしてもスピーカー中心にならざるを得ないところがあると序盤は感じましたが、後半はどんどん意見が出てきて聞いてても楽しめました。

招待講演「Agile Sapporo: Learn from experience and continue to repair wholeness」

「招待講演は札幌から」と札幌でソフトウェア会社を興して10年になる島田さんによる「大事だと学んだこと」の話でした。CEOという立場から、ということもあり凄く視野の広がるお話でした。

大事なものとして以下の4つが挙げられていました。

• 全体を意識する
• 感情に耳を傾ける
• 人ではなくプロセスをリードする
• 練習する機会を持つ

全体を意識する

当初から「全体」の意識が変化しており、より外側に、より長期的な視野に変わってきていることが印象的でした。いろいろな価値を提供していくうえでどれかではなく全部をやっていく必要があることや、人やチーム、組織が一致団結して成長しているさまを「いきいき」と表現していることに凄さを感じました。

感情に耳を傾ける

組織における評価は定量的評価が重視されすぎているが、感情に耳を傾けてもいいことがある、というお話でした。変化しないものはないから、その時その場所にいる人たちがどう感じているかと向き合う必要がある、というのは直感的にもしっくりくる内容でした。

人ではなくプロセスをリードする

リーダーシップの多くは他者を導くことが多くて気後れしてしまうことがあるけど、プロセスや場を動かすために必要なことならできそう、というはなるほど！と思いました。対人関係で悩む人は多いと思うので、今回のような考え方の変化が起これば受け入れられるケースがある、というのは新しい学びでした。

練習する機会を持つ

練習する機会として「アジャイル札幌」は最適ですよ、という内容でした。アジャイル札幌の立ち上げの思い出話やアジャイル札幌が如何にエンジニアの成長に貢献するかが紹介されて、アジャイル札幌との繋がりを感じるお話は3日間のスクラムフェス札幌を締めくくるにふさわしいエモさがありました。

speakerdeck.com

クロージングセッション

実行委員長による〆として、3日間を面白いトークを挟みつつ、振り返る内容でした。Day1に参加しなかったのが本気で悔やまれる…

おわりに

Day0はラジオを聴くように気楽に聞けましたが、Day2はワークショップやOSTを含んでいることもあり、「今自分は会場に居たっけか」と勘違いするほど集中して参加することができました。

現場感のある話が多く凄くためになったのに加えて、いろいろなところに遊び心の多さから、フェスらしさ、非日常感を感じることができたのかな、とも思いました。満足感がとても高いイベントでした。いつか現地で参加したいです！

*1:仕事のため

2020/11/5（木）、スクラムフェス札幌2020（Day0）に参加しました。

オンラインですが、「スクラムフェス札幌2020」に参加しました。
3日間のイベントのうち、初日であるDay0は前夜祭的な位置づけとのことです。

www.scrumfestsapporo.org

Day0は大きく以下の3つのコンテンツがありました。Day0のスピーカーは全員、札幌会場からの参加*1で、現地感がしっかり出ていると感じました。

• オープニングトーク

• 紙粘土スクラムから得たアンチパターン

• プロダクト生存戦略 : スクラムギャザリング東京の10年から学ぶ

オープニングトーク

前夜祭に乾杯から始まりました。しょっぱなから良い空気が漂ってくる感じが出てました。

札幌のスクラムイベントは自然災害にぶつかることが多いらしく、このスクラムフェス札幌2020も当初は4月の開催予定だったとのこと。COVID-19の影響で延期になりましたが、無事開催できて流石だと思います。

行動規範を序盤に共有したことは参考になりました。近年、行動規範を設けるイベントが増えてきていますが、私が参加したイベントでは初だったかもしれません。「こうやって共有するんだ」って運営側の視点で勉強になりました。

あと印象に残ったのは、つっこ飯ですね。食べたい。

hachikyo.com

www.youtube.com

紙粘土スクラムから得たアンチパターン

アジャイル札幌の名物イベントでもある、紙粘土スクラムで得られたアンチパターンを開発者（DEV）、スクラムマスター（SM）、プロダクトオーナー（PO）ごとに紹介いただきました。

紙粘土スクラムは、スクラムを用いて紙粘土で動物園を作るワークショップです。紙粘土で童心に戻るような感覚になる一方、短時間で4イテレーションを回す過酷さも併せ持ち時間が溶ける感覚を味わえる、とのことです。紙粘土なのに普段の仕事の仕方がはっきり出て来るし、毎回何かしらのドラマが出てきているそうです。オンラインでも紙粘土スクラムが体験できる*2らしいので、やってみたいです。

アンチパターンはどれも参考になったのですが、私が一番グッときたのは「過保護なSM（スクラムマスター）」でした。障害をSMが取り除き過ぎるためにチームが成長しないパターンのことで、改善ポイントとして「障害を直接取り除くのではなく、チームが障害を取り除く手助けをする」というフレーズがいいな、と感じました。「温室ではなく、野生で生きていけるチームを育てる」ともあり、昨今の不確実性に溢れている仕事の多い時代に適した考え方だと思いました。

プロダクト生存戦略 : スクラムギャザリング東京の10年から学ぶ

日本のスクラムイベントを牽引する運営チームによる、10年を振り返りを深夜ラジオのノリで語ってくださいました。

1回目のイベントの難しさや「チケットは売れたけどギャザ感がない」時期があったこと、徐々に主催が考えていない学びが増えてきていることなど、堅い公演では聞けないようなお話が聞けたように思います。

印象に残ったのは「最初は運営がウォーターフォールだったけど、慣れてきたらアジャイルになってきた」ということでした。運営が慣れてきてタスクが固まってくると、皆が自主的に行動できるようになってくる、ということがあったらしいです。イベント運営はアジャイルに行うことが難しいという印象が私にもあったために、「運営もアジャイルにできる」ということに対して、自分なりに深めて考えたいと思いました。

全体的な印象

スクラムフェス札幌は雰囲気づくりが凄い、という印象を受けました。

スクラムフェス札幌はDiscordを中心に色々告知なども行っているのですが、部屋などの作り込みが凄かったです。残念ながらDay0では特に部屋分けの効果はありませんが、Day1, Day2でその効果がみられるかと思います。

また、札幌感溢れるバーチャル背景が公開されていたり、北海道ギフトを頂けたりと、運営のたっぷりなおもてなしを受けることができます。Day0のコンテンツはすべてちゃぶ台ステージからの配信だったりと、いろいろと楽しませてくれる工夫で満載でした。

おわりに

Day0は前夜祭的な扱いと言われていますが、短い時間ながら満足度の高かったイベントでした。私はDay1は参加できず次はDay2の参加になりますが、おもてなし満載のイベントで今から楽しみです。

*1:フェイスガードなどの対策がされていました

*2:ただし、紙粘土は使わない