スクラムとSECIモデルの関連を考えた

スクラムについて調べると「SECIモデル」というキーワードに触れることがあります。SECIモデルとはスクラムの生みの親と言われている 野中 郁次郎さん が提唱した、ナレッジ・マネジメントの枠組みのことです。そのため、SECIモデルとスクラムは関係性があると言えますね。今回はSECIモデルにスクラムを当てはめてみるとどうなるか という点について考えてみようと思います。

SECIモデルとは

以下の記事が分かりやすいです。
SECIモデル（せきもでる）：情報システム用語事典 - ITmedia エンタープライズ
【野中郁次郎氏対談】第1章 組織で「知」を生み出すための起点は、「共感」をベースにした「対話」 | Hello, Coaching!
テレワーク環境でのコミュニケーションとナレッジマネジメント〜SECIモデルから考える〜｜ほったりょうと｜note

SECIモデルは暗黙知から形式知、形式知から暗黙知というサイクルを繰り返すことで「知」を進化させていくフレームワークです。4つのフェーズに分かれます。
共同化（Socialization） は暗黙知を共有するプロセスです。「共感」によって個人と個人の知識を結びつけます。
表出化（Externalization）は暗黙知を形式知にするプロセスです。多くの人に伝えられる情報になります。
連結化（Combination）は形式知同士を結合し、新たな形式知を生み出すプロセスです。
内面化（Internalization）は形式知を実践し経験により暗黙知を得るプロセスです。

この4つのフェーズを「共同化→表出化→連結化→内面化→共同化→・・・ 」の順に回しながら「知」を進化させていくのです。

スクラムとSECIモデル

さて、このブログのメインです。スクラムの「デイリースクラム」や「プロダクトバックログ」とSECIモデルはどういった関連があるのか考察してみました。

スプリント

1ヵ月以内のサイクルで他のスクラムイベントを進めていく「スプリント」はSECIモデルをまわすことにつながると思います。スプリントを繰り返しながら、暗黙知→形式知→暗黙知 を進めて「知」を進化させていくのです。

スプリントプランニング

「プロダクトバックログ」という形式知から「スプリントバックログ」という形式知を生み出す「スプリントプランニング」は「連結化」に当たると思います。
また、「スプリントプランニング」はプロダクトバックログアイテムについて「価値は何か？」「どうやって作るのか？」という対話を行います。「プロダクトバックログ」で形式知になっていなかった暗黙知を引き出すこともするため「表出化」にも当たります。

デイリースクラム

1日分の作業を共有し、スプリントゴールに向けて適応していく「デイリースクラム」は暗黙知の共有にあたる「共同化」に当たると思います。起こった事象に共感し、チームの「知」を育てていくのです。

スプリントレビュー

スプリントの成果を確認し、プロダクトバックログを更新する「スプリントレビュー」は「連結化」に当たると思います。すでに完成している成果(形式知)からプロダクトバックログ(形式知)を生み出すのです。

スプリントレトロスペクティブ

今回のスプリントの暗黙知を共有し、次スプリントに向けて改善を決定する「スプリントレトロスペクティブ」は「共同化」に当たると思います。実績と感情を共有することで「共同化」が進み、共感し具体的なアクションに繋がるのです。

プロダクトバックログ・スプリントバックログ

プロダクトの改善に必要な一覧である「プロダクトバックログ・スプリントバックログ」は「形式知」の塊です。スクラムチーム全員の形式知となり、この「知」をベースに開発するのです。

インクリメント

開発し作成される「インクリメント」は「形式知」です。「形式知」はドキュメントというイメージもありますが、動くソフトウェアはそれ以上に価値のある形式知だと思います。

まとめ

スクラムでSECIモデルのサイクルを実践できる

• 「スプリントプランニング」は「表出化」と「連結化」
• 「デイリースクラム」は「共同化」
• 「 スプリントレビュー」は「連結化」
• 「スプリントレトロスペクティブ」は「共同化」
• 「スプリント中の開発」は「内面化」
• 「プロダクトバックログ・スプリントバックログ・インクリメント」は「形式知」

