bussorenre Laboratory

hoge piyo foo bar

DONEを定義するのではなくUNDONE を定義する

@bussorenre です。

スクラムで議論が難しい要素の一つに「DONEの定義」というものがあります。 「プロダクトが顧客にリリースされるまでに必要なすべての要素」のうち、スプリント中に完了できるものがDONE、できないものがUNDONE というすごくざっくりした定義をしたりしますが、「DONEの定義」という名前に引っ張られてDONEを定義しようとすると上手く行きません(実際上手く切り分けられませんでした)

そこで、とにかくプロダクトの企画からリリースまで、ありとあらゆるすべてのタスクを列挙していき、以下の3つに整理します。

  • このタスクはチームの責務であると明確に言えるもの
  • このタスクはチームの責務ではないと明確に言えるもの
  • どちらとも言えない、わからないタスクや、今まで存在しなかった新たなタスク

「このタスクは開発チームであると明確に言えるもの」はそのまま「DONEの定義」に放り込むことができます。設計・実装・レビュー・テスト等、どんな組織でもおおよそ存在するであろうタスク要素は分解が簡単ですが、そうでないタスクも全然あると思います。

「このタスクは開発チームの責務ではないもの 」と明確に言えるものは、基本的にDONEでもUNDONEでもない、「やらなくていいタスク」として扱えます。しかし、このリストは定期的に見返す必要があります。「本当にやらなくて良いタスクだったのか?」「組織の境界がどうなっているのか?」という、スクラムチームの周囲を取り巻く環境を把握する唯一のコンパスになるからです。

そして、最後「どちらとも言えないわからないタスク」は「UNDONEの定義」になります。UNDONEは言い換えると負債です。UNDONE が積み重なれば積み重なるほど、プロジェクトはどこかで爆発します。UNDONE と定義されたタスクを、いかにして「DONEの定義」に落とし込み負債の解消に務めることが出来るかどうかは、スクラムマスターの腕の見せ所の一つです。

過去の経験上、しっかり意識していないと「UNDONE」に陥りやすいなと考えているタスクは

の3つです。特にドキュメンテーションは本当に難しいです。大真面目にやると、実際にコードを書く業務の3倍くらいはドキュメンテーションの読み書きに費やしていってると言っても過言じゃないくらいの膨大な量になるし、かといって適当にやると後から「このコードなんでこんな挙動しているんだ?」と言って、混乱のもとになって結果的にタイムロス(=負債)になります。また、一度ドキュメントを書いたから良いというわけではなく、コードと同様にドキュメントもメンテナンスされ続ける必要があります。このドキュメント保守が非常に厳しい。

ドキュメンテーションは「コード」に対するドキュメントの話だけでなく、あらゆる要素に対して発生します。例えば、コンテンツの管理(どこにどのファイルが格納されているか)といったドキュメントであったり、顧客対応履歴(ex.課題管理票の更新)であったり、そもそもプロジェクトに関わるファイルがあっちこっちに散らばってどれがどのファイルだったかわかりにくくなったりなど。

他にはenvファイルの更新(devとprodで違う値をどう確認するか)とかがUNDONE になったりするでしょうか。

「全体のタスク - UNDONE = DONE」という至極シンプルな計算で DONE を定義すると、DONEの定義に明確性が増し、またチームが持つ課題を認識しやすいと思われます。DONEの定義をにらめっこしてても良いDONEの定義はできません。

心理的安全性を生み出すスクラムマスターのムーブ

@bussorenre です。 ここ二週間くらい、プロジェクトマネジメントとディレクション、開発チームの組織の仕方、運営方法などについて色々回したり考えたりしてました。

心理的安全性とはなにか?を定義する前に、自己組織化されたチームについて説明する必要がある。

自己組織化されたチームとは、例によって江端先生(@ebacky)の言葉を借りると以下のような形になる。

 - チームのゴールが明確であること
 - チームの仕事や裁量の境界が明確であること
 - チームメンバーが,自分たちのやるべきことを自分たちで1秒以内に決定できること

そもそも自己組織化とは、あるランダムな状態にある構成要素が、構成要素間に働く相互作用により自発的に特定の秩序構造を形成する現象のことで、要するに統制する人(いわゆるプロジェクトマネージャーとか)が存在しなくても、自発的に何らかの目的のために自走し続けるチームを「自己組織化されたチーム」と称する。

チームメンバーが次何やるべきかを即決するためには、「チームあるいはプロジェクトの状態」が一瞥しただけで完全に理解できる状態でなければならない。アジャイルボード・カンバンなど、様々なタスク管理方法はあるが、それらは所詮ツールでしかなく、基本は「ほうれんそう」で、JIRAとかTrelloとかgithub issues に乗ってくるチケットリストはその副産物に過ぎない。

この情報共有の精度の高さ(抜け漏れの無さ)と心理的安全性の高さは非常に高い相関があると考えている。

上手く行っている時は良いのだが、上手く行っていない時に正しく情報共有されるかが非常に重要で、ミスや失敗や目標不達などを、きちんと周囲に共有できるか、また、それを良しとする心理状態にチームがなっているかが、心理的安全性の高さだと思われる。

この問に対して具体的な解は無いものの、ヒントのような、今までの試行錯誤から得たバッドノウハウが蓄積されてきたので共有します。

前提:チーム構成やメンバー構成など

組織の構成から考え直さないといけない、致命的なケース。

POとスクラムマスターを同一人物が兼任しない

スクラムの基本にして超重要かつ、これが達成されただけで問題の8割は解決すると思っている問題。散々スクラムで「POとSMは兼任しては行けない」と言われているのにも関わらず、結果的にスクラムマスターがPO的なムーブをしていたり、POがスクラムマスター的なムーブをしてしまうケースが非常によくある。

そのような事が発生する理由は多岐に渡るが、基本的には「スクラムマスター」というロールへの周囲(あるいはスクラムマスター本人)の理解不足が原因だと思われるケースが多い。POはROIに対する権限と責任を持つが、それ以上の権限はない。スクラムマスターに至っては、そもそもプロジェクトに対して何一つも決定権を持たない。

友人がアドバイスしてくれた「POとSMが兼任するとなってしまった場合、それはもはやただの圧にしかならない」という言葉にはかなり納得感がある。圧になってしまうと、チームが萎縮してしまい情報共有が素直になされない。

対策としては、上長含めチーム全員にスクラムについて学んでもらう(そのために資料を用意したり勉強会を行ったり研修の予算を確保したりなど)のが最も効果的だと思われるが、これはなかなか難しいし骨が折れる。端的に言って面倒くさい。

しかし、これを行うのもスクラムマスターのムーブの一つだと思う。

先程も説明したとおり、スクラムマスターにはプロジェクトに対しての決定権が何一つ無いのだが、POを兼任しているとなると、ROIの優先度高の項目に「チームのスクラムへの理解の向上」というプロダクトバックログアイテムを建てれると思うので、真摯にやってくしかないと思う。

メンバーのスタンスが育っていない

