Runner in the High

技術のことをかくこころみ

大きなリリースをするべきではない4つの理由

自戒を込めてメモ

大きなリリースはバグを増やす

大きなリリースになればなるほど、コードベースに潜むバグが増える。充分なテストがないチームでは、コードレビューにテスト相当のタスクが求められるようになり、本質的な設計の優先度は低くなる。結果として、長期的に見たコードの品質は落ち、よりバギーなコードが生まれやすくなる。

また、大きなリリースでは変更があまりに多すぎるため、バグの特定が困難になる。それどころか、見過ごされるバグが生まれ、顧客に届く価値は不完全なものになる。

大きなリリースはロールバックを難しくする

大きなリリースはロールバックも大変になる。下手するとロールバックすらできない。大きなリリースは戦艦建造のようなもの。戦艦はデカい巨体を地上で組み上げてそれをいっきに海へ浮かべる。海から地上へは戻せない。でも、ソフトウェアは戦艦の建造とは異なり、大抵の場合プログレッシブにやれる。

小さくプログレッシブに機能をリリースできるチームは挑戦的になれる。問題が起きても場合やり直しが容易であり、ひとつのリリースに多くのものを詰め込む必要がないことで余裕を持って品質の高いに開発の計画を立てられる。

大きなリリースはチームにプレッシャーをかける

リリースが少ないチームは絶対に納期を守らねばならないというプレッシャーをかけられている。なぜなら、そのリリースを逃せば次のリリースはずっと先になるから。

開発チームとしては体裁を保つためにリリースでは絶対に成果をださねばならない。先送りはできないというプレッシャーをかけられる。プレッシャーをかけられた開発チームは毎日遅くまで残業することになる

大きなリリースは仕様を不完全なものにする

大きなリリースでギリギリになって仕様の漏れが発覚しても、自分がリリースの遅れ引き起こす要因になることを恐れてメンバは仕様忘れをひた隠しにする。ドキュメントの欠落などで、もともとあるはずだったものが消え失せることもある。

度重なるリリースの遅延により、必要とされていた仕様が不要になってしまうことすらもある。その結果、顧客に届く価値は全く意味のないものになる。

ソーラーパフミニが被災したときに便利だった

先日9/9に、千葉県広域で大規模な停電があり、自分の家も約一日にわたって電気が使えない状況になった。我が家は自分とおじいちゃん&おばあちゃんで生活しているが、真夏30度のなか暗闇とともに生活をするのはなかなかにしんどいものがある。

そのときにとても役に立ったのが、このソーラーパフミニという製品で、簡単に言うと折り紙のようにたたんで持ち運び可能&ソーラー発電式可能な発色の優しいウォームライト。

これのいいところは、まず光がすごく優しいので、電球やロウソクと比べて暗闇の中で目が痛くなるようなことがない。それに、停電の際にはあまり火を使いたくない(火災に繋がる危険があり、暗闇で燃え広がると大変な事故になる可能性もある)ので、このような蓄電で動くライトは非常に助かる。

今回、まったく蓄電などの準備していない状態でいきなり使ったのだが、まったく遜色なく動いてくれてすごく助かった。一度しっかりと光の下で充電しておけば、二晩くらいは余裕でもつんじゃないかと思う。

続・最近読んだ太平洋戦争に関する本4選

この記事の続編(?)

izumisy-tech.hatenablog.com

深海の使者

ノンフィクション・ドキュメンタリーの大御所、吉村昭によって描かれる遣独潜水艦作戦のドキュメンタリー。

映画「ダンケルク」を見てから、船乗りから見る潜水艦というのはめちゃくちゃ怖いものなんだというイメージを持っていたが、一方で潜水艦に乗る人間もまた異常な緊張感に晒されながら生きていたということがよく分かる。

読んでいて自分も思わず息を止めてしまうような描写が多い。特に敵の多い海域で数時間も酸素交換せずに連続潜行をしたり、海上駆逐艦をやり過ごすために海底で息を潜めながらもジワジワと艦内の酸素が失われていく描写には、逃げ場のない空間特有の恐ろしさがある。

日本軍兵士―アジア・太平洋戦争の現実

太平洋戦争の日本兵がいかに劣悪な環境および装備で戦っていたかをひたすら紹介する本。

意外な事実だが、当時の日本兵は実際に敵兵に銃で撃たれたりする「戦死」よりも、環境からくる病死のほうが多かった。もちろん、兵士が病気になるということは、太平洋戦線の極限的な環境からは容易に想像できるものだが、ほとんどの場合、兵士に対する処置は場当たり的なものに終止するだけで、何かしらの恒久的対策は取られることがなかった。