図にするとこんな感じです。冒頭に貼った図と同じです。

暗黙知も大切

暗黙知は形式知にした方が良いとは思っていましたが、暗黙知をためた方が良いと考えたことがなかったです。SECIモデルはそのことを教えてくれます。このインタビュー記事(【野中郁次郎氏対談】第1章 組織で「知」を生み出すための起点は、「共感」をベースにした「対話」 | Hello, Coaching!)に「SECIモデルは、共感」から始まります。」という言葉があります。共同化フェーズで対話を通じて共感し知的なぶつかりあいを起こすことがイノベーションに繋がると書かれていました。スクラムの各イベントも暗黙知を持ちより、対話し、共感することが大切だと気付きました。

関連する過去記事

対話を学ぶときにお勧めしたい一冊です
iucstscui.hatenablog.com

スクラムについていろいろと記事を書いてます
iucstscui.hatenablog.com

文章力をあげるため 理科系の作文技術 を読んだ

わかりやすい文章を書きたい。伝わる文章を書きたい。誤解を与えない文章を書きたい。ブログだったり、仕事だったり、文章を書いていると願うことです。そんな期待に応える本が「理科系の作文技術」です。

理科系の作文技術 (中公新書 (624))

1981年に発売された本が今も名著として読まれています。古さを感じる部分もありますが、それはほんの一部で今も普遍的に使える内容ばかりです。明快・簡潔な文章を書く技術を学びたい方にお勧めできる一冊です。

読み終えたあとの大量のメモの中から、
　①大切にしたいと思ったこと
　②すぐに使い始めたテクニック
をピックアップしてまとめていきます。気になったらぜひ本書を手にとって見てください。

心構えと技術が学べる

文章の目的と対象読者は明確になっていますか？〈目的〉は書くテーマが決まっているだけでなく、そのテーマについて伝えたいメッセージを決めることが大切だと書かれています。また、(i)対象読者は何を知りたいと思っているのか、(ii)本文を理解する前提知識はあるのか、によって書く内容が変わると書かれています。

「目的と読者を意識しましょう」は同意できますが、実践が難しいですよね。本書はその実践〈も〉教えてくれる一冊です。たとえば、読者のために書くとは、序文で(i)本論に必要な予備知識、(ii)本論を読むべきかどうか判断する情報、を与えることを勧めています。本論では(i)概要から詳細の順序で書くこと(ii)読者が知りたい情報から書きはじめること、を勧めています。他にも多数の技術が書かれています。

このように、心構えとそれを実現する技術について書かれているので、技術を学ぶモチベーションが上がります。手段と目的はセットで説明することが大切だと改めて思いました。

事実と意見

事実と意見が混ざると不当な結論が導き出されることがあるため、仕事の文章では事実と意見を区別することが大切だと書かれています。事実は誰もが同じ結論になるもの、意見は人によって結論がかわるものです。たとえば、「汚い部屋」は事実のように思えますが意見です。同じ部屋を見て、汚いと思う人もいれば普通と思う人がいます。「おもちゃが50個以上落ちている」が事実です。事実と意見をわけることについては NVC（Nonviolent Communication＝非暴力コミュニケーション）でも登場していました。言葉でも文章でも人に伝えるときは事実と意見を分けることが大切ですね。
iucstscui.hatenablog.com

すぐにマネできる技術が多数

この本で学んだことはさっそく仕事の文章に活用しています。すぐに活用をはじめた技術を少し紹介します。

並記の方法

本ブログの前半でも書いた

読み終えたあとの大量のメモの中から、
　①大切にしたいと思ったこと
　②すぐに使い始めたテクニック
をピックアップしてまとめていきます。

という書き方です。一つの文で AとB のように複数の事柄を並べて書くときは番号を打つという技術です。AとB それぞれが長くなる場合、読みにくい文になって困っていたのですが、この方法を知ってからは多用しています。
以下のように改行しなくても読みやすいです。

読み終えたあとの大量のメモの中から、①大切にしたいと思ったことと、②すぐに使い始めたテクニックをピックアップしてまとめていきます。

