非IT業界の妻にPullRequestを送ろう ~家計簿GitHubリポジトリ化の軌跡~
こんにちは。hinoshibaです。
皆さんは、家計簿をつけていますか。
つけている方は、どのようなものを利用していますか。
弊家の家計簿は、GitHubリポジトリで管理しています。
今回の記事では、家計簿のGitHubリポジトリ紹介と、
非IT業界の妻に毎月Pull Request（以降:PR）を送る運用フローの導入案件？を紹介させていただきます。
家計簿のGithubリポジトリ
今回紹介する弊家の家計簿は、github.comにMarkdown形式で管理しています。
なお、GitHubが使えなくなっても問題がないように、汎用的なMarkdownとして管理しています。
そのため、正しくは、“家計簿GitHubリポジトリ化”では無いのですが、
一旦GitHubに置いている為、そのような表現をさせていただいています。
サマリレポートとしては、以下のような物を出力しています。
（詳細ページの画像は、マスキングだらけになってしまうので、割愛）
MarkdownのTableを用い、収入や支出、黒字値（収入ー支出）などをパッと確認できるようなレイアウトにしています。
上画像には含まれていませんが、1決裁単位のCSVをリポジトリ内に一緒に保管しています。「詳細」という表は、それらのCSVをカテゴライズし、生成しています。
CSVは、クレジットカードの利用履歴やネットバンクの明細をダウンロードしてカラムを整える事で利用できるようにしています。
ちなみに、これらの集計は、お手製コマンド（kai-ab）です。 おそらく、GitHub Actions等でも行えるとは思いますが、
- 将来GitHubが利用できなくなった場合にも引っ越しができるようにしておく
- 計算中には、外部リソースを利用したくない
といった理由から、お手製コマンド（kai-ab）を書きました。
GitHubリポジトリ化の経緯
過去の家計簿は、Excelでした。
私が学生一人暮らし時代をしていた2013年頃から行っており、
毎年テンプレートをアップデートした秘伝のタレ状態のExcelを使っていました。
6年物のExcelは、以下の画像のようなサマリ画面となっています。
仕組みとしては、
毎月のシートに、決済単位の情報を記録し、手動で分類を実施。
Excel関数が分類を元に集計し、サマリ画像に出している表に集計されます。
この仕組み自体は、とても気に入っていたのですが、
妻と共に運用する際に問題があることもわかり、仕組み自体の見直しを行う事になりました。
問題を2点だけ紹介します。
1点目: 今月の更新内容が把握しづらい
誤更新のロールバックや、今回の更新内容把握のために、家計簿の過去の状態を保存したい要件がありました。
しかし、単一のExcelファイルに複数世代を完全に保存しておくことは、容易ではありません。
その為、「2021家計簿_20210401.xlsx」「2021家計簿_20210501.xlsx」というように、「<ファイル名>_yyyymmdd.xlsx」形式でファイルを保存し、見比べる事で差分が分かるように管理していました。
これによって誕生するのが、ウォーリーを探すよりも難しい間違い探しゲームです。
diff <fileA> <fileB>のように差分を簡単に出力できれば、更新内容を把握することも容易ですが、そんなツールがありません。
その為、妻から、「今月はどこが更新されたんだっけ？」と問われるたびに、間違い探し大会が開催されていました。
頻度が低ければまだ救いがありますが、家計簿は月次更新です。
妻へダブルチェックを依頼する度に発生するので、月1度以上の頻度となってきます。
2点目: 妻の確認済みが分からない
家計簿を作るタスクは、1人でやる方が効率的な為、作る作業は1人で行っています。妻に協力してもらうのは、確認作業です。
ミス発見のためのダブルチェックや、夫婦の家計なので、単に把握してもらう目的で行っています。
ただ、複数人で作業を行うには、対象の状態を同期することが必要となってきます。
結婚前（厳密には同棲前）には、1人作業だったので起きなかった問題ですが、
ファイルに対して、“確認が終わった状態”や”ミスがあった状態“を区別できる表現が必要となりました。
下手をすると、よくネタ（？）で見る、下記の状態が起きるわけです。
どれが最新なんでしょうね。
hinoshiba@fs:~$ ls -la /mnt/r1/accountbook/fy2020/
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_承認待ち.xlsx
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_承認待ち_差し戻し.xlsx
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_承認待ち_差し戻し_完成版.xlsx
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_完成版.xlsx
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_完成版_再レビュー.xlsx
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_レビュー済み.xlsx
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_レビュー済み_修正板.xlsx
-rw-rw-r-- hinoshiba hinoshiba <ファイル名>_yyyymmdd_レビュー済み_修正板_完成版.xlsx
もちろん、こんな酷い事にならないよう、共有シートを活用したり、フォルダ移動管理なども試してみましたが、手順が複雑になるだけでした。
コンピュータに仕事を任せて楽したいのに、本質ではないところで考え事が増えても何も幸せになりません。
脱Excelを考える
紹介した問題以外にも、問題点はいくつかあり、
毎月の家計簿更新とともに貯まっていく不満をどうにか改善できないかと、色々な方法を試しました。
高コスト（PHPでの自作家計簿webシステムを開発してみる、法人向けの資産管理ソフトウェアを使ってみる）な物から、低コスト（マネーフォワード 等の既存サービス利用）まで様々です。
社会人である以上、お金に関する作業は数十年間継続的に発生すると思うので、
対応コストに見合った成果が得られる物にしなくては、運用自体が回らなくなる懸念がありました。
そのため、程よいバランス感の物を約1年ほど試行錯誤していました。
世界（家計簿）に囚われないで考える
「差分がわかりやすく、確認済が管理しやすい家計簿」で適切なものは、中々見つかりませんでした。
そのため、「家計簿」に囚われて考える事を一旦やめ、問題に目を向けてみることにしました。
要は、「差分が確認できて、確認ステータスが見れるもの」を探し始めました。
当時から、GitHubは活用していたので、PR機能にすぐ目をつけました。
そして、そもそもこれに家計簿を載せてしまえば、全て解決するのではないか。と考えるようになっていきました。
当時、家計簿以外に目を向けた目的は、問題に対する解決策のアイデアとして、家計簿以外にも目を向けてみる。事でした。
その目的外の影響でしたが、
この方向転換が結果として、「既存の仕組みに、家計簿を載せてみる」という家計簿GitHub化に結びつきました。
GitHub家計簿の運用フロー
現在の運用フローは、ざっくり以下の通りです。
家計簿を作成するタイミングでbranchを作成し、データの追加やお手製コマンド（kai-ab）で計算をいます。
カテゴリ化などは、autofil mfil 等のサブコマンドに支援させており、calcサブコマンドで集計しています。
集計が終われば、家計簿として見れる状態のため、PRを作成します。
その後、妻に連絡を入れるとレビューとマージをしてくれるといった流れです。
重要なのは、Reviewerとして妻に見てもらうことなので、マージはhinoshibaが行うこともあります。
実際のPRでは、以下のように、今月のイベントを簡単に記入するフォーマットにしています。
これにより、当月の例外を簡単に把握することができ、意味のあるレビューが行われます。
数ヶ月前の振り返り時に、イベントの把握も簡単に行えるという副次効果もありました。
導入前の妻「GitHub!? ナニソレ美味しいの??」
妻はhinoshibaのようなオタクでは無いので、上記のような表現はしていませんが、同じような意味の言葉を述べていた事が印象に残っています。
実は。本家計簿の導入構想は、2019年からありました。
しかし、実際に導入が行えたのは、2021年です。
非IT業界の妻にとっては、YoutubeやLINE、Googleドライブ、Dropboxなどは馴染みがあるようですが、開発者が集うGitHubに馴染みがありません。
そのため、「いきなり、よくわからんツールを提案してきている夫」という状況が生まれてしまいました。
そして、2019年最初の導入提案は見事撃沈しました。
hinoshibaが話下手な事も加わり、GitHubに嫌悪感を抱かれてしまったかもしれません。
そのため、
妻へのGitHubを知ってもらう事や、そもそものシステム準備を含めて諸々の時間がかかり2021年に導入できました。
最初のアクションは、「MS TODO を使うこと」
「GitHubに親しみを持ってもらうために、Microsoft ToDo (以降: MS TODO)を使い始めました。」
よく分からない話でしょうが、私なりに考えた結果の第一ステップでした。
まず、GitHubを知ってもらうために、日常的に使ってもらう事を考えつきました。
そこで、考えたのが、お買い物リストのIssue管理を、GitHubに載せる事です。
当時の弊家では、スーパーでのお買い物リスト管理方法を検討していました。
既存の方法は、「口頭連携」、「手のメモ」や「LINEでの共有」などでしたが、購入漏れやダブりが発生することもあり、問題意識があったためでしょう。
そこで、共有できるリスト管理の方法として、IssueのOpen, Closeでお買い物リストで管理する方法を思いつきました。
しかし、当時、GitHubは、まだスマフォアプリが未リリースでした。（リリース計画は、アナウンス済の時期）
そのため、ステップをもう1段階細かくし、「スマートフォンで共有リスト管理を定常化させる」事を先に行いました。
そこで、対象として、MS TODOを選択し、
「りんご」「バナナ」「納豆」などをオープン、クローズすることでお買い物リストの管理を実施したという流れです。
余談ですが、
MS TODOには、リストにアイコンを設定できます。
作成時は、お金を利用するリストなので、「💸」を指定していました。
数日後、妻にお金を失っているようで辛いとコメントを受け「🍎」に変更がありました。
言われてみるとその通りで、ちょっと面白かったのが思い出です。
失敗: GitHubを使ってもらう
MS TODOの利用開始から、約半年後、無事にGitHubのスマフォアプリがリリースされたため、お買い物リストの移行を行いました。
しかし、何事も計画通りにはいかない物なんでしょうか。
お買い物リスト運用が滞る自体が発生しました。
GitHubのスマフォアプリでIssueのOpen, Closeが大変手間だったのです。(下の画像の通り、3ステップ)
完全に誤算でした。
Open Issueを買い物する対象として扱う運用では、買った際のCloseや買って欲しい時にOpenを行うため、頻繁なOpen, Closeを行う作業が伴います。
MS TODOでは、「リストへスワイプして、Close」でできた作業が、「都度画面が切り替わり、タップ数も増えるClose」をしなくてはいけなくなったことが、利用の課題となってしまったようです。
成功: 間接的に、GitHubを使ってもらう
「GitHubに馴染みを持ってもらうために、使ってもらう」という思いはありましたが、「日々ストレスのたまる手間な作業を妻に強要する事」は本望ではありません。
そのため、「GitHubに馴染みを持ってもらうために、 間接的に 使ってもらう」事にしました。
SlackBot化です。
使いやすいUIを0から作ること手間がかかりすぎるので、お買い物リストのフロントエンドをSlackのBot化し、間接的にGitHubを使ってもらう形を用意しました。
使い方は、すごく単純です。
以下の画像のように、特定チャンネルでメッセージを送るだけです。
そうすると、対象のリポジトリに、IssueがOpenになります。
Issueの特性上、「削除」ができないので、
間違えた際のdelコマンドは、IssueにDestoryというラベルをつけ、Destoryは、表示しないといった工夫などもあります...w
他にも、現在のリストを見るためのSalckBot用コマンドも存在します。
これにより、妻はGitHubのUIを扱う事なく、お買い物リストの更新ができる環境が整いました。
結果、この導入は、大成功を納めました。
妻に、GitHubを普段から利用してもらうことを実現でき、「GitHubがさ～」といった会話も、自然に行えるようになっていきました。
なお、MS TODOよりも使い勝手が良かったらしく、妻も気に入っているようです。
Botの応答表現への要望を出してくれたり、障害時に「うさ（アイコンがウサギ）が無視する！w」と教えてくれたりと、運用への積極性を感じています。
無事、導入。運用開始
お買い物リストをSlackBot + GitHub Issue化して、数ヶ月経過し、GitHubに親しみを持ってもらった頃に、
改めて、家計簿のGitHub化を行いたい事や、メリットデメリットについて伝え、相談しました。
そして、すんなり受け入れてもらう事ができ、無事、本記事で紹介した家計簿のGitHub化に成功しました。
会話した際の感覚としては、「システム的に、妻の承認が可視化される点」が良かったようです。
複数人運用では、可視化や透明化による、認識の低コスト化がとても大切ですものね。
2021/01から運用を開始し、執筆時点（2021/05）では、運用がだいぶ軌道に乗りました。
今では、非IT業界の妻は、休みの日にGitHubを開き、まるで共同開発者のようにPRを眺めてくれます。
後書き
いかがでしたでしょうか。
家計簿のGitHubリポジトリと、その導入に至るまでの流れを紹介させていただきました。
hinoshiba（家庭内をIT化したい系夫）に対して、
妻の理解があるために、実現できる事でもあり、とても感謝しています。
さて、
本件ですが、家計簿を作成しているのは私なので、
妻に納得してもらわず、強制的にGitHub化する道もあります。
しかし、家庭の共同運営者として、共に歩むパートナーとして、状況を連携し、納得感を持って一緒に進める事を大切にしている関係のため、
本記事のような流れがありました。
他にも弊家では、入籍時の苗字も夫婦で話合い、お互いに良いと思える理由で選択しています。
苗字を選んだエピソード記事: Re:ゼロから始める「妻の氏」選択
周りがどうでも良いとは言いませんが、家庭の共同運営者として、しっかりと話し合える環境は、とても大切だと思っています。
さて、まだまだ検討したい事は、家庭内に存在しています。
妻ともっともっと相談していき、自宅情シス主幹として、最適化を繰り返していこうと思います。
Discussion