既存のシステム設計手法ではつらいので、数理的システム設計という手法をつくった #agileto2019

現代のソフトウェアシステムにおけるシステムアーキテクチャ設計手法や、それらをとりまく各種手法は素晴しい。だけど、わたしはまだまだもっと理想にちかづきたい。 そんな思いから課題をみつめて、自分なりに設計手法をつくってみました。 いまはこれを数理的システム設計とよんでいます。まだαバージョンくらいです。

いままでも、これについては筑波で2度勉強会をしており、今回はAgile Tour Osaka 2019で講演してきました。

アジャイル システム設計 Meetup - connpass

システム設計ハンズオン勉強会 -リジェクトすえなみチャンス暑気払い- - connpass

Agile Tour Osaka 2019 × miniPLoP 2019年11月9日（大阪府） - こくちーずプロ

で、今回はたぶんはじめてスライドを公開しました。 スライドにある通りですが、基本的には僕の経験のみの話で、業界にたいする評価とかではありません。

speakerdeck.com

1. アイディア、仮説、要求 と アーキテクチャ へのギャップがおおきく、それによってビジネスの可能性を小さくしてしまっていたり、技術進歩への追従がしにくくなっていたりする。
2. 主観的に機能や仕様の配置をしてしまうことによって、システムの無駄がおおくなる。
3. 機能に依存した設計をすると、変更によわくなる

おおまかにはこのへんの課題意識があって、これをかいけつするために、より要求などによりそいながらも、アーキテクチャとしてつくるものを想像しやすく、数理的な手法があればいいのではないだろうかという気持ちがうまれました。

そこで参考にしたのが、クリストファーアレグザンダーの The Nature of Order 15の幾何学的特性です。 建築をはじめとして、美しい設計というのは15の幾何学的特性をもっていると発見したというのが彼の主張です。

ということで、これによってシステムを設計してみようということで手法としてつくりあげたのが、この数理的システム設計です。

スライドにもあるようにたくさんの課題がありますが、ITをつかったシステムが巨大で複雑化していくなかで、よりアイディア、仮説、要求などと具象的な技術をつなぐ設計手法として大成できていけたらいいなとおもっています。

これに付随してさまざまな設計手法について勉強するようにもなったのもこの数年の成果かもしれません。

で、またこれのはなしをかるくさせてもらう機会をいただきました。

すえなみチャンス忘年会2019 本編 - connpass

数理的システム設計以外についてもシステム設計、アプリケーション設計についてはいくばくか詳しいつもりなので、登壇、研修、実務でのアーキテクト業などのご依頼もおまちしております。 kyon-mm.com

参考書籍

生命の現象

形の合成に関するノート/都市はツリーではない (SD選書)

クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

ソフトウェアシステムアーキテクチャ構築の原理 第2版

マイクロサービスアーキテクチャ

エンタープライズアプリケーションアーキテクチャパターン

進化的アーキテクチャ ―絶え間ない変化を支える

情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計

エンジニアのためのデザイン思考入門

レゴスクラム研修を筑波技術大学の先生達に提供した話 #lego4scrum

個人事業主うさぎ組 kyon-mm.comでは、スクラムやアジャイルの研修も仕事にしています。 今回はenPiT ビジネスシステムデザイン分野でずっと一緒にお仕事をしている、筑波技術大学 渡辺准教授の職場でスクラムを知ってもらうという目的で研修をしてきました。渡辺さんが声をかけてくださった先生方を対象にという感じです。 その様子を紹介します。

座学

私からアジャイルマニフェスト、スクラムガイド、アジャイルの各手法の関連などを整理して、概観を説明しました。 その後、参加者同士で座学の内容を振り返ってもらって質問を出してもらい、回答したり議論をしたり。 ここで想定以上の量の（しかも良質な）質問が出てきて、議論が盛り上がりました。 ほとんどの参加者がアジャイル開発の経験がないにも関わらず、なかなか鋭い質問があり、「本当にやったことないのかな。。。？」と思ってしまうほどでした。

レゴで街づくり

講師である私（プロダクトオーナー役）からレゴで作って欲しい街の情報を伝えて、あとは各チームで街を作ってもらいます。まずはどんな街にするのかを自分たちで考えて、見積もって、作ってみて、レビューして、やり方を振り返りして、とスクラムのスプリントを実践します。 今回の研修では3スプリント実施しました。

ペルソナについて議論したり、スプリント計画をしているときは各チームいろんな議論の仕方がありました。

ユーザーストーリーマッピングを使いながら、バックログを作って優先順位をつけていき、受け入れ条件を考えていくのも実践してみます。

