はんなりと、ゆるやかに

アジャイル、スクラムが好きが日々から学んだことをアウトプット

「言葉にできるは武器になる。」を読んで、「内なる言葉」と真剣に向き合うことに決めた

今年の抱負に「言語化を得意になる」と掲げましたので、それに近づくための書籍「言葉にできるは武器になる。」を読みました。

意見や想いを伝えるための「考えを深める思考法」、「伝わる言葉にするプロセス」が学べる書籍です。ブログ、プレゼン、ビジョンなど何かを伝えて周りにポジティブな影響を与えたい!と思った方は読んでみるとヒントが見つかりますよ。

自分は「何を伝えたいのか」にとことん向き合う

【1章「内なる言葉」と向き合う】、【2章 正しく考えを深める「思考サイクル」】は「内なる言葉」の大切さと深め方について書かれています。内なる言葉とは何でしょうか?それは、本書で以下のように紹介されています。

この「内なる言葉」とは、人が物事を考える時に頭の中で使っている言葉であり、考えを進める、広げる、深める、といったあらゆる側面で機能する。

考えたり、悩んだりしていると頭の中で色々な言葉が連想ゲームのように浮かんでは消えるを繰り返します。「今からお菓子を食べよう」「いや、でももう寝る前だし」「少しなら良いかな」「今日は仕事も頑張ったし」「ご褒美ご褒美」「でも、健康に良くないしなぁ」「甘さ控えめのお菓子ならいいかな」・・・こんな感じで頭の中は言葉であふれています

そう、あふれているから良くないのです。

頭の中だけで考えていると思考があっちいったりこっちいったり、たまにいったまま戻ってこれないこともありますよね。この状態は「考えたつもり」で考えられてないのです。

じゃあ、どうすれば良いの?

という問いに答えてくれるのが2章の正しく考えを深める「思考サイクル」です。

考えを頭の中から外に書き出す

本書では考えているときに浮かんだ言葉をすべて紙書き出しましょうと提案しています。先ほどのお菓子の例なら「今からお菓子を食べよう」~「甘さ控えめのお菓子ならいいかな」をすべて書き出します。

さっそく、この本の書評を書くときに試してみました。本を読んで思ったことを幅広く書き出してみたんです。すると、わかるんです。思ってたより考えてない。本を読みながら色々考えていたはずなのに、書き出してみるとあまり数は出ない。色々考えていたのは同じようなことを考えていただけだったと気付けました。

でも、ここで落ち込む必要はなくてここからさらに考えを深める思考法としてT字型思考法が紹介されています。詳細は本書を読んでいただければと思います。

本書を一読して良い本に出合えた!と思えた部分が、この考えを深める「思考サイクル」です。今年の目標にしている言語化のために深く広く考える癖付けが重要だと思っています。例えば「エモい」の一言で片づけず何がエモいのか、どうエモいのか、エモいとどうなるのか、と思考を深めたり広げることで伝わる言葉に置き換えられます。

言葉に自分らしさをのせる

【3章 プロが行う「言葉にするプロセス」】は自分と向き合って深まった自分の意見を言葉に変換するプロセスが紹介されています。大きく2つのプロセスが紹介されていて「日本語の「型」を知る」と「言葉を生み出す「心構え」を持つ」です。2つのプロセスで今までよりも伝わる文章になると感じました。そこの詳細は本書に任せて、このプロセスを使って「自分を言葉にのせる」ことが大切だと思いました。

本書でも書かれていましたが、ただきれいだけの言葉は響きにくいです。自分の経験や知識がのった言葉だからこそ響くのです。そのために「内なる言葉」と向き合うことが大切だと感じました。

まとめ

  • 言葉にできるは武器になる。を読みました。
  • 「内なる言葉」と向き合うことが伝わる言葉を表現するうえで大切
  • 自分の経験や知識で自分ならでは言葉も大切

2021年の抱負

新しい年がはじまりました🎍🐄
「一年の計は元旦にあり」なんて言ったりもしますので、今年の抱負です。頑張るぞ!

図解を得意になる

物事や考えを整理整頓するの苦手なんですよ。嫌いじゃないんですけどね。苦手。