これも基本にして超重要な話なのだが、スクラムは「すべてのチームメンバーが、自分の力で考えて、判断行動できる」という大前提に立っている。これが出来ないと話にならない。この「スタンス」に関しては研修プログラムや各社の人事評価精度によって様々な表現方法があると思うが、リンク&モチベーションの研修だと「STARの観点」と評されていたり、リクルートの評価指標だと「6つのスキルと4つのスタンス」等と呼ばれていたりする。要するに「自分の力で考えて、判断行動できる」人材がメンバーである必要がある。

また、この「スタンス」に関しては後天的獲得が難しい(歳を取れば取るほど習得が難しい)と考えられており、実際の肌感として自分もそう思う。(過労やそれに伴う病気などにより、一時的にスタンス面が劣ってしまうことは全然あるが、その場合は環境を整えれば回復すると思う。)

対策としては、採用時にふるいをかける以上に効果的なものは無いが、「スタンス面が足りていないな」と思う人材が、精神的に若手であればあるほどチャンスは大きい。 「精神的に若手」とはどういうことかと言うと、「周囲の同僚にリスペクトを持ち、学び成長をを得ていこうとする姿勢」を持っている人材のことで、逆に言うと年齢が若くても学ぶ姿勢がない人はかなり厳しい。

スクラムマスターとしてのムーブの一つに、自らのスタンスを魅せるけるというのがあると考えており、スタンス面で未熟なメンバーのロールモデルの一つになるというのが唯一にして最後に許されたムーブだと思われる。

日々の行動

前提の2つが解決すれば問題の80%以上は解決しているが、より具体的な行動指針として、意識してか無意識でかで、自分がやっているムーブは大きく以下の3つ

チームメンバとしてのロールを持つ

これは、スクラムの原則とは多少少しズレたところにあるが、POとSMの兼任ほどのバッドノウハウではない。スクラム体制の構築が甘かったり、周囲への理解を深めていこうというフェーズに有効。「あいつあれこれ言うだけで1行もコード書かねーじゃね―か」と言われるのを阻止する。

チーム内で最も技能や知識が豊富なエンジニアでありたいと思うが、そうでなくてもいい。むしろそうじゃなかったから良かったのかもしれない。周囲の同僚にひたすらコードレビュー等でミスや問題を指摘されまくってるからこそ良かったのかもしれない。

上手く行ってない時に、「上手く行っていない」と自分が言う事ができる。というか、そもそも自分がそれをできていないなら、心理的安全性の高いチームとは言えない。ミスったなと思ったら「ミスりましたすみません」というムーブを見せることが出来るので、スクラム初期にはチームメンバー兼任はむしろ良いムーブだと思う。

が、正直、率直な同僚の評価を聞いてみたい気もする笑

自分の弱みを見せる

例えば、僕は生活リズムが超乱れやすい。朝6時くらいから始業している時期もあれば、13時まで起きれない時期もある。が、この業界朝弱い人が比較的多いので、「わいも朝弱いんすよー」「じゃぁ定例遅めに設定するか」みたいな会話が出来る。

これに関しては、自分が意識してやってきたと言うより、同僚に自分も乗っかることが出来た。という側面のほうが大きい。彼が居なかったらここまでフリーダムな会議体の設定は出来ていない。

簡単に書いたが、「自分の弱みを見せる」というのは実は非常に難しく、周囲に弱みを肯定してくれる同僚がたくさんいたからこそ出来たと思う。そうじゃなかったら出来ないし、出来なかった。「bussorenre くんなら出来るよ」というエンカーレッジを周囲の人がたくさんしてくれたからこそ、今のロールを担えている側面もあるし、自分も「〇〇さんなら出来ますよ」みたいなエンカーレッジをし続けていたいと思う。

サーバントリーダーに務める

多分、無意識でやっている。

よく自分はトイレ掃除に喩えるのだが、トイレ掃除なんてものは誰もやりたくない。しかし、誰かがやらないとアメニティが下がる超重要タスクで、正直、やってもまるで評価されない。直接的な営業成績が上がるわけでも、トイレ掃除をしたからコードが改善されるわけでもないから。

ソフトウェアエンジニアにおいても、トイレ掃除にあたる仕事があり、その主たるものの一つに「マネージャー」と呼ばれるロールのタスクがあると思っていて、他の業界は知らないけど、この業界はマネージャーになってもあまり良い事がなく、むしろ自分でコードを書く時間が相対的に減ってしまったり、そもそも人間と付き合うのが苦手だからソフトウェアエンジニアやってるのにどうしてみたいな、色々な闇の側面が強い。

が、誰かがこのあたりを整えることによって、他のメンバーが快適に業務に従事できたりする。「マネージャー」というロールのタスク以外にも、あれこれアメニティを上げるタスクはあると思うが、組織やビジネスの成長フェーズによってかなり違いがあると思うので具体的に何をどうするか?は一概には言えない。「全体を俯瞰して、影になっている部分に光を当てる」くらいの感覚なのかなぁ…?

冒頭この項目で「無意識にやっている」「評価されない」と書いたが、冷静に考えると、現状の自分はかなり評価してもらえている環境に居ると思っていて、だからこそ、特に意識せず、目の前の影に光を当てるというタスクに従事出来ているのかもしれない。

まとめ

色々偉そうな書き方をしてしまったけど、某フィギュアに砂かけて写真取る人のダースベイダーみたいな上司はかなり心理的安全性が高いと思っており、彼は「仕事だるい」とか「プリキュア見るから休みます」みたいな事を堂々と宣言して仕事をサボったりして部下に安心感を与えつつ、一方で戦闘時は最前線で戦ったり、きちんと結果にコミットしている。ああいったムーブを出来るようになりたいなと常々思う。

ある種「弱み」みたいなものをちゃんと見せつつ、メンバーの弱みを理解しつつ、それでもなお結果を出すにはどうしたら良いか?を考えて行動できる人は真のスクラムマスターだと思う。

あと、後半は書きながら「あれ、これ自分の力じゃなくて周囲の力じゃね…??」と思いながら書いてた。実際、周囲の力があってこそなりたってると思う。この点に関しては、「つまり、あなたの職場環境が素晴らしいと言う事ですよね?」という問いに対して「はいそうです」としか言えない。いい職場だマジで。(笑)

自分もその「周囲の力」の1因子だと言うことで、その1因子がどういう動き方をしているのかを言語化したら、こんな感じになった。ということでどうかひとつ。

天才ではない自分が「けしからん」ことを面白可笑しくやるにはどうしたら良いか?

こんばんわ。 @bussorenre です。

先日、情熱大陸 #1140「サイバー技術開発集団 統括・登大遊」 が放送されました。 tver.jp

隠れた天才が、ついに多くの人々に知れ渡ることになってしまったわけですが、この人は本当にすごい。頭がおかしい(※天才過ぎて常人には理解できないの意で使用しています)。高校生のときに既に、64のGoldeneye が好きすぎて似たようなゲームを自作したり、そのプログラミングノウハウを本にして出版したり、どういう用途にするつもりだったのかさっぱり意味がわからないけど、高校で放送された校内放送を全部録音してアーカイブ・参照できるようにしたり。

