そこに仁義はあるのか(仮)

略してそこ仁!

Software Design 4月号にGitの入門記事を寄稿しました!

タイトルの通り、Software Design 4月号(3/18発売)に、Gitの入門向け記事を寄稿しました!
寄稿したのは第二特集の「本質から学ぶGit」の1章を担当しました。
第2章は、一緒に「いちばんやさしいGit&GitHubの教本 第2版 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)」を執筆したよこなさんが担当されています!

Software Designは若手の頃から読んでいた雑誌だったので、その雑誌に寄稿できるというのが嬉しくてたまりません。
このような貴重な機会をいただいて、ありがとうございました。

🖋 全体の流れ

執筆期間は全体で1ヶ月程度が確保されており、余裕を持って作業ができました。
(「いちばんやさしいGit&GitHubの教本」の第二版の修正・加筆時期と執筆期間が結構被っていたのですが、期間が長く助かりました…!)

連絡や執筆記事のやりとりは、メールとGoogle Driveを使って文書を共有する方法を選びました。
slackやTwitterのDMなどの連絡手段に対応しているとのこと、また、ドキュメントのやりとりも柔軟にご対応いただけるとのことでした。
Google Driveの機能を使ってフィードバックコメントをいただけたので、リアルタイムに対応ができましたし、対応状況の管理もしやすかったです。
初めての寄稿ということでこまめに確認依頼をしてしまいましたが、担当者の方はそれに合わせて丁寧に原稿をチェック・フィードバックしていただき、不安を解消しながら進められました。

見出し案の調整→草稿の作成→レイアウト調整→著者校正という大まかな流れで進めていきました。
どんどん記事ができていく、という体験はワクワクしてとてもよかったです。
最後の最後までここはこうした方がわかりやすいかも!というお願いをしましたが、それも快くご対応いただきました。

🎁 読者プレゼント企画にもご対応いただきました

技術評論社様とインプレス社様にご協力いただき、「いちばんやさしいGit&GitHubの教本」の第二版をSoftware Designの読者プレゼントとしてご提供いただくことができました!
Software Designで記事を読んでいただき、もっとGitの概念について丁寧に知りたい・他にもコマンドやGitHubの使い方を知りたいなどあれば、是非書籍も読んでいただけると嬉しいです。
応募方法はSoftware DesignのP16をご参照ください!

f:id:syobochim:20220322111908j:plain

🐥 喜びのツイート

めちゃくちゃよかった。また機会があれば寄稿させていただきたい。

初心者向け「いちばんやさしいGit&GitHubの教本」の第二版が出ました!

2018年に出版した「いちばんやさしいGit&GitHubの教本」ですが、昨日の2022/3/17に第二版を発売いたしました!

出版した当初から、概念が分かりやすいなど、SNSやレビューなどでご好評いただいており、晴れて第二版の出版となりました!
みなさま本当にありがとうございます!
タイトルに『いちばんやさしい』とあるとおり、初心者の方でもGitやGitHubを使えるようになることを意識して解説しています。
Gitは開発者の必須知識になりつつあるので、まだGitの使い方を知らない・なんとなく使っているけどよくわかってない、という方は是非読んでいただけると嬉しいです!

何が追加されたの?

出版してから新しく追加されたコマンドやオプションを追加しました!
また、GitHubについてもUIの変更に追随したり、新しい機能にも触れています。
初版でわかりにくかった共同作業の進め方についても、説明を追加してわかりやすくなっています。

書籍の内容については、第一版を出版したときのブログを引用して以下に記載します!

📖 本書の内容

本書の1番の特徴は、Gitの操作にコマンドラインを使っていることです。
コマンドラインを使うことで、ツールの操作ではなくGitの理解に集中できる+時代の移り変わりに左右されず、身につけた知識をずっと使っていけます
コマンドラインの操作は難しいように感じられるかもしれませんが、画面イメージをたくさん使いながら未経験者の方でもわかるように解説しています。

各レッスンの最初には、その操作にどういった意味や役割があるのかを解説しており、しっかりとバージョン管理の流れを理解しながら読み進められるかと思います。

f:id:syobochim:20181227183358p:plain

