スクラムフェス大阪2019が最高のカンファレンスだった

スクラムフェス大阪、最高のカンファレンスでした。

www.scrumosaka.org

パワーがすごい。かつ様々な実践の共有があり、多様性もすごかった。スタッフの皆様のモチベーションも高く、しかもマネーに対するするどい嗅覚もそこここに見え隠れする。

微笑ましい事例の紹介もあるし、そうかと思えば胡乱な取り組みを胡乱なスピーカーが発表し、場を胡乱な空気が支配するようなセッションもある。 計画されたカオスがそこにあった。

そこここに学びがあった。常に交流があり、お互いの状況を伝え合う中での自然なギブアンドテイクが生まれていた。

主催者の提供するコンテンツを参加者が消費するような、一方向な情報の伝達ではなかった。主催者が提供していたのは、交流が起こる場だった。参加者はみなその場自体が価値を持っていることを理解していて、自主的に参加する。

カオスはパワーを生み、予測できない相乗効果が発生した。メンバーのコミュニケーションを促進するのは消費行動ではなく学びであり、コミュニケーションを取るほどに創造性が生まれる。結果として、クリエイティブなカオスがそこに現出した。

アジャイルの意義とは効率良く学習できることにある。そういう意味で、スクラムフェス大阪はアジャイルの体現だった。統制の取れないすばやい学習がいたるところで行われていた。いろいろなスタイルの学びがあり、それで良いとする寛容があった。そしてあふれるほどのリスペクトと感謝があった。

一方「いかに儲けるか?」というビジネス目線の話も数多く、技術に偏ろうとしてしまう技術者とのバランスを取っていた。

「ユーザーに価値を提供する、すると儲かる。だから開発を続けていける。俺達のスタイルは顧客に価値を届けるための手段だ。つまりこのやり方が正しいんだ!」

そのような力強いメッセージが自信を持って語られ、実際利益を上げていることが説得力を与えていた。 こういう成功の匂いは、経営層にとって魅力的に映るだろうと感じた。

素晴らしい場を提供していただいた、スタッフの皆様と参加者の皆様に感謝を。僕にできるせめてもの恩返しとして、僕が学んだことの一部をここに共有します。次回開催予定も決まっているとのことなので、興味ある方はぜひ参加してください。

企業でOSSへのコミットを奨励する体制をつくりたい

僕の兼ねてからの問題意識として、勤務先がスタッフにOSSへのコミットを許可、奨励するようにしていきたいということがありました。

その理由は普段の仕事にOSSを使っているのだから、OSSに価値を返すべきだ、それが巡って自分たちにメリットとして返ってくるはずなので、長期的にメリットがあると思うからです。

ただ、営利企業としては自分たちに利益がないとそのようには考えないので、どのように経営層に提案したら良いのか悩んでいました。

そのような相談をしたところ、自分たちで使っているOSSを拡張するときにフォークするのではなく、OSS自身に取り込んでもらうのが良いと意見をもらいました。

フォークしたプロジェクトはマージし続けなければならず、メンテコストが掛かるので取り込んでもらったほうが自社にとってメリットがあると伝えれば、OSSへのコミットを許可してもらえるようになるのではないか、という意見です。これは目から鱗が落ちる意見でした。

OSSへの貢献を許可してほしいと思ったときにはすでに!OSSへの貢献を終わらせているんだぜ!」ということですね。このやり方であれば、事実をもとに相談ができるので説得もしやすそうです。

この問題は、個人的にずっと悩んできた問題だったので、その問題への見込みのありそうなアドバイスをいただけたのは本当にありがたかったです。 実際に取り組んでみようと考えています。

みな悩んでいるという気付き

僕は自分の職場環境が、他の企業の職場のようにはうまくいっていないと感じてきました。しかし話を聞いてみると、みなうまくいっていることばかりではなく、問題を抱えていて悩んでいるんだと驚きました。