DirectX9.0 3Dアクションゲーム・プログラミング―DirectXを使った3Dアクション・ゲーム作成のノウハウ (I・O BOOKS) | 登 大遊 |本 | 通販 | Amazon

で、この人はさぞ物事を論理的に考えているのかと言うとそうでもなく、本人も以前にブログで書いているように、 インスピレーションや面白そうと思ったことを突き詰める事を優先しており、補助的に論理的思考を使っているように見える。

softether.hatenadiary.org

まぁ、色々書いたが、↑の記事を読むと、「結局こういう人の事を一言で要約する天才としか言えないよね」となるわけで。実際に登さんの天才性は、僕が今まで出会ってきた人の中で、頭50個くらい飛び抜けていると思う。

優秀なプログラマーとそうでないプログラマーの生産性は100倍近くも差があるともいうが(実際登さんは1万倍くらいあると思うが笑)、かといって登さんのような天才が1人いればすべての課題が解決するかというわけでもなく、そもそも、登さんは登さんしか居ないわけで、それでは組織やイノベーションがスケールしない。

ではどうすればよいか?と考えた時、2つのアプローチが思いつく。「天才を増やす」ことと、「天才をエミュレートする」ことである。

天才を増やす

天才を増やす方法として、古くから議論されているのが、浅く広くプログラマーを増やすというのが知られている。資料などでは、「裾野を広げる」となどいう言葉でよく表現されている。参考: www.ipa.go.jp

一見矛盾しているかのように見えるが、天才が存在する確率がN%だとすると、100人のプログラマの中に存在する天才はN人だが、1万人居たら天才が100N人存在するということになる。(実際はこんなに単純ではないと思うが)

後天的な教育だけではカバーしきれない無類の才能を発揮するからこそ「天才」と称されるのであって、母集団を増やす(裾野を広げる)ことが最も有効な技だと思われる。

このような観点から見た時、昨今「プログラミングスクール」と呼ばれる事業者が増えてきたことは、基本的に歓迎すべきことだと思う。今まで業界人が「好きな人は放っておいても勝手にやるでしょ」みたいな空気でやってきたのが、需給のバランスが完全にぶっ壊れて、「とにかく高速道路を整備しないと色々な事業が人材不足で死ぬ」となって、人材育成の必要性が急々急務になってきた。

もちろん、課題点も多い。転職詐欺みたいな業者も存在するし、企業から見たら「勉強した割にこいつ使えないな」みたいな人材が一定数居ることも事実だと思う。

しかし、「本当に良い高速道路なのか?そもそもこの道はちゃんと目的地にたどり着く高速道路なのか?」と言った議論・改善に挑戦し続ければ、いずれどんどん良くなると思う。既に業界にいる我々が、「プログラミングスクール卒とかww」とバカにするだけの老害になってはいけない。もちろん、スクール以外の手法・高速道路もどんどん整備しなければならない(それは地下道だったり飛行機だったりするかもしれない)

天才をエミュレートする

すごいざっくり言うと、「三人よれば文殊の知恵」作戦。

今日の本題。

仮に登さんの生産性が通常のプログラマの生産性の100倍だとすると、生産性1のプログラマを100人集めれば同等のパワーが出せるのか?と言われると否で、それは既に「人月の神話」等で徹底的に議論されているし、実経験としても、コミュニケーション遅延が発生したり、コンテキスト境界がぐっちゃぐちゃになったりで、実際100人居たとしても20 程度のパワーしか出ない。

そこで考えたのが、生産性が10のプログラマを3人集めて、(多少のオーバーヘッドを加味して)3人の合計生産性を20にする。このチームを5つ作る。そうすると15人で100になる。1台の化け物クロックCPUを作るのではなく、複数のCPUを用意してクラウドコンピューティングするイメージが近い。

f:id:bussorenre:20210210034836j:plain
3人よれば文殊の知恵作戦は成立するか?

さて、このような組織を作るときに必要なのは、統率ではなく、プロトコルである。

従来のSIer あるいは SESと呼ばれる形態の組織構造は、おおかれ少なかれピラミッド型で、最上位層から最下層へ指示を伝達して物事を達成しようとする構造をしている。

f:id:bussorenre:20210210042332j:plain

この構造だと、ボトルネックになるのはマネージャーと呼ばれる指示を出す人で、要はディスパッチャーに負荷が集中してしまい、一見スケール出来るように見えてスケールできてない。

そもそも、「ワーカー」と「ディスパッチャー」という、明らかに役割の違う2種類の人員を用意しなければいけない。これはスケールしにくい。また、今までワーカーとして機能していた人員が、「君優秀だから昇格ね」と言われてディスパッチャーに回ったとしても、全く異なる機能を求められるので、ワーカーとしては優秀だったけどディスパッチャーとしては全然機能しない可能性がある。これでは人材がスケールしない。

目指すべき姿は、プロトコルによってお互いがお互いに情報をやり取りしワークする双方向な体制。全員が同じプロトコルを使えると仮定すると、この組織はわりと柔軟にスケールさせることが出来る。と仮設を立てている。

f:id:bussorenre:20210210042352j:plain

特定の目的を達成するために各々が共通のプロトコルを用いて行動を行うことによって、いわゆる「チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ」という状態に持っていくことが出来る。この「共通のプロトコル」と呼んでいるやつは、具体的には巷では「スクラム」と呼ばれていたり、「アジャイル」と呼ばれている物だったりするかもしれないが、これは目的に沿っていれば正直何でもいいと思う。

しかし、言うは安し、寿司は旨しで、これを実現するには非常に大きな課題がある。それは、「何を達成するために我々は居るのか?」という目的の共通認識をしっかり持つことが難しいということである。ピラミッド型組織は良くも悪くも最上位のディスパッチャーが、「ジョブを割り振る」という方法で、組織の向きを統制することが出来る。しかし、双方向型の組織はこの機構が無いので、全員が同じ向きを向いて働いていますよね?というチェック機構が別途必要になる。

今の所、僕はこれに対する明確な回答を持っていない。1 on 1 をやる。360度評価をやる。キックオフやビジョンミーティングをやったり、ミッションをより明確に打ち出す、採用時にカルチャーマッチを重視するなど、各論はわかるが、仕組みとしてこのプロトコルに取り入れる手法に確信を持てていない。

ここで、「目的の共通認識をしっかり持つ」ために更にもう一つの仮設を立ててみる。それは、ほんの少しだけ天才の真似事をしてみる、ということ。

具体的には、登さんのように、「極論目的とかどうでもいいんです、(モチベーションのために)面白いからやる」ということなのだが、これを論理的に考えてパクろうと考えている時点で「論理的思考を破棄する」に反する。

自分がやるならどうすればいいかなーと考えてみるのだが、自分ならおそらく、突然好きなキャラのコスプレをして、中二病全開で「俺は世界の変革者だ。こんなことが実現したら、たいそうけしからん!面白くなりそうだ!」と叫んでみる。などをやると思う。この行為に多分論理的な思考はないと思う。多分。(追記:これを書いているのは深夜帯なので、夜が明けたときに自分がこの記事を書いたことを覚えていたら撮影してみようと思う笑)