苦手苦手とも言ってても変わらないので宣言してこの1年で得意になろうと思います。図解が得意になれば整理整頓スキルも高くなると思いますので、図解のパターンを知り、使うことでレベルアップしていきます。

ブログも図を多用していきます!

システム思考を得意になる

「SCRUMMASTER THE BOOK」もシステム思考について言及されていました。俯瞰して色々なことをシステムとして捉えられれば、良い課題が見つけられそうです。

「図解を得意になる」と合わせて武器🗡にできれば大きな強みになれそうなんですよね。

言語化を得意になる

今年の後半に「アオアシ」を読んで「言語化が大切だーーー!」となってます。すぐに影響されるんです。

alu.jp

このコマはプレーした内容を細かく説明しているシーンです。言語化により感覚でプレーした内容を考えて整理できます。言語化できるとふりかえりにも活用できますし、考える癖がつきます。

このブログも言語化の1つですね。さらに特訓の場所を増やすためにTwitterの投稿も増やしたいなーと思ってます。

健康

去年は5月ぐらいまでは継続してランニングできました。その後は暑かったり、寒かったり、とか言い訳をして止まってしまいました。今年こそ継続します!

計画立てて生活する

去年の抱負にも計画を入れていたのですが出来てませんでした。今年こそ!

まとめ

  • 図解、システム思考、言語化により課題の抽出や改善の質を高くする
  • 計画立ててやるべきことに力をかける
  • 決めたことはやりきる

「顧客志向」が「楽しい環境」を作る / 10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方に参加した

10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方」に参加しました。サブタイトル「「エンジニアが楽しい」環境をどう実現するか?技術トップがホンネで語ります!」も良いですね。

「顧客志向な開発カルチャー」と「エンジニアが楽しい環境」の両立を目指して日々開発に勤しんでいる僕としても興味深いテーマでした。

また、10Xさんは「Free Agenda」のPodcastで、みてねさんはアプリの利用者として普段からお世話になっているので、そんな企業の方々のお話が聞けるのも楽しみでした。

connpass.com

今回の配信はアーカイブ、公開されていますので、ご興味のある方は御覧いただけます。ありがたい。
www.youtube.com

今回のイベントは株式会社ミクシィの酒井さんと株式会社10Xの石川さんが自社の開発組織の説明をした後、参加者からの質問にパネルディスカッションで答える流れでした。詳細は動画に任せるとして、本記事はお話を聞いて僕が特に「おぉーー」と思った点に絞ってまとめていきます。

内容のハイライト

みてね さんの開発

  • サービスのミッションとは別に開発グループ向けにミッションがある
  • 自身の領域に閉じず、あらゆる物事に前のめりなチーム
  • エンジニアが責任感を持って、チャレンジしていく
  • 顧客にも、技術にも、好奇心を継続させる
  • 組織作りは理論だけじゃなく、課題から取り組んでいる

10X さんの開発

  • 状況に応じて何でもやる
  • Why/WhatまではPMが決めるが、Howはエンジニアに任せている
  • ビジネスチームがユーザーの声を集めて、言語化してエンジニアに伝える
  • 課題に対してビジネス1名、エンジニア2名の少数チームで開発している

パネルディスカッション

  • エンジニアが顧客を知る機会はどのような場があるのでしょうか?
    • 酒井さん
      • ユーザーインタビューに同席
      • カスタマーレビューを見たりリアクションしたり
      • 社内ユーザーにヒアリング
    • 石川さん
      • 専用チームからインタビュー動画やレポートがアップされる
      • エンジニアも現地に出向いて仕事を知る
  • 技術よりな関心の強いエンジニアに顧客志向な開発カルチャーを浸透させるには?
    • 酒井さん
      • ユーザーの声やアプリレビューの声に対して責任を持ってどう関わるか考えてもらう
      • 個々というよりチームとして顧客志向を目指す
    • 石川さん
      • メンバー全員が日ごろから顧客の声を聞くことが普通になっている
      • エンジニア力を高めるために顧客志向が第一じゃないメンバーも必要になる
      • チームへの貢献によりチーム全体が顧客志向になっている状態が良い
  • エンジニアチームが「プロダクトによる顧客の喜びやその手ごたえ」を感じながら楽しく働くために取り組んだこと
    • 酒井さん
      • わいわいの楽しさじゃなく、顧客の課題を解決してプロダクトを良くすることが楽しくなる
      • 人を褒める文化を作っていく
    • 石川さん
      • 大きく任せることを意識している
      • 自分で考えて、自分でリリースして、良いフィードバックがあれば嬉しい