改めて考えてみると、これは当たり前のことですね。問題というのは解決しても、また別の問題が出てきたり、問題を解決した事自体が新たな問題を生み出したりして、いつまで経っても問題は尽きないということです。みな今より良い状況を目指しますが、そこに到達すると次の目標が出てきてしまう。

いつまで経っても問題がなくなることはなく、悩み続ける。なのでみな悩んでいるんだと気づきました。

そう考えて自分の歩いてきた道を振り返ってみると、強いプレッシャーの中でしたが、問題点に対処し続けてきました。とりあえずの対処だけではなく、問題の本質への対処も試してきた。そしていっしょに協力してきてくれたメンバーへの感謝がある。

感謝を伝えあう文化が育ってきていて、以前に比べれば楽観的な会話が増えてきたと感じる。そう考えるといい方向には進んできているんだろう。

そこにはコミュニティから今までにもらってきたアドバイスや、本から得た情報にも大きく助けていただきました。

その恩返しとして、自分たちの取り組み、自分たちの成果、自分たちの失敗というものも、事例紹介してコミュニティに貢献してもいいのかもな、と思いました。

大きな成功がなくてもスクラムをずっと続けているという事例

confengine.com

生存者バイアスというのは冷や水のような感覚があります。

成功者によって自身の成功体験が語られても、「それはあなたがたまたま運が良かったからうまくいっただけでは?同じことを試して死んでいった無数の失敗事例を考慮に入れてないだけでは?」というような疑問が湧きます。

そういう意味で、この発表には勇気をもらいました。 華々しい成功がなくてもずっと同じことを情熱を持って続けられる、それはそこにそれだけの情熱をかけるに値する価値があるのだという証だと思います。

たとえずっと見返りがなかったとしてもそれを続けていくことができるか?それにYesと答えられることを人生で取り組めるなら、それは幸福な人生と言えるでしょう。この事例は、アジャイル開発に取り組むことに不安を持っている数多くの人に勇気を与えると思います。

発表者の方と懇親会でお話することができましたが、情熱を持ったすばらしい方でした。 参考になる事例の紹介を本当にありがとうございました。

本をいっぱい知れた

会場に旅するアジャイル本箱というのが置かれてて、みなさんのオススメの本を知る機会になりました。 それをキッカケに、僕もこの機会にいろんな本を買ったりウィッシュリストに追加したりしました。それらの本を共有します。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

問いかける技術――確かな人間関係と優れた組織をつくる

問いかける技術――確かな人間関係と優れた組織をつくる

0→1の発想を生み出す「問いかけ」の力

0→1の発想を生み出す「問いかけ」の力

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法

デザイン思考の先を行くもの

デザイン思考の先を行くもの

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

なぜあの商品は急に売れ出したのか―口コミ感染の法則

なぜあの商品は急に売れ出したのか―口コミ感染の法則

最後に

スクラムフェス大阪、本当に最高でした。ここには書ききれないくらいの数知れない学びと、勇気をいただきました。 スタッフの皆様、本当にありがとうございました。

そして今回来れなかった方、次回はぜひ一緒に楽しみましょう!

敬意の払い方

スモールリーダーシップに、メンバーへの敬意の払い方について、すごくしっくりくる説明があった。

一つ、メンバーはあなたと同じように高い知性を持っていると考えよ 一つ、メンバーはあなたと同じように横着だと思え

...

ここでいう「知性」とは、たとえ知らないことであっても、ミッションの達成に必要なことを学習して身につけていく能力を指しています。

...

メンバーをいわば「横着な賢者」だと考え、一緒に困難なミッションを達成しようとすると、リーダーが価値を置くべきことは大きく二つあります。なにより大切なのは、メンバーに「敬意」を払うこと、もう一つは「規律」の意識を持つことです。

...

ここでいう「敬意」とは、メンバーの持つ知性に対する敬意、すなわち、メンバーも自分と同じ情報を与えられれば、正しい解を導き出せると信じることです。

相手が高い知性を持ってるとみなすことはすごく大事なことだと思う。