目次

  • Chapter 1 Gitの基本を学ぼう
  • Chapter 2 Gitを使う準備をしよう
  • Chapter 3 ファイルをバージョン管理してみよう
  • Chapter 4 GitHubのリポジトリをパソコンに取得しよう
  • Chapter 5 ブランチを使ってファイルを更新しよう
  • Chapter 6 複数ブランチを同時に使ってファイルを作業しよう
  • Chapter 7 コンフリクトに対処しよう
  • Chapter 8 GitHubをさらに使いこなそう

前半(Chapter1〜3)

バージョン管理に必要となる基本的なGitの操作方法を、順序立てて丁寧に解説しています。
Gitを使うとどんなメリットがあるのかから始まり、必要なツールのインストール方法やターミナルの開き方、基本的な操作コマンドなど初心者の方でもつまづかないような説明もありつつ、最終的にはGitでファイルをバージョン管理し、履歴を確認するところまで操作できるようになります。

後半(Chapter4〜8)

チーム開発を想定して、実践的なワークフローを試しながらGitHubを使っていきます。
チーム開発で絶対に必要となるプルリクエストの作り方、つまずきがちなブランチについての説明や、実際にチーム開発をしている時に一番困るであろうコンフリクトの解決など、必須となる知識を網羅する内容になっています。


皆さま、是非本書をご活用いただければ幸いです!

100日間かけてエヴァンス本を完読しました(PDF公開)

11/25から3/4の100日間かけてエリック・エヴァンスのドメイン駆動設計を完読しました!

ソフトウェア開発の複雑さに立ち向かうための方法に「ドメイン駆動設計」があります。
エリック・エヴァンスのドメイン駆動設計(以降、エヴァンス本)は発売から20年・日本語訳発売から10年経っても読まれていて、ドメイン駆動設計の原著であり、多くのエンジニアが名著という一冊です。
その分厚さや内容が難しそうというイメージからずっと積んだままになっていている人も多いのではないでしょうか。

私もそんな一人で、ドメイン駆動設計をなんとなく知った風に過ごしていましたが、ドメイン駆動設計に関する勉強会への参加をきっかけにエヴァンス本と向き合い、知ったこと・学んだことを毎日1ページにまとめてツイートする活動を始めました。
100日間中にお正月や誕生日もあったのですが、夫の実家にもエヴァンス本を持っていき、無事に完読することが出来ました!理解ある家族でありがたいです。

100日間のツイートはこちらのモーメントにまとめています!
twitter.com

🙌 やってよかった

ツイートして発信することで、「ここはこういう解釈をするんだよ」や「この本で知識がアップデートされているよ」など、たくさんの情報をいただきました。
ただインプットするだけではなく、アウトプットすることの価値を改めて感じました。

また、100日目の完読記念に、増田さん主催のコミュニティでイベントを開いていただき、学んだことをお話しさせていただくとても貴重な機会をいただきました。
祝完読! しょぼちむのエヴァンス本のススメ - connpass

そこで発表した資料がこちらです。
エヴァンス本を読んでみた正直な感想や面白かったところなどをまとめているので、書籍の感想などはこちらを見ていただけると嬉しいです!

📖 100日のノートをPDFとして公開します

100日のノートをPDFとして公開します。
手書き文字にも関わらず文字検索もできたので、ご活用いただけると嬉しいです!
(NotabilityというiPadアプリを使いました。すごい。)

表紙にも書きましたが、正しい知識を得るには原書を読んでいただくことをオススメします!
また、営利目的・商用目的での利用はおやめください。社内の勉強会で使っていただく分には問題ありません。
「使ったよ!」などのご報告をしょぼちむ ( twitter:@syobochim ) までいただけると喜びます。

ダウンロードはこちらから 👇
drive.google.com

2022/4/4 追記

この活動をきっかけに、会社のYouTubeチャンネルでも配信をすることになりました!
ゲストに増田さん・きょんさん・福井さんをお呼びして、座談会がメインでこの時のお話や、皆さんがドメイン駆動を学んだきっかけなどをお話ししています。
是非見てみてください!

youtu.be

【覚えておきたい】サービスの災害復旧パターン

大規模災害が起こった時の災害対策パターン、基本的なことだけど名前も含めて忘れがちになるので備忘のためにまとめておきます。

前提でわかっておきたいRTO / RPO

