ヌーラボさんと共同でやってたEffective DevOps読書会、やっと読了した

ゆっくりゆっくりと弊社とヌーラボさんで続けていた、Effecitve DevOps読書会がやっと読了しました。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

本当に長かった...いつ読み始めたのか忘れるくらいに長かった。 最初の読書会の記録を見返したところ、2018/6/15でした... 1年以上かけて1冊の本を読み切りました。

まず、これまでに読書会に参加していただいた皆様に感謝を申し上げます。 僕にとっては学びの多い会を最後まで続けられたのは、参加していただいた皆様の協力のおかげです。 本当にありがとうございました。

今のタイミングで、この読書会の経緯とこの会から学んだものを、僕の視点から整理してみます。

読書会を始めるきっかけ

たしか、読書会を始める数ヶ月前からEffective DevOps読みたいなーと個人的に考えてたと思います。 チームビルディングについて悩んでたのもあったし、「組織の文化」というものが何なのか、 何を重視したらいいのかとか、どうしたらいいのかもわからなかったし、そういうことへの解答が あるんじゃないかと期待していました。

それで2018年の5月くらいに、品質管理のリーダーとして福田さんが入社して、福田さんと今後の会社の方向性について話し合ったときに、「すぐに効果を出す目的じゃなくて 長期的に見ていい方向に会社を持っていくときに役立つ知識を学びませんか。ぼくはその知見が Effective DevOpsっていう本に書いてるんじゃないかと思ってます」みたいなアプローチをして、 Effective DevOpsを一緒に読んでいくことにした、んだったと思います。

せっかく2人で読むなら他の人も誘いましょうか、ということで社内チャットで呼びかけをして、 読書会が始まりました。

f:id:kmdsbng:20190713094939p:plain
最初の読書会開催の記録

初期

初期はもの珍しさも手伝って、まあまあ参加者が集まりました。 「DevOpsっていうタイトルからは想像できないけど技術者以外の人にとっても役に立つ」 みたいな誘い方をして、事務や営業の人にも参加してもらいました。

読書会を始めた頃に、興味を持ってもらおうと思ってまとめたDevOpsとは何かっていう箇条書き。 これを書いた頃は、組織の文化って何?みたいな感じだった。

最初の方は結構飛ばしながら読んでいて、記録を見返すと1ヶ月くらいで半分くらい読んでた。超速い!

進め方は模索しながら進めていて、その中でペースが早すぎてあまり理解できてない、というフィードバックが あって、じゃあ1センテンスだけ読んだら感想をみんなで語り合うようにしよう、みたいなやり方に変えたのが 大きな変換点だったと思います。ちょっとずつ読み進めるように変えたところ、いくつかいいところが ありました。

  • 言葉の意味や、書いてる内容がわからない点についての質問がいっぱい出てくるようになった。
  • 自分の経験や気付きなどが語られるようになった。

これらの点は、僕にとってはすごく貴重なフィードバックだ、と感じました。 みんなが考えてること、不安に思ってること、懸念してることを、 書いてる内容ごとのテーマで表明してもらえるようになったので、これは効率性を犠牲にしたとしても ぜひ得たい情報だ、そこでお互いに情報交換することが、DevOpsにとって重要な「自分たちのことを知る」ことに 向かっていくのですごく質の高い学習だと感じました。

参加者に聞いてみても好感触だったので、以降はこのスローペースでずっと読み続けました。 Effective DevOpsっていう本が、こういう読み方に向いていたなーとも思います。 みんなでワイワイと俺はこう思う、僕はこうだ、と情報を交換し合うことで理解が進む本だった、と感じています。

ヌーラボさんを誘う

半分くらいまで社内で読み進めたあたりで、組織間の交流についての話が出てきて、 他の会社の人を読書会に誘うのはどうだろう、というアイデアが出てきました。 他社の参加者もいたほうが、フィードバックにより広がりが出るんじゃないか、という 期待もあってぜひ実現したかったのですが、前に弊社に務めていてヌーラボに 転職された中伏木さん経由でヌーラボさんに話を通していただき、リモートでの 読書会が実現することになりました。ヌーラボさん、本当にありがとうございました!

新しく参加される人も増えるので、その時点でまた最初から読み直すことにしました。 事例ごとにみんなの感想を聞くのが有益だとみんなが感じてたので、最初から読み直して 新しい感想が聞けるならいいんじゃないか、とということになりました。