自分と相手の認識や振る舞いに差異があるとき、相手の知性の不足だと考えるのは良くない。知性の不足が原因なのではなくて、今まで経験してきたことが違うために、同じものを見ていても違う側面を見ていることが差異の原因と考えるほうが健康的だし、人はみな自分が正しいと思いたがるバイアスが働いていることを考えると、おそらくこちらのほうが正しい。

知性に対して敬意を払うということは「自分と同じ情報を与えられれば、正しい解を導き出せると信じる」ことだ、という説明はすごくしっくり来る。必要な情報を得れば、自ら考えて解決できると仮定して、その仮定から導き出される信頼ベースの付き合い方をすることが大事だと思う。これはメンバーのモチベーションにも良い影響を与えるはずだ。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

百万遍あたりに最近できた良い飲食店の紹介

今年は百万遍あたりにいろいろ食べるお店が増えてよかった。特に本格中華料理店がいくつかできたのがうれしい。なぜか知らないけど中国人によるお店が突然増えた。一通り店巡りをして、良かった店を紹介する。

上等カレー

t.co

得正グループのカレー屋さん。ルーにいろいろ素材が煮込まれてて甘みと辛味が共存しておいしいカレーだ。値段も安くて、カツカレーが700円くらい。

夜のみ得正カレーうどんが提供されるようになった。大阪で食べた得正のカレーうどんとちょっとルーの味が違うきもするけど、すごくおいしい。出汁とカレーのコンビネーション、それに加えて甘い肉の佃煮が乗ってて一気に食べれてしまう。

方圓美味

t.co

本場の四川料理人による中華料理店。お値段もお手頃。ランチなら1000円以下で定食が食べれる。 メニューが豊富。鉄鍋で炒めた香ばしさがすごく出てて美味い。本格四川料理だけど、日本人に合わせてくれてて辛味は控えめで食べやすい。麻婆豆腐も安心して食べれる。

お昼は満席になってることも多い。お客さんにも中国人が多い。

火楓源

t.co

ここも中国人料に人による中華料理店。四川料理じゃないと思う、けどすごく辛い。一人で食べれる鍋もあるけどこれも辛いのが多い。

この店の隣に長江辺という中華料理店が昔からあるんだけど、そこと味がよく似てる。どちらも鍋のラインナップが充実していて、寒い日に辛くて熱い鍋を食べると最高。

テーブルは金色のテーブルクロスが掛かってて、メニューは壁一面にバックライトを付けたパネルになっててどハデ。コック帽をかぶった料理人が4人くらいいるけどそんなに働いてる感じはなくて、売上大丈夫かちょっと心配になる。この店も中国人の客が多い。

東北燒烤涮

これも火楓源の隣くらいにある中華料理店。田中里ノ前付近は華祥もあるし、おくだもあるし、上海バンドもあるしで、めちゃくちゃ飲食店の層が暑くなった。

この店は地下への階段を通って店に入るんだけど、外からでは中の様子がわからないのでちょっと入るのに勇気がいるが、中に入ると結構広い。ランチでは台湾ラーメンみたいなラーメンとか定食などが食べれる。

味は濃い目でかなり塩辛く感じた。個人的には火楓源のほうが好き。

麺家 あくた川

tabelog.com

百万遍にできたラーメン屋。烏丸通のあくた川の系列店。よく行列ができてる。 ここのラーメンは個人的にかなり面白い。スープは一口目は臭いが強くて塩辛すぎると感じて、麺も単体では最初は太くてボソボソしていると感じるんだけど、麺とスープ一緒に味わうととたんに味わいが出てきてズルズルっと一杯食べてしまう。不思議な感覚だけど、満足度が高くて行列ができるのも頷ける。これは家系ラーメンっていうのかな?家系ラーメンを食べたことがないのでよくわからない。

ラズパイで音量検知して光るガジェット作った

ラズパイで大きい音量を検知すると、光って知らせるガジェットを作っていたんだけど、連休に仕上げよう、とがんばって、やっと完成した。