災害が起こった時の対策を考える前に、まず理解しておかなければいけないのがRTO(Recovery Time Objective / 目標復旧時間)とRPO(Recovery Point Objective / 目標復旧時点)です。
このRTOとRPOがどのくらい許容できるかが、災害復旧のためのアーキテクチャを選ぶための大前提の要件になります。
災害復旧のための構成を充実しようとすればするほどコストがかかってくるので、このRTO / RPOとコストのバランスを考えて構成のパターンを選択していきます。

RTO(Recovery Time Objective / 目標復旧時間)

RTOは障害が発生してからシステムがまた利用できるまでにかかる目標時間のことです。
この時間が長くなればシステムが使えない時間が長くなり、逆に短くなると災害が起こってもすぐにサービスが利用できるようになります。
災害が発生してしまったときに、特にライフラインに関わるシステムはこのRTOの時間を短くするような設計が必要です。
逆にゲームなど「災害が起こった時は止まっても仕方がないよね」といえるサービスについては長くてもそこまで問題にはなりません。

RPO(Recovery Point Objective / 目標復旧時点)

RPOは復旧作業が発生したときにどの時点の状況に戻すかの目標時点を示したものです。
この時点が大きくなると障害によって失うデータが大きくなり、逆に小さくなると失うデータは少なくなります。
例えば、RPOを1日とすると最大24時間のデータが消え、5分とすると最大5分のデータが消える可能性があります。
これはデータの重要度や、データを失ったときに取れるオペレーションなどを考慮して検討するといいと思います。
例えば、紙の帳簿をインプットする社内システムは紙があれば数日前のデータでも復旧できますが、ECサイトの決済系のデータは損失が許されません。

RTOとRPOのイメージはこちら。

f:id:syobochim:20210914233733p:plain

【本題】災害復旧のためのパターン

ここからが本題です。災害復旧のためのパターンを4つ書いていきます。

  • バックアップ&リストア
  • コールドスタンバイ / パイロットライト
  • ウォームスタンバイ
  • ホットスタンバイ / マルチサイト

バックアップ&リストア以外はRPOを高くすることができます。
また、下に行くほどコストはかかりますが、RTOを短くできます。
コストバランスと求められるRTO / RPOを考えてパターンを選んでいきましょう。システムの重要度が高くなるほど下のパターンを選ぶ必要が出てきます。

また、災害復旧という観点で考えると災害対策用のデータセンターの場所も重要です。
例えば東京のデータセンターが潰れてしまうほどの災害が発生したときにもシステムを止めたくない場合は、関西のデータセンターに災害対策用の環境を用意する必要があります。
さらには、関東・関西のデータセンターが潰れてしまうほどの災害が発生したときもシステムを止めたくない場合は、海外のデータセンターに災害対策用の環境を用意することを検討します。

では、それぞれのパターンについてもまとめていきます。

バックアップ&リストア

最初の構成パターンはバックアップ&リストアです。
RTOとRPOが他のパターンよりも大きくなってしまいますが、一番コストを抑えられるパターンです。
災害が発生したときにデータの損失がある程度許容され、サービス停止も長時間許される場合はこのパターンが適切です。

システムを運用していく上でデータはとても大切です。ある程度のデータ損失は許容されても、データを全て失ってしまうとサービスの継続ができなくなってしまうので、最低限バックアップをしておきましょう。
そして、災害復旧のときにはバックアップをリストアしてデータを復元し、システムを構築し直します。

f:id:syobochim:20210915001701p:plain

RTOとRPOについて

このパターンのRTOはバックアップしたデータをリストアして構成を作り直すので長くなります。
システムを1から構築する時間とバックアップをリストアする時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。

このパターンのRPOはバックアップの頻度とそれをコピーまたはレプリケーションする頻度に依存します。
日次でのバックアップをしている場合は、最大24時間のデータ損失が発生します。

コールドスタンバイ / パイロットライト

次の構成パターンはコールドスタンバイ / パイロットライトです。
バックアップ&リストアよりもRTOをRPOを小さくすることができ、ウォームスタンバイやホットスタンバイよりもコストも抑えられるのがこのパターンです。
災害が発生したときにデータは無くなってはいけないけれど、サービスの停止はある程度許される場合はこのパターンが適切です。

