「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」をよみました
「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」を読みました。
## モブプロにプラクティスはあるのか？
本書を読む前、モブプロについては「エンジニアが会議室に集まって、1つのモニターを見ながらワイワイコーディングをする」くらいのイメージしかありませんでした。ひょんなことからモブプロを始めることになり、インターネットで情報収集を進めるうちに本書にたどり着きました。アジャイルと一緒で、まずはベスプラを学ぶことが大事だと考え、読んでみました。モブプロ実践にあたり役に立ちそうなポイントを並べてみたいと思います。
## モビングセッションのタイムテーブル
1回のモビングセッションは約2時間です。初回のモビングセッションではモビングの意義や役割分担の説明時間が取られますが、ここでは割愛します。
モビングインターバル（1時間30分）
1回のインターバルは10分です。各インターバルが終わるごとに、キーボード前に座る人「タイピスト」と周りの共同作業者「その他のモブ」が入れ替わります（1つのインターバルがかなり短い印象ですね）。タイピストはプログラマーではなく、その名の通り、周囲のモブの発言を実装するスマートアシスタントに例えられます。タイピストが自分で考えて実装していき、その他のモブがタイピストの実装の様子を眺めるわけではないことに注意してください。
モブレトロスペクティブ（20分）
モビングセッションで実施された内容についてふりかえり、将来のセッションをどう改良できるかについて話し合います。スクラムフレームワークで実施されるスプリントレトロスペクティブはモビングセッションに閉じないチーム全体のふりかえりであるのに対して、モブレトロスペクティブはあくまでモビングセッションについてのふりかえりです。本書ではモビングに慣れてきて、モブレトロスペクティブをオーバーヘッドに感じ始めたらモブレトロスペクティブは廃止してもよいとしています。
## デイリースクラムを廃止すべきか？
本書では、毎日1日中チーム全員がモビングに参加している状況であれば廃止を検討してもよいとしていますが、基本的にはデイリースクラムの廃止は推奨されていません。一方で、モビングによってチームの共通認識が増えるため、デイリースクラムでの問いを以下の2つに絞ることがすすめられています。
- 今日済ませなければならない最も大切なことは何か？
- そのためにどうするか？
スクラムフレームワークで定められたチームとのコミュニケーションの機会は基本的に削減しないというのが本書の基本的なスタンスであると考えられます。もちろん時間経過にともなって、イベントを簡略化していくことは問題ありません。
## バットマン = スクラムマスター
チームメンバーがモビングに集中するために、外部からの妨害を防ぐための役割としてバットマン（アメコミヒーローではなく、将校の雑用係の兵隊を示す軍隊用語）を置くことを推奨しています。このバットマンがチームの連絡係となり、モビング中のチームへの連絡などはすべてバットマンに集約されます。スクラムを実践しているチームであれば、スクラムマスターがこの役割を担うのがスムーズでしょう。
## エキスパートがいるモビング
チームの中に一人だけエキスパートがいる場合、エキスパートがタイピストを担うことで、他のチームメンバーを置き去りにしてコーディングを進めてしまい、結果としてモビングが形骸化する危険があります。このような場合、エキスパートには意図的にタイピストの役割を回さず、初心者の中でタイピストの役割を回すことが望ましいとされています。また、モブとなったエキスパートは、タイピストの作業を一人で細かく指示しすぎないように注意する必要もあります。
## さいごに
今回は特にモビングの進め方を中心に解説しましたが、本書ではモビングを実施する際の考え方も含めて、シチュエーション毎に解説されています。チームでモビングを始める際の指南書として手元に置いておきたい1冊です。
アジャイルに関する書籍をまとめました
今年のゴールデンウィークはアジャイルをテーマにしていくつかの本を読みましたので、まとめてみたいと思います。
## それぞれの書籍の関係性
いきなりですが、まとめ図です。大きく2つのブロックから構成されます。上部は開発で何を作るべきかをどう定めていくのか（=プロダクトバックログをどうつくるか？）を学べるブロック、下部はスクラムをはじめとするアジャイル開発方法論（=アプリをどうつくるか？）を学べるブロックであり、アジャイルチームの規模に応じてさらに2つのブロックに分かれています。
## どうつくるか？
小規模なチーム
単一チームでどのようにスクラム開発を実践していくかを学ぶためには「SCRUM BOOT CAMP THE BOOK」がおすすめです。スクラムマスターを引き受けることになった"ボクくん"を中心として、初めてチームがスクラム開発を進めるストーリーになっており、スクラム開発ってなに？おいしいの？状態の人が初めて手に取る本としてぴったりです。
大規模なチーム
10人以下の単独チームで実現できるシステムは小さいものとなるため、大きなシステムをつくるためにはチームをスケールさせなければなりません。そこで参考になるのが、「ユニコーン企業のひみつ」です。4月末に発売された本書は非常に話題になりました。いわゆる"Spotifyモデル"を解説したものです。Spotifyではスクラムチームをどのようにスケールさせていったのかが描かれており、単なるチーム構成を解説するだけでなく、チームを信頼した上でどう権限を委譲し、自律的なチームをつくるのか？など、SpotifyやGoogleをはじめとする"テック企業"がどのように組織をつくっているのかを垣間見ることができます。ただし、これは執筆時点でのSpotifyにおける組織モデルを解説しているものにすぎず、現在もカイゼンされ続けていることに注意してください。（すなわち、組織をカイゼンし続ける文化にテック企業の本質があり、このモデルを模倣したからといって、エンタープライズ企業がテック企業に変身できるわけではないということです。）
## 何をつくるか？
スクラム開発を解説した本はそのほとんどが、どのような目的で、どのようなアプリケーションを作るかについてはすでに定まった前提で描かれています。しかし実際には、顧客の体験をどう変化させるかという、新たなユーザーストーリーを描く作業は非常に難しく、ステークホルダーが納得できるプロダクトバックログができた段階で、スクラム開発は7割終わった状態だと言ってしまっても過言ではありません。また、スクラム開発は適宜優先度の高いプロダクトバックログアイテム（=ユーザーストーリー）が差し込まれるため、開発されるアプリケーションの全体像を見通すことが難しいという難点もあります。まさにスクラムによるアプリケーション開発の要ともいえる、ユーザーストーリーの描き方を解説した本が、この「ユーザーストーリーマッピング」です。ドキュメントを使った"伝言ゲーム"を脱却し、ユーザーストーリーを軸として、ステークホルダー全員で"良質な会話"を行うことで、よりよいユーザーストーリーを創り出せると述べています。
## SAFe®︎との関係
大規模アジャイルフレームワークの中で最も普及率の高いSAFe®︎との関係性についても簡単に述べておきたいと思います。SAFe®︎は非常に汎用性の高いフレームワークであり、複数のスクラムチームを束ねてART(Agile Release Train)を構成し、PI Planningと呼ばれるイベントでARTを同期させながら、開発を進めていきます。このARTは「ユニコーン企業のひみつ」で紹介されているSpotifyモデルのトライブに相当します。また、SAFe®︎ではARTを組織する前に、Operational Value Streamを描くことで顧客のジャーニーマップを明確化しますが、これはまさに「ユーザーストーリーマッピング」におけるユーザーストーリーそのものです。このように、これらの書籍はそれぞれが、SAFe®︎の構成要素を深掘りしたものとしてとらえることもできるのです。SAFe®︎を学んでみたい（学んでいる）方が、それぞれの要素をより深く理解するために、これらの書籍を読んでみるのも良いかもしれません。
## さいごに
いかがでしたでしょうか？今回はいままで紹介してきた書籍の関係性を、SAFe®︎も交えながら解説してみました。それぞれの書籍の関係性を意識しながら読むことで、みなさまにも新たな発見があれば幸いです。
「ユーザーストーリーマッピング」をよみました
Jeff Pattonによる「ユーザーストーリーマッピング」を読みました。
## ストーリーを使う目的は、良いストーリーを書くことではない
ストーリーは、ステークホルダー間で良い会話を行うための材料にすぎないということです。本著ではユーザーストーリーマッピングのフレームワークが丁寧に記載されていますが、フレームワークそのものよりも、そのフレームワークからもたらされる良質な会話からステークホルダーの共通理解を得ることが非常に重要なのであると、Jeffは繰り返し述べています。「テンプレートにしたがって書かれたものでなくても、ストーリーはストーリーだ。」
## 製品開発の目標は、製品を作ることではない
アウトプットを最小限に抑えた上で、出来る限り早く、良きフィードバックを受けることで製品を小さなループで改善していくということです。場合によっては、ソフトウェアを作る必要すらなく、デザインコミック（アイデアを使って実際の問題を解決するシーンを漫画で描いたもの）やペーパープロトタイプを使うことで、アイデア〜アウトプットまでの時間を最短で数時間にまで短縮できます。そうすることで、ユーザーから素早くフィードバックを受け取ることができます。仮にユーザーから良い評価を得られないとしても、無駄になるのは数時間だけです。もし勝手な思い込みで、重厚長大なソフトウェアを作り始めていたとしたら、ゾッとしますね。。
## 「会話」で岩を砕いていく
大きなストーリー（＝オポチュニティ）からスタートし、会話によって徐々にストーリーを砕いていきます。
- ナラティブ・ジャーニーマップを使って会話し、オポチュニティを導く。
- オポチュニティキャンバスをつくり、会話でオポチュニティを絞る。
- ユーザーストーリーマッピングでMVSをプロトタイプし、ユーザーからフィードバックをもらう。
- フィードバックをふまえ、徐々にソフトウェアを膨らませていく。
ユーザーストーリーマッピングの実施方法については、以下のサイトも参考になります。
## さいごに
本著にはたくさん写真が掲載されていて、皆がいきいきとストーリーについて会話している様子が伝わってきます。ただただ、楽しそう。一方的に押しつけられる「要件」ではなく、双方向的な「会話」によってユーザーにとって本当に価値のあるものを、すばやく作っていく開発の現場を私はあまり知りません。GW明けに自分のチームでも実践してみたいと思います。
マンションを売却し確定申告しました
2020年にマンションを売却し、翌2021年に確定申告を実施しました。インターネットで検索するとさまざまな不動産業者のブログ記事がヒットしますが、情報が不足していたり、必要な情報が抜けていたりと、情報収集に苦労しましたので、私自身の実体験をもとにまとめてみたいと思います。マンション売却時の確定申告に苦労している人の助けになれば幸いです。※2020年分確定申告時の情報です。
## 注意事項
私は専門家ではありません。本記事は私が確定申告を実施した際に、個人的に収集した情報のまとめになりますので、内容を参考にする場合は自己責任でお願いいたします。最新情報は国税庁のサイトなどでご確認の上、お近くの税務署等にお問い合わせください。
## 前提条件
- 5年前に中古で購入したマンションを売却し、売却益発生。
- 2019年12月に売買契約を行い、物件引き渡しは2020年1月。
- 「確定申告書等作成コーナー」で作成し、郵送で提出。
- 3,000万円の特別控除を利用予定。
以上の条件で確定申告を実施しました。つまずいたポイントをもとにまとめていきます。
## いつ確定申告をすべきなの？
今回は売買契約と物件引き渡しが年をまたぎました。そのため、2019年分と2020年分どちらで確定申告を実施すべきか悩みました。
結論：原則は引き渡しを基準にして2020年分だが、2019年分で確定申告してもよい。
## どんな書類を提出しなければならないの？
提出書類が多いですが、サイトが多く、正確な情報がわかりにくいポイントです。一番よくまとまっているのは以下の三井のリハウスのサイトです。
私が特に迷ったのは以下の2つの書類です。それ以外の書類については、取得時・売却時の書類にすべて入っていると思いますので、探してください。
- 譲渡した土地・建物の全部事項証明書 → 登記所で取得（後述）
- 戸籍の附票などの居住していたことを証明する資料 → 必要なかった（後述）
(1) 譲渡した土地・建物の全部事項証明書
この書類は登記所で取得できます。土地と建物それぞれの全部事項証明書の計2通を取得する必要があるため、印紙代として計1,200円が必要です。全部事項証明書を取得する際は、売却対象マンションの「地番」が必要ですので、契約書で確認しておきましょう。また、分譲マンションの場合は部屋番号まで指定して申請し、マンションの全部屋分の全部事項証明書を取得しないようにしましょう（全戸分取得しても問題ないですが、必要はないです）。
(2) 戸籍の附票などの居住していたことを証明する資料
この書類は、多くの人で必要ないと思います。この書類が必要となる条件として、「契約日前日における住民票の住所と譲渡した資産の所在地が異なる場合」となっており、売買契約時の前日時点でまだ売却対象のマンションに住んでいた場合は必要ない書類ということなります。
## さあ、確定申告書を作っていきましょう
「確定申告書等作成コーナー」に向かい「作成開始」ボタンを押して進んでいきます。手順は別サイトでの解説に譲り、入力時に迷った2つのポイントに絞って解説します。
(1) 譲渡価額に入力する金額
「譲渡価額（＝不動産売却で得た収入の合計）」は売却したマンションの売却代金だけではないことに注意してください。マンション売却時に清算する「固定資産税の清算金」を含める必要があります（金額はマンションの売却代金に比べると小さいものですが忘れず含めてください）。その他の注意点は以下のサイトを参考にしてください。
(2) 中古マンションの土地建物割合
中古マンションは土地と建物まとめて価格が設定されているため、新築マンションのように消費税などから価格割合を算出することはできません。そのため毎年、都道府県から送付される固定資産税の納税通知書に同封されている「○○年度固定資産税・都市計画税課税明細書」から土地と建物の価格の比率を計算する必要があります。
## さいごに
中古マンション売却時の確定申告でつまずいたポイントを中心にまとめてみました。マンション売却は頻繁に発生するものではありませんが、もし売却した際のみなさまのお役に立てれば幸いです。
「Clean Agile」をよみました
アジャイルの生みの親のひとりであるボブ・マーチンの「Clean Agile」をよみました。
## アジャイルが死んだ時代
アジャイルに携わるものとしてドキッとする言葉です。本著の訳者は、"2010年代は生みの親たちの手を離れたアジャイルが、まさに「死んだ」時代だったのだ"と記しています。私はアジャイルが生まれた2000年代、まだソフトウェア開発に携わっておらず、まさにアジャイルが「死んだ」2010年代にアジャイルと出会いました。近年、デジタル化の名の下にアジャイルが注目を浴び、さまざまなお客さまからアジャイルの導入支援を依頼されるようになりました。そのような状況にあって、私自身も世間のアジャイルに対する認識のズレが気になる場面に多く遭遇するようになっていました。
## 「スクラムをやりたいです」
違和感を感じる言葉です。アジャイルを免許制のように捉えている人があまりにも多い。プラクティスの背後に存在している原則を忘れてしまい、手段が目的化してしまっています。本著にもこう記されています。"メソドロジーとプラクティスは補助輪のようなものだ。最初のうちは非常に役に立つ。（中略）メソドロジーやプラクティスにこだわりすぎると、チームや組織が本当の目的を見失ってしまう。本来の目的は自転車の乗り方を教えることであり、補助輪をつけることではない。"
## アジャイルがソフトウェアを高速に提供するプロセスに変わっている
目的を見失ったアジャイルはバズワード化し、いつの間にかソフトウェアを高速に提供するプロセスに変化してしまいました。あらかじめマネージャーがスコープと納期を定義し、スプリント期間で予定のストーリーポイントを消化できなければ、遅れを取り戻すために、次のスプリントで開発者が残業でキャッチアップするような"なんちゃってアジャイル開発"が蔓延してしまっています。特に日本企業では、このようなアジャイルの本質を理解しない開発プロジェクトが多発している印象があります。（このような状態を本著では「アジャイルの二日酔い」と呼び、警鐘を鳴らしています。）
## 基本に立ち戻ろう！
アジャイルが生まれて20年がたち、私たちの周りにはさまざまなアジャイルのフレームワークが存在し、たくさんの"認定"スクラムマスターがビジネスを支援しています。アジャイルが一大ビジネスになった今だからこそ、今一度アジャイルの基本に立ち戻り、何のために我々はアジャイルを導入しようとしているのか？と問い直すことが必要なのではないでしょうか？
## さいごに
本著は、2001年当時、アジャイルが生まれた歴史的背景が生き生きと描かれています。また、アジャイルそのものについてもシンプルかつ丁寧に描かれており、アジャイルが何のために生まれ、本来どう使われるべきなのかを知ることができるはずです。私も定期的に読み返すことで、原点を忘れないようにしていきたいと思います。
不確実性を楽しむITコンサルタント
近年、ITコンサルタントとして、お客さまのデジタル化を推進するプロジェクトが増えてきました。私は主にデータサイエンス・アジャイルの専門性を駆使して、お客さまのデジタル化を阻む課題を特定し、チームをリードしながら 課題を解決していきます。デジタル化プロジェクトは非常に不確実性が高いため、プロジェクトそのものをアジャイル開発と捉えて振る舞うとうまくいくことが多いです。
## デジタル化プロジェクトとは？
この定義については企業によってもさまざまですが、一般的にはAIやアジャイル開発手法、ブロックチェーンなどのテクノロジーや方法論を駆使して、お客さまのビジネス課題を解決していくプロジェクトを指すことが多いです。これらのデジタル化プロジェクトで私が最も重要であると思う特徴は、お客さま自身も自身の企業のビジネス課題を明確に捉え切れていないという点です。バズワード化したテクノロジーワードに惑わされ、本来解くべき課題は何なのか？その課題を解くために本当に必要なテクノロジーは何か？などが不明瞭なまま私たちに依頼がやってくることが少なくありません。
## ビジネスの現場を見にいく
まずは課題を解像度を上げることが最優先です。そのためにはビジネスの現場で何が起きているのか、徹底的に観察します。アプリケーション開発であれば、ミーティングに顔を出して、開発現場で何が起こっているのか自分の目で確認します。また、将来的に自身が提案する施策を実施するのはビジネスの現場ですので、この時点で関係者と顔見知りになっておくことは非常に重要です。
## まずは書き出してみる
プロジェクト開始時は課題がフワフワしています。しかし、ここでお客さまにゼロベースで確認を求めてはいけません。お客さまも不安なのです。まずはITコンサルタント側が課題を細分化し、その内容を書き出した上で、お客さまに確認をとるようにすべきです。不確実性の高い状況でも仮説ベースで具体的なアウトプットを見せることが、お客さまの不安解消につながります。また、ここでお客さまに正解を示さなければならないと必要以上に気負う必要はありません。まずは書き出してみることがなによりも大切だと思います。
## お客さまのサブリーダーを味方につける
ITコンサルタントとお客さまの対立構造を作り出さないことが大切です。具体的にはお客さまのサブリーダー層と短時間で定期的に会話する場を設定し、こまめに方向修正をしながら、徐々にプロジェクトの不確実性を排除していくことが重要です。こうすることで、お客さま側責任者との会話においても、サブリーダーはこちらのチームのサポーターになってくれるはずです。
## Webカメラオンでハキハキ話す
コロナの影響で、プロジェクトをオンラインベースで進めることが多くなってきました。このような状況下では対面ではあまり気にしていなかったポイントにも注意する必要があります。まずはWebカメラをオンにして、顔を見せることが大切です。会話においてもお客さまの質問には0.5秒以内にはっきりとした口調で回答しましょう。いずれもお客さまの不安感を増やさないための対策です。まれにお客さまに「〜でよろしいでしょうか？」といったような質問を行うコンサルタントがいますが、これはNGです。お客さま自身も正解を知らないのですから。。
## さいごに
本日お話しした内容はいずれも、"お客さまの不安感をいかに解消するか"という点につながります。プロジェクト開始時は、お客さまもコンサルタントも不確実性から来る不安感に包まれています。 この不安感を一歩ずつ解消し前に進んでいくことがプロジェクトを成功させる秘訣であると思います。不確実性を楽しみましょう！
庵野さんはアジャイルでエヴァをつくっていた
4/29にNHK BS1で放送された「さようなら全てのエヴァンゲリオン〜庵野秀明の1214日〜」をみました。
小学生の時に初めてエヴァンゲリオンを見たとき、まさか25年後も自分がエヴァンゲリオンを追いかけ続けているとは思っていませんでした。NHKで放送されたこのドキュメンタリーを見ていると、「これはまさにアジャイル開発ではないか！」と思えるようになってきました。本日は普段とは少し違った視点で、エヴァンゲリオンを見ていきたいと思います。
## シン・エヴァンゲリオン劇場版について
本題に入る前に、、
最新作である「シン・エヴァンゲリオン劇場版」についての感想を簡単に書いておきます（笑）。私自身、エヴァンゲリオンの解明できない謎に取りつかれ、小学生のころから様々な解説本を読みあさり、最近ではエヴァンゲリオンの謎に迫ろうとするさまざまなYouTube動画を見ていましたが、本作を見終わった時、それらの謎は実は本質的な問題ではなかったのではないかと思えるようになりました。劇場で配布されたパンフレットには、本作で出てきた"専門用語"が大量に記載されていましたが、それを見た時、実はこれらの言葉にはほとんど意味はないのだと庵野さんに諭されたような気がしたのです。また、ラストシーンを見終わった時、長い旅が終わった安堵感に包まれたのを覚えています。これは庵野さんの長い旅のゴールなのであり、一緒に旅をしてきた我々もまた、それぞれの"旅の終わり方"があって良いのだと感じました。ありがとうエヴァンゲリオン。
## 庵野監督の映画のつくりかた
前置きがすこし長くなってしまいました（笑）昨日のドキュメンタリーを見るにつけ、エヴァンゲリオン最新作を生み出す庵野さんの姿勢にアジャイルを感じずにはいられなくなっていきました。（このような視点でエヴァを見ること自体、私自身の時の流れを強く感じます。）
## 絵コンテをつくらない
庵野さんは今回、アニメーションの設計図である絵コンテをつくることなく、スタジオに組まれたセットを使い、自由にカメラアングルを探るという手法で、カットを作成していきました。試行錯誤の中でよりよい作品の可能性を探って行こうとする姿は、まさにアジャイル開発そのものです。さらに、作り上げたプリヴィズ（＝プロトタイプ）をスタジオスタッフに見てもらい、より観客に近い視点での意見をすくい上げていき、作品を修正していきます。これはアジャイルにおける"ふりかえり"そのものです。
## ギリギリまで現場のスタッフに任せる
もう1点印象的だったのが、庵野さんは制作に関わる多くの作業を現場のスタッフに任せているという点です。特にスタッフに何かを指示するわけでもなく、スタッフに何かを聞かれても「今はまだわからない」とだけ応える。。スタッフは困惑します。さらに庵野さんは、NHKのドキュメンタリースタッフに「スタッフが困惑している姿を撮影してほしい」と伝えます。一流のチームが悩みながら彼らのベストを尽くす姿にこそ、スタジオカラーの本質があると考えているようでした。実際に庵野さんはそれを、"肥大化した自己に対するアンチテーゼ"という言葉で表現していましたが、これはまさに自分のチームを信頼し、権限を与えることでより優れたものを生み出そうとするアジャイルの本質そのものでした。
## さいごに
もちろん庵野さんはアジャイルという言葉を知った上でこれらの行動とっているわけではないと思います。より良い作品（＝バリュー）を生み出すためにはどうすればよいかを突き詰めて考えた結果として、アジャイルの本質を捉えた行動をとっているのです。普段ITコンサルの現場にいる私としても非常に興味深く、学びの多いドキュメンタリーでありました。