それで場が白けたら、「調子に乗りましたすみませんでした」と言ってやめれば良い。そもそも「自分が面白い」と思わなかったらやらない。冷静に考えたら「いや無理でしょ」とか「いやだめでしょ」と言ったことを、普段やらないような言動でを全力で提案してみる。最初はくっそ恥ずかしいが、とりあえず言うだけ言ってみる。

2人乗ってきたら、自分含めてちょうど3人よって文殊の知恵作戦が立てれそうなので、やってみる。10人が乗ってきたら多すぎる。スモールスタートには向いていない。やめたほうが良い。あるいは人数を絞って3人で文殊の知恵作戦をすれば良い。

こういうのを繰り返し行っていくと、徐々に組織が同じ方向に向いていくんじゃないかな―と思っている。現状まだ思っているだけなので、実際にこれからやってみる。やっってみた結果は2021年の振り返りあたりで書こうかなと思う。

まとめ

  • 1人の天才にすべてを依存するのは組織やイノベーションがスケールしない
  • 天才を増やすには、裾野を広げるしかない
  • 天才をエミュレートするには、徒党を組んで、かつ個々人が独立してワークするための「プロトコル」と「目的の共通認識」を保つ必要がある。
  • 「目的の共通認識」を保つためには、突拍子も無いことを言ったりやってしてみて、人が乗ってくるか試してみる。程よい人数が乗ってこなければ辞める。

今日はかなり抽象的な方針だったり仮設を書いてみたが、より具体的な各論は試して見る過程で発見したり学ぶことができたら共有していこうと思う。

※ ご意見・知見などは全力でコメントやTwitterでお待ちしております。

追記:「生産性が10のプログラマを3人集めて20にする」。について

ここはもっと議論というか改良の余地があると思っていて、お互いの得手不得手を補い合えるような3人が集まったとすると、実際には10*3 の30よりも大きな50くらいまで生産性は出せるんじゃないかなと思っている。(いわゆる相乗効果を狙うという奴) だが、実際にこの相乗効果を狙うのは難しいパズルを解くのと同じくらい難しく、人材パズルの天才が必要なんじゃないかと思ってあえて考慮しなかった。

しかし、最後に書いた「目的の共通認識」を保つために、面白そうな事を面白おかしく言ったりやったりしてるうちに、自然と「自分は(君たちが持ってない)こういうところが得意だから、それを手伝えるよ」といったフォロワーシップのある人が出現してくる気もしており、人材パズルの天才は実は不要なんじゃないかという可能性もあると思う。

あと、天才と称される登さんでさえ、チームを組んでプロジェクトに挑んでいるのだから、天才で無い僕はなおさら徒党を組む必要があると思う。そのために人間同士のプロトコルについて勉強したいので、最近はEngneering Manager というロールにかなり興味がある。他の組織がどういうEMを育てているかめっちゃ興味がある。

追記2:モチベーションと努力について

結局のところ、↑で書いた手法は内発的動機づけに依存すると思う。誰しもが何らかの内発的動機づけを持っているわけではないと思う。一方、外発的動機付けによってとんでもないモチベーションとパワーを発揮する天才も居ると思っていて(私には真似できないが)、外発的動機づけのほうが優先度が高い人は、そういった天才を真似するにはどうしたらいいかを考えるのもアリなのかもしれない。

あと、モチベーションのベクトルの強さと、努力の量と質はかなり相関があると思っていて、結局「自分の好きなこと」じゃないと、深い努力につながらないのでは?という気もする。本当に些細なことから好きなことを見つけて努力や挑戦につなげる才能(メタ才能のような概念)も必要だが、それについては考えがあるので別途まとめてみようと思う

2020年を振り返る

@bussorenre です。今日が仕事納めでした。

個人的にも最後の20代ということで、かなり区切りとなる年だったなと思います。2020年は、世界的にも、自分的にも大変化の年でした。

まず、コロナ。

現在進行系なのでアレコレ言及するのも難しいのですが、確実に言えることは、まさか2020年にもなって世界的に感染症が大流行して大混乱になるだなんて誰も予想してなかったなと思います。もちろん私も予想してませんでした。 それがあれよあれよという間に大変なことになって。

でも、だからといって「コロナが来たから世界が変わってしまった」とはあまり思えず、「コロナによって今まで水面下で動いていたものが表面化した」とか「コロナがその動きを加速させた」と考えています。

随分前から、リモート出勤、時差出勤、在宅勤務などは叫ばれており、徐々にそういうムーブメントは広がりつつありましたし、実際、私の所属する企業ではコロナ以前から(事前承認は必要だが)フルリモートOKでした。 チャットだけで、オンラインだけで完結するコミュニケーションなんて、MMO全盛期に廃人をしてきた私からしたら現実世界でのコミュニケーションよりも慣れ親しんだものなので、 困ることはなかったです。余計な忖度もなく、オフィスで他者の目線を過剰に気にすることもなくなり、自分らしく、自分の得意な方法で、自分の役割をこなすことができたと思います。

さて、そんな世界を加速させたコロナによって、私生活も大きく劇的に変化しました。何かというと、離婚しました。

永く続かせたいとは思っていました。が、あれよあれよという間に、一瞬で瓦解しました。 反省はたくさんあります。相手のこともあるので詳細は述べません。

ただ一つ言えることは、自分の意志で決めたこと。進めて来たこと。背負ったリスク。払った代償。 これら全てに偽りは何一つなく、「やりきったぞ」と自分に言えることですね。

「あのときどうすればよかったのか?」をどう振り返っても代替案などなく、つまり、その時の自分に出来る全力を出し切っての失敗だとしか思えないのです。 全力でやりきった事に後悔なんてないってかっこいい主人公は言いますが、そんな事はまずなく、全力でやりきったからこそ、後悔があります。 もちろん、相手のことは、たとえ宇宙が滅んでも許しません。私はそんなにキレイな人間ではありません。恨むべくは恨む。

ただ、もう一つ言えることは、この件に関して、金銭的・時間的にはかなり大損をしましたが、それで済んだということです。つまり、まだ取り返せます。

人生において、高校生というのはたった3年間しかなく、その期間は(少なくとも日本においては)やり直すことはできません。 私が人生で大きく挫折したあの期間は、もう戻ってこないし取り返せない。だからこそ、今まで辛く・深い闇に囚われたまま生きてきました。

しかし、この件に関しては、まだまだ取り返しが効くんですね。別に再婚しても良いわけですから。これはありがたい。 人は「失敗を恐れずにチャレンジしろ」と無責任に言いますが、それは失敗しても後がある心身ともに裕福な人たちのセリフで、多くのケースにおいて、一回失敗したら再起のチャンスなんてほぼないんです。

なので、この「失敗しても次のチャレンジがある」というのは非常にありがたいです。

そして、私自身も、いつの間にか「失敗しても後がある」心身ともに裕福な人になっている事に気が付きました。

「次のチャンスやチャレンジ」を提供してくれる場所・機会・人に恵まれていること。 また、私とともに、あるいは私の代わりに怒ったり喜んだりしてくれる人々に囲まれていること。 私の存在を認めれくれ、次の私に期待を寄せてくれる人がたくさんいること。

