2022年ふりかえり
ScrapboxにいったりObisidianにいったりフラフラして放置してるこのブログですが、ノージャンル的な記事の置場として久しぶりに更新。
2022年1月に今の職場(PKSHA Technology)に転職して、明らかに前職までと技術や人の水準が変わったので必死にキャッチアップして、その上でやりたいことに片っ端から首を突っ込む濃密な1年だった。
趣味では触ってるけど仕事ではない、みたいなレベルのものを含めると、React, Next.js, AWS, Terraform, CDK, Backend Python, Figma, etc... など色々と学んで実践して、ちゃんとエンジニアを名乗れるな、と思えるようになった。 要件定義の会議してる裏でFigmaでワイヤーフレーム書いて、そのまま諸々設計してAWS構成図書いてCDKでIaCしてAPI立ててReact書いて... みたいなことを入社して半年後にはやっているので、必要なことを必要なときにガッツリ習得する、みたいな振る舞いはそれなりにできたはず。
前職までは業務で関わる技術だけではエンジニアのキャリアとして不安が大きかったので業務外で色々と勉強してたが、今はそういう不安はあまりなく、プライベートで学びたいことと仕事の重なりが非常に大きくなっている。現時点では日々のキャリア的な不安はほぼ解消された気がする。
その一方で、個人的な勉強と仕事の境目がやや曖昧になったので、ある意味ではON/OFFのメリハリが弱まったかもしれない。
これ自体は幸せなことであって特に問題ではないが、集中力と生活の水準を上げるために意識的にON/OFFのコントロールは改善したい。
他にもメインの仕事をやりながら情報の可視化、コミュニケーション改善、オンボーディング構築などチーム改善っぽいことを色々実施。
直接の改善効果だけでなく、こういう領域に興味と強みがあるキャラクターとしてある程度認知してもらえたことは今後の自分にとってもチームにとっても有益なはず。
結果としてグループ横断イベントの企画、採用など、より広い領域に関わらせてもらえるようになっている。
また前職までは割と一般的な職場だったと思っているが、ベンチャーに転職した当初は違和感を感じるシーンも少なからずあった。
その際、チームのメンバーやEMときちんと対話して、違和感の背景となる過去の経緯などをきちんと聞くことの重要さを改めて理解した。
特にベンチャーだと1年で状況が激変するので、今見えてる状況とは全く違う背景が隠れていることがあると学んだ。
丁寧に対話して理解してその上で行動する。これを臆すことなく習慣的にやれているのは、自身の振る舞いとしても場の心理的安全性としても良い状態が作れている。
こういうシーンをチームのふりかえり(KPT)などの場でKeepとして言語化して表明するところまでセットで習慣化できている。
特に内部向けの広義なコミュニケーション(ドキュメント、アサーション、ファシリ、etc)は興味があり強みとしたい領域なので、ここの強化と実行を進めることができたのは良かった。
エンジニアリングに限らずプロジェクトマネジメントや採用など学ぶべきことは無限にあって力不足感は常につきまとうが、それはそれとして、1年前と比べると非常に大きく成長できたししきちんと価値提供できたとも思える。
学びが多く、その上で強みも発揮できた、充実した良い1年だった。
Scrapboxで書いてます
1枚絵でポモドーロ・テクニックのアレンジを紹介
ポモドーロテクニックを私なりにアレンジしたやり方を1枚絵で紹介。
実際に仕事をしながら1年以上続けている、限界までシンプルにしたやり方。
タスク管理というより集中テクニックとして、自分としては割と完成形。
紙のノート ＋ 物理タイマーが最強
ポモドーロアプリとかタスク管理ツール、スプレッドシートなど色々試したが、最終的に紙のノートにササッと書くのが一番手間がかからず継続しやすい。アプリと違って画面を切り替えることなく、机の上のノートにX書くだけで良いのが大きな利点。
折り返しやすいリングノートが便利。
Amazon | コクヨ ノート 4冊パック 6号 セミB5 A罫30枚 ス-T602A | 文房具・オフィス用品 | 文房具・オフィス用品
タイマーについては25分と5分が即起動できること、無音にできること、残り時間が見えることが重要。
この条件を満たすタイマーはかなり少ないが、タイマーの使い勝手はポモドーロ継続に非常に重要。
使っているタイマー↓
Amazon｜LIORQUE キッチンタイマー デジタル大画面 時計付け カスタム機能 消音切替
これもよさそう↓
Amazon｜Jコートン キッチンタイマー 大画面 5分、25分 勉強タイマー 多機能
参考
ポモドーロテクニックのざっくりした基本形はこちら
1枚絵でポモドーロ・テクニックの基本形をサクッと知る
2年以上つづけているポモドーロ・テクニックの基本形を1枚絵で紹介。
以前に名古屋の勉強会でポモドーロネタで喋ったときのものはこちら。
参考書籍
どんな仕事も「25分+5分」で結果が出る ポモドーロ・テクニック入門 | フランチェスコ・シリロ, 斉藤裕一 |本 | 通販 | Amazon
アジャイルな時間管理術 ポモドーロテクニック入門 | Staffan Noeteberg, 渋川 よしき, 渋川 あき |本 | 通販 | Amazon
スクラム初心者がRSGT2021から持ち帰るメモ
初参加のRSGTの内容や感想を会社に対してフルボリュームで報告するわけにもいかないので、スクラム初心者がスクラム未導入のSIerに持ち帰る資料作りのメモ。
組織・チーム・人
- チームが大事＜＞SIerの案件に人を割り当てる（可変）
- 「チーム」単位で練度、ツール、情報、etcが蓄積してレベルアップしていく必要がある
- SECIモデル
- ふりかえり、フィードバックを得てスパイラルを回す
- 「チーム作り」「共通認識」が重要 （長沢さんのコーチズクリニックより）
コミュニケーション
- オンラインコミュニケーションにおいて、顔出すの必須。顔が見えないと反応がわからないししゃべるタイミングもわからない。
- アジャイルコーチも社内研修の講師も同じこと言ってた。
- 練度が低いチームほど必須。
ツール
道具は本質じゃないけど、まずなにから整備するか
- CI環境・自動テストは現実的に必須
- 情報共有の整備。最新情報が常に全員に確実に手に入る状態。誰でも手軽にメンテできる状態。
- Scrapboxを使っている事例もあるとのこと。
テストの考え方
- テストの4象限の「不具合を出さないためのテスト」できてないし、スクラムやるには必須。
- コード書いてからテストではない。常にテスト。
- テストは単純作業ではなくもっと抽象的・包括的なプロセス。設計のリファインメント。
顧客との関係
- 準委任が望ましい(IPA,ryuzeeさん資料、他）
- 導入する案件や顧客について、ユーザが何を臨むのか明確にするのが重要。 予算や作るものが固定されているならアジャイルである必要はないしウォータフォールでよい。（OSTより）
- 共通理解、歩み寄り、共感（チーム・ユーザ）
- 「車が水の上／橋の上を走っている」という父子のエピソード。
その他（RSGT2021関係ないもの含む）
SI案件への導入
www.slideshare.net
NRIの開発チームの見学会
RSGT2021 Day2メモ
RSGT2021初日に参加したセッションのメモ。
※記憶に残ったもの、かつ解釈を加えたりしているので、純粋な記録ではありません。
What’s Testing Got to do with Quality?
DragonFire Inc. Agile Coach Janet Gregory
What's Testing Got to do with Quality? - Regional Scrum Gathering Tokyo 2021
クオリティは皆の責任。
品質が上がれば生産性は自動的に上がる。
品質の定義
「品質」の定義は難しい。（どのお茶がほしいか、という問い）
抹茶の品質は高いかもしれないが、好みじゃない人もいる。
品質はプロダクトによって異なる。
製造ベース＜製品ベース＜ユーザーベース＜価値ベース＜超越的
金融系システムを作っていたときに「フォントが小さい」というクレームが立て続けにあった。
システムは設計を満たしていた。クレームの原因がわからずユーザを訪問して確認した。
「Traderにとっては完璧だが後ろに立つSupervisorから見えない。小さすぎる」というものだった。
品質とはなにか？製品？人？プロセス？
ソフトウェアテスト
完成度や品質を調査、評価するプロセス
What is tesing? according to Janet
- フィードバックを返す
- 隠れた前提条件を特定す
- 製品の状態に関する情報が得られる
「車が水の上／橋の上を走っている」
という父子のエピソード。
視点が違うと見えるものが違う。テストをするには同じ目線になる必要がある。
歩み寄り、共通理解が重要。
Agile Testing Quadrantsの4象限
右側は不具合を見つけるためのもの。左側は不具合を出さないためのもの。
測定してフィードバック
チーム・組織に対して
Goodhart's law
指標が目標になったとき、それはもはや指標にならない」
カバレッジ80%を目指すために細工する、テストケース数やバグ数を満たすためにテストを設計する、などは違う。
参考：
品質を定義する
プロダクトによって求める品質は異なる。
複数の指標があり、製品によって求めるレベルは違う。
開発を始める前に対話することが必要。
Q&A
- Janetのいうテストはコミュニケーションツールとしての側面を持つのか？
- 「コーディングしてからテストするのをやめろ」と言う。 テストは設計やスコープなどの上位概念を含む。コーディングは活動。
- コミュニケーションは増えると思う。
- スクラムチームにテストの専門家がいる場合、POとどう関わるべきか？∞ループの側を担うことになる。
- コミュニケーションミスを生まないために開発チームと会話する際は3人組にするとよい（PO, QA, Dev)
スクラムにおける「完成」とはなにか？
Attractor Inc CTO / Agile Coach Ryutaro YOSHIBA (Ryuzee)
プロダクトとは？
価値を運搬するもの（プロダクトマネジメントでの定義）
プロダクト＝ソフトウェアではない。サービスなど多くのものを含む。
プロダクトバックログに含まれる可能性があるもの
- ソフトウェアの顧客向けの部分
- ソフトウェアの内部向けの部分
- プロダクトに関係するソフトウェア以外のもの
- プロダクトの将来の価値を生み出すもの（検証、実験、etc)
よくあるソフトウェアの完成の定義を作っても、バックログアイテムに画一的に適用できない。
※カバレッジ、ドキュメント、クロスブラウザ、etcを完成の定義とした場合
各領域に完成の定義を用意する。
枠組みを作って埋めること以上に、「共通理解」こそが透明性を生む。重要。
共通理解がすべて。
完成の定義をいつ作るか
スプリント1開始前が望ましい。
完成の定義をどう作るか
組織の標準があるならそれに従う。プロダクトの種類によって追加したり変更する。
組織の標準がないならスクラムチームで作る。
完成の定義をどう守るのか
- 全員が完成の定義の内容を理解しなければならない。
- 誰でも見える形で文書化する。
- 完全に記述することは不可能なので、レビューなど曖昧さや解釈の余地は残ってよい。
- 自動化できるものは自動化する。
- スプリントレトロスペクティブなどをきっかけに改善していく。
アジャイル戦略論 「チーム作りの巻」
Yosuke Matsuuraさん, Yasunobu Kawaguchiさん, Ken Matsumotoさん
要約・概要
- 成果の上がるチーム = 継続的なカイゼン文化 × 信頼関係の構築 × 成功体験の積み上げ
- チーム作りの6ステップ。以下6stepに沿ってまとめ。
- 一人目の仲間を作る
- 話し合いながらアウトプットする
- ものの置き場を確保する
- 成果をアピールする
- やったことをふりかえる
- 技術的負債を解消する
話し合いながらアウトプットする
- 圧倒的な量の失敗や経験をして改善し続けることで、質に転化するスピードが早くなる
- アジャイル開発は失敗や経験に重きを置いて、質に転化するスピードを早めている
ものの置き場を確保する
- ワーキングアグリーメント。共通認識を作る。
- 作ったものは全員が見える場所に置いておく。
- 置き場所にはこだわる。チームが見ない場所に置いても意味がない
やったことをふりかえる
- ふりかえる
- うまくいったこととカイゼン点を整理できる
- 改善を繰り返す
- システムの不具合を直すわけではなく、不具合が生まれるプロセスを直す
- なるべく高頻度(1日に1回, 15分に1回)にふりかえりする
- 心理的安全性がある場でふりかえりすること
- 全員が話すことが重要
技術的負債を解消する
- 目先の利益のために長期的な生産性を犠牲にした結果、チームが持続できなくなる
- トレードオフスライダーを作る
- 市況によってトレードオフは変化する。定期的に見直しをする。
- 技術的負債は可視化する(https://www.servantworks.co.jp/2020/making-tech-debt-visible/)
- ビジネスサイドの人への説明に有効。技術的負債を金額として表してみたりすると、納得してもらいやすい。
Scrumチームに「テストは単純作業ではなく創造的な活動だ」という意識を浸透させて良品質＆低コストの製品を作るようになるまでの物語
QA Engineer BizReach Inc. Yuya Kazama
https://speakerdeck.com/nihonbuson/agile-testing-essence-20201117 speakerdeck.com
事例1：仕様のリファインメント
実例をともなった会話をもとにコーナーケースの使用などを明確化。
事例から学ぶ実例マッピングのやり方 / Example Mapping
実装前にテストの考え方を取り入れる効果
コーナーケースなどテストの要点を抑えて開発される。 余計なバグやチケット起票、修正などの工数がかからない → 質によってスピードも改善
事例2：テスト実行
テスト実行までの過程
テストプロセス（JSTQB)より
分析＞設計＞実装＞実行
よくあるテスト設計レビューでは「テスト分析」としてテスト項目にフォーカスしがち。
「テスト設計（どうテストするか）」も重要。
「テストケースをへらす設計」の重要性。
※事例として、ケースを減らした上で不具合数も増えない
テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities
品質の作り込み
テストを減らせるかどうか、は設計レベルの話。 その時点でテストケースを考えるとともにことで開発時に余計なロジックを書かなくて済む。
テストマニフェスト
RSGT2021 Day1メモ
RSGT2021初日に参加したセッションのメモ。
※記憶に残ったもの、かつ解釈を加えたりしているので、純粋な記録ではありません。
アジャイルを忘れるチーム Unlearn Agile
発表者
オンザロード @kyon_mm
Regional Scrum Gathering Tokyo 2021 - アジャイルを忘れるチーム Unlearn Agile | ConfEngine - Conference Platform
取り組み
- 複数パターンのスプリント(15min / 1hour / 1day / 1week / 1month)
- KPT as ART
- ミーム…スーザン・ブラックモア
- パタンランゲージと性質…Sscrapboxでまとめている
- etc
パタン・ランゲージ
- 「つよくてニューゲーム」…繰り返し作業は効率がいい
- 「脊髄感謝」…ネガティブフィードバックは萎縮を起こす。ゆっくりした口調で感謝。
- 「ついでの一仕事」…始めるのは大変、ついでにやるのは簡単。
良いチームではなく「心地いいチーム」「心地いい共同作業」
Q.「心地いい共同作業」とは？その理由とは？
→オンサインとDiscordで発言大会。超盛り上がる。
「パターンを実行しているがうまくいかない」ことがある。
スクラムイベントやってるけど形骸化している、などはよく聞く。
一方で生き生きしているチームは確実に存在する。何が違うのか？
（びばさんオキザリス、筑波大学enPIT）
→直感＆客観を深く共感する
それに寄与するパターンはなにか？
チームの秩序マップ
ルール・原則・ガイド＞実験＞直観・客観の深い共感
たった一人からはじめて70人の縦割り組織にスクラム導入した話
Cyber Agent 鑓水 優行
背景
スマホアプリ開発の話。
デザイナや開発者、テスターなど非常に細かく職種が別れている縦割り組織。
職能別のサイロ型組織で、それぞれにリーダーやサブリーダーが存在する。
伝言ゲーム、タスク調整で忙殺されて仕事が進まない。
状況がわからないと不満が募る
→仕様まだ？実装まだ？
→デザイナ仕事遅い、プログラマ室が悪い…などの悪口が出始める
発表者自身はリーダーでもなんでもなく、特に権限もない。
その状態で影響を与えるための戦略
- タイミングを見計らう
- 体制変更、目標の変更、etc
権力者に直談判する
- 将軍の耳元でささやくパターン
-> Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 将軍の耳元でささやくパターン
信頼貯金は必要
-> 人を動かす難しい用語は使わない
- 既存のやり方を否定して対立を引き起こさない。
- 新しい言葉を使わない。拒絶反応を避ける。
- 効果測定…スクラム導入チームとそうでないチームでABテスト
スクラム導入した結果
タスク調整の負担がなくなった スケジュール調整という役割がなくなった。
課題
- 新しい言葉を避けた結果、いまだにスクラム用語は使えていない
- スケーリングできていない。教える側が不足している。
なぜ私はチームにい続けるのか。あるいは、エンジニアとしての成長のためのチームの活用について。
背景
レガシーなシステムの開発・メンテをひとりぼっち。
エンジニアとしての成長が感じられない日々。
→転職を決意
元々いたチームはいいチームだったが諸々の理由により解散。
転職のときに求めた条件
- 言いたいことを言えるチームであること
- チームを守る/守ろうとする人がいること
転職活動で人やチームを見るのは大変。
プロダクトは見えやすいが誰がどう当たらいているかは見えづらい。
とくに、そこに「自分」が入ったイメージを考えるのは難しい。
→社内で及部さんに出会う。同期、雑談ベースで機会、カフェスペース
自分は年上の部下など後ろめたさ… →「その懸念は実在するのか？」確認するしかない →「言ってみる」しかない
背中を預けられる安心感/背中を預かる緊張感
言ってみたことを聞いて前向きに動いてくれる。
失言があったときにそれを嗜めるとともに理由を伝えてくれる。
→「言っても大丈夫」という安心感
チームを安定させたい
「自分がボトルネックにならないこと」
自分がいなくてもできる状態を目指す。
→あれ？自分いらないのでは？
本業以外で経験を積んでチームに持ち帰る
日本人と外国人のディスカッション：日本でのアジャイルとスクラムの導入をどう加速すれば良いか？
Japan Intercultural Consulting Rochelle Kopp
Why this session?
日本におけるアジャイル・スクラム導入の課題に関して議論する - 文化的ハードル - 組織的ハードル
Q1.日本におけるアジャイル・スクラム導入で大変なこと
※この辺のセッション中のホワイトボード貼っていいんだろうか…駄目だったら教えて下さい…
Q2. アジャイル・スクラム導入における日本特有の難しさはなにか
- マネージャーが「自分がマネジメントされたやり方」を踏襲しようとする
- コードが書けない管理者が多い
- 新規メンバーを育成対象（能力がない、信頼しない）とみなす
Q3. 日本におけるアジャイル・スクラム開発の導入 を加速するための最もよい方法はなにか
- マネジメント層から変えるべき
- 成功事例を示す（Small win small start)
- 社外の人の力を使う
Great Scrum Master
Zuzi Sochova
Regional Scrum Gathering Tokyo 2021 - Great ScrumMaster | ConfEngine - Conference Platform
スクラムマスターの役割
「アジャイルをやること」と「アジャイルになること」は違う。 「アジャイルになるには数年の時間が必要であり、まだ私は途中にいる」。
- Teaching, Mentoring（最初の教育）
- Removing Impairment（障害の除去）
- Facilitation（ファシリテーション）
- Coaching（コーチング）
- Teachingと何が違うのか？ Teachingはその分野の専門知識が必要だがCoachingは違う。 その分野の知識がなくても「勉強の仕方」などは教えられる
- Observe（観察）
- その後の経過を観察する。トヨタの製造ラインの話。
スクラムを拡大していくために
- Curiosity（好奇心）
- Respect（尊重）
- Patience（忍耐）
- Playfulness（遊び心）
サーバント・リーダーシップ
別の会話にて
Servant LeadershipをLeader who servesと言い換えるという話があった。
サーバント・リーダーシップだと感覚的にリーダーではなく雑用する人、みたいな聞こえになりがち。
あくまでリーダであり、支援する人なのだ、ということを明確に表す言葉としてLeader who servesという言葉はいいのではないか。
スクラムマスターの学び
ソフトスキルについて講義などできちんと学んだことはあるか？
実際に現場のスクラムマスターに聞くとYesは10%もない。
Join My Class
認定スクラムマスター資格。
オンライン講座あり。
割引コードもあり。
アギレルゴ アジャイル研修
Q&A
- サーバント・リーダーシップの素養はなにか？ジュニアには難しいのでは？
所感/Discordの会話
「文化人類学者であれ」の言わんとすること
「こうあるべき」を押し付けるのでなく、そのチームのありのままを観察して、なぜこういう行動をとるのだろうというのを興味をもって考察する。
観察をしたらコントロールしなければいけないという先入観を無くせ！というための言い換えとして、文化人類学なんだろうか。
技術的な部分も知識や経験を持っておくと「共感」というツールの幅のあるコーチャーになっていけるって感じなのかなぁ。
技術に限らず、経営的な知識・視点を持てれば上位層に対しても共感しやすくなり、巻き込みやすくなる？
実際に仕事をすすめるために、かつ自分の共感のチャンネルを広げるために知識・スキルはあるにこしたことはない、という感じかな。
とはいえ時間は有限だし好奇心にも偏りはあるので、とても難しい。
とにかく知り合いを増やすことを目的とした会
Growth Architectures & Teams, Inc. Agile Coach Saito Norihiko
Rakuten Inc. Manager Shinya Ogasawara
Regional Scrum Gathering Tokyo 2021 - とにかく知り合いを増やすことを目的とした会 | ConfEngine - Conference Platform
ランダムにグループ分けして記者会見をテーマにした質問会。
私は知り合いゼロで参加してたので、ほんっとーーーーーにありがたいセッションでした。
企画していただいてありがとうございます！！
関連リンク
セッションやDiscordで言及があった書籍など。
記事・サイト
書籍
- Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- パタン・ランゲージ―環境設計の手引
- 人を動かす 文庫版
- 教育学概論-第2版 (教師教育テキスト)
- アリ語で寝言を言いました
文化人類学…Zuziの話で度々出てくるもの