災害対策用のデータセンターにデータを同期させるスタンバイ用のデータベースを用意します。
データベースのスペックはコスト削減のために低いものにする場合があります。
コスト削減のために、データベース以外のアーキテクチャ(アプリケーション層など)は構築しません。
災害が発生したら、スタンバイ用のデータベースをマスターにして、残りのサービスの構築します。

f:id:syobochim:20210916003827p:plain

RTOとRPOについて

このパターンのRTOはデータベースの構築とデータのリストアが不要な分、バックアップ&リストアよりも短くなります。
データベース以外の領域を構築し、サービスを再開できる時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。

このパターンのRPOはデータを同期しているため短くなります。
最終のデータ同期タイミングまでのデータが災害対策用のデータセンターに残っているのでデータ損失が発生しにくくなります。
データを同期レプリケーションしているか非同期レプリケーションしているかでRTOが変わります。

ウォームスタンバイ

次のパターンはウォームスタンバイです。
RPOはコールドスタンバイと変わらず、RTOをより短くでき、コストをホットスタンバイよりも抑えられます。しかし、災害が発生したときにサービスのスペックが低くなるのがこのパターンです。
災害が発生したときにデータは無くなってはならず、サービス停止も数分から数時間までなら許容できる、またはサービスのスペックの縮退が許容できる場合はこのパターンが適切です。

コールドスタンバイの構成に加えて、データベース以外のレイヤーもサービスを構築します。
しかし、コスト削減のためにサービスが動く最低限の構成・スペックで構築しておきます。停止しておく場合もあります。
災害発生時は、サービス停止しておいた場合は起動し、リクエストの向き先を切り替えることでサービスが縮退された状態での素早い復旧ができます。
復旧後にスケールアップ・スケールアウトを追って実施することで、段階的にサービスのスペックを通常稼働と同じ状態に合わせられます。

f:id:syobochim:20210916004610p:plain

RTOとRPOについて

このパターンのRTOはシステムが構築できているためコールドスタンバイよりも短くなります。
サービスを構築後に停止している場合は起動とリクエストの切り替えにかかる時間を、停止していない場合はリクエストの切り替えにかかる時間を想定してRTOを計算します。
人の手が必要な作業もあると思いますが、構築が事前に済んでいる分、比較的自動化がしやすくなります。なるべくRTOを短くするために自動化を検討します。

このパターンのRPOはコールドスタンバイと同じです。

ホットスタンバイ / マルチサイト

最後のパターンはホットスタンバイ / マルチサイトです。
RPOはコールドスタンバイと変わらず、RPOを最小にできますが、コストが最もかかります。災害が発生したときにも即時に本番環境と同等のスペックを得られるのがこのパターンです。
災害が発生したときにもデータ損失をせずに、短時間で業務復旧する必要がある場合はこのパターンが適切です。

通常の構成と同じ構成を災害対策のためのデータセンターにも構築し、リクエストの切り替えをするだけでサービス継続できる状態にします。
サービスのスペックの縮退もありません。

f:id:syobochim:20210916011144p:plain

RTOとRPOについて

このパターンのRTOは最も短くなります。
災害用のデータセンターにリクエストを切り替えるためにかかる時間を想定してRTOを計算します。
リクエストの切り替えもなるべくRTOを短くするために自動化をしましょう。DNSの設定による切り替えができるので自動化もしやすくなります。

このパターンのRPOはコールドスタンバイと同じです。

パターンまとめ

備忘のため、災害復旧のための4つのパターンをまとめてみました。

f:id:syobochim:20210916011039p:plain

OSS X Users Meeting #31 ~オープンソースプロジェクトを支える言語たち~ に参加しました!

OSSをテーマにしたイベントの OSS X Users Meetingに参加してきたので、その参加レポートです!

oss-x-users-meeting.connpass.com

基調講演『改めて学ぶオープンソースの秘密』まつもと ゆきひろ氏 / 一般財団法人Rubyアソシエーション代表理事

プログラミング言語が誕生してからどういった経緯・歴史を経て現在利用されているプログラミング言語になっていったかというお話をされていました。
「今までコンピューターでできなかったことが出来るようになると、それが人工知能って呼ばれる」など、発表の中で面白い表現が使われていて楽しくお話を聴けました!

