Murga

個人的に言いたいコト・主張・気持ち。

エンジニアらしい Excel にしたかった

ニホンノエスイーは Excel を表計算ソフトとしてではなく、方眼紙として使用するのはよく知られた事情。モロにニホンノエスイーだった前職から転職した今も、方眼紙を作らされることはよくある。

現職ではご意見番の長老が幅を利かせていて、とにかく Excel で全ての資料を作らせてくる。彼が作らせる資料は、

  • 人間が目視で確認するための表であり、
  • 人間が目視でデータを比較しやすく、
  • 紙印刷して使いやすい

ことを目指しており、ひどくアナログなのだ。

要は「上の人間はこまけぇこたぁ分からん、パッと見で要旨が分かるようにせい」ということで、その視点は不要だとは思わない。上司に説明するための資料であれば、ペライチで言わんとすることが表現されている方が良いのは、まだ分かる。

でも今回作っているのは、開発者と運用担当が相互に用いる、細かなサーバ設定やソフトのパラメータを記すための資料なのだ。そもそも Excel なんかで作る必要はなく、設定情報を YAML や JSON なんかで出力させて diff とった方が良いのは明らかなのだが、Excel で作るにしても、

  • EXACT 関数で前回の値と比較するとか、
  • 条件付き書式で空欄や明らかな不正値を検出するとか、
  • データのインポートや表の整形などをマクロで実装しておく

とかして、Excel の機能を最大限使って、人間が目視でじっくりチェックせずとも異常が炙り出せるファイルを作った方が、運用しやすいし、間違いが減らせるだろう。

もちろん、人間が目で読むこともあるし、加筆修正は人間がするものだが、こうした機械によるダブルチェック機構も用意しておくことで、より人的ミスを防ぐ仕組みづくりができると思う。


ただ、仮にそのようなチェック関数やマクロを仕込んだ Excel ブックを作ったとしても、更新する人間が Excel の仕様を知らなかったり、そのブックにどのような関数が仕込まれているかを把握せずに手を加えてしまうと、途端にそのブックは壊されてしまう。

他人が作った Excel ブックを「壊す」人は、Excel を知った気になっていて、いくら丁寧に更新手順を書いていても正確には読めず、自己流のやり方で作業して、条件付き書式を壊してみたり、罫線を崩してみたり、チェック用の関数を消してみたり、行参照をズラしてみたりしてくる。

できるなら

  • 条件付き書式を使わない
  • 各行や各列に計算用セルが必要になる作り方にしない
  • 実線と点線を組み合わせるような複雑な罫線の使い方はしない (全部単純な実線で十分)

というような対策で、ブックを壊されても被害が少なくなる作りにしたいが、データの比較をしたいとか、集計したいとかなると、なかなか厳しい。

ならばと書式や数式を正しい状態に復元するような自己修復するブックのマクロを書こうと思うと、それこそ膨大なコストがかかるので、技術的には可能だとしても、そのような Excel は作り込まずに諦めてしまう。

こうして、デキる人は Excel に対する (というより Excel のリテラシが低い連中に対する) わだかまりを深めていき、Excel を方眼紙としてしか見ていないエンジニアごっこをしている連中はいつまでも同じ手作業を繰り返しては悦に入っていて成長しない状況が続くのだ。

「エンジニアたるもの、関数やマクロを使いこなして、全てを自動化しようではないか」と思っていたが、もう諦めた。

そういうゴリゴリに計算するような Excel は一人で作って持っておけばいいや。そんで、対外的にはバカどもに見せるバカ用の Excel を作って回すことにしよう。同じような資料を2つ作ることになるが、自分だけは楽に、間違いなく運用できる Excel を使うとしよう。

Excel 最強の教科書[完全版]――すぐに使えて、一生役立つ「成果を生み出す」超エクセル仕事術

Excel 最強の教科書[完全版]――すぐに使えて、一生役立つ「成果を生み出す」超エクセル仕事術

コードを書かずに GitHub の草を生やしたいなら、GitHub Issues でタスク管理する

転職活動の際に、GitHub アカウントの提示を求められたりする機会が増えているみたい。自分も実際、転職活動中には GitHub アカウントを教えてと云われて、見せたことがある。