トピック・センテンス

パラグラフ(ある一つのトピックについて述べた文の集まり) にはパラグラフを要約した一文を先頭に書きましょう。これが、トピック・センテンス です。文章の構成として概要から詳細の順序で書いたほうが良いと紹介しました。それはパラグラフにも当てはまるということです。一行目でパラグラフの主張を頭にいれてから詳細を読むことで理解しやすくなるのです。また、「読者が知りたい情報から書きはじめる」という心構えとも関連します。

他にも多数の技術が紹介されています

私がメモした内容を抜粋すると下記です。

思いつくままメモ

「2.5 材料あつめ」の章で、主題を頭のどこかに置いておき、何かをきっかけに浮かんできたアイデアやキーワードをとにかくメモすることをお勧めしています。あとから読み返して使えなくてもいいから、とにかくメモせよと。あのとき思いついたアイデアなんだっけ？ということありますよね。「この問題とあの問題は似ているな」「この技術を応用すれば解決できるかも」「もしかしたら、関連がありそうだ」とか。とにかくメモしましょう。ブログのネタ出しにも使える方法ですね。

まとめ

• 理科系の作文技術は今読んでも学びの多い書籍
• 読む人を意識して書く
• 意識だけでなく技術も多数書かれている。

伝わりやすい文章を学べました。日々の開発で文章を書くことが多いですし、ブログでも毎週書いています。少しでも読みやすく書けるように本書を参考にしたいと思います。

現在のブランチ名が取得できる git rev-parse を調べた

git rev-parse --abbrev-ref @ というコマンドを見かけて、「rev-parse？」「--abbrev-ref？」とちんぷんかんぷんだったのでrev-parse コマンドについて調べました。ちなみに、git rev-parse --abbrev-ref @ を実行すると、現在のブランチ名が取得できます。同じようなことはgit branch --containsでもできますが、取得できるブランチ名の先頭に「*」が付くのでブランチ名だけが欲しい場合は前者を使った方が良いですね。

git rev-parse は他に何が出来るかを調べました。

git-scm.com

git rev-parse --abbrev-ref @

現在のブランチ名が取得できます。これは便利です。

$ git rev-parse --abbrev-ref @
testBranch

ブランチ名を指定すれば、同じブランチ名が取得できますが、どんな時に使うかはわかりません。

$ git rev-parse --abbrev-ref master
master

git rev-parse @

ブランチが指すコミットのハッシュ値が取得できます。

$ git rev-parse @
71d...(省略)...cb6

$ git rev-parse master
d4d...(省略)...46c

git rev-parse --show-cdup

カレントディレクトリから最上位ディレクトリまでの相対パスが取得できます。サンプルは test1/test2/ のディレクトリから実行した場合です。

$ git rev-parse --show-cdup
../../

git rev-parse --show-prefix

--show-cdup と逆で最上位ディレクトリからカレントディレクトリまでのパスが取得できます。

$ git rev-parse --show-prefix
test1/test2/

git rev-parse --is-inside-work-tree

カレントディレクトリがgitリポジトリかどうか判定されます。

$ git rev-parse --is-inside-work-tree
true

「ユニコーン企業のひみつ」を読んで、働き方を考えた

ユニコーン企業のひみつを読みました。本書はSpotifyモデルで有名なSpotifyがどういった思想でどういった開発をしているのか教えてくれる本です。

本書を読んで感じたこと、取り組もうと思ったことを中心にまとめていきます。

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

Spotifyをユニークな開発組織として知ったきっかけはSpotifyモデル

Spotifyは音楽やポッドキャストを楽しめるストリーミングサービスで、僕も使っています。Spotifyはサービスとしても良いサービスなのですが、それとは別にSpotifyモデルと呼ばれる開発手法としても有名です。僕もこの開発手法を知り、Spotifyを音楽サービスの会社ではなく、ユニークな開発組織として意識するようになりました。
Spotifyモデルは以下の記事が詳しいです。
lean-trenches.com