特に印象に残ったお話

ソフトウェアはもともと自由なものだったのが、商品化されて制限が厳しくなってきた、そんな中で再び自由を手に入れるためにフリーソフトウェアの考え方と、著作権を守るライセンスという考えが整理されていった。

オープンソースはソースコードはコードが公開されているだけでなく、自由なライセンスをつける必要がある。

オープンソースの定義という10項目がある。

  1. 再頒布の自由
  2. ソースコードがある
  3. 派生ソフトウェア
  4. 作者のソースコードの完全性(integrity)
  5. 個人やグループに対する差別の禁止
  6. 利用する分野(fields of endeavor)に対する差別の禁止
  7. ライセンスの分配(distribution)
  8. 特定製品でのみ有効なライセンスの禁止
  9. 他のソフトウェアを制限するライセンスの禁止
  10. ライセンスは技術中立的でなければならない

↑はメモが間に合わなかったので、こちらから引用しました。後で読む。
オープンソースの定義 (v1.9) 注釈付 – Open Source Group Japan – オープンソース・グループ・ジャパン

オープンソースの定義は素晴らしいが、開発者が生活出来るようにどうすればいいかをこれからは考えていかなければならないという課題がある。

オープンソースはここ20年で出てきた新しい世界で、オープンソースがないときに比べて遥かに良くなっている
オープンソースをこれから守っていきつつ、貢献していきましょう。

講演『オープン化が進むC++の現状と展望』高橋 晶氏 / cpprefjp(C++)コミュニティ コアメンバ

私はC++を触ったことがないので、こういうライブラリがあるんだ〜・こういう状況なんだ〜と初見のお話が多かったです。

質疑応答のところであったGitHubスポンサー、知りませんでした。
開発者を経済的に支援できる仕組み。
GitHub スポンサーについて - GitHub Docs

資料はこちら
speakerdeck.com

特に印象に残ったお話

C++はまだまだオープンソースになっていない部分もあるが、オープン化自体は進んでいる。
そして、オープン化することで議論も活発になり、言語の進化が大幅に加速している。

高速化することで大きなメリットはあるけれど、教育が追いつかなくなっている。
変わりやすい最新のライブラリの設計をどう共有していくのかというのも課題。
オープンソースだと情報共有なども含めてボランティアに頼っているので、インセンティブをどう持たせるか・それに合わせて責任をどう持ってもらうかを考えていくことが、長く開発を続けていただくために必要
GitHubスポンサーという仕組みがうまくいき始めているところもあるようで、それがもっと発展していけば良いかも。
GitHub スポンサーについて - GitHub Docs

C++の仕事が無くなったと良く聞くようになった。それは、C++が活躍する場が変化したことが原因。
C++はGUIやゲームなど、高速化のためのバックエンドとして利用するという需要が増えてきていて、領域に特化して言語が選ばれることは健全な流れ。
C#のバックエンドやPythonのバックエンドにもC++が利用されている。

特定の言語に固執せず、複数の言語を学んで適材適所でプログラミング言語を選んでいくのが良い

講演『Pythonの現在とこれからと』鈴木 たかのり氏 / 一般社団法人PyCon JP Association 副代表理事

Pythonの概要から、どんな歴史で開発されてきたのか、どう運営されているかなどのお話がありました。
後半では言語のアップデートやこれからのPythonの未来のお話など、勉強になりました!

資料はこちら
slides.takanory.net

特に印象に残ったお話

Pythonで便利なライブラリを見つけるときはこのサイトがオススメ:Awesome Python
Pythonの妥協のないコードフォーマッター:Black
他にも旬なプロジェクトがいくつか紹介されていました!

Pythonのコミュニティも豊富

Python3.10のアップデートでは「Better error messages」という更新も入り、初心者に優しくなった

これからの未来:Pythonの高速化が進んでいきそう
The “Shannon Plan” :4年で5倍の高速化(1年で1.5倍)
GitHub - markshannon/faster-cpython: How to make CPython faster.

講演『26 Java Years - これが今のJavaだ!』谷本 心氏 / 日本Javaユーザーグループ代表

Javaは古い?堅い?ダサい?→No!! という走りだしから始まって楽しいプレゼンでした。

特に印象に残ったお話