ヌーラボさんからも興味を持った方に参加いただけて、フィードバックの幅がぐっと広がりました。 会社がちがうと抱えてる問題や文化も違って、自分たちの無意識の前提にも数多く気づくことができました。

時間も毎日 12:00から30分というルールにして運用していきました。

2018年8月から年末くらいまで

このころから、読書会ができない日が多くなりました。 初期はたまたま僕が時間が取れてる日が多かったのですが、このころ時間があまり取れないことが続いて、参加者もあまり集まらず、休会が多くなりました。

この時期は読書会の進め方について悩んでた時期で、僕が会に時間を割けないせいで、読書会というコミュニティのエネルギーが損なわれてるのではないか、と感じていました。

がんばって時間を割くようにテコ入れしようかと思ったこともあったのですが、結局は「休みが多くても良い」というポリシーにすることに決めました。

その理由は、この本で学習しているDevOpsというものが、ずっと続けられる文化を目指すものだというのが一つでした。 継続可能な体勢を作るための学習が、誰かのがんばりに依存するようなものであってはうまくいかないはずです。 であれば、目指すべきは無理をして短期間で終わらせることではなく、自分たちのペースでずっと学び続けることだ。 なので休むことに罪悪感や引け目を感じることなく、堂々と「今日は参加できない」と言えるようにしようと思いました。

f:id:kmdsbng:20190713131220p:plain
堂々と不参加表明する(堂々と...?)

また、この頃読んでた箇所に学習時間についての考え方のヒントがあって、学習時間を遊び(作業として割り当てない時間)として設定し、 緊急作業が入ったときにはこれを消費するのが良い、ということが書かれてました。 これを読んで、僕らの読書会は学習のための遊びの時間とみなして、作業が入ったらそちらに時間を割り当てるのは 問題ないよね、ということをメンバーで共有して、会の開催形式についても会自体で調節していきました。

2019年以降

あいかわらず休みは多かったですが、特にそれは問題ではないと考えて運用を続けました。 他に参加者がいないときは一人で読み進めることも考えたこともありましたが、それは採用しませんでした。 この本については知識をえることよりも、それぞれのテーマについて参加者のフィードバックを得ることこそが 有益だと考えていたので、ゆっくりとみんなで学習することを楽しもう、と思って一人で先に読むことはがまんしました。

あせらず、自分が楽しいと思える状況を維持することに気を付けて続けました。 自分が面白いと感じることは、きっと他にも面白いと思う人はいるはずだし、そこを損なわないことに気をつければ この活動は続けられる。そう自分に言い聞かせつづけました。

そんな感じで読み進めてきた結果、ペースを保ったまま、なんとかこの分厚い本を読了することができました。

学んだこと

いろいろと学んだことは多かったのですが、今思いつく範囲でこういうことを話したよなー、ということをせっかくなのでいくつか書いていきます。

組織の文化とは何か

組織の文化というのは、組織が内外について伝えたり、メンバーが実際に行動によって作られる価値観やみんなが信じること。

主に文化について語られるのは組織の健全性について話すときで、メンバーが安全と感じているか、そうでないかというのが重要な観点になる。 メンバーが安全と感じていれば、リスクを取って行動しようと考えるようになるし、安全でないと考えていれば、自分の身を守ろうと行動するようになる。

リスクを取ることを組織が奨励しているか、それが口だけでなく実際の行動でもリスクを取ったことを責めないようになってるか、という点が心理的安全性に影響を与える。

あとは何が重要かをはっきりさせていることも文化を作るのに重要。

それがないと、みんななにが目標で仕事しているのかわからないまま仕事することになる。 そんな状況はまずいだろ、と感じるかもしれないが、そういう組織は結構ある。

固定思考と成長思考

固定思考は「人の能力は生まれつき決まったもので、行動によって変わらない」と信じること。 成長思考は、人の能力は後天的に獲得できると考えること。能力の獲得だけじゃなくて、自分の無意識の前提に気づくことができれば、行動も変えられる、と考える。

この本では固定思考は悪で、成長思考が良いという考え方を取っている。 固定思考なんているのか、と最初にこれを読んだときは思ったが、相手が固定思考か成長思考か どちらを信じているんだろいうと意識して話をするようになると、結構人は変わらないという前提で 話している人は多いんだなーと今は感じている。