他にも色々な質問があり、時間オーバーするぐらい盛り上がっていました。

学んだこと

今回のイベントで「顧客志向な開発カルチャー」と「エンジニアが楽しい環境」の両立を目指すために大切なことが見えてきました。

「顧客志向」が「楽しい環境」を作る

f:id:iucstscui:20201224004451p:plain

「顧客志向」と「楽しい環境」は関係性がありそうです。自分の開発したプロダクトで誰かの役に立ちたい。そういう志でエンジニアを目指した方は多いと思います。顧客の声を聞き、開発し、さらに顧客からフィードバックをもらうサイクルが回っていれば顧客志向で楽しい環境になりそうです。

そのためには、何ができるでしょうね。スクラムを採用していればスプリントレビューのタイミングで顧客の声を共有し話し合えたら良いなと思います。そんなとき、POだけじゃなくエンジニアから「こういう機能、どうですか?」とか話せると最高だな。

チームで顧客志向になる

f:id:iucstscui:20201224233348p:plain
かといって、1人ひとり全員が顧客志向は難しいです。エンジニアの個性もあるでしょうし、顧客の声が表れにくい開発もあります。バックエンドの改善やセキュリティ周りなど。こういった開発も貢献が感じられて、結果チーム全体として顧客志向になれると良い。

そのためには何ができるでしょうね。貢献と効果が目に見える形で表されて、良いこと悪いこと含めてフィードバックできると良さそうかなって思いました。良いことはすこし大げさにみんなで褒める!

Who/Why/Whatまで決めてHowからは一緒に進める

f:id:iucstscui:20201225001139p:plain
「POに言われたから作った」ではなく、自分が開発したと胸はって言えるよう「一緒に作った」感覚が欲しいですね。みてねさんも、10Xさんも、細かなタスクじゃなくて大きな仕様を渡して作り方はエンジニアに任せていました。

そのためには何ができるでしょうね。Howは決めずWhy、Whatまで決まったらエンジニアと共に考えるだと思いました。そして、考えるときは共通認識がブレないようにユーザーストーリーを使うと良いでしょう。「[Who]として[What]がしたい。なぜなら[Why]だからだ」の[●●]が埋まった段階で相談して、「じゃあ、こうすれば」「それも良いね。さらに、こうすれば。」「じゃあ、この機能は後回しでも良さそう」と会話の中でHowを決めていく。一体感が生まれ、コミュニケーションの中で予想を超えるHowも見つかると思います。

また、ユーザーストーリーを使えば[Who]が明確になるので自然と顧客に意識が向きます。

まとめ

  • 「10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方」に参加
  • 「顧客志向」と「楽しい環境」は関係性があり、「顧客志向」だから「楽しい」状態が良さそう
  • チームで顧客志向になる
  • Who/Why/Whatまで決めてHowからは一緒に進める

登壇、運営のみなさん、ありがとうございました!

2020年のブログふりかえり

今年も僅かになりました。年末といえばふりかえり。来年も楽しく過ごすために今年1年をふりかえりましょう。

今年の目標に対するふりかえり

年始に目標を設定したので、それに対するふりかえりです。

インプット、アウトプットを継続する。開発スキルをあげる。

今年もほぼ毎週ブログを書き続けることが出来ました。2年以上このペースを続けられて習慣になったなーと実感しています。

今年のブログ活動で一番大きかった出来事は2020/03〜2020/05の3か月間、カックさん(@kakakakakku / id:kakku22)にブログメンタリングしていただいたことです。この期間は新しい技術にも挑戦しましたし、ブログメンタリング以降の行動が積極的になったなーと自覚します。ブログのPV数も昨年の「約9000」から「約31000」と飛躍的に伸びました。定性的にも定量的にも伸びた年です。

この期間でブログと私は大きく成長しました。
カックさんに感謝です。

学習を促す環境をデザインできるようになる。

