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

略してそこ仁！

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

本読んだ チーム アジャイル

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

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

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

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

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

📖 目次

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

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

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

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

リソース効率

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

フロー効率

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

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

www.slideshare.net

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

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

新しい取り組みを進めていくときにはちゃんと効果を出せているのか不安になると思います。
そこで最初に期待値を設定しておくことが重要と「1.3.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年前の自分とも全く結果が違う気がする。。。

認定スクラムマスターを取得しました！

アジャイル 開発手法 社外勉強会

2/1 - 2/5に認定スクラムマスター取得のためのトレーニングを受講し、2/10に試験に合格して無事に認定スクラムマスターの資格を取得しました！
証書にはトレーニング完了日が記載されるようですね。

f:id:syobochim:20210211172548p:plain

認定スクラムマスターを取得しようと思った経緯

2年前にアプリケーション開発者をしていたときにアジャイルの考えを取り入れた開発をしていました。
開発手法は私自身の興味領域でもあったので、これまでもスクラムガイドを読んだりスクラム関連の書籍を読んだりしてきました。
しかし、これからの仕事でスクラム開発に関わる可能性が出てきて、きちんとスクラム開発を学びたいと思い、認定スクラムマスターのためのトレーニングと認定取得にチャレンジすることにしました。

トレーニングの内容

トレーニングはこちらから申し込みました。
これで、5日間のトレーニングと2回の認定資格受験資格をもらえます。
www.odd-e.jp

5日間のトレーニングはすべてオンライン（Zoom）で開催されました。
9時から15時までワークショップを含めたトレーニングがあり、その後に16時まで質疑応答の時間が設けられていました。
ワークショップは少人数のチームに分けられてMiroを利用してリアルタイムにボードを編集しながら進めていきました。

トレーニングでの講義やワークショップでは、「アジャイルやスクラムで大切にしている考え方」や「スクラム開発での役割の理解」に関する内容が多かったです。
「デイリースクラムとは」「スプリントレトロスペクティブとは」という細かいプラクティスに関する内容は少なく、「アジャイルソフトウェア開発宣言」や「スクラムマスター・プロダクトオーナー・開発者の役割」「最初のインプットとなるプロダクトバックログとは」「チームの作り方」というようなベースとなる考え方の理解を重点的に解説やグループワークによる議論を進めていきました。

色々と勉強になる点は多かったですが、スクラムマスターの研修ということで参加前には「スクラムマスターはどんなことをしなければいけないのか学びに行こう」という気持ちでしたが、スクラムマスターは自立自走を促していって、最終的には何もしなくても問題ない状態になるよう働きかけていくということを学びました。

トレーニングを受けるにあたり、スクラムの前提知識はそこまで必要ではなかった気がします。ただ、トレーニング前に以下のドキュメントとサイトに目を通しておくように案内はありました。
こちらを事前に読んでおけば、トレーニングでついていけないということはないと思います。

個人的には15時以降の質疑応答の時間が楽しかったです。
講義の内容についての質疑応答ももちろんありましたが、「自分の現場ではこういう問題が起こっているけど、どうしたらいいか」というような相談会にもなっていて、他の参加者の実態なども知れて面白かったです。
その時間でトレーナーの方の話を聞いた結果、（スクラム開発ガイドには準拠するという前提で）問題が発生した時にこうするべきだというプラクティスはなく、関わる人たちの話を聞いてチームで解決できる道を考えていくという回答が多くありました。
スクラムマスターは答えを提示する役割ではなく、スクラムチームが自分たちで解決方法を見つけられるように促していくという役割であることが、質疑応答の時間からも理解できました。

テストの内容

トレーニングで認定試験を受験しても問題ないとトレーナーに判断されたら受験資格をもらえます。
（推測ですが、私の受けたトレーニングでは全ての方にトレーニング資格が届いていたのではないかと思う・・・）
資格試験は2回受験でき、一度は落ちても大丈夫とのことでした。

資格試験はWebで自宅から受験でき、日本語を選択可能で、選択式の問題でした。
スクラムガイドの内容を理解できていたら落ちない試験かと思います。

これから

今回、晴れて認定スクラムマスターになりました🎉
トレーニングの内容を理解できたことと、試験に合格したことで自信も得たので、これから仕事にも活かしていきたいと思います✊

また、研修の中でいくつか書籍も紹介いただいたので、それを読みつつ更に理解を深めていこうと思います。