JavaはOSSと共に歩んできた言語。エンタープライズ系で使われることが多い言語でありながら、開発環境・ライブラリ・フレームワークなどにOSSプロダクトが盛んに使われていた
言語も現在はOSS化され、企業でも提供を開始している

IDEはIntelliJ IDEAが主流。
追加で調べてみたら、2020年でシェア72%らしいです。良い。→数字で見る 2020年における Java の現状 | The IntelliJ IDEA Blog

主流になったOSSのプロダクトがJavaの標準機能として取り込まれている。
そうやって企業・団体・エンジニアの貢献によって、JavaのOSSエコシステムは成熟していった。

しかし、その一方でJava界隈のOSSで起きた問題もいろいろあった。
Javaは Write Once, Run Anywhereというポリシーを守るため、JavaではないものをJavaと認めないという意思があった。(不要なJavaの分断を防ぐという意味では良い判断。)
JavaであるかどうかについてはTechnology Compatibility Kit (TCK) で互換性のチェックを通っているかで判断している。
以下については、そういった考えがある中で、Javaと認められないことよって起こった事件。

  • Apache harmony事件 → OpenJDKに合流
  • Android事件 / Google訴訟事件 → OpenJDKになってAndroidの開発に適応されたが、既にJavaではなくKotlinが主流に。

※現在はOpenJDKが唯一のOSS版Javaになっている。

今の主流は各社が提供するOpenJDKを利用することが主流。
各社によって少しずつ提供するツールは異なるが、コア機能については100%同じ。他の部分も99%は同じ。

Javaのように長い歴史と巨大なエコシステムを伴うものをOSS化していく上で相当な努力があった。

講演『エコシステムと WebAssembly』chikoski氏 / WebAssembly Night、Rust.Tokyo 主催

WebAssembly、聞いたことはあるけれど触ったことがなかったし概念もよく分かってなかったので、そもそもWebAssemblyってなに?ってところからお話いただいたのとてもありがたかったです。

特に印象に残ったお話

Rust.Tokyo 2021: 9/18 開催

WebAssemblyは C / Rust / Assembly Script などをコンパイルしてブラウザで高速に動かせるようにしたもの
ブラウザの上でJavaScriptではないプログラム(C++など)を動かしたいというニーズはずっとあった。
VimをWebAssemblyで動かしてブラウザ上で動かしているというツールも既にある。
他にも、Webアプリでは Acrobat / Squoosh / Zoom / Autocad、サーバレス環境では Envoy / Istio など、利用例は広がっている。

WebAssemplyが利用されるにつれてニーズが分類できるようになってきた。それがエコシステムとパフォーマンス
パフォーマンスについて、WebAssemblyはネイティブよりも1.2倍遅いと言われてはいるが、ブラウザで処理することでAPIでアクセスすることもなくなり、そのレイテンシがいらなくなるなど、純粋に比較することは難しい。
パフォーマンスはJavaScriptよりも安定していると言われている。常に同じようなパフォーマンスで動いてほしいというニーズに合っている。

現在はパフォーマンスよりもエコシステムについての期待が高い
既にある資産をJavaScriptに書き直すのではなく、WebAssemblyを使うと少ないコストでブラウザ上で動かせるというメリットが大きい。
手に馴染んだ言語が使え、開発者体験をの向上が期待できる。(学習コストや既存資産の活用など)

WebAssemblyの利用事例:Shopify
Getting started

言語を選定する上で、Performance x Flexibility x Security を考える必要がある。WebAssemblyは以下の通りニーズを満たせる。

  • Performance
    • サーバー内の実行
    • ネイティブコードの事前生成
    • 精製したコードのキャッシュ
  • Flexibility
    • プログラムなのでユースケースが広い
    • いろんな言語で実装可能
  • セキュリティ
    • メモリ保護
    • 安全な実行コードの生成
    • アイソレーション

WebAssemblyはコンパイル・デコンパイルができるので、コンパイル後のもののコードが読めるというメリットもある。
Wasmファイルはコンパイルによって作られる関数定義のまとまり

WebAssemblyの辛いところ

  • Wasmにはバージョンがなく(1で固定されている)、仕様もさまざま。
  • データ表現に関する規定がない。
    • 言語ごとにライブラリを提供し、それを使ってデータ表現を統一しながらコンパイルをしていく必要がある。