やりたかったことは、うちの子供たちが大声で騒いでしまったとき、自分たちでそれを気づけるようにすること。興奮して騒いでくると、自分の声の大きさに気づけなくなるじゃないですか。居酒屋でみなさん経験してますよね。

それで連日のようにマイクラしながら大声で騒ぐんだけど、大声を出してる自覚がないので親が指摘するのも気疲れする。なので、自分たちで気づけるように状況を見える化しよう、と思って作ってみた。一通りやりたかったのが完成した状態がこれです。

開発当初はラズパイのセットアップ方法とかもしらなかったので、どのラズパイを買えばいいのかというところから結構迷った。

初期の構想ではGrovePi+っていうパーツアダプターとGrovePi+用のマイク、LEDを付けて作ろうと思ったんだけど、ラズパイ経験者の矢野くんからUSBマイクとディスプレイ付けたほうがいいんじゃないかとアドバイスを受けて、その構成で作ることにした。

マイクはこれ。

Amazon CAPTCHA

500円くらいだけど十分な性能だった。

https://t.co/BKLxKkk465 この小型ディスプレイも買った。付属のHDMIアダプターでラズパイと接続する。特に設定など不要で画面が映る。タッチパネルを使うには、付属のソフトをラズパイにインストールする必要がある。

ディスプレイは買っておいてよかった。別途ディスプレイとつなげる必要がないし、これ自体が通知インターフェイスにもなる。ラズパイと合わせて10000円弱程度になってしまうが、なかったら開発は大変そう。

ラズパイ本体もどれを買っていいのかわからなかったので、矢野くんと相談してRaspberry Pi 3B+ っていうやつにした。RSコンポーネンツとElement14という2個の製造元があるが、Element14は品質が悪いってネットに書かれてたのでRSコンポーネンツの方を買った。https://t.co/h498R5hAnC

SDカードが相性悪いと、ラズパイが起動しないみたいな情報もあった。東芝製のSDカードなら大丈夫らしいので、東芝製の16GBのSDカードを買った。SDカードも4GBだとOSの容量が足りないので16GB以上くらいがいい。1000円くらいで買えた。https://t.co/oUwuINCCLw

ラズパイのOSは、本家サイトからダウンロードしてSDカードに書き込んでおく。この記事とかを参考にしてインストールした。https://t.co/IYONbjhwbL

ラズパイのOSにはpythonが初めから入ってるので、それを使ってプログラムを作った。はじめてのpythonだったけど、シンタックスちょっと違うなー、くらいで特につまづかずにプログラミングはできた。USBマイクから音量を取ってきて、それを画面にグラフとして描画する。画面への描画はpygameっていう2Dゲーム用のライブラリを使った。

pixe.laを使って、大音量を検知した回数を記録するようにもした。pixe.laはリリースされたときからぜひ使ってみたいと思ってたので、いい機会だった。curlだけでユーザー登録、グラフ作成、グラフ更新ができるのですごく便利ですね。

pixe.la

作ったプログラムはgithubに上げました。

t.co

これで子どもたちが自分自身で音量調節できるようになるといいんですけど。どうなるかしばらく様子を見てみます。

ユビキタス言語についての考えの整理

(この記事は、ユビキタス言語について、自分の考えを整理するために書いたものです。)

DDDは分類法の一つという側面がある。一番大きな分類は、境界づけられたコンテキストだ。境界づけられたコンテキストはある業務領域に対応する分類の枠だ。ECサイトなら商品発送で一つのコンテキスト、請求処理で一つのコンテキスト、くらいの単位だ。

コンテキストは名前空間として働く。ドメインの用語はコンテキストの内部だけで有効だ。コンテキストを越えると同じ言葉であっても別の概念として扱わないといけない。

例えば発送処理と請求処理でコンテキストを分けているとして、それぞれのコンテキストで「顧客」という用語を使っていても、それらは別の概念だとみなさないといけない。