戦場での病死意外にも、戦場におけるいじめ、自殺、上層部の混乱、覚せい剤の乱用、などなど様々なテーマで戦争という状況が生み出す地獄が、当時を生き延びた人の証言とともに描かれている。中でも個人的に恐ろしかったのは、海没死の章で紹介されていた水中爆傷。軍医の証言を読むだけでも恐ろしい。

ドキュメント戦艦大和

戦艦大和が撃沈される菊水作戦を描いた、生存者による証言ベースのノンフィクション・ドキュメンタリー。

筆者による描写は連合軍と日本海軍それぞれの記録に基づくものに限られ、それ以外の大半は実際の乗艦者及びパイロットによる記録、証言になっている。この本を読むと、日本海軍のトレードマーク的存在であったはずの戦艦大和が、取り回しのしづらいお荷物的兵器になっていた事実が分かる。まさか大和の最期が片道燃料のみの玉砕戦闘になるとは、作った当時は誰もが想像していなかっただろう。

また、なにより連合軍による爆雷撃が始まったあたりからの描写の激しさがハンパではない。恐ろしいほど細かい戦闘の描写が描かれていて、ただ読んでいるだけでも実際に自分が大和の乗組員にでもなったかのような気持ちになる。しかし、海の上で四方八方から攻撃を受けるというのは、その場にいれば本当に気が気ではなくなるだろう。

ミッドウェー戦記

元海軍軍人の作家、豊田穣によるミッドウェー海戦の戦史物語。ここまでの本の殆どがノンフィクション・ドキュメンタリーであったが、コチラの本はもう少し登場人物のフィクショナリ―感がある。

ミッドウェー海戦といえば前回の記事で紹介した失敗の本質でも触れられる旧日本軍の失敗作戦のひとつとして有名だが、この本ではそのミッドウェー海戦の前後含めてどのように実際の戦いが行われたかが描かれている。日本海軍が空母の艦載機を爆装に切り替えている最中に連合軍機動部隊から急襲を受けるあの混乱具合は、こちらでもしっかり描かれており、読んでいてこの部分に差し掛かるだけでも肝が冷える感覚を味わえる。

しかしながら、若干気になるのはこの本で描かれているもののどこまでが事実で、どこまでがフィクションなのかがいまいちぼんやりしていること。本の中で出てくる登場人物はどれもめちゃくちゃ饒舌だが、よくもまあここまで当時のことを覚えていられるなと。しかし戦争ほど強烈な経験をしたら、そうそう記憶が薄れるということもないのかもしれないが...

"Elm Meetup in Summer" を開催して登壇した

elm-jp.connpass.com

前回Elmのミートアップが最後に行われたのは1年以上前で、運営や会場の関係で長らくこのようなElmを愛する者達の交流会は開かれていなかったが、急遽弊社オヒスの大広間(?)を貸してElmエンジニアたちを集めてワイワイしようという運びとなった。CTOが食事を出す件も快諾してくれ、とても豪華なイベントになったのではないかなと思う。

このイベントに自分は開催前から当日まで大きく関わらせてもらったものの、人がたくさんあつまるイベントをオーガナイズするというのは人生で初めてと言ってもいい経験だった。参加者の方や、登壇者、運営のお手伝いをしてくれた方々には本当に感謝しかない。次回もこのようなミートアップを開催する折には、Elmコミュニティを盛り上げるようなすばらしいイベントにしたいという意気込みがある。

また、当日の盛り上がりはABさんの作ってくれたこのTogetterで見れる togetter.com

コミュニティのメンバ(そもそもメンバという概念はないが)である@y047akaさんがミートアップのためのステッカーを作ってきてくれた。まさかステッカーが作られるとは思ってなかったが、やはりこのような物理のグッズがあるというのはテンションがアガるものだ。

トークについて

自分はElmを最大限学ぶための資料をたくさん紹介する、という体のトークをした。

ちょっとElm界隈に詳しい人なら「そんなの知ってるよ」となってしまうような内容だったかもしれないが、参加者の方からは、少なからず知らないものがあったのでよかったというフィードバックを頂けて、このテーマでよかったなという気持ちになった。

新しい言語を学ぶにあたっては、やはり最初期のオンボーディング体験がすごく重要であると思う。オンボーディングがどのようなものだったかで、主観的な言語へのイメージというのは大きく変わるといってもよい。今回の僕のトークで、Elmに興味のある人たちがより多くのElmリソースに触れるきっかけになれば嬉しい。