チームごとに出来上がる街は最初は小さかったり、体験の設計が不足していたりしますが、どんどん良くなっていきます。お互いに「そういうのが得意なの？」なんて驚きもあったりして楽しそうでした。

スプリント毎にプロダクト、自分たちの進め方をふりかえって、自分たちのうまくいっているところや、なんとかしたいなーっていうところを話し合い、自分たちでどうしていくのかを考えていきます。

3スプリントが終わったら1日のふりかえりをして終了です。研修が楽しかった話や、得た学び、今後自分たちはこれをどうやって活かしていくのかなど議論は尽きませんでした。 生徒たちのことを熱心に考えている先生方、尊いわ。。。

まとめ

レゴ®︎によるスクラムの研修をソフトウェア開発などを教えている筑波技術大学の先生方とやってみてわかったのは、何かを模索しながら誰かに何かを提供する、学びについて普段から考えているという人にとってはスクラムの考え方はマッチしやすいのかもしれないと改めて気づかされました。 普段はソフトウェア開発企業の方々にレゴスクラム研修を提供することが多いのですが、もっと違う業界の方にも提供できると良さそうだなぁと。 もしご興味ある方いらっしゃれば https://kyon-mm.com や https://twitter.com/kyon_mm からご連絡いただければ！

あと、筑波はいいぞ！

チームはミッションのためだけではない。生き方そのものである。 #RSGT2020

Regional Scrum Gathering Tokyo 2020というカンファレンスのセッションは公募制で、私も発表してみたかったのでプロポーザルをだしました。 聞いてみたいかたはぜひ下のサイトでVoteしてもらえるとうれしいです。このプロポーザルにおいてどんな話をするつもりなのかをすこし紹介します。

confengine.com

www.youtube.com

1. セッション概要の引用

1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

2. チームとはなんのためにあるのか

わたしが今まで読んできた書籍であるとか、発表であるとか、会話のなかでは、チームというのはミッションのためにつくられるものであり、そのため同じ目的をいかに共有するのか?という話に焦点があてられていました。 ほかにもチームとグループはちがうとか。ビジネスの世界ではそうだという話がおおくあるとおもっています。

では、プロジェクトがことなれば、ミッションが細分化されていれば、それはチームとはよべない。そういうことになります。そうしてチーム横断での仕事の仕方や組織作りになやむ。そうした日々をおくる。ありふれた風景におもえます。

我々基盤チームも事実上の解散になり、そうなるのかとおもっていました。 でも、我々は基盤チームで仕事をしていくことに誇りをもっており、そしてなによりこのメンバーと仕事をし、失敗も成功もかみしめ、成長をしていくその過程が楽しいとおもってこの5年間をすごしてきました。

ミッションがことなっていても、チームとして存続する方法を模索する。そんな挑戦をはじめました。

3. フラクタルスプリントのスケールアウト

我々がしっている古典的なチーム横断は2つです。横断組織をつくる。そして期間の長いタイミングもしくはアドホックなタイミングで情報の同期をつくる。 これをやっていてはおおきなチームとしては成立しない。基盤チームはこれをかえるために、プロジェクトがことなってもフラクタルスプリントをすることにしました。

なので、プロジェクトがことなるチーム同士で、15minスプリント、1Hourスプリント、1Dayスプリント、1Weekスプリントを実施しています。つまりフラクタルスプリントを複数チームにスケールアウトさせました。

フラクタルスプリント

フラクタルスプリントを複数チームで同期させながらおこなう

これによりミーティングの時間はのびたりのびなかったりしていますが、我々の経験上、目安時間からずれてしまうの修練上の誤差のようなものであり、メンバーは「いまは修練の時だ」という認識でただひたすらにこのスケールアウトされたフラクタルスプリントをいかに上手につかいこなすのかということをかんがえています。

4. 発表ではなすこと

おおくの組織でチーム同士をつうじた組織の成長、多層な学習、という課題があるとおもいます。事実わたしの仕事ではほとんどがこういった話題です。

まだ小さな事例ではありますが、複数プロジェクトにおいても同期されたスプリントを実行するとえられる効果。そしてこの手法の転用方法や展開についてをはなせるとおもいます。

また、この考え方の根本ともちかい進化心理学からみたアジャイル開発についても話をすることになります。 チームとはミッションのためだけにあるものとかんがえることが、可能性をせばめているときづいた話です。 言い換えれば、なぜ人間はチームを作りたがるのかということについて学術的な側面と、経験的な側面について話します。

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