また、2020年にSpotifyはSpotifyモデルを使っていないという記事が注目されたことから多くの方が参考にされる手法だと分かります。本書のあとがきにも今のSpotifyモデルと今のSpotifyとの違いが説明されています。同じモデルを使い続けるのはアジャイルな感じがしないので、有名になった当時のSpotifyモデルが使われていないことは正しい進化だと思います。
agile.quora.com

権限と信頼

本書を読んで一番印象に残ったことは信頼して権限をチームに渡すことです。Spotifyモデルではスクワッドと呼ばれる職能横断の少数のチームで開発されます。スクラムでいうスクラムチームに似ています。カンパニーベットと呼ばれる抽象度の高い会社としての重要事項(たとえば、「モバイルに注力する」)は示されますが、具体的な方法や実現手段はスクワッドで考え決定します。あらゆる情報はオープンにされ、色々なことがチームで決められる仕組みや制度が整えられていました。

「信頼されている」という感覚はモチベーションに大きく影響を与えますね。そして、権限があればスピードも向上します。信頼と権限は開発を進めるうえで大切なことだと改めて思いました。権限が大事だからといって「よしよし、権限委譲が大事なんだな。すべて任せる！」っとなると混乱すると思いますので、デリゲーションポーカーなどを使って期待値と現状をすり合わせて進めるのが良さそうですね。

マネしてはダメ

10章では本書で学んだことの活用方法について書かれています。その中に以下の一文があります。

世界有数の企業の取り組みの研究を続けて、自分たちの役に立ちそうだと思えるものなら何でも試してみることを、私個人としては強くおすすめるする。
～中略～
他所でやっているからといって、そのままコピーしてはだめだ。

完全、同意です。

「Spotifyモデルは良さそうだ！さっそく、明日から体制を変えよう」は良くないですね。チームや組織が混乱するだけです。これはSpotifyモデルに限らず、「スクラム」「アジャイル」などどれでも同じです。学び続けることは大切だと思いますし、好奇心があるのは強みです。だからといって今の会社、組織、チームの状況を無視して当てはめると明るい未来は待っていません。僕も経験済みで、こんな発表をしています(笑)
iucstscui.hatenablog.com

何か新しく魅力的な手法を見つけると、今の問題をすべて解決する手法だと勘違いしてしまいます。でも、そんな銀の弾丸は残念ながらありません。「スクラム」のようなフレームワークの形になるとマネしやすく広まりやすいですが、状況に合わせて取り入れ方を工夫しないとうまくいきません。

スクラムフェス大阪2020のふかやみわさんのお話で「やりやすそうな仕掛けは何か間違っている」という言葉があり、ハッとしました！色々なフレームワークはヒントにはなりますが、答えにはならないのです。

「手伝おうか？」

6.6章のタイトルです。次の僕のステップはこれだと思いました。まだまだ自チームのことだけを考えがちです。局所的にはチームという単位で区切られていますが、視野を広げれば同じチームです。視野を広げて自チームで得た情報を外に公開したり、他チームが困っていそうな雰囲気を感じたら声をかけたり、していこうとおもいました。

「手伝う」というよりも、そもそも「それも含めて自分の仕事」と捉えて開発していきたいと思いました。

訳者のあとがき を実現したい

訳者のあとがきに「毎朝、仕事に行きたくなるような、全力を尽くしたくなるような・・・」という一文があります。

scrapbox.io

こちらも完全に同意です。僕も含めて一緒に働くメンバーが毎日充実して楽しく過ごせる環境を作っていきたいと思います。

まとめ

• Spotifyの働き方や文化を知れる一冊です
• とても読みやすい本です
• Spotifyモデル はマネをするのではなく、自分たちの環境に合わせて適応させた方が良いです
• 毎日、楽しく働きたい

その他、参考記事

スクラムフェス大阪2020 の参加記事書いてます
iucstscui.hatenablog.com

本書でも「学習」が大切だと取り扱われています。僕も「顧客に寄り添いながら継続的に学習している状態がアジャイルじゃないかな」と思っています。
iucstscui.hatenablog.com

システム思考のレベルアップが出来る本 / 世界はシステムで動くを読んだ