社内向けのイベントを多数立ち上げたり、学んだことをメンバーに共有する習慣が付きました。

健康

コロナ堝で運動不足にならないように、YouTubeで筋トレやヨガを始めてお腹周りが引き締まってきました!

計画を立てて進められるようになる

これは、まだまだ苦手。来年こそ計画立てて行動、ふりかえりの短いサイクルをまわしたいなぁ。

四半期ごとにふりかえる

今年を四半期にわけてふりかえっていきます。

⛄1-3月

2月にカックさんからブログメンタリング募集のアナウンスがありました。


この時点で1年以上は週一ブログ更新を続けていましたが、PV数の伸び悩みや自身の学びへの繋がりの薄さを感じていました。続けた割には伸びないな。。。という悩みを解消するために応募しました。

しかし、「ブログのライザップ」と呼ばれるブログメンタリング。

応募、悩みました。ブログメンタリングの紹介にあるノルマだったりペナルティを見ると軽い気持ちでは応募できません。でも、このままも嫌。ということで悩みに悩み申し込んだのです。ブログメンタリングの結果はブログにまとめています。

さっそく3月はブログメンタリング効果で今まで触れたことないCircleCIについての記事を3連投しました。

この期間でお気に入りの記事はこちらです。ブログ駆動で学んだ新しい技術です。

🌸4-6月

この期間はカックさんからのアドバイスもあり、 git に関する記事を増やしました。普段から使っているgitも知らないコマンドやオプションはたくさんあります。「知っているつもり」から「知っている」に変えるためにブログは良いきっかけになります。人に教えるようにブログを書くと、その技術について改めて調べます。そのたび新たな気づきがあり、理解が深まります。

6月はLTにもチャレンジしました。スクラムフェス大阪2020の「教えて!あなたの一歩を後押しした本」のセッションで本を紹介する企画に応募し、カイゼン・ジャーニーを紹介させて頂きました。

この期間でお気に入りの記事はこちらです。git を調べてこんなに便利な機能があるんだ!とブログを書くことで気づいた機能です。

🌞7-9月

9月は楽しみにしていた書籍「SCRUMMASTER THE BOOK」が発売されました。

スクラムマスターという役割は何をすべきなのか、どうすべきなのかが書かれた書籍です。ここに書かれている内容を体現できれば、理想的なリーダーになれそうですがまだまだ力足らずです。インプットしてもそれを、実践に投入する力が弱いんですよねー。

この期間は"対話"関連の本をまとめて読みました。特に「問いのデザイン」は実践にも活用できています。ブレストのミーティングを開催するときは設定する「問い」について考えるようになりました。前よりも活発に意見が出るようになったっと思っています。
人間関係は「箱」から出れば良くなる / 2日で人生が変わる「箱」の法則 を読んだ - はんなりと、ゆるやかに
効果的な問いでファシリテート上手になる / 問いのデザインを読んだ - はんなりと、ゆるやかに
仕事、子育て、プライベート、すべてを豊かにするためのコミュニケーション / NVC 人と人との関係にいのちを吹き込む法 - はんなりと、ゆるやかに

この期間でお気に入りの記事はこちらです。書評の中に日常と絡めた例や他で学んだ知識との関連をまとめられたり、本の要約だけじゃないオリジナリティがある書評になったと思っています。

🎄10-12月

新しく学んだことを調べてまとめて記事にすることが多いのですが、この期間は考えを整理しなおした記事が多かったです。それはNotionというツールを導入したことが大きいと思っていて、ふと浮かんだネタをNotionにさっとメモするようになりました。「タスクの重さと荷物の重さって似ている部分がありそう」という思い付きをメモにして記事にしたのが下記の記事です。

この期間でお気に入りの記事はこちらです。Notionを導入するとき色々な方の記事を参考にさせていただきました。その結果、今もNotionを活用して続けられています。自分の使い方もブログにまとめることで新たにNotionを始める方の参考になれば良いなと思って記事を書きました。過去の自分が知りたい情報をまとめたつもりで、読者の方を意識して書けた記事だと思います。

まとめ

  • 今年1年もブログを続けることができました
  • ブログメンタリングで大きく成長できました
  • ブログを書くことで成長の実感が出来はじめました
  • 来年は学んだことを実践に活かしていきたい

