読者です 読者をやめる 読者になる 読者になる

Best effort JavaScript

×article ○weblog

ツールに振り回されない

work

最近読んだ本によると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する当初お話を受けた時のように、

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

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

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

「レガシーソフトウェア改善ガイド」読書会 #1

work

今週から会社で読書会を始めました。(毎週水曜1時間)
現状定期的な読書会はなく、以前不定期にやっていた読書会はしっかりと議論する、本を持っていない人に印刷して配る、などのコストが高かったためか自然消滅していまいました。

電子書籍をプロジェクターに映して本を持っていない人も準備不要、
VOYAGEさんの読書会を参考に、作業しながら聞きが出来るようになスタイルで業務の負担にならず継続出来ることをコンセプトにしています。

techlog.voyagegroup.com

今回は 前書き から 位置No.556 知識の孤立 まで進みました。

印象に残った箇所

レガシープロジェクトとはなにか

  • レガシーコードはあなたが最初にHello Worldを書いた時よりも前から製品化され、もう何十人もの開発者が入れ替わり立ち代り保守している
  • 「レガシー」の定義は保守または拡張が困難なプロジェクト
  • 何世代かのメンテナが交代することによってシステム元来の設計や前のメンテナの意図に関する知識も失われる
  • コードが多ければバグも多い。新しい変更によってリグレッションを引き起こす可能性も高い
  • 優れたテストスイートは事実上のドキュメンテーションとして機能する
  • 「完璧なものは十分に良いものの敵だ」けれどもそういう次善の策をプロジェクトに追加する場合はあとで時間があるとき、そのコードを見直してクリーンアップすることを、必ず計画に入れるべき
  • 一時的な、あるいはハックのようなソリューションは、どれも製品全体の品質を低下させ、将来の仕事を困難にする
  • それがあまりにも多くなったらいつかはプロジェクトの進行が停止してしまう

レガシーカルチャー

  • 変化が怖い
    • どの機能なら、もう使われていないので安全に削除できるか?
    • どのバグならば修正しても安全なのだろうか?
    • 振る舞いを変更する前に、どのユーザーに問い合わせる必要があるだろうか?
  • こういう情報が欠如しているので、多くのチームは現状を最も安全な選択肢として尊重するようになり、ソフトウエアに「不必要な変更」を加えることを恐れるようになってしまう
  • どのような変更も、まったくのリスクとみなされ、変更によって利益が得られる可能性は無視される
  • このためプロジェクトは進展のない沈滞の状態に陥り、開発者は現状を維持することに精力を注ぎ込み、まるで琥珀の塊に封じ込められた蚊のように、ソフトウエアをあらゆる外敵影響から保護しようとする
  • 彼らがリスクを嫌悪するあまりソフトウェアの進化を許さないために、彼らの組織が競合他者に遅れを取るという非常に大きなリスクにさらされることが多い
  • もし他社が新しい機能をあなたの組織より早く追加することができるのなら、彼らがあなたの組織から顧客と市場を奪い取るまで、あまり時間がかからない