これほど、これほどありがたいことはないんです。

特に今回は上記のような事もあって、かなり多くの人に助けてもらいました。これは本当に感謝しています。

その恩を仇で返さないための唯一の方法は、「前向きに生き、次の機会に挑戦する」こと。それだけなんですね。 これに気がつくことのできたのが今年最大の気付きだったでしょうか。

お世話になった方々、本当にありがとうございました。

さて、ここまでエモい話で具体性のないふわっとした話題だったんですが。笑

具体的な仕事の話でいうと、今年はいっぱいプログラムを書きました。

実はかれこれ10年近く、プログラムと向き合うのが苦痛で苦痛で仕方がなく、 長い長いスランプを生きてきたのですが、一昨年くらいからその出口が見え始め、ようやく完全にスランプを脱出したなと思います。

10年かかりました。好きなことで生きていく大きなリスクの一つに、精神的に取り返しがつきにくいことがあると思います。その間、なにかの未練で成仏できないさまよう魂みたいな感じでした笑

業務で書いたプログラム量はおおよそ去年の2倍。趣味プロ含めるとおおよそ3倍近く。何か書いたり作ったり調べたりしたでしょうか。スランプの期間はこれが苦痛で苦痛で、 「これを調べても、これを作っても無駄になんじゃないだろうか」という虚無感と恐怖感に襲われない日はなかったです。

ここに至るまでのブレイクスルーは何段階かあるのですが、まず1つが、Scala と出会ったこと。これは非常に大きいです。 今まで様々な言語を触れてきましたが、そのたびに「なにか違う」という違和感を拭えずにいました。go言語を触れたころあたりからこの違和感の正体に気が付き始め、 Scala で完全に払拭できた感じでしょうか。 静的型付けの有用性の再確認。関数型的なアプローチを提供する裏側で、しっかり計算機科学的に効率の良いアルゴリズムを採用していること。実際にビジネスロジックを表現するのにかかせないOOPとしての側面。 広く利用されるJVM上で動くという利点。

何より、学べば学ぶほど、自分の力になっていると感じることの出来るパラダイムでした。これは、本当に10年ぶりくらいに感じた楽しさでした。初めてC++に触れた時以来の感動です。

そしてそれを業務として成立できたこと。これも非常に大きい。

実際穴だらけのコードを書いてるなって反省することも多いですが、とにかく量をこなすことを意識してきたこの二年でした。 (それでも同チーム内の1位の人には余裕で4倍近い生産性の差をつけられてるし、なんなら今年はscalafix などをいい感じにやってくれるbot にも負けてる気がしないでもないが笑)

まぁ、流石にこの精度でこの生産性じゃ微妙なので、来年はもうちょっと精度を上げると比例して生産性も上がるみたいな戦略を模索していきたい所存。

他には、(これはチーム的にどう思われてるかは正直未知数だが)スクラムマスター的な事をしたり、メンター的なことをしたりもしましたね。 自分みたいな奴がそういう重要ロールやって大丈夫か?????ってビクビクしながらやってますね。

この辺は、定量評価が難しいのでなんともな部分もあるのですが、自分の中に「あるべき姿」みたいなのが描けるようになったのは大きいですね。「ゴールが見えない」のに「これをやる」とかだと人は納得しませんからね。 そういう意味では、年始に受けたCSMトレーニング(記録記事はこれ)はかなり役に立ってます。

来年はもうちょっとこの辺を成熟して、外部に公開できる知見として出していければ良いかなという所存ですね。

とにもかくにも、激動の一年でした。来年も大変そうなので、来年の抱負は来年考えます。それでは!!

Certified Scrum Master研修記録 2020.02.06-08

はじめに - CSMの概要 と 受けたきっかけ

2020.02.06 から2020.02.08 から3日間、 https://www.odd-e.jp/ja/service_csm/ の CSM研修 を受けてきました。研修を行っているのは、 odd-e ですが、資格を発行・認定するのは Scrum Aliance という会社です。

私が受けた会の講師は江端一将( ebacky )さんで、日本人唯一のCST (スクラムを教えられる認定コーチ)です。

ebacky さんいわく「参加者のレベルや状況によって内容をその場その場でアレンジしている」とのことなので、同じ研修でも会によって全然内容が異なります。この記事を読んでも「全然違う研修だった」ということもあると思います。

研修の流れですが、

  • odd-e のトレーニングプログラム(2日 or 3日)を受ける
  • webテストの案内が来るので、これを受けて合格する

以上の2プロセスにより、認定スクラムマスターになれます。認定スクラムマスターになって初めて受けられるアドバンスドな研修やイベント等もあるようなので、まずはここを目指すと良いのかなと思います。

認定の期間は2年間です。更新手続きもありますが、それは別途そのときに書こうかなと思います。

受講経緯

CSM の存在は、社内の過去の参加者のLT会等でも知ってましたし、界隈で有名だったので知ってました。 書籍だと kaizen journey 等でスクラムが取り上げられていたり、自社でも過去にodd-e の方をスクラムコーチとして呼んでいたこともあります。(私はその当時そのチームには居ませんでしたが…)

個人的なモチベーションとしては、個人の力の限界をひしひしと感じておりました。いくら一人が技術的・仕事的にスキルアップしても、一人の力はたかがしてれます。 当時は「組織として製品を作る」という経験が乏しいと感じていたので、そのための組織論であったり方法論であったりを深めたいというモチベーションがありました。

また、当時所属していたチームは完全な縦割りで、何かしらコミュニケーションを加速させる役割の人が必要だなとも思っていたので、そのための一歩として申し出て受けました。

研修を受けるにあたっての心構え・前準備

本研修は、スクラムに関する知識を体系的に学習するための講義ではない です。 (体系的な知識は、基本的に事前資料であったり、 Core Scrum を読む必要があります)

スクラムマスターならどう考え、どう行動(改善)するか」 という トレーニングが主目的です。

受け身の座学の部分も多少はありますが、基本的に自発的な参加を求められる「ディスカッション」や「ワーク」などの時間が最も多いです。曰く

スクラムマスターって言うのを雇うと良いって聞いたんやけど、実際何がええん??」と言う問いに答えられなければなりません。また、「スクラムマスターを雇ってよかったわ。ありがとな!」と言われるような行動を示さなければなりません。

また、この記事をリライトする前に、スクラム 仕事が4倍速くなる“世界標準”のチーム戦術 | ジェフ・サザーランド, 石垣賀子 |本 | 通販 | Amazon を読みました。スクラム創始者の一人、「ジェフ・サザーランド」さんの書籍です。事前に読んでおくと良かったと思う一冊ですが、研修を受けてから読んで理解した部分も多いので、教科書的に何度も読み返す事をして良い本だと思います。

スクラムに関する知識とか

言葉の定義など

グラウンドルールとしての、言葉の定義

本来の定義というよりは、「この場ではこういう意味で扱います」という意味で共有されたもの

  • 研修 : 一方的な情報伝達
  • レーニン : 自らの努力などの働きかけによって自らのスキルを伸ばす
