Magnolia Tech

いつもコードのことばかり考えている人のために。

USB Type-Cケーブルは迷わず『⚡︎3』刻印入りのThunderbolt 3ケーブルを買おう

USB規格のケーブル、どれもコネクタ部分にサポートしてる規格を刻印してないから、後から何が何だか分からなくなっちゃうけど、Thunderbolt 3ケーブルは何故か規格を刻印してる製品が多いので(全部じゃないけど)、後から区別できるところが良いところ。

なので…

Thunderbolt3にしておけばUSB3.1にも対応してるし、ディスプレイ接続にも使えるし、USB PDの給電も100Wまでいけるし、迷う要素が無い。

たいていのソフトウェア開発の方法論や、機能は、「用法用量を守って正しくお使いください」に行き着くよね

ちゃんとわきまえてるけど、そこに関心量を向けたくないから機能や方法論で縛っておいてほしい話と、用法用量が守れないメンバーがいるので強制力を持たせたい人の会話がすれ違ってることが多い気がするんだよね…

そこにさらにもっと開発者を信頼すべきだ的な論調が混じると、まぁみんな自分が直面してる課題は違うので…という当たり障りのない結論になってしまったりして世界は難しいし、分断されてるんだ。

10年目の『アジャイルサムライ』を読んで見たら前半はアジャイルというより、普遍的なソフトウェア開発のノウハウの話だった

本棚から発掘した『アジャイルサムライ』を久しぶりに読み返した。

同じ著者による『ユニコーン企業のひみつ』が話題になっていたから…というわけでもないけど、たまたま最初に読んだ時以来読み返していなかったなーと思って。

blog.magnolia.tech

原著は2010年出版、翻訳も2011年に出版されているので、もう10年経っている。その元となるアジャイルマニフェストが2001年の発表なので、20年経っていることになっている。

agilemanifesto.org

たぶんこの10年でもインフラとしてのクラウドの利用や、企業活動におけるソフトウェアの重要性の高まり、またそれを契機としたソフトウェア開発の内製化への回帰…いろいろな要素がアジャイル向きの環境に変わっていってきている。

企業活動とソフトウェア開発が不可分になれば、それはもうプロジェクトではない。プロジェクトは有期であることがその定義だが、企業活動は(一般的には)無期だからだ。

従来のOA化や、業務改善であれば切れ目も作れるか、企業活動に切れ目は無い。ずっと続けていかないといけないし、その中で変化していくことが求められる…それが早いか、遅いかは業務特性に依るが、その活動をスケールさせるためのソフトウェアの変化も、そのスピード感に依っているわけで。

アジャイルウォーターフォールという対立軸で見てしまうと、それは違うと思っていて、要は自分たちが必要としている要素に合致しているか否かじゃないかと思っている。

で、そんなことを考えながら『アジャイルサムライ』を読み直してみると、前半がもう全然アジャイルに固有ではない、普遍的なソフトウェア開発のノウハウの話だった

ウォータフォールだったら開発チームに権限はなくてもいいとか、チーム間は縦割りでもいいとか、顧客は参加しなくていいとか、自己組織化されていなくていいとか、メンバはプロフェッショナルでなくてもいいとか、熱意はなくてもいいとか、そんなことを言う人はいないと思うんですよね。プロジェクトスタイルの方法論ではなく、プロジェクト運営の問題をウォータフォールというラベルで代用していませんか?という話で(というか、この本の中でもべつにウォータフォール批判はされていないんですよね)。


というわけで、自分のプロジェクトがアジャイルかどうかは関係なく、読んでみるといいなと思います。後半はよりアジャイル向きのプラクティスになっていきます。

とはいえ、プロジェクトの可視化、テストコード、リファクタリング継続的インテグレーションなどは、アジャイルとは切り離しても有効なプラクティスになってきているので、実質は「第8章アジャイルな計画づくり:現実と向きあう」と、「第9章イテレーションの運営:実現させる」「第10章アジャイルな意思疎通の作戦」くらいだったりしますが。

あと、なんとなくですけど、あんまりこの本で語られているアジャイルって、自社サービスというより、コンサルティング会社やSIerみたいな、業態が受託でソフトウェアを作るシチュエーションが暗黙の前提になっているなーって感じました。同じ会社に居るプロダクトオーナーが非協力だったら、そもそも事業を運営する体裁が整っていないだけかなと。その辺は実は自社サービスのアジャイルは、また違うような気もします(よくアジャイルは自社開発じゃないと無理みたいな論調もありますが、そうとも限らないと、この本を読んで思いました)。