それぞれのコンテキストの顧客は共通のこともあるけど、業務が異なるので違う振る舞いを期待する。そういうのは別の概念として分ける。実装時にはそれぞれのクラスはそれぞれのコンテキストの中に別のクラスとして実装する。

このようにコンテキストの内部でだけ有効な用語を関係者みんなで使いましょう、それをユビキタス言語と呼びましょう、というのがユビキタス言語だ。

ユビキタス言語をうまく作用させるには、みんな(開発者もドメインエキスパートも)がユビキタス言語に則った用語を使うこと、ドメインモデルにもユビキタス言語を使った名前付けにすることが必要だ。

同じ言葉を使ってコミュニケーションすることで、ドメインを効率的に学習していくことができる。ドメインについての質問をユビキタス言語を使って行うことで、共通の言葉を使って概念を整理していくことができる。

それらのドメインの概念は、そのままプログラムでも表現する。そのために、パッケージ名、クラス名、メソッド名にもユビキタス言語をそのまま使用する。会話している言葉と同じ言葉を使ってプログラムを名前付けするために、翻訳しながらプログラムを読み取る必要がなくなる。

(コンテキストの中の)ドメインモデルの分類にはユビキタス言語を使うことになる。クラス名にはユビキタス言語で定義された用語が使われるし、用語間の関係はパッケージでグルーピングされる。パッケージの名前にもユビキタス言語で定義された用語が使われることもある。

ドメインモデルをユビキタス言語で分類するためには、ある用語がドメインの中のある一つの概念と結びついてないといけない。そうでないと曖昧な責務になってしまうだろう。あとはある用語が2つ以上の意味に使われているといけない。

ユビキタス言語これらの性質を満たしているというのが、DDDがうまく動くはず、という根拠になっていると思う。

なぜ ユニークな概念に紐づくユビキタス言語を作ることが可能かというと、それで実際の業務が回っているから、というのが根拠になっているのではないかと思う。業務を回しているということは、曖昧な用語を使ってコミュニケーションロスが発生していないはずなのだ。

例えば新しく田中さんが職場に入ってきて、すでに田中さんがいた場合、田中博、田中太のような感じで、自動的にユニークで誤解のない呼び名が生まれるはずなのだ。業務で扱っている言葉であれば、それが誤解を生むような用語であれば業務が回らないようになってしまう。

業務を回しているということは、そのような事態は発生しないということを保証している。なので、ドメインエキスパートと開発者の間で共有できるユビキタス言語を作ることが可能なのだ。

目標を共有する、ということについて考えたこと

今日のEffective DevOps読書会で、チーム間で目標を共有することの重要性という話が出てきた。チーム間で目標とすることがずれていると協調して作業することができない、という文脈だ。

なぜ目標がずれてしまうのか?それはそれぞれの視点が違うからだという意見が出た。

例として開発者とテスターの視点の違いで考えてみると、開発者は素早く機能をリリースすることが目標になるが、テスターは機能にバグがないことを保証することに価値を置くため、素早く機能をリリースすることには価値を見出さない、といった感じだ。

視点の違いによって目標にズレが出てしまう、という意見は本質をとらえていると思う。これはチーム間だけでなく、経営層と開発チームで目標を共有できていない理由にも適用できるし、同じ職種であっても、人によって視点は違うので、おそらく目標もずれているだろう、と推測できる。

視点の違いを乗り越えて目標を共有するために、目標を明文化、見える化することが重要なはずだ。個々の視点、価値観がぴったり揃うことはないだろうが、それでも共有できる部分について目標を共有することは可能なはずだ。

ところで目標を共有できているというはどういう状態だろうか。 個人的に目標の共有には「なぜその状態を目指すのか」というWhyに答える情報が必要だと思っている。

もう一つ必要なのは「勝利条件の設定」だと思っている。 たとえばカードゲームだと相手のHPを0にしたり、デッキを空にする、などの複数の勝利条件が設定されているし、Civでも文化勝利や制覇勝利など複数の勝利条件がある。勝利条件を定義し、どの勝利条件を目指すかということを共有しないといけない。文化勝利を目指すのと制覇勝利を目指すのでは戦略そのものが変わってくるだろう。