「ストーリーポイント」は「荷物運び」でたとえると分かりやすい

スクラムではプロダクトバックログアイテムを見積もるときに「ストーリーポイント」という単位を使います。

見積もりと言えば、「このタスクは2時間」「このタスクは7時間」といった時間🕒の絶対値で見積もることが多いと思います。「ストーリーポイント」は基準となるタスクから相対値で見積もります。

例えば、「ログイン画面を作る」をストーリーポイント「2」と決めて、「〇〇画面を作る」は開発部分少ないから「1」とか、「〇〇機能を追加する」は影響範囲が多いから「5」とかです。


ここで疑問がわいてきます。なぜ時間で見積もらず、まわりくどく「ストーリーポイント」で見積もるのか。どんな良いことがあるのか。


そこでピンっときたのが、ストーリーポイントを「荷物運び」でたとえてみる。です。

「荷物運び」と「ストーリーポイント」

f:id:iucstscui:20201210230449p:plain

ある地点からある地点まで大量の荷物を運ぶ必要が出てきました。この時、荷物の運ぶ時間を見積もることが時間見積もりです。荷物の重さを見積もることがストーリーポイントを使った見積もりです。

荷物を見積もろう

重さを見積もるのに「はかり」があれば正確に測れますが、過去の経験から見積もらないといけない場合、「これは10.235.kg」「これは2.173kg」と正確に見積もるのは困難ですよね。「これは10.235.kg、いや、10.245.kgか?、いや、・・・」なんてやっていると時間がもったいないですし、どうせ間違えます。また、直感で見積もっても時間かけても見積もっても、正確性に差が出ることは少ないです。こういうことを「収穫逓減の法則」と言います。

そこで見積もり時間短縮に有効な手段が相対見積もりです。基準となる荷物の重さを「2」と決めます。あとは簡単です。「これはちょっと重いから「3」。こっちは軽いから「1」」とぱっぱっぱっと見積もっていくのです。ただ、これも細かくし過ぎると見積もり時間がかかるので「1,2,3,5,8,13,21」のフィボナッチ数列を使われることが多いです。基準から遠い荷物はきっと正確な数値を出せないので選べる値も極端にします。

また、複数人で見積もる場合にもストーリポイントの利点がでます。
時間見積もりは同じ2キロの荷物でもAさんは1時間、Bさんは3時間、と能力によって見積もり結果に差が出ます。じゃあ、あいだ取って2時間にしようかってすると、どちらが作業しても見積もりミスになります。また、関係性によっては1時間で押し切られて、Bさんが作業したら大幅な見積もりミスになります。こんなときもストーリーポイントであれば荷物の重さを見積もるので個人能力で差が出ません

さらに、見積もりの差について話し合うことで作業の漏れや余計な作業をしようとしていることに気づけます。
Aさんが2kg、Bさんが10kgと大きく差が出た場合、「この荷物を運ぶときは合わせてこれもセットで運ばなきゃいけないんだよ。」「そうなの!?」って暗黙知を可視化できるのです。
f:id:iucstscui:20201210234639p:plain

全部運び終わるにどれぐらいかかるか予測しよう

時間で見積もった場合、1つひとつの見積もり時間を足せば「後50日で終わりそうだ。」と予想が立てられます。そして、1日目から遅れていくのです。

ストーリーポイントの場合、運ぶ重さは分かりましたが、どれくらいで運び終えられるかは分かりません。だから、とりあえず、運び始めます。1日目運んでみたら「10ストーリーポイント」運べることが分かりました。じゃあ、残りは「900ストーリーポイント」だから後90日で運べそうだとわかります。

ただ、時間で見積もった場合も1日目終わったあとにリスケをすれば良いので、結果は変わらないと思います。ただ、予想より2倍かかりそうって分かったら荷物1つ1つの見積もり時間を修正していく作業が発生しますし、上司やステークホルダーに「すみません、間に合いそうにないです。」と気が重い報告しなくちゃいけません。時間で見積もったら正確に見積もれたって気がしますが、そうでもないです
f:id:iucstscui:20201211003458p:plain