全体を通して

全体を通して、OSS化によって言語の発展が活発になっているというポジティブさを感じました。
その一方で、ボランティアで成り立っている以上、開発者の生活をどう支えていくかについて課題を感じているという意見も複数あり、OSSの難しさもあるなぁと思いました。
セッション途中で紹介されたGitHubスポンサーがとても良い仕組みですね。

楽しかった〜!

モブプログラミングのやり方がぎゅっと詰まった「モブプログラミング・ベストプラクティス」を読んだ

「モブプログラミング・ベストプラクティス」を読みました。

"モブプログラミング"とは、3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくことです。
モブプロをチームで実践したことがないまま、「みんなが集まって一つのコードを修正するって非効率じゃない?」寄りの考え方だったんですが、この本ではそんな考え方に対する回答も書いてくれていて、納得しつつ読み進められました!

モブプロというテーマだけで一冊の本になっちゃうほど色々とプラクティスが詰まっていましたが、どれも丁寧に解説されていてわかりやすい+モブプロを始めるイメージがつきやすい本でした。
サラッと読めるし、手元に置いておきたい。

📖 目次

  • 1章 なぜモブプログラミングなのか
  • 2章 モビングの始め方
  • 3章 モビングと人
  • 4章 モビングの軌道修正
  • 5章 定期的なモビングのための仕事場の改造
  • 6章 モビングを定着させるためのチームへの働きかけ
  • 7章 フロー重視の考え方
  • 8章 モビング定着後の長期的な展望

リソース効率とフロー効率

冒頭で書いた「みんなが集まって一つのコードを修正するって非効率じゃない?」という考え方をしている人は7章「フロー重視の考え方」がオススメです。
リソース効率とフロー効率という言葉は先日取得した認定スクラムマスターのトレーニングでもサービスの改善(ビジネスの俊敏性)を上げていくために重要な考え方として解説がありました。

書籍ではリソース効率・フロー効率のそれぞれについて次のように解説されています。

リソース効率

リソースを最大限使おうとする考え方。
例えばフロントエンドの仕事があるたびに、それを早くこなせる人に仕事を振る。
リソース効率を重視するとスペシャリストとボトルネックが作られていく。(スペシャリストの作業待ち、キャパオーバーなど)
新機能の開発コストを下げる

フロー効率

機能全体を早く市場に送り出すことを重視する考え方。
チームは一丸となって新機能に取り組む。
フロー効率を重視するとゼネラリスト(広範囲で知識・技術がある人)が作られ、機能を早く市場に送り出すことに力を入れられるようになる。
新機能を早く市場に送り出して利益を得る

リソース効率・フロー効率についてはこのスライドもわかりやすく解説されていて参考になります。

www.slideshare.net

モブプログラミングはフロー効率をあげるためにコストパフォーマンスの良い方法です。

モブプログラミングの成功をどのようにして計測するか

新しい取り組みを進めていくときにはちゃんと効果を出せているのか不安になると思います。
そこで最初に期待値を設定しておくことが重要と「1.3.2 成功をどのようにして計測するか」に書かれていました。
モブプログラミングが解決する問題は複雑なので計測が難しく、チームが直面する課題によっても変わるという前提で、計測方法として検討する価値があるものとして以下が挙げられています。
上2つは定量的で計測可能なもの、下2つは定性的でメンバーにヒアリングしていくものです。

  • マージコンフリクトの解決にかかる時間の短縮
  • 本番システムに入り込む欠陥の数の減少
  • チーム内の経験の浅いメンバーの学習度の上昇
  • チームがモブプログラミングの導入を改善と感じているかどうか

モブプログラミングのタイムテーブル