実際の開発案件であれば、ユーザーが業務をこなせる機能を1か月以内にリリースすること、とか、課金ユーザー数を半年以内に1万人、2年以内に10万人を達成する、などだ。ビジネスとして開発をするなら、そのビジネスが存続できるための条件が必ずあるはずだ。それを明文化しておくべきだ。

Whyと勝利条件。これらが必要な理由は、スタッフ、チームが自主的に動けるようにするためだ。これらの情報がなければ、どのように動けば効率的に目標を達成できるかを決められないだろう。

インセプションデッキで最初に決めることは「なぜ我々はここにいるのか」だ。Whyに答えることが目標を定義する第一歩なのだと思う。

直感に頼る

ロジカルシンキングは好きなんだけど、意図的に「論理的に正しい」手段より、直感でうまくいきそうな手段を採用することがままある。こうしたほうが間違った意思決定を避けることができると思うからだ。

たとえば「今マンションを買ったほうがめっちゃお得!」みたいなセールストークを受けた時などにこういう感覚を働かせている。 こういうセールストークをする人は、矛盾の無いように理論武装してるので、その場で論理的矛盾を着くことはできないこともありうる。

そういう時に論理的な正しさをよりどころにしていると、毎回マンションとかホーム家電とか新しいスマホとかを買わないといけなくなってしまうが、それはコスパの悪く、満足度の低い意思決定になるだろう。

なぜ論理的に正しい(そうに見える)結論を採用し続けると、正しくない意思決定に陥ってしまうのだろうか?おそらく前提に見落としがあったり論理展開に瑕疵があったりするのだろう。前提に全く見落としがないということを保証するのはほとんどのケースでできないので、間違った意思決定に繋がりうる。

おそらく論理的思考は、ある仮説の正しさを短時間で確度を高く評価したい時には向いているが、正しそうに見える論理が本当に間違ってないかを検証するのには向いてない。長期的な未来予測はほとんど当たらない。それは実は重要な前提の考慮漏れがあるからなのだろう。

それでも僕たちは日々意思決定をする必要がある。 僕はその確度を高めるためには論理的思考ではなく、直感に頼るほうが良いと考えている。そのほうが質の良い意思決定につながると考えている。

「マンションを買ったほうがいいという意見は正しそうに見えるけど、実際に運用することを考えるとローン返すことや、抵当権設定の処理や、住宅ローン利率の変動や地震などの災害や、考えないといけないことが増えて面倒そうなんで買わない。」というような感覚だ。

ある一面だけ見ると正しそうに見えるけど、それが本当にワークするのか?ということを想像することで、「論理的に正しそうに見えるけど間違った意思決定をしてしまってどうしようもなくなる」という事態を避けられることが多いと感じる。

必要な前提を洗い出して、論理に瑕疵がないなら、論理的に正しいことは必ず正しい。けど、現実的な計算時間で、すべての前提を漏れなく考慮することは不可能だ。それができるって言う人は、単に前提見落とししてることを意識外に出してるだけなのだ。直感に頼る理由はコスパがいいということにつきる。

直感に頼るという戦略を採用するなら、直感を鍛えることが重要であるという結論に行き着く。 直感とは超能力ではなく、経験から導き出されるパターンマッチ能力のことだと考えている。

人間のパターンマッチ能力は優れているので、論理的な根拠は示せなくても「ヤバそう」などの感覚として感じることができる。

なので、「ヤバそう」と感じること、そう感じた時にそれを言語化して、パターン化することを意識している。 僕にとってはテレビゲームはこの感覚を鍛えるのに役立ってると感じている。

Tower Defenseやローグライクが大好きなんですが、これらのゲームはヤバそうな雰囲気を察知することや、正しい意思決定をし続けることを要求するゲームです。 これらのジャンルのゲームをするのは直感を鍛えるのにオススメです。