世界はシステムで動いている。

問題が起こるたびに再発防止策を考えているのに同じ問題が起こってしまう。良くしようと思って考えた施策が悪い影響を及ぼした。問題は起こっているけど、原因が見つからない。

今を良くしようと考えているのに上手くいかないことありますよね。その原因は出来事に注目して、問題が発生する構造を理解できていないからです。

今回読んだ本「世界はシステムで動く」はシステム思考という考え方を活用して、出来事が起こった構造を見つけて効果的な改善点(レバレッジポイント)の見つけた方を学べる書籍です。

世界はシステムで動く ― いま起きていることの本質をつかむ考え方

システムとはなにか

システムは「要素」「 相互のつながり」「 目的」 の3種類で表現される構造のことです。たとえば、自転車のシステムならこうです。

体力と筋力の力をインプットとして自転車の性能に伝えられ動力に変わります。その力が速度へ変換されるのです。

ポイントは何を要素として洗い出すかです。この図を書くときも悩みました。洗い出す要素が多すぎても少なすぎても良くないでしょう。もっと詳細にもっと広く洗い出すこともできるので、事前に分析する範囲を決めることが重要だと思いました。

この図、「要素」「相互のつながり」はありますが、「目的」はありません。しかし、システムにおいて目的は重要です。(目的は図に表現しないと思ってますが合っているのかな。。。)

自転車で速度を出す目的が目的地に着くことなのか、自転車レースで優勝することなのかによってレバレッジポイントが変わります。「目的地に着く」ことが目的であれば、「体力」「筋力」にプラスして「電力」を追加し、電動自転車として速度を出す改善案が浮かびます。目的が「自転車レースで優勝」の場合は電力を追加するわけにはいきませんので、「体力」「筋力」を高める改善案を考えるわけです。

こんな感じで分析したいシステムを捉えることで改善案が見つかります。

ストックとフロー

上記の図の中で四角で囲った減ったり増えたりする要素はストックと呼ばれ、ストック同士をつなぐ矢印がフローです。何度かシステム思考を使って分析しようとしましたが、何かしっくりこないことがありました。今思うとストックとフローを意識できていなかったため、矢印のつながりが曖昧になっていたように思います。

ストックに入るフローをインフロー、ストックから出るフローをアウトフローと呼び、改善案を考える時はどちらも対象になります。

フィードバックループ

システム思考で図を書くときには2種類のフィードバックループを見つけます。

• バランス型フィードバックループ：目標を保とうとするループ
• 強化型フィードバックループ：変化を増進するループ

たとえば、バランス型フィードバックループは以下の形です。

目標速度を保つために、体力を使って加速するループです。このような形でシステムを考えるといたるところでループが見つかります。スケジュールを立てて開発を進める時もスケジュールを間に合わせようというバランス型フィードバックループがありますよね。改善案を考える時は悪影響を及ぼしているループを見つけるんですね。

システムは生き物

システムには３つの特徴があると書かれていました。

• レジリエンス：環境が変わってももとに戻ろうとする力
• 自己組織化：システム自体がシステムを変える力
• ヒエラルキー：システムの中のサブシステム

この特徴について読んでシステム自体が意思を持った生き物のように感じました。この感覚を持てたことは大きい。人を変えることは難しいように、システムを変えることも同じように難しいです。

パターンがある

変えることは難しいと言いつつも、本書には問題のパターンと介入するポイントに関するヒントが「第5章 システム の 落とし穴…… と チャンス」「第６章 レバレッジ・ポイント システムの中で介入すべき 場所」に書かれています。システムを分析したあとは5章、6章を辞書のように使っていこうと思います。

6章に書かれていた「パラダイムを超越する」は最近もやもやしていたことが繋がった感覚がありました。(パラダイム=前提)が変わるような考えを受け入れる状態を保ち続けることが変化に強くなる要素だと思いました。

システム思考はあらゆる場面、範囲で使える

範囲の大小に限らずシステム思考の考え方は有効でしょう。しかし、使いこなすには経験が必要です。小さな部分から使ってみます。