人が自分をだます理由:自己欺瞞の進化心理学

Re: モッククラス、下から見るか？横から見るか？

先日Twitterでリプライがきたのでみてみたら素晴らしいブログ( モッククラス、下から見るか？横から見るか？ )がありました。

プログラムにおける自動単体テストでモックをつかうべきかどうか悩んでいるというもの。

私なりにこれに回答しようとおもいます。みんなもなにかおもうところがあれば、SNSではなくブログにしてほしい。(Webからそのままアクセスできるという点において)

1. 基本方針

1. 可能なかぎりモックライブラリはつかわず、コンストラクタDI(Dependency Injection)で解決できるならそうする
2. 往々にして厳密な単体テスト(1ファイルにとじたテスト)はしておらずコンポーネントテスト(複数ファイルにまたがったテスト)がおおい

2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう

自動化されたテストがなく、これからリファクタリングをしたいというときには、既存のプロダクトコードを変更せずに自動テストを実装すべきです。そのときには時刻やDBやAPIなどに依存したコードをテストしなければいけないでしょう。

テスタビリティの低い設計ではこれらを「テストから設定」することがむずかしかったり、高速な単体テストとすることがむずかしかったりします。そのときには、モックライブラリをつかって時刻やDBやAPIなどをテストダブル(スタブやモック)におきかえます。

モックライブラリは実質的にリフレクションなどをつかっているものがおおく、プロダクトコードを変更せずにプログラマーが自由なコードで一部の処理を代替させることができます。これによって自動テストを実行できるようにしてから、徐々にリファクタリングをすすめていく。という場面ではモックライブラリが適切でしょう。

3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。

たとえばトランザクションやコネクションのコミットやクローズ処理が確実にされているかを検知したい場合につかえます。 単体テストのメリットとして、IO処理が失敗した場合を簡単に模倣できるという点があります。それ自体はコンストラクタDIな設計における簡易なテスト用のスタブクラスでもできます。

ですが、たとえばDB操作が失敗したときに必ずコネクションがcloseされていることのテストはなかなか検知できません。モックライブラリであればできます。 もちろん静的コード解析でも対応できる部分はありますので、一概にモックライブラリでやるべきとはいいませんが、なかなかに便利なときがあります。

Javaだとtry-with-resourcesとかでかいておけばいいじゃんというのもありますが、rx系というかpromise系というかのライブラリをつかっていたり、いくつかの設計においてはtry-with-resourcesをうまくつかえないことがあります。そのときには、モックライブラリで検知させるというのは妥当だとかんがえています。

実践テスト駆動開発 (Object Oriented SELECTION)

テスト駆動開発

Effective Java 第3版

スクラムフェス大阪で基調公演。もしくはJASRACへの支払い #scrumosaka #agileradio

2/22 - 2/23 に開催されたスクラムフェス大阪にてKeynoteを担当させていただきました。 @TAKAKING22 くんと一緒に壇上に上がる日がこうやってくるとはおもってもみませんでした。 テックカンファレンスで世界初「オープニングムービー + 入場曲 + ジャズピアノ生演奏 + メイキング映像 + アンコール + キーノートタイトル参加者で議論」という構成でおとどけしました。(要出典)

本エントリでは、なぜこうできたのかの一部、また、日本で楽曲を使用するときに課題になる JASRACへの対応方法をのこしておきます。

キーノートのタイトルを参加者が付箋にかきだして自分のキーノートタイトルを決めてもらった

www.scrumosaka.org

なぜこの構成にできたのか

この辺の大枠は先日出演させていただいた #agileradio にて軽くはなさせてもらいました。

Scrum Fest Osaka 2019 トーク その１ | アジャイルラジオ

簡単にまとめると次の流れでした

1. 大切にしたいことは 2018/12に @TAKAKING22 と きょんで決定
2. アイディアを RSGT2019 の OSTの1セッションで議論
3. OSTにて「アンパンマン」「生演奏」「脇役としてのキーノート」というアイディアがかたまる
4. 2日後の1/14 に企画提案、プランニング
5. 以後怒涛のプレゼンテーション、編曲、練習、動画編集、構成をねりなおすの制作1ヶ月をすごす

いやー、本当にたのしかったです。 アーティスト活動のさわりをやったのかなっておもうんですが、たしかにこれはたのしい。 バンド活動していたり、絵をかいたりする人達の気持ちがすこしだけわかりました。すごいな。

これは結果であって、なぜこうできたのかという話ですね。僕の中ではだいたい次の要素が強かったなと。