なお、この本でぜひ読んで欲しいところといえば「5.4 何を諦めるのかをはっきりさせる」です。

最近有名な「荒ぶる四天王」こと、「時間」「予算」「品質」「スコープ」のトレードオフについての話題です。

はるか昔、とある方に「我々は、”まだどのくらい品質を落とせば、どのくらいコストが落とせるか”、という相関関係をコントロールできるような技術は持っていない」と言われたことが強く記憶に残っていて、この本でも書かれている通り、品質は高い水準で維持するしかないんです。

バグの数を5%増やせば、コストが10%低下する、その際の事業リスクは最大で10万ドルです、みたいな計算式は作れないのです。


最後に、昔オンプレ主体の時代だと、そもそもインフラの購入・設置・構築にすごく期間がかかり、その前段のアーキテクチャ検討も含めてプロジェクトスケジュールの基礎がそこに依存していたプロジェクトも多かったと思うんですけど、そんな時代のアジャイルはどんな風景だったんでしょうね。イテレーションゼロの時点でどこまでインフラを揃えていたんでしょうね。ちょっと実体験をしていた方々に聞いてみたいところです。


というわけで10年経っても色褪せない名著なので、未読の方はぜひ読んだ方がいいですよ。きっとあと10年後でも役に立っていると思える1冊です。

『ハンズオンNode.js』、みっちり詰まっている一冊

ハンズオンNode.js

ハンズオンNode.js

  • 作者:今村 謙士
  • 発売日: 2020/11/17
  • メディア: 単行本(ソフトカバー)

GWはJavaScriptを学び直そうと思って、『ハンズオンNode.js』を買ってきた。

なんかもうみっちり詰まってて、サーバサイドのJavaScriptを学ぶにはいい感じの密度と、リズムだなって。

あと、表紙が好き。

一貫性…長くメンテナンスをするために、大事なこと

blog.magnolia.tech

昨日のエントリーは随分たくさんの方の共感を得られたようです。みんな頑張っていきたいですね!

そのあと考えてみたのですが、エラー処理と並んで大切なことに「一貫性」があるのではないかと思い至りました。

保守するにしろ機能改修にしろ、内容を素早くざっと把握するためには全部を見てるとキリが無いので、驚きを最小にするためにも一貫性が保たれていることが作られた時点で保証されてると安心できますね。

運用に耐えられるコードを書くために

『ユニコーン企業のひみつ』を読んだけど、ひみつは書かれてたっけ?と思ってしまった

たぶんこの本の一番間違った使い方は、エライ人が読んで「よし、うちもこんな組織運営に変えるぞ!」って言い出すことなんじゃないかなって。

まずは、「メンバを信頼し、権限・裁量を与えても大丈夫な組織に変えていくために何をやるか?」から考えていくところが出発点ではないでしょうか。そういう意味では、そこはこれまでも散々語られてきたことなので、「ひみつ」なのかなーとまず思ってしまいました…(だからと言って、本書の価値が低いわけでは無いですよ)

あと、この本で頻繁に出てくる「プロジェクトでは◯◯はやらない」「エンタープライズ企業では□□はできていない」みたいな言説は、割り引いて読んでおいた方がいいかな。


結局、冒頭ででてくる、以下の言葉を鵜呑みにし過ぎない、ってことが大事だし、案外一番重要なのは「訳者あとがき』に書かれている、その後のSpotifyの組織変遷だったり、Spotifyモデルに対する評価だったりするのかも。

今どきのテック系ユニコーン企業のソフトウェア開発はこれまでとは別物だ。書籍に書かれているようなアジャイルなんてやっていない。もちろんスクラムもだ。ユニコーン企業のやり方はもう全然違っている。なんだかうまいことやっていて、スタータアップみたいな働き方で、エンタープライズ企業みたいなスケールを達成しているんだ。

そういう意味でも和書で読むことをお勧めします。


あとはコレに尽きる気もするけどね。

というわけで、次は『アジャイルサムライ』を読み直します。


追記

大事なことを書くのを忘れてた