僕の場合は、転職活動当時は「ライブラリを試しに使ってみた」リポジトリを立てていたり、簡単なスクリプトを配布するテイでまとめていたりして、それなりに活動している風の Contributions に仕上げてあった。レベルの低いコードばかりであったが、ココにはウソはなかったし、リアルな「これからガンガン勉強していきます!」感は伝わっていたのではないかと思う。

その頃の僕は、前職の仕事をのらりくらりとかわして定時退社し、夜通しプログラミングしたりしていた。PC の持ち込みは禁止されていた職場だったが、こっそり MacBookPro を持ち込んで出社していて、昼休みの間に近所のカフェで React の勉強をしたりもしていた。自宅と職場が近かったし、男の一人暮らしだったので、他の家事なんかも全て犠牲にしてプログラミングに費やしていたから、GitHub Contributions は自然と増やせたのだ。

しかし、状況の異なる皆さんの中には、そうそうコードでの成果ばかり見せる時間がない人も多いと思う。PC 環境もネット環境も違うだろうから、みんながみんな、コーディングだけで GitHub Contributions を充実させるのは難しいと思う。


そこで、今回僕が紹介するのは、GitHub Issues でタスク管理することで GitHub Contributions の草を増やすという方法だ。

コチラの公式ガイドによると、Contributions にカウントされる内容はこうしたものだそうだ。

  • Committing to a repository's default branch or gh-pages branch
  • Opening an issue
  • Proposing a pull request
  • Submitting a pull request review
  • Co-authoring commits in a repository's default branch or gh-pages branch

1つ目が、普段のコミットで草が付く原理。注意すべきは、リポジトリのデフォルトブランチか gh-pages ブランチへのコミットが対象なので、Feature ブランチを作る運用だと、マージするまで草が生えない。僕の場合は、「ライブラリの勉強中リポジトリ」みたいなモノは全て master ブランチに Push していたので、ガンガン草が生えていた。

2つ目が、今回の要旨。Issue を作成 (Open) すると、Contributions としてカウントされるのだ。この Issue は自分が作ったリポジトリに自分で Issue を上げてもカウントされるのが特徴。

そこで、自分のタスク管理用のリポジトリを作り、日々のタスクを Issue として書き出すのだ。自分の場合は、「Neos21」という名前のリポジトリをタスク管理用にしていて、「このブログにこのネタ書きたい」とか、「このライブラリの使用感を確かめたい」とか、そんな課題・ToDo を Issue として上げている。

コードは書いていないし、まだ「やりたいこと」を書いたまでで実現もしていないのに、Issue を Open するだけで草が生える。

最近、GitHub Issue ページのデザインがスマホ向けにも調整されたので、スマホからの Open、Close なんかも楽チン。ラベル付けに難があるものの、とりあえず書くだけなら問題ない。

ToDo を書き出すことは自分のタスク整理のためにも重要なことだし、日々の ToDo 管理を GitHub Issue で行うだけで草が生やせるなら儲けものである。


コードを更新する場合は、この方法でもっと草が生やせる。

まず、タスク管理用リポジトリで「○○リポジトリに□□機能を追加する」というタスクを上げておく。続いて、「○○リポジトリ」側にも同じような Issue を作る。

そしてコードは Feature ブランチを切って更新し、プルリクを作る。このとき、プルリクのタイトルで「○○リポジトリ」に作った Issue の番号を入れておくと、プルリクをセルフでマージした時に、Issue もクローズしてくれる。

プルリクのオープンや master ブランチへのコミットがそれぞれ Contributions としてカウントされるので、少し濃い草を生やせるのだ。


本当に草を生やしたいだけなら、拙作の gh-contributions というシェルスクリプトでも実現できるが、Contributions の中身を見られるとフェイクだとバレる。

タスク管理として Issue を使っています、草が濃いところは実際にコードをマージしたところです、一人でやってますがプルリクとかも使いこなしててチーム開発も大丈夫です、という感じで、GitHub を見せたときのアピールポイントが増やせるので、コードをガリガリ書く余力が作れない時は特に、こうした手法も使ってみてはいかがだろうか。

いちばんやさしいGit&GitHubの教本 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

いちばんやさしいGit&GitHubの教本 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

GitHubポケットリファレンス (POCKET REFERENCE)

GitHubポケットリファレンス (POCKET REFERENCE)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)