スクラム関連の言葉の定義
  • チーム
    • 7±2 人で構成された組織。それ以上でもそれ以下でも定義に反するのでチームと呼ばない
  • プロジェクト
    • 現状と目的の差を埋めるための活動。(※ 現状と目的との差分の明確度や、個数などは問わない
  • プロダクト
    • 「価値」だと考えられるもの(難しいが、「価値そのもの」ではない。価値だと「考えられる」。お金でも無い)
    • 一つの「プロダクト」に複数の種類の価値が発生することもある
  • スクラム
    • 「プロジェクト」の現状を把握するための「方法論」の一つ
  • スクラムチーム
    • プロダクトオーナー(以下PO), スクラムマスター(以下SM), チーム で構成された組織

方法論とプラクティスの違い

方法論とは

  • 学問に基づいて理論立てて構成されたもの
  • いかなる条件や環境でも有効に働く
  • 目標に対して、直接的には寄与しない

ラクティスとは

  • それまでの習慣や、感覚的に「良さそう」と思われているもの
  • 特定の条件や環境の中でのみ有効に働く
  • 直接的に、目標に寄与する

先述の「スクラム」の定義によると、スクラムは「方法論」なので、具体的なプラクティスは厳密にはスクラムではない。 あくまで、「スクラム」という「方法論」があって、それを肉付けするのが「プラクティス」(具体的に日々やってたりやってなかったりすること)

スクラムは、基本的に「組織学」と「集団心理学」に基づいて構築された「方法論」なので、それらの分野に精通するとよりスクラムへの理解が深まる。

中央集権的組織 vs チーム中心主義的組織

中央集権的組織とは

  • いわゆる「トップダウン型」「三角形のピラミッド型」の構造を持った組織
  • 統制・統治する ことが最大目的の組織構造
  • ピラミッドの最も上に居る人から、末端にかけて「指示・司令」を出して行き組織のコントロールを生み出す。

チーム中心主義的組織とは

  • ボトムアップ型」「相互作用型」という形の構造を持った組織
  • より良い成果を出す ことが最大目的の組織構造
  • 中央集権型組織と異なり、「司令塔」のような存在は無く、各々が各々の「役割」を果たすことで最大の成果を生み出す。

スクラムチームは「チーム」の一種であるのが、スクラムチーム以外にも「チーム中心主義的組織」を生み出すことは可能。(スクラムじゃないから、研修では扱わないとのこと)

日本の企業はほぼみんな「中央集権的組織」になるが、開発で「スクラムチーム(チーム中心主義的組織)」を採用しようとすると、スクラムチームの中と外でどうしても構造上の歪が生まれてしまう。 特に、歪の渦中に飲まれやすいのは、人事評価する評価者(上司とか社長とか)であったり、スクラムチーム外とのやり取りが多い役割の人物であったり、スクラムマスターであったりする。

逆に言うと、これらの人はスクラムチームに余計なノイズが入ってこないように努力する必要がある。

スクラムチームの定義

PO(1人), SM(1人), チーム(5-9人) で構成された組織。

  • PO は スクラムチームの ROI を最大化する
  • チーム は スクラムチームの生産性を最大化する
  • SM は スクラムチームの成果を高めるための活動を見直し、「成果を高める確率」 を最大化する
プロダクトオーナーの責務

どんなプロジェクトにも「予算」は必ず存在する。ROI(投資対効果)を最大にするのがPOの責務。 ここで言う「予算」とは「お金」「人」「時間」など。

ROI を最大化するために、顧客に提供する価値を記述したプロダクトバックログを作成したり、それらの優先順位をつける。

チーム

一方、チームには生産性を最大化する責務がある。ここで言う生産性とは「プロダクト」に対する生産性である。「プロダクト」とは製品の製造だけでなく、関わるドキュメントの作成、メンバーのスキル、文化、なども「プロダクト」になる。何をプロダクトと捉えるかは、プロジェクトで決定される。

「プロダクト」を分解したものが「ストーリー」であり、「ストーリー」を数値化したものが「ストーリーポイント」である。 つまり、ストーリーポイント/スプリント = ベロシティ を最大化することがチームの責務になる。

「ストーリー」に紐付かない作業はすべて「タスク」として分類される。タスクは「ストーリー」ではないので、いくつクリアしてもストーリーポイントは0。つまり、ベロシティに貢献しない

スクラムマスター

上2つのロールと異なり、スクラムマスターは、実際に手を動かしたり、実際にプロジェクトに関わる意思決定をすることができない。 あくまで「成果を高めるための活動を見直す」ことに注力する。

例えば、チームの稼働時間のうち「タスク」に割いている時間の割合が多く、ベロシティに寄与していないと考えたのであれば「タスク」が多く積まれてしまっている原因はなにか、解決するためにはどうしたら良いのか、課題を発見し改善する方法を「提案する」

提案されたプランを採用するのは、PO あるいは チーム あるいは組織外の人の裁量によって行われる。つまり、良いスクラムマスターは自分の出したプランが、チームに採用される確率が高い。

提案したプランを実際に実行して効果が出るかどうか。より効果が期待できるプランを提案する必要があるし、一度提案したプランを見直し、更に良い状態にするための提案を繰り返し行う必要がある。

スクラムの構造

  • 学問
    • 集団心理学
    • 組織学
  • 状態
    • Transparency
    • Inspect
    • Adapt
  • ルール
    • Role
    • Event / Celemony
    • Artifact
    • Time

これらの要素が一つでも欠けていればスクラムではない。

学問

集団心理学、あるいは組織学に基づいて論理的に証明されたことをベースに組み立てられている。 なので、スクラムのルールに追加・変更がある場合は、基本的にそれらの学問において新たな論文が採択される時である。

状態

以下の3つの状態を満たしていなければ、スクラムではない。

  • Transparency
    • 正しい情報が、一箇所に集められており、次の行動が誘発され続けている状態
  • Inspect
    • 目的と現状の差分を把握し続けている状態
  • Adapt
    • 目的と現状の差分を埋めるための活動を続けている状態

Transparency について。「正しい情報」とは

  • 過去の情報ではなく、「現在どうあるか」という現在の情報であり、
  • 誰が見てもどう見ても、一意に同じ解釈ができるもの

つまり、チームの中で一人しか把握していなかったりすることは「正しい情報」ではない。 最初は一人しか把握していなかったことを、チーム全員に共有する(あるいはいつでも見れるようにドキュメント化するなど)をして初めて「正しい情報」になる。

次の行動が誘発され続けている状態とは、↑を見聞きして、「じゃぁ次これをやる必要があるな」と各々が判断できる状態のこと。

Incpect について。「目的と現状の差分を把握し続けている状態」を行うために「カンバン」などのツールを適宜利用する。ツールの運用等に関しては「方法論」ではなく「プラクティス」の領域なので講習の対象外

Adapt について。 これは単純に「ゴールに向けて頑張ろう」という意味だけではない。「このベロシティではこのゴールにたどり着けない」や「そもそも本当に価値のあるものではなくなった」など、変化に対して柔軟に差分を埋める活動を行う。つまり、「目的」さえも変化の対象になりうる。「Transparency」を満たすことが大事

ルール
  • Role
    • 先述の通り、PO(ROI), SM(成功確率), チーム(生産性)、の3つの役割がある。
    • 基本的に兼任は良くないとされているが、あくまで役割なので多少は崩しても良い
      • が、それは熟練したスクラムチームでも難しいので、あくまで欠員が出たとか緊急時のみに留めたほうがいいとの事
  • Event / Ceremony
    • やることが「Must」なこと。これらをやらないとスクラムは成立しない。上からスパンが長い順に並べてる
    • Product Backlog Refinement
      • 要するに優先順位付け
      • プロダクトバックログアイテムの洗い出しや、それらの価値の推定。優先順位決定を行う。
      • 中長期スパンで行う
    • Sprint Planning
      • そのスプリントで何をするかを決める。
      • ここで大事なのは 「何をどうすれば完了になるのかをチーム全員が把握している状態」 がゴールであること
      • スクラム初めてのチームは、スプリントプランニングだけで数日使うこともザラにある
      • (ebacky 先生曰く、最初は全部のチケットが同一ポイントになるよう分解すると、わかりやすいとのこと)
    • Sprint Review
      • スプリントの振り返りを行う
      • できた。できなかった、ベロシティの計測は基本。
      • スプリントプランニングで見積もったポイント数と、実際にやってみたポイント数の大きさの誤差を必ず記録する
        • ↑をやらないとどれだけスプリントを回しても見積もり精度が向上しない
    • Sprint Retrospective
      • チームの「振る舞い」に対する振り返りを行う。
      • 多分、全セレモニーの中で、最も難しく、最もスクラムマスターの腕が問われるイベント。
      • KPT は、チームの振る舞いを評価するフレームワークなので、できたできなかったの評価は違う(それはYWTなどのほうが向いている)。
    • Daily Scrum
      • 毎日やる
      • スプリントプランニングで決定した「やること」「ゴール」に対して、今どのあたりにいるかを全員で共有し、再計画する
      • DS は ただの日報共有になりがちだが、目的は「スプリントの再計画」なので、積極的に課題を共有したりしないと意味がない。
      • ここもガチでやるとかなり難しい。
  • Artifact
    • Artifact とは、製作物・遺作物 とでも翻訳される。下手に日本語にしたほうが難しいのでアーティファクトという概念で覚えたほうが良い
    • スクラムプロジェクトの過程で必ず生まれる物
    • Product Backlog
      • まず、「プロダクトバックログ」と「スプリントバックログ」は似て非なる別物である。ということから始まる。
      • プロダクトバックログには、価値の源泉となる「プロダクトバックログアイテム」が記載される。
      • プロダクトバックログアイテムの書き方の手法の一つして、「ストーリー」がある。プロダクトがユーザーや顧客に提供する価値を記述する。
      • 「ストーリー」という概念で表されることが多く、提供する価値の高い物 = ストーリーポイントの高いもの となる。
    • Sprint Backlog
      • 一方、スプリントバックログは、チームのタスクリスト。具体的な実装など、当面の作業計画を示すもの。
      • ここで列挙される「Aを実装する」などということは「タスク」という概念で表される。
      • タスクはストーリーではないので、ストーリーポイントは付かない。 あえて付けるなら0
      • タスクは、ストーリーと違い、完了の定義が明確に存在する。 = 誰が見ても「これはdone にしてOKだね」といえる状態でないといけない。
    • Increment List
      • リリース判断可能な単位のことを「インクリメント」と呼ぶ。
      • 複数のタスクの集合。「これらのタスクが全部done なら この機能に関してはリリースしてOKだね」と呼べる単位。
      • 実際には、複数のインクリメントの集合をどかんと一つのリリースとして出すことがあるが、「切り分けられるか」という意味で
    • Done / Undone
      • チームの視点を持ってして(つまりタスクとして) 完了しているかどうかの定義。
      • 「実装したけどセキュリティリスクがある」とかは「Done」ではない。
      • Done の定義をチーム全員で共有していることが大事
    • Acceptance
      • プロダクトオーナーの視点をもってして、「プロダクトバックログアイテム」が成立しているかの判断基準。
      • Done を満たすこと、Acceptance を満たすこと。両方を持ってはじめて価値として提供することが出来る。
    • Rapidly Shippable Product
      • Increment List が「タスクの集合」であるのに対し、こちらは、「プロダクトバックログアイテム」として成立しているかどうか。
      • より早く価値を提供するには、ストーリーを完成させる必要がある。インクリメントとストーリーが近いほど、高速な出荷(リリース)が可能になる。
  • Time
    • Sprint
      • 区切られた期間。別に一週間でも一ヶ月でも良い。チームの傾向に合わせて。
      • ebacky 先生的には、スクラムに慣れていないチームはスクラムの流儀に慣れるという目的で1週間をおすすめしているらしい
    • Sprint Stop
      • 開発終了のこと

ごちゃあっと書いたけど、これらをすべて満たしていないとスクラムではない。 例えば、スプリントリファインメントを行わないスクラムチームはスクラムではないし、PO, SM のいずれかが不在でもスクラムではないし、チームの人数が多すぎても少なすぎてもスクラムではない。

余談だが、 ebacky 先生は新たなルールとして「Working Agreement」を提唱している。

スクラムマスターの役割と、求められるスキル

スクラムマスターは、スクラムの専門知識をもってスクラムを回すのをサポートするが、スクラムを成立させることが最大目的ではない。

中央集権的組織の最大目的は、統治すること。つまり、関心が「人をどうするか」にある。 = Controll 一方、チーム中心主義の最大目的は、結果を手に入れること。つまり、関心が「事をどうするか」にある = Manage

Manage は、管理するとか訳されるけど、ニュアンスとしては、「(方法を問わず)いい感じにする」が近い。

スクラムマスターに求められる役割は、「価値を提供するための手段をスクラムチームに提案する」こと。 色々な選択肢の中から、より成功確率(よりユーザーに価値を届けられるかどうか)の確度が高い手段・方法をPO・チーム・その他の関係者に提案することがスクラムマスターの介在価値になる。

必要なスキルとして以下の4つを定義している

  • Facilitation(to be が明確なとき、to beまで導くことが目的)
  • Teaching(to beが明確なとき、as is から一歩踏み出させることが目的)
  • Mentoring(to be が明確ではないとき、 よりto be に近い方向に軌道を修正することが目的)
  • Coaching(to be が明確ではあるが、よりよい to be を提案することが目的)

これらは似たように聞こえるし実際似たようなことをやることもあるが、それぞれ目的が異なる。

更に、これらに加えて、Situationing(2つの事実の因果関係を見出す能力)が求められる。

体験編

講義中にワークショップとして、「1日目の講義を振り返ってスクラムマスターとして改善点を述べよ」や「←のアイデアを1位〜30位に順列をつけろ」などのワークショップがある。スクラムの知識が必要というよりは、論理的思考が求められる。

徹底した論理的思考、あるいは議論が求められる。「とりあえず締切が決まってるから締め切りまでになんんとか適当なアイデアを出そう」は決して許されない。それはスクラムの原理に思いっきり反しているから。しかし、それがわかっていたとしても、実際に実行するのは非常に難しい。

参加した感想とか

実際に参加した感想としては、思ったよりSIer 企業からの参加が多かった(ウェブ系ばっかりだと思ってた)。参加者のレベルによってクラスのレベルも変わるらしい。「これからスクラムをやるぞ」というよりは、「スクラムやってるけど理解が足りない」という人のほうが向いていると思う。ただ、これは講師の特性もあると思っていて、ebacky さんじゃないクラスのほうは、「はじめてスクラムやるぞ」という人向けなのかもしれない。

内容としては、自分が全然理解していなかったことが多かったので、その穴埋めが出来て非常に良かったと思う。一方、自分が所属するチームの開発手法はスクラムとはかなり乖離しており、自分が所属するチームをスクラムに持っていくのか持っていかないのかの議論から出発しないと行けない。「スクラムとしてやっていくぞ」という方向になれば、SMとしてスクラムの知識を回していきたい所存

人間同士の通信プロトコルを見直し、ユビキタス言語で会話しよう

【Mentor Ver.】TechTrain Advent Calendar 2019 18日目の記事として書いています。

はじめまして。 @bussorenre と申します。主に業務では Scalaを利用してサーバーサイドアプリケーションを書いたり、時々terraform スクリプトを書いたりしてAWSでインフラを整えたりしています。

TechTrain の説明を少しだけさせていただくと、なんと、「無料でエンジニアになんでも相談出来る」というすごいサービスです。 メンターの方々も、メルカリやLINE 等、第一線で活躍されているエンジニアさんばっかり。

相談出来る内容も

  • 具体的な実装の相談(ReactであれこれしたいがAという問題に詰まって悩んでる)
  • キャリアの相談(副業とかどうしてるのか、就職先をどうやって決めたか)
  • 起業相談(←代表の小澤さんが趣味でやってるだけ?笑)

などなど、幅広く、むしろ私が相談にのってほしい。(ダメ?笑)

はじめに - コミュニケーションロスと向き合う

業務としてプログラムを書き始めるようになると、それまで趣味でやってた時に比べて明らかに圧倒的に「他者とのコミュニケーション量」が増えます。「この実装いつまでに終わりそうですか?」といった簡単なほうれん草から、「この仕様を実現するために、どういう設計にしようか」といった複雑な議論まで、一人で仕事が簡潔しません。

チームに人数が増えれば増えるほど、物事を伝えるということに工数が増えていき、実作業に取られる時間が減っていくなんてことが起こりがちです。

人間同士の通信プロトコルを定義しよう

人間同士で「今質問していいですか?」「いいですよ」「ありがとうございます。Aということについてなんですが…」 と会話を始めるように、TCP コネクションを張るときは 「SYN」「SYN ACK」「ACK」パケットを送信しあって、通信を始めます。

我々が普段仕事で当たり前のように使っているインターネットがこんなに広く普及してるのは、早期に「通信規約(=プロトコル)」が標準化されたからです。

インターネットの通信方法がRFCで標準化されているように、人間と人間の間にも通信のプロトコルを明示的に示すと非常に便利です。 特に、「常識」と言われていることほど、「お互いにとって常識かどうか」を確認しあうと便利でしょう。

例えば、リモートワークなどをするときは、

  • 始業時に「リモートワークを開始します」とSlackで宣言する。
  • 昼食などで離席するときは「離席しています」とSlackで宣言する。
  • 就業するときは「リモートワークを終了します」とSlackで宣言する。

というプロトコルを共有しておくと、今誰が仕事をしているのか、今誰に話しかけても問題ないのかなどがわかって便利です。

大事なのは、プロトコルのルールの中身よりも

  • 「ルールをみんなで共有している状態」
  • 「ルールの是非をみんなが納得している状態」
  • 「柔軟にルールを変更できること」

が大事です。これらができていないと、せっかくプロトコルを規定しても、それに従わないメンバーが一定数出てきてしまい形骸化してしまうからです。 形骸化したルールを早く修正しないと、プロトコルは腐ってしまいます。

ユビキタス言語を定義して、言葉の齟齬を減らそう

例えば「アイテム」という言葉を使う時、そのアイテムって一体何なんでしょうか?

  • ゲームでプレイヤーが入手できる道具?
  • 課金して購入できる商品のこと…?
  • テーブルビューの一つの要素…?

英語的にはおそらくどれも正しいですが、チームメンバーが「アイテム」という時の意味は一体なんなんでしょうか?

ユビキタス言語はドメイン駆動設計において非常に重要な概念の一つで、チーム内で共有する固有の言語です。 今から作ろうとしているシステムの仕様や動作を伝えたりする時に使用します。

何が、何と関連しているのか。何が何を操作するのか。ソフトウェアが解決すべき問題(=ドメインモデル)を定義する時に使います。

日々の人間同士のコミュニケーションでも、今話している話が「ゲーム内のアイテム」なのか「商品」のことなのか等、共通の認識があると スムーズに議論が進むことができます。

私の本業のチームでは「○○チーム用語集」という共同編集可能なmarkdown で書かれたページが有り、そこにドメイン用語を記載しています。特に、「新しいチームメンバー」が入ったときほどユビキタス言語を見直す良い機会です。

「AdminUser と OrganizationAdminUser と CustomerAdminUser の違いってなんですか?」とか「NormalPermissionとGeneralPermission って意味かぶってませんか?」等、普段使ってて感覚が麻痺している古株のチームメンバーのいい刺激になります。

先程の、コミュニケーションプロトコルの話と同じですが、チームメンバーみんなが共通認識を持っており、理想状態に近づけるために柔軟に変更できる状態が最も望ましいです。

ドメインモデルでプログラムを表現できるようにしよう

ユビキタス言語と、アプリケーションの中での表現が一致していれば、これ以上便利なことは有りません。

これは、人間同士のコミュニケーションロスを減らすだけでなく、人間←→プログラムという変換ログを少なくすることもできます。

ドメインモデルだけでビジネスロジックを表現できるようなアーキテクチャを採用すると、技術的関心事に左右されることなく、 「このソフトウェアが実現しようとしている事はなにか」ということにのみ注力することができます。

具体的には「レイヤードアーキテクチャ」「クリーンアーキテクチャ」などと呼ばれる構造を取り入れたりすることで解決に向かうことができます。

この辺を語りだすと adventcalendar 毎日書いても終わらないので、参考になったリンクを張っておきます(下部に参考書籍も載せておきます)

buildersbox.corp-sansan.com

まとめ

業務エンジニアに必要なスキルでかつアマチュアエンジニアではそこまで必要ないスキルの特徴として、コミュニケーションという課題があるなと思い、 こんな感じで記事を書きましたが、中途半端なDDDの紹介に行ってしまった中途半端な記事になってしましました…。猛省。

まぁ、実際通信を実装するのも、アプリケーション内での通信の定義がほとんどだったりしますし、自分がコミュニケーションで使ってる「プロトコル」を見直すと 良いのかなと思いました。以上です。

以下に、参考書籍のリンクを張っておくので、ぜひよかったらどうぞ。