Best effort JavaScript

but most favarite is Python.

ツールに振り回されない

最近読んだ本によるとGoogleでは「何でも議題に出来る会議」を「TGIF」と呼び毎週金曜に開催しているらしく、
社内業務とは異なる角度でビジネス、技術、ライフスタイル全般に刺激を生み出せる場があると良い気がしたので、
自分の会社でも取り入れてみる事にした。

How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

段取りが固まっていなかったので、
大好きなrebuild.fmをインスパイア、話題にしたいトピックを事前にshow notesにまとめ、
その場の空気と残り時間に応じてセレクトするスタイルで行った。

以下が使用したshow notes。

medium.com

課題としては

  • 7名程度メンバーが居るので全員がshow notesを書くと収拾が付かなくなりそう。
  • 社内メンバー同士で社内の枠組みを離れた最先端のトピックに触れる事が社内でのビジネスに重要な影響を与える事、業務と関係の無い遊びに見えて実は会社の方向性を決定付ける重要なファクターであるというコンセンサスが十分に取れていない気がする。
  • 皮膚感覚として、自分とチームのフィーリングが合っている気がしない。今日ピックした話題が面白いかどうか以前に、友人同士や勉強会でのディスカッションで得られる「それぞれの知的探究心が連鎖し、やがて文化的な時間軸に滞留する感覚」が全くない。

特に一番下の項目については時間が経過するにつれ段々と負担になってきた。

まずは以下の内容について、
決して関係者を批難する内容ではないと前置きさせて頂きたい。
個人的な信条を文書として永続化するきっかけになってくれた訳でどちらかと言えば感謝している。
今回の会議ではもともと議題項目が少なかったため「強いて挙げれば…」的なメンタリティで議題に追加されただけで、それほど深刻な問題として取り上げた訳では無かったものと推測する。

新しいメンバーがgithubでPullRequestの作成先ブランチを間違えたようだ。
それはマージされた訳でもなければ、誤ってリリースされて実害が出た訳でもない。

議論はこの事実についてどうすれば良いか?というざっくりとした出発点からだった。

開発フローについてドキュメントを書くなどの結論に着地したようだが、
私にはどうも「ソースコードの反映手順を誤る事による本番環境への実害を回避したい」という文脈で会話がなされているように感じて、
「みんな、そもそもどうしてgitを使うようになったのか考えた事があるんだろうか…」
と心の中で溜息してしまった。

たとえば、レガシーな組織がgitを導入するまでのシナリオをイメージしてみよう。

  • バージョン管理をしていない。ローカルで開発したものをSFTPなんかで検証環境にアップ。問題なければ本番に同期している。
  • 誤って書きかけのソース(syntaxエラー状態)を検証環境にアップ、何かの拍子で本番に同期されてしまったりなんかしたら大変だしリカバリが難しい。確実な防止策に欠けヒューマンエラーが起きないよう祈るしかない。
  • 有事の際はとある開発者がたまたまローカルにハードコピーしていた(2015_1011_1630_bkのようなディレクトリ名)ソースを大慌てでデプロイ、何とか事なきを得る。
  • 会議でこの事案が取り上げられる。どうすれば誤った変更のデプロイを防げるか?
  • 内容近年デファクトとなったgtihubを用いた開発フローを採用する事とした。以下の利益を同時に享受出来る、画期的なソリューションだ。
    • バージョン管理
    • デプロイされる内容を特定のブランチに制限する事で、デプロイ前にPullRequestを通過する必要を強制出来る
    • ロールバックの確実化
    • 特定の人物にのみwrite権限を付与する事で、それ以外の人物が「誤った内容をデプロイする」ヒューマンエラーを起こす事が物理的に不可能となる
  • 一般の開発者はgitでたとえ操作を誤っても物理的に実害を起こす事は出来なくなったので、チームはどうすれば誤った変更のデプロイを防げるか?のような危惧に対して会議の時間を割く必要は無くなった。

新しいメンバーにブランチ戦略を説明して開発フローのコンセンサスをチームで固める事は大事だが、
それは入社時のトレーニング、PullRequestのレビューコメントなりその都度口頭でやりとりすれば済む話だと思う。
わざわざ全員の時間を使っている会議で持ち出して真面目に議論するに値する内容なのか?
「新メンバーが誤ってPullRequestの送信先を誤ってしまう環境が、そもそもチームとして問題があるのでは?」などのレトリックが現れるなり、
CIAの「Simple Sabotage Field Manual」を思い出し心の中でため息をつく。

CIAが敵の組織を破滅に追いやるために潜入スパイに実行させた「愚者の心得」をまとめたマニュアル「Simple Sabotage Field Manual」 - GIGAZINE

私はこのような問題を回避するためのツールのはずが、理解不足のためツールに振り回され開発の本質がおなざりにされるケースが大嫌いだ。

ここから先は非常に私的な吐露であるが、
上記の例に限らず、現状のチームおいて議論を根本から再定義したいと感じる場面はしばしばある。

一方的に議論を断ち切るのはたとえ自分の主張が正論であったとしてもチームの雰囲気が険悪になるデメリットの方が大きいように思えるし、
心底不毛だなと愛想を尽かしながら黙っているのも非常にストレスフル。
かといって湧き上がるフラストレーションを内部に隠蔽し、やんわりと指摘出来るような性格ではない。

今回のケースでは

  • そういう議論をしなくても済むようにgitを使ってるんじゃないの?
  • そんな分かりきった事も分からずにgitを使っているの?
  • 何のためのgitなの?
  • もっと開発・ビジネスの本質的な部分に時間割こうよ

というフラストレーションは客観的に見ても正当であるという認識が拭えない。

部署には私よりもずっと業務能力が高い人たちが多いと思われるが、

  • その業務はいつまで持つのか?
  • 顧客を快適にするのか?
  • 会社の方向性と自分の熱量の交差比率から見て、両者の利得が最大になるポイントは何処なのか?

など「会社とは材・サービスを提供し対価を頂く組織」であるというビジネス的にシンプルで高レイヤな視点をどれだけ普段の業務に据えられているのかはやや懐疑的なので、個人的にチームとして歩調を合わせようとは思えない。

blog.yamotty.com

このようなマインドを持っている者がチームメンバーとして在籍する事が良い方向に作用するとは思えないし、

現職にJOINする当初お話を受けた時のように、

  • 会社がビジネスをスケール・継続させる上で技術的課題を抱えている
  • 私が専門的スキルを提供し、技術的支援を行う

チームを抜けてこれだけの、 会社 のシンプルな関係に戻りたい。
違うチームだけど、同じ目的のため協調する関係がベストだと感じている。

会社は好きだし、意欲的な仕事が出来る環境であると思っている。