なお、登壇資料の中で言及したNoRedInkのリチャードフェルドマンによるカンファレンスでのトークまとめは以下の記事になる。正直、どれも50分程度のキーノートかつ全英語なのでハードルは高いが、電子辞書片手にしても充分に見る価値がある。

izumisy-tech.hatenablog.com

余談

なお、弊社の会場からの眺めが非常に好評でよかった。

晴れた日は夕方とくにキレイで、状況によっては富士山も見える。最高のロケーションだ。

こうして個人的には楽しみな一方で心配も多かったElmミートアップの開催は幕を閉じた。

最初は30-40人程度集まれば充分だな〜と思っていたものが、フタを開けてみると応募の時点で100人超え、当日来場者でも70人ほどの比較的大きなイベントとなった。やはり、同じものが好きな人間同士であつまるイベントというのは楽しいし、イベントを通して様々な学びもあった。

今回のElmミートアップで感じたのは、やはりコミュニティの存在感というのはすごく重要なものであるなということ。Elmのコミュニティには、JavaScriptにはない独特の良さがある。これは自分がelm Europeで感じたのと同じものだし、それを日本でも感じられるというのはすごく幸せなことだ。これからも、少なからずElmという言語、そしてコミュニティに貢献していきたい。そう思えるようなミートアップであった。

労役をする側には前提として作業効率を改善するメリットがない

いくら効率を上げて作業量を減らしたとしても、労働者からすれば、減った分を補う余剰の仕事が増えていくだけ。うれしくなるのは経営者、マネージャ層だけであって、労役側は効率が上がることによるメリットをなにも享受しない。

できるだけ働きたくない

労働をする側が望むのは、ラクな仕事をダラダラやってできるだけ多く遊びの時間を作り、できるだけ早く帰ること。突き詰めれば、どれだけ仕事をせずにお金をもらうか。この点から見ると、効率をあげることで自分の仕事が増えるほうがリスクであり、積極的に効率が低い方式を採用するほうがメリットになる。効率化は労働をする側にとってはデメリットだ。

開発者で言えば、デプロイが遅ければそれを言い訳にコーヒーを飲みに行ったりネットサーフィンをしたりできる(この場合、並列で仕事をするなどの積極的労働はしない)が、これが早くなってしまうと、この「遊び」の時間が少なくなってしまう。デプロイが遅い、という事実が普通*1になれば「今日はデプロイだけの日にしましょう! 時間がかかるので^^;」と説得できる。その日はデプロイだけやって、一日おわり。あとは飲みにでも行って、さっさと帰って家で寝るとしよう。

最も大きな敵は、見返りもなにも求めずに積極的に改善活動を行う人間だ。このような「やる気のある人間」がいることで、相対的に怠けている人間が炙りだされることになる。組織全体がサボタージュに向かっている集団では、このような人間は積極的に排除されていく。

労働者と経営者的観点

このような見えないサボタージュを続けられてしまうと会社は非常に困る。会社からすれば、できるだけ人件費あたりの生産効率を良くしたい。そのためには、誰かが効率改善をする必要がある。だが、現実的な改善活動を経営者やマネージャだけが行うのは難しい。改善というのは前線で手を動かして働く人間だからこそ分かる不満から生まれうるものであるし、労働者以外の人間から思いつく改善というのは微妙なものも多い。

結局、一般的に労働者がよく言われる「経営者的観点を持て」というのはこれを指すことが多い。ただ言われたことをするだけではなく、労働者が自ら全体効率を改善することで企業の利益アップにつながっていくことを経営者は望んでいる。だが、多くの場合一ミリも理解されずに終わる。

できるだけ働かずにお金をもらいたい労働者と、できるだけ人件費をゼロに近づけたい経営者。このパレート効率的関係を改善することで会社は成長する。

労働者は効率を改善するのか

はなから仕事をする気がない人間というのはここでは論外とする。しかし、会社の成長が自分の利益に直結するということが学習されると「自らが会社を成長させるんだ」と意気込む労働者は少なくない。彼らは会社や経営者を信じているし、自分たちの労働で会社が大きくなることを喜ぶ。会社を経営する側からすれば、こうした人間を積極的に採用したいし、それ以外の人間はできるだけ重要なポジションから排除したい。

つまり、経営者には労働者の自己効力感を養うことが求められる。自分たちの手で会社が成長している、そして自分の利益にもなっているんだ、という実感を労働者に与えること。

こうして初めて、労働者が経営の目を持ち始める。

*1:CDフローの改善なんて、世の中にある数パーセントのイケイケスタートアップだけがやっていることで、我々はそんなことをする必要がないんだぞ、と。