効果的にモブプログラミングをしていくためには「準備としてのお膳立て」や「モブプログラミングの振り返り」というのもタイムテーブルに組み込んで、モブプログラミングをやる意義の理解や改善をしていくことが大切です。
(モブプログラミングって、人が集まって急に始めていくものかと思っていました…。)
「2.3 お膳立て」のコラムに書かれているモブプログラミングのタイムテーブルがこちらです。

  • 準備:お膳立て(30分前後)
    • モブという形でひとつの仕事に取り組むことの意義を説明する(10分)
    • モビングでの役割分担を説明する(8分)
    • モブが解決する問題の概要を説明する(10分)
    • タイピストの順番を決める(2分)
  • 本体:モビングインターバル(1時間30分前後)
    • 最初のタイピストにキーボードを渡す
    • タイマーを10分にセットして開始する
    • モブ全員が協力して問題の解決のために努力する
    • 10分経過したら、タイピストは作業を中止して次の人に交代する
    • セッション終了の20分前まで、タイマーをセットし直して、インターバルを繰り返す
  • 締めくくり:経験からの学習(20分前後)
    • それまでのセッションを振り返り、うまくいったこと、うまくいかなかったことを挙げ、次回の改善方法を議論する

英語のスライドですが、冒頭のモブプロの説明を補うために使えるオンラインスライドも提供されています。
モブプロの進め方の動画も差し込まれているので、使いやすそうなスライドだと思います。
Introduction to Mob Programming

💬 まとめ

他にもモブプロを進めていく上でのチームとしての課題に対するアプローチや、モブプロを取り組みやすくするためのアプローチ(席やホワイトボード・ディスプレイの配置なども含めて)など、幅広くしっかりと解説されていました。
モブプロを始めたくなる一冊ですし、始めた時に手元に置いておきたくなる本だと思いました!

チームビルディングのためにお互いの性格を知る『ビッグファイブ性格特徴モデル』

チームビルディングでは、チームでより大きな力を発揮するためにメンバー同士がお互いのことを理解することが大切です。

それぞれの個性をあらわし、理解する時に時に役立つのが、「ビッグファイブ性格特徴モデル」です。
これは科学的・心理学的に信憑性があり、世界のさまざまな文化の違いを超えて信頼できることが証明されている分析方法で、性格は次の5つの要素の組み合わせによって決定されるという考え方です。

  • 外向性(外向 ←→ 内向)
    • 社交的・話好きで活発な振る舞いをする
  • 協調性(協調 ←→ 排他)
    • 他人に対して思いやりがあり協力的
  • 勤勉性(勤勉 ←→ 怠惰)
    • 自己コントロールをして忠実に行動する・達成を目指す・計画的
  • 情動性(論理 ←→ 情動)
    • 心理的ストレスを受けやすい
  • 創造性(創造 ←→ 保守)
    • 珍しいアイデア・好奇心・目新しさや多様性を好む

この性格診断は、それぞれの要素があるかないかの◯か×かで判断するのではありません。
要素に対してどの程度か を判断していきます。
また、この診断は人間の優劣をつけるものではなく、人間の強みを調べるものだということを理解しましょう。

ビッグファイブの診断ができるサイトは多くあります。
私は次のサイトを試してみました。120問の方も10分程度で終わったので是非やってみてください。


自分の個性タイプがわかったら、チームビルディングのためにお互いに説明することでコミュニケーションのヒントにしていきます。
ただし、個性タイプを示すことは結構勇気がいることだと思うので、それぞれのメンバーがグループに対して信頼を寄せていなければならないし、かつ何のためにそうするのかを理解している必要があります。
説明をする場には、管理職など自分の昇進・昇格に影響があると感じる人はいない方が心理的な安全性は高くなります。

グループディスカッションをする時には以下のような流れが参考になるかと思います。

  • メンバーに対して個性の説明をする
  • 進行役が説明者に以下の質問をする
    • 今の説明はあなたがどういう人間化をよく表していると思いますか?
    • この評価を見てどう感じましたか?
    • この評価は正確ですか。正しいところとそうでないところを詳しく説明してください。
  • チームメンバーの話をきく
    • この評価は役に立つと思うか
    • 今挙げられたこと以外で持っていると思う長所は何か

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

こういった性格の理解をお互いに深めていくことでチームメンバーがどういった力をチームで発揮してくれるか考えていけるヒントになると思います。

おまけ

恥ずかしいけど私の結果も出しておこう。
科学的性格診断・心理テスト | Big5-Basic(ビッグファイブ・ベーシック)を使ってテストしてみました。
この後に色々と細かい説明が記載されています。

f:id:syobochim:20210419092525p:plain:w400

多分、3年前の自分とも全く結果が違う気がする。。。