関連

iucstscui.hatenablog.com

子どもとScratchでペンギンゲームを作った

2020年度4月から小学校でも「ブログラミング教育」が始まったそうです。小さい頃からプログラミングに触れておくと、プログラミングの授業が始まっても不安が減りますね。

今回は子どもとドットインストールを見ながらペンギンゲームを作りました。子ども向けのレッスンというわけではありませんが、子どもでも集中して楽しく取り組める内容でした。僕はドットインストールの再生だけして、「Scratch」の操作は子ども1人で行えました。※もともと、子どもは「Scratch」に触れたことがあるレベルです。

作ったゲームはこちらです。右から大小の氷が流れてくるので、スペースキーを押してジャンプしながらよけてハイスコアを競うゲームです。

ドットインストールのページはこちらです。
dotinstall.com

レッスンが細かく分かれているのでリズムよく進む

ペンギンゲームのレッスンは1～3分の動画が全23回分あります。1回の動画が短いため「動画を見る→「Scratch」を書く→動画を見る→「Scratch」を書く・・・」とリズムよく進められます。また、動画が短いので子どもの集中力も途切れなかったです。横で見ていた下の子どもは「すぐにおわるやーん」っと笑ってましたが。

作るものがおもしろい

ゲームを作れるということ自体が子どもの興味を引きます。作ったあとも弟と作ったゲームで遊んだり、作ったゲームをさらにオリジナリティを加えて楽しんでいました。

簡単すぎない作り

ジャンプのコードを書くレッスンで感心しました。y座標をただ移動させるだけではなく、自然なジャンプになるように、頂点に向かって徐々に速度を遅くし、頂点から地面は徐々に早くなるように説明されます。ただ作るだけでではなくゲームとして成り立つ工夫がされていました。

まとめ

プログラミングを始める時は「何を作るか」を決めることが第一関門です。単純に足し算するようなプログラムを書いても面白くはないですよね。ゲームを作ることで、楽しく学べ、作った後も遊べるのでお勧めのレッスンです。

「偏愛マップ」と「みんなで記者会見」を混ぜてみた

「偏愛マップ」と「みんなで記者会見」を混ぜたプラクティスをやってみたので感想です。プラクティスの名前は「偏愛 記者会見」とでもしましょう。ワイワイ盛り上がれました。

「偏愛マップ」はこちらで紹介されています。
tamkaism.com
uxmilk.jp
「みんなで記者会見」はこちらで紹介されています。
springaki.github.io

やり方

1. 時間を決めて好きなものとにかく書き出す(偏愛マップを作る)※事前に作っても良い
2. インタビューアー(聞き手)複数人とインタビューイー(話し手)1人を決める
3. インタビューイーは書いたものを見せて質問を待つ
4. インタビューアーは公開された偏愛マップについて質問する
5. インタビューイーを交代する

感想

好きなことを話すので盛り上がる

インタビューアーは何を聞かれても好きなことです。好きなこと話すことは楽しいですよね。1つの質問から話も広がりやすく盛り上がっていきます。また、「分かることしか質問されない」と分かっているので緊張もほぐれます。

質問形式なので聞き手も前のめりになる

記者会見方式の良いところはインタビューイーから質問することです。質問するためにインタビューアーの偏愛マップをじっくり見ますし、気になったことを質問するので興味を持って聞けます。聞き手が前のめりなので話し手も楽しいです。

知らない一面を知れる

偏愛マップの良いところですね。長年一緒にいても知らないことはあります。こういった機会がないと知れないこともあるのでお互いを知るには良いプラクティスです。「え？なにこのキーワード！」というのが見つかりますよ。

進行も簡単

1つの話題が終わったあとは何を話すか迷う必要がありません。偏愛マップに書かれた内容を質問すれば良いのです。また、質問と質問の切れ目に割り込めばインタビューアーの交代もスムーズです。

その他

好きなこと、得意なことを質問されると嬉しいことについて仕組みを考えた記事が面白いです。盛り上がる要因はこの記事と重なる部分もありますね。
dailyportalz.jp