(参考) 講義で紹介されていた書籍

リーン・スタートアップ　ムダのない起業プロセスでイノベーションを生みだす
学習する組織 ― システム思考で未来を創造する
大規模スクラム Large-Scale Scrum(LeSS)

動画のサイズを減らすffmpeg

メモ 動画作成

オンラインの仕事も増えて、動画を作って触ることが増えました。
iMovieなどの動画編集ソフトで動画編集もするのですが、編集した動画をエクスポートすると基本的にファイル容量が増えてしまいます。（元々が200MB程度だった動画が1GB近くなったりしていた。）
動画を仕事相手に共有する際の制約などから動画のファイルサイズを小さくしたかったのですが、やり方が分からずとても苦労していました。
実際に編集ずみの動画を画面に流して画面収録で取り直したり。。。

そこで、ffmpegというツールを知り、コマンドで簡単に動画サイズを縮小できたので、自分用にMEMOしておきます。
具体的には、
元ファイル：200MB → 動画編集ずみ： 900MB → ffmpeg：200MB
くらいになったので、個人的には大満足の結果になりました。

インストール方法

macの場合は Homebrew を使って簡単にインストールできます。

brew install ffmpeg

WindowsやLinuxのパッケージもあり、ここからダウンロードできます。
Download FFmpeg

動画のサイズを減らす

動画には詳しくないのですが、CRFというエンコーダーの数値があり、それを指定して動画変換することで動画サイズを圧縮できました。

コマンドとしては以下のようにオプションを指定します。

ffmpeg -i input.mp4 -crf 18 output.mp4

圧縮方法によってCRFのデフォルト値は異なり、CRFの値は小さくなるほど品質が良く、大きくなるほど品質が悪くなっていきます。
こちらのサイトによればそれぞれの圧縮方法に対してのCRFデフォルト値は以下のようになっており、±6の変更によってファイルのサイズは半分もしくは2倍になるとのこと。

  • x264 : 23
  • x265 : 28
  • 1080p HD video : 31

上記のコマンドとして記載している18は品質をかなり良いものにしているのですが、iMovieなどの動画編集ソフトで付けられた無駄なファイルサイズを削減することが目的であり、動画品質はなるべく落としたくなかったので全く問題ありませんでした。
動画変換後も私が感じ取れる品質の変化はありませんでした。

参考：
FFmpegで動画変換！各OSごとのインストール方法と使い方まとめ｜新卒エンジニアの開発日記
CRF Guide (Constant Rate Factor in x264, x265 and libvpx)

オンライン飲み会（やミーティング）を切り上げるためのクソアプリ

自作アプリ エモ

この記事はクソアプリ Advent Calendar 2020 - Qiitaに参加したかったけどできなくて羨ましくてクソゥ！な私が気持ちの供養のために作ったクソアプリの紹介です。

どんなアプリ作ったの？

オンライン飲み会では切り上げるタイミングがわからず、グダグダとなんの盛り上がりも無いまま時間が過ぎていくことがあります。
（そして、オンラインミーティングでは、参加者からの厳しい質問の中で回答が浮かばずにミーティングを切って逃げたくなることがあるでしょう。）
そんな時に、何か言い訳があれば…。みんなが仕方ないと思うような言い訳があれば…。
そんな全人類のためのアプリを作りました。…クソアプリじゃないな？？？

f:id:syobochim:20201216221555j:plain

アプリの動き

言い訳が表示されているので、ラジオボタンで選択して「失礼します。 😫」ボタンを押します。
その言い訳に合わせた音声が流れてくれるので、あとは選択した「言い訳」と「失礼します」を申し訳なさそうな顔😫で言って「退出」ボタンを押しましょう。
「退出」できたら「抜け出し成功 😏」ボタンを押して音声を止めます。

実際のサイトはこちらで試せます。（音量注意）
オンライン飲み会を終ろう

f:id:syobochim:20201216235521p:plain



アプリのコードはこちらです。
github.com

音声の出し方

音声はHTMLの

HTMLに以下のように記載して

<audio id="aka-naki" preload loop>
    <source src="audio/aka-naki.mp3" type="audio/mp3">
</audio>

JavaScriptを使って再生する。
JavaScriptを使わなくてもHTMLだけで音源の再生は可能ですが、今回はボタンを押したイベントで音声を流したかった。

const iiwake = document.getElementById(reason);
// 再生
iiwake.play()
// 停止
iiwake.pause()