スクラムは時間固定で開発するから、ストーリーポイントの方が改善結果が分かりやすい

カイゼンマインド」を持ち、前よりもっと成長したいと思いながら開発していると思います。その場合、「成長したかどうか」を計測することが大切になります。

スクラムで開発する場合、1週間とか、2週間とか、固定の期間で繰り返し開発します。この固定期間で完了した数値をベロシティと呼びます。

開発期間は固定なので時間見積もりの場合、集計できる対象は荷物の数になります。荷物の数をベロシティにする場合、軽い荷物を13個運んだ日と重い荷物を1つ運んだ日でベロシティが異なります。何か改善しても次の日の運んだ荷物によってはベロシティが下がる可能性があります。「あれ?効果なかったかな?」っとなるのです。

ストーリーポイントの場合はその合計がベロシティです。ストーリーポイント「1」の軽い荷物を13個運んだ日と、ストーリーポイント「13」の重い荷物を1つ運んだ日で同じベロシティになります。(どちらも13)

たとえば筋肉がついて運べるスピードが上がった場合、1日のベロシティが「10」から「15」に変わって成長が見えます。また「荷台を購入する」という画期的なアイデアにより運べるスピードが格段に上がった場合も「10」から「30」と大きな成長が見えるのです。
f:id:iucstscui:20201211002425p:plain

まとめ

  • ストーリーポイントは荷物運びでたとえられる
  • 荷台は荷物を運ぶのに役立つ

参考にした記事

www.ryuzee.com
qiita.com

スクラムの背景を学んで改善しよう / 「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」を読んだ

スクラムの「なぜ」が学べる「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」を読みました。

ケン・シュウェイバー氏と共にスクラム」を確立したジェフ・サザーランド 氏によるスクラムです。いろんな本やイベント、実践を通じてスクラムの進め方についての知識はついてきました。さらに深く理解するためにスクラムの背景を知りたいと思い、手に取りました。

本書は一つ一つの要素が丁寧に書いてあります。スクラムの全体像が分かった状態で読んだ方が学びは多いと思います。SCRUM BOOT CAMP THE BOOKスクラムガイドを読んでスクラムオーバービューがイメージできる状態になってから、本書を読むと深く学べると思います。

目次

「進みが遅く、出来上がったプロダクトが使われない」という問題を解決するところから始まったスクラム。そんなスクラムの誕生の経緯からスクラムの核となる概念がまとめられています。

第1章 過去のやり方は通用しない
第2章 スクラムが誕生するまで
第3章 チーム
第4章 時間
第5章 無駄は罪である
第6章 幻想を捨て、現実的なプランニングを
第7章 幸福
第8章 優先順位
第9章 世界を変える

イベント一つ一つに歴史がある

当たり前と言えばそうなのですが、デイリースクラムにしても生まれた経緯があります。「デイリースクラムは15 分間、毎日、同じ時間・同じ場所で開催して調整するんだよ」というやり方だけ知っている場合と、「数百におよぶソフトウェア開発プロジェクトを分析して成功しているプロジェクトを視察したところ、仕事を達成するために必要なことをチーム全員が知っている状態が重要だとわかった。その一つの要素としてチームメンバーが毎日集まり話し合い解決していたので、それを取り入れたのがデイリースクラム。15分以内にしている理由は・・・」というように各イベントの背景を知ることで理解度が変わります。また、「なぜ15分なのか?」という理由も合わせて知ることで本質からズレずに自分たちの環境に合わせた改善ができます。

アップデートしたいと思った大きな3つ

僕はスクラムフレームワークを使って開発をしています。常にもっともっと改善したいと思っているのですが、本書を読んで特に開発の改善に繋げようと感じた3つを紹介します。3つ以外にも全然できてないなーって刺激を受けることがたくさん見つかった書籍です。

チーム

本書は理想のチームの一つとしてラグビー ニュージーランド代表の「チーム」と試合前に行われる「ハカ」について取り上げられています。

この「集中力」「一体感」「強い意志」「仲間が攻め込んだ時の歓喜と賞賛」といった要素がスクラムには組み込まれています。スクラムマスターはリーダーシップをとってこのような自己管理型のチームを目指していきます。本書を読んだり過去にも考えたのですが、ソフトウェア開発、プロダクト開発で目指すチームはプロスポーツチームと同じだと感じています。過去の記事でも同じようなことを書いています。