失敗は悪、と考えてしまうのも固定思考で、成長するなら失敗するでしょ、と考えるのが成長思考。 失敗はまずいこと、と考えてしまうのはどっちかというと自然な心の動きのような気もするので、人間はデフォルトで固定思考なのかもと思う。 仕様を最初にバシッと決めたらあとはそれを実装さえすればいい製品ができる、という考え方も固定思考の結果だと思う。

開発初期には自分たちは開発後期に比べて十分な知識がないはずなので、その時点の設計は間違っている可能性が高い、そう想定して開発することでリスクを減らせると考えるのが成長思考的だと思う。

今まで失敗したことがない人のほうが固定思考になる傾向があるらしい。

成長思考の考え方からすると、固定思考から成長思考に変わることも可能と考えるが、自分の中での気付きが得られないと、変われないので、なかなか難しいだろうなあとも思います。

人を成長させるために必要なこと

直接本に書いてあったことか覚えてないんだけど、読書会を通じて得た考え。

人が成長するには、自分のボトルネックになってる無意識の前提に気づき、自発的に自分の行動を変える必要がある。 とするなら他人を成長させるにはどうすればよいかというと、自分の考えを相手に押し付けるのではなく、相手が気づきを得ることを手伝うのが有効なはず。 そのためには相手の考えを聞き、それに共感し、事実に関してフィードバックするのが大事。 回答になることを的確に相手に伝える必要はないし、それをすると逆に気付きが得られず、行動の変化につながらないことも多い。

例えば相手の心配に思ってることなどを聞く。まずはそれについて共感する。「そっかー、それは大変だね」「それはよかったね」と言ってあげるべきだ。

それについての解答を最初に与えようとしてはいけない。まず聞き、共感する。それで相手は考えの整理が進む。 次に事実についてフィードバックする。「間違ったSQLを実行してしまったために、そのリカバリーに半日かかったね」など。 「そもそもなんで間違ったSQLであることに気づかなかったんだろう」というように、一緒に原因追求や、よりあるべきだった未来について考えてあげたりする。

その中で、ボトルネックがどこにあるかを共有できて、それが自分の行動によって改善できる、と相手が気づけば、行動は変わるかもしれない。

読書会を終えて

定期的に学習時間を作って、ゆっくりとでも無理なく学習をつづけられたのは本当に良かったと感じています。 同時に、もっとみんなに価値を感じてもらえる学習の仕組みを作っていきたいなあとも思ってます。 無理なく、面白く、という両立は難しいだろうと思いますが、継続的に実験していきたいです。

この本から学んだことを、実際のチームビルディングにも生かすことができました。調整役として最近まで参加していたプロジェクトで、各メンバーが懸念点を表明できる環境を保つことができたのですが、それにはこの本からの知見が活かせたと感じてます。

また、最後まで一緒に読書会をつづけて頂いたヌーラボの中伏木さんから、これで終わらせるのはもったいないから 何か別の本を読みませんか、という提案もいただけました。

大変嬉しい申し出だし、僕以外の誰かに価値のある場と思ってもらえたこともすごく嬉しいです。 次に何をやるかは決まってないんですが、みんなが興味を持てることをつづけられるといいなあと考えてます。

読書会の感想など

今日のEffective DevOps読書会に出てきたいい言葉

16.1 に出てきた言葉。

devopsとは、ある意味では、アイデンティティだと思い込んでいるものを理解し、場合によっては変えていくことである。職務に基づいてアイデンティティだと思うものを内面化し、そのアイデンティティに一致しない行動を取る人たちを拒絶するとき、さまざまなことに影響を与える。例えば、どのようなエンジニアを尊敬するのか。採用活動のなかでどのような候補者を有望だと考え、どのように面接に臨むか。何を「内輪」だと思うかといったことだ。devopsとは、「私はもともとこういうことをしているので運用だ」と言うのではなく、「私は今こういうことをしているので運用だ」と言うべきということだ。これは、私達が固定思考に代えて成長思考を推奨していることに通じている。「devopsをしているかどうか」ではなく、問題をどのように分析し、アプローチしているかが大切だ。

「devopsとは、アイデンティティだと思い込んでいるものを理解し、場合によっては変えていくこと」というのはすごく面白い。目標を立てて、それを組織で共有しつつ、かつ、それは固定の目標だと盲信せずに変えていくことが大切なんだろう。

この「ある地点を目指しつつ、そこが正しいゴールかをたびたび見直す」感覚は、ただしいゴールに至るための大事な心構えだと思う。この考え方を忘れないようにしたい。

スクラムフェス大阪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がうまく動くはず、という根拠になっていると思う。

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

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

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