1. @TAKAKING22 と きょんが大枠で信頼しあえる仲であった
2. @TAKAKING22 がプロレスやアイドルという「エンターテイメント」を好きでありよく見ている
3. ジャズピアニストがきょんが所属する基盤チームにいた
4. きょんの夢がエンジニアで東京ドーム公演であった
5. きょんが昔、ニコニコ動画でアンパンマンのジャズアレンジを聞いたことがあり感動していた
6. @TAKAKING22 や きょんを信頼してくれる仲間がいた

どの要素も重要だったのかなーとおもいました。どれかが欠けてもこの構成にはならなかったのではないだろうか。 そしてこの企画をうけいれてくれた 運営および参加者に感謝しています。

楽曲の使用。JASRAC

生演奏するということで、JASRACとのつきあいが必要になりました。 先日料金をおさめたので、そこまでの流れは次のとおりです。

1. 会場がJASRACと契約しているかを調べる
2. 会場の定員数、チケット代、利用する楽曲のJASRAC登録されているか検索、利用するときの長さを確定する
3. オンラインで見積もりをしてみる
4. 開催5日前までに申請書を書いて会場最寄りのJASRAC支社に郵送する
5. 後日電話で詳細の確認がくる
6. 請求書が送付される
7. 振り込みをして完了

大学とかで開催する場合でも、きっと音楽教室みたいなところはJASRACと包括契約している場合があるかとおもいます。一般的にはライブハウスとかです。 今回の会場はどうも契約していないのではないかということだったので、2にすすみました。 基本は会場の定員数で料金がきまります。利用するときの長さはメロディをどれくらい演奏するかです。今回のわたしたちの構成はメロディ部分はすくなかったので料金をおさえられました。 楽曲はこちらから検索できます。

作品データベース検索サービス

見積もりはこちらでできます。

使用料計算シミュレーション JASRAC

これでだいたいの料金がわかるとおもいます。 ちなみに私は「ファッションショー」みたいなもので見積もりをしました。

ここからは郵送してうんぬんです。公式に手続きの流れがあるのでリンクを。

各種イベント、施設での演奏など JASRAC

スクラムフェス大阪は会場が大阪だったので大阪支社に郵送しました。 そうすると後日、イベントの概要とかいろんなことを電話で5minくらい確認してくれます。そりゃIT系のカンファレンスで生演奏してとかわけわからんですよね。。。

で、後日請求書がとどくので振込みをします。 こんな封筒です。

JASRAC封筒

まとめ

最&高なプレゼンテーションのありかたを模索していきたい。大切な1歩をふみださせてくれたみなさまありがとうございました。 どのような形になるかはわからないけれど、ご依頼うけつけております。一緒につくりだせたらとおもいます。

Special Thanks

• ツインスピーカー @TAKAKING22
• ジャズピアニスト ねの
• PA おの
• 会場音頭 さとりゅー
• キュー出し ぎーの
• メイキング映像作成サポート みやざき
• RSGT2019 OST参加者
• スクラムフェス大阪運営委員会
• スクラムフェス大阪参加者
• 関西大学
• JASRAC
• 株式会社オンザロード
• 楽天株式会社

それ1ピクセルずれてない? ってわかるのか試してみた

Regional Scrum Gathering Tokyo 2019 というカンファレンスで @ryuzee さんとはなしているときに、

Webサイトみていると、これなんか1ピクセルくらいズレているってすぐわかるよねー。きになる。

と言っていました。わたしもたまにWebサイトつくることにかかわるけれども、(要求されている品質の都合上)なんとなくでやっていることもままあって、厳密に綺麗にしようみたくするのはあんまり経験がないなーと。

で、自分でつくるかどうかはおいといて、まず「それ1ピクセルずれてない?」って自分で判断できるのかためしてみようとおもいました。

Do you think you’ve got a designer’s eye?

次のWebサイトで簡単なテストをできました。

https://www.supremo.co.uk/designers-eye/

クリックすると次のような画面がでてきて、「このドットは中心ですか?」にYesなら左、Noなら右をクリックしていくかんじです。 10問連続で正解すればクリア。

テスト例

結果、私は2回目くらいでクリアしました。 1回目では三角形の中心がうまくわからず失敗しました。

これだけでWebサイト全般ってわけじゃないけど、Webサイトつくる初心者の人に中心ってわかるー? みたいなノリで研修のアイスブレイクとかにやるのはいいかもなーっておもいました。

ある改善、プラクティスやTryをいつやめるのか。もしくは5000枚のKPTの理由。 #scrumosaka #rsgt2019