終わりに

本家のアドベントカレンダー、見ていてとても楽しい！

Macのストレージ容量が無い！容量が大きいファイルの調べ方＋フォルダごとのサイズを簡単に見る方法

メモ macOS

Macのストレージ容量が逼迫してしまっていたけど、なんのファイルに容量が使われているのかすぐにはわからなかった。
こう見れば楽にわかったなというメモです。

まず、Macのストレージ容量は画面左上のアップルマークから「このMacについて」をクリックし、
表示されたポップアップから「ストレージ」のタブを開きます。

f:id:syobochim:20201216134802p:plain
※原因だったファイルを消したのでキャプチャ取得時にはかなり余裕がありますが、残り23GBまで逼迫してました。

右上の「管理」のボタンをクリックすると、どの領域に容量を使っているのかがわかる画面が表示されます。

f:id:syobochim:20201216135153p:plain

本来なら、ここで大きいファイルが表示されているはずでしたが、問題になっているファイルが大き過ぎたのか、なぜか表示されていませんでした。
（私の場合はiMovieのプロジェクトファイルが原因で300GBありました。iMovieの操作の中でファイルがバックグラウンドで作成されていたので、300GBのファイルを意図的に作成・ダウンロードしたわけではなく気づけませんでした。）

また、この表示だと「このファイルがどのフォルダにあるものなのか」もわかりにくくなっており、ファイルをサクサクと消しても良いのかどうかが判断しにくくなっています。

対応といっても単純なことなのですが、画面上部の「大きいファイル」から「ファイルブラウザ」に変更します。
これにより、どのフォルダにストレージ容量がかかっているのかを見てファイルを掘り下げていくことができました。
ファイルを右クリックするとゴミ箱にもこの画面から入れられるので、ファイルの整理が簡単にできます。

macOS Catalina
f:id:syobochim:20201216135739p:plain

macOS Big Sur
f:id:syobochim:20201216140130p:plain

【Electron】アプリを全画面モードでも他のデスクトップに移動しても常に最前面に表示する

Electronでアプリを作りました。

アプリは

  • ワークスペース（デスクトップ）を切り替えても表示される
  • 他のアプリよりも前に表示される
  • 他のアプリを全画面表示した時も前に表示される
  • Keynoteをプレゼンテーションモードにした時も前に表示される

としたかったです。

特に4つ目のKeynoteでのプレゼンテーションモードが一筋縄ではいきませんでしたが、最終的にはこんな感じで実現ができました。

f:id:syobochim:20201116213210g:plain

package.json の main で定義している main.js にてウィンドウを開くときに設定を追加していきました。

const { app, BrowserWindow } = require("electron");
const is_mac = process.platform==='darwin'     // macOSかどうかの判定をする

if(is_mac) {     // macOSの時のみこの設定を反映する
  app.dock.hide()          // Dockを非表示にする
}

const MAIN_WINDOWS_WIDTH = 300;
const MAIN_WINDOWS_HEIGHT = 350;
function createClapWindow() {
  // Create the browser window.
  const mainWindow = new BrowserWindow({
    width: MAIN_WINDOWS_WIDTH,
    height: MAIN_WINDOWS_HEIGHT,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
    }
  })
  mainWindow.setAlwaysOnTop(true, "screen-saver")    // 常に最前面に表示する
  mainWindow.setVisibleOnAllWorkspaces(true)      // ワークスペース（デスクトップ）を移動しても表示される
  mainWindow.loadFile('public/reaction.html')
}

app.whenReady().then(() => {
  createClapWindow()
})

app.dock.hide() の設定によって、macOSにて全画面モードで開いた時にその上に表示できるようになります。
Windowsにはこの設定はないので、事前にmacOSであるかどうかを判断してmacOSの時のみ設定を適用しています。

mainWindow.setAlwaysOnTop(true, "screen-saver") の設定をすることで、キーノートのプレゼンテーションモードの時にも最前面に表示されるようになります。
BrowserWindow にも alwaysOnTopのプロパティを持っていますが、これに true を設定してもキーノートのプレゼンテーションモードでは適用されませんでした。（他のアプリの全画面モードでは最前面に表示されたのに。。。）

mainWindow.setVisibleOnAllWorkspaces(true) の設定で、ワークスペース（デスクトップ）を切り替えても一緒に移動して表示されるようになります。

これらの設定で実現できました。

参考