サッカーで例えるとスプリントプランニングは「試合前の戦術ミーティング」、デイリースクラムは「試合中の選手同士の会話」が近いと感じていて、そのメタファーでスクラムを捉えなおすと新しい発見があるかなって思っています。

ムリ・ムダ・ムラの観点

スクラムトヨタ生産方式の影響を受けていると書かれています。トヨタ生産方式と言えば「ムリ・ムダ・ムラ」ですね。本書でも「計画で無理を避ける、実行でムラをなくす。評価して無駄を削る。」と書かれています。スクラムではレトロスペクティブ、スプリントレビューがこの観点を使うメインのイベントになると思います。KPTでふりかえりするなら、Pを出すときにこの3要素の観点でふりかえりすると良さそうです。「間に合わなさそうだったから残業して間に合わせました。間に合って良かったです!」ではなく、ムリをして開発した原因はなぜかを考えていくと、今まで見えてなかった問題が見つけられそうだと思いました。

透明性

スクラムの3本柱である「透明性」は本書を読んでも改めて大切だと感じましたし、自分に足りていないと感じました。チームを阻害する要因の一覧(障害一覧やインペディメントリストと呼ばれます)を見せて開発の改善が進んでいく話があり、こういう使い方があるんだと気付きました。「透明性」となるとプロダクトバックログやスプリントバックログ、インクリメントが大切ですが、障害リストも同じように大切ですね。ちなみに障害リストは認定スクラムマスター研修でスクラムマスターが管理する作成物として紹介されました。(できてない。。。)他にも INVESTなプロダクトバックログアイテムなど大事だ大事だと思いながらも出来てないことがたくさんあるなぁっと反省です。改善していきます。

まとめ

スクラムは導入してOK!というシステムではありません。本書でも「スクラムは進化的で適応性があり、プロジェクトを進めながら修正していくシステム」と書かれていますし、スクラムガイドにも「スクラムフレームワークは意図的に不完全なもの」と書かれています。また、認定スクラムマスターの研修では「スクラムは問題を発見するフレームワーク」と紹介されました。スクラムは導入してからがスタートなのです。継続して改善するためにもスクラムの背景を理解してみるのはいかがでしょうか。

Synology Moments と Photo Station で同じデータを参照する

撮った写真を管理するためSynology社のNASであるDS120j を購入しました。このNAS、写真管理用のアプリが2種類あります。Photo StationSynology Momentsです。

www.synology.com
それぞれ機能に違いがあるのですが、今回の記事で取り上げたいのは保存場所です。保存場所に違いがあるのです。Photo Stationは/photo/を参照していますが、Momentsは /home/Drive/Moments/を参照しています。

どちらの機能も使いたくてPhoto StationMomentsそれぞれのアプリを使って写真をアップロードした場合、2重管理になります。この部分を解決する方法を調べました。今回は/photo/に写真データを保存し、Photo StationとMomentsはそのフォルダーを参照して表示する方法です。

写真は photo に保存する

File Station や Photo Station を使って写真ファイルを/photo/アップロードします。

Moments で 共有写真ライブラリを有効化する

共有写真ライブラリを有効化するとMoments が/photo/を参照するようになります。

Moments の設定画面を開き、共有写真ライブラリタブを表示します。有効化していない場合は下記のような画面になりますので、「共有写真ライブラリ有効化」をクリックします。
f:id:iucstscui:20201206230613p:plain

共有するユーザーの設定を行います。
f:id:iucstscui:20201206231210p:plain

完了です。

Moments で 共有写真ライブラリの写真を見る

はじめに書いたようにMomentsは /home/Drive/Moments/を参照します。参照するライブラリの種類を「共有写真ライブラリ」に変更すると、Moments が/photo/を参照するようになります。
f:id:iucstscui:20201206231530p:plain

まとめ

  • NASであるDS120j を購入
  • 写真管理アプリが2種類あり、どちらもフォルダパスが異なる
  • 共有写真ライブラリを有効にすると、Photo Stationの管理ファイルをMomentsが参照できる

参考記事

www.synology.com