先日、 Scrum Fest Osaka 2019というカンファレンスでとある方からこんな質問をうけました。

きょんさんのチームでは、何度かやればうまくいきそうなTryとかプラクティスがあるときに、いつまで挑戦するとか、いつになったらやめるとかそういった基準とかはありますか？

これ聞かれたときに昔の自分だったら「やれなくなるまでは挑戦しつづける」って答えていたとおもうんですよね。でも、今は違うなーと。 僕が答えたのは「やりたい意思がある限り続ける。やりたくないものをやるのは楽しくない。」で、もっと端的にいうと

チームにできるプラクティスは残るし、できないプラクティスは残らない。

というものです。ある種の適者生存というか。プラクティスが正しいから残るのではないというかんじですかね。 ただ、それだと怠惰でルールのないチームは一向に成長しないので、成長するための仕掛けは必要だとはおもいます。 でもそのときに、ただ問題を解決するためにプラクティスをいれることでは定着しないんだろうなーというのが自分の感覚です。 毎日のように徹底された食生活管理と運動を納得してもできないこともあるし。

まだうまくまとめられないんですが、感覚的には「問題を解決する方向と、自分が楽しめる方向が同じ方向をむいている」ってことかなーっておもいます。 で、過去の自分もそうでしたが、「人を問題に寄せる」のはビジネスなんだから当然のようにできるっておもってしまって、いろんなところでヘイトがたまる。。。 いまの基盤チームはそれは時間がかかるのが普通なので、15min毎にとても小さな量のいい事にもわるい事にも触れ続けることで、人を問題に寄せる、問題と一体となるくらいに考えられるような場にしていくことをやるようになりました。それが大量の付箋となっている KPT as ARTなやつです。 Scrum Fest Osaka にておおまかには bleisさんとdico_lequeさんが話してくれました。

KPT as ART

Scrum Fest Osaka 2019 - 感謝のKPT 5000枚 -基盤チームのレトロスペクティブ- | ConfEngine - Conference Platform

KPT as ART になった理由。ふりかえりへのむきあいかた。

わたしからはこれの経緯とか語られなかった部分を。

これも最初からうまくいったかというと、チーム内でいろんな意見もありましたが、わたしはこれがうまくいくと信じていたし、いろんな議論をへて今の形になりました。チーム内であったのは「情報がたくさんあって整理できない」というものでした。これはいわゆるKPTとは情報を整理し、問題や改善案を具象化する行為だと考えていれば当然だとおもいます。でも、私がおもうにそれは長期間存在するチームには無理だということです。おおくの人はかしこいというか、かしこくないので、具象化できる課題はすぐに尽きます。いいかえると、適切な具象化をあまりできません。

人間はあまり賢くないので整理するため具象化するためのKPTというのはすぐに限界をむかえます。これがKPTがうまくいかない根本だと私は考えています。

1週間に1度できないKPTにむかいあうよりも、具象化するための材料となる量を増やしていき、文字通りその情報にかこまれることで、なんとなく自分達の状況が心にうかびあがってくる。そういったスタイルが長期間存続させるチームには最適だと。

ので、ふりかえりででるような情報は整理しながら増やしていくのではなく、好きなときに整理する、どちらかというと、整理できる状況になったら自然とされる、というのがいいのだろうと。エンジニアというのもあって、とかく情報を整理したがる性質からの脱却に時間がかかったメンバーもいましたが、それもふくめてゆっくりと慣れていきました。

これに似たこととして、チームの外から「この付箋を見返すことなんてできないから意味ないでしょ」とかいわれます。これも結局は上と一緒で、KPTとは整理してチームの道標となるべきものであるという考えからだとおもいます。私達はそういうことをこのKPTでやりたいわけじゃないので、別にそういった必要はないという回答になります。

では、基盤チームは自分達が向かうべき場所についてはどのように話しあい、どのようにそれがのこり、どのようにいまかかえている問題がのこるのか。 基本的には会話でなされていて、それがテキストとしてはKPTにのこります。でもその付箋を見返すことはないですね。 チーム内で濃密に会話したときの体験のほうが付箋に貼られるよりずっと記憶にのこり、そして信頼関係を築くためにはずっと大切だと、そう実感しているからです。 そしてまた、私が基盤チームの考えをプレゼンテーションにしていき、みんなの意思がまた1つかたまる。そういったサイクルをこの4年間続けてきた。といったかたちです。

ちょっと長くなってきたので、基盤チームの話はこのへんで。 続きとか、他の話気になるー!って人は、飲みにさそったり、お仕事のご依頼おまちしております。(あ kyon-mm.com