USB Type-Cケーブルは迷わず『⚡︎3』刻印入りのThunderbolt 3ケーブルを買おう
なので…
Type-Cケーブルは迷わずThunderbolt3ケーブルを買っておけ派ですが、理由はけっこうな確率でコネクタに「⚡︎ 3」って印字されてて規格が確認し易いからです
— magnoliak🍧 (@magnolia_k_) 2021年5月30日
USB規格のケーブルではこうはいかないです
「Type-Cケーブルは迷わずThunderbolt3ケーブルを買え」
「でも充電専用ならUSB 2.0、3Aを買え」
USB3.1、USB PD 5A対応ケーブルと比較すると800円〜1000円とか高いものもある(そこまで高くないものもある)けど、あの規格の刻印さえ有れば確実に分かる安心感を考えると、刻印代と言ってもいいくらいの価値がある
— magnoliak🍧 (@magnolia_k_) 2021年5月30日
(そして今規格の分からないケーブルが目の前に…)
Thunderbolt3にしておけばUSB3.1にも対応してるし、ディスプレイ接続にも使えるし、USB PDの給電も100Wまでいけるし、迷う要素が無い。
たいていのソフトウェア開発の方法論や、機能は、「用法用量を守って正しくお使いください」に行き着くよね
たいていのソフトウェア開発の方法論や、機能は、「用法用量を守って正しくお使いください」に行き着くよね
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
でもなー、用法容量を守らないで痛い目に合わないと分かんないんだよなーって側面もある
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
個人的なコードで、何度も書いては捨て、書いては捨て、みたいなのを繰り返したらいいけど、みんなそういうことができるわけじゃないしね https://t.co/YCCEscOjWB
ちゃんとわきまえてるけど、そこに関心量を向けたくないから機能や方法論で縛っておいてほしい話と、用法用量が守れないメンバーがいるので強制力を持たせたい人の会話がすれ違ってることが多い気がするんだよね…
そこにさらにもっと開発者を信頼すべきだ的な論調が混じると、まぁみんな自分が直面してる課題は違うので…という当たり障りのない結論になってしまったりして世界は難しいし、分断されてるんだ。
10年目の『アジャイルサムライ』を読んで見たら前半はアジャイルというより、普遍的なソフトウェア開発のノウハウの話だった
- 作者:JonathanRasmusson,西村直人,角谷信太郎
- 発売日: 2017/07/14
- メディア: Kindle版
本棚から発掘した『アジャイルサムライ』を久しぶりに読み返した。
同じ著者による『ユニコーン企業のひみつ』が話題になっていたから…というわけでもないけど、たまたま最初に読んだ時以来読み返していなかったなーと思って。
原著は2010年出版、翻訳も2011年に出版されているので、もう10年経っている。その元となるアジャイルマニフェストが2001年の発表なので、20年経っていることになっている。
たぶんこの10年でもインフラとしてのクラウドの利用や、企業活動におけるソフトウェアの重要性の高まり、またそれを契機としたソフトウェア開発の内製化への回帰…いろいろな要素がアジャイル向きの環境に変わっていってきている。
結局SoE型のシステムが増えてきていて、プロジェクトって形で明確な切れ目を定義するのが難しくなってるんですよね。プロダクトとして仮説検証という方向がやはり増えてきてはいるので。
— カルロスわらふじ@牛勢 (@RyoMa_0923) May 9, 2021
企業活動とソフトウェア開発が不可分になれば、それはもうプロジェクトではない。プロジェクトは有期であることがその定義だが、企業活動は(一般的には)無期だからだ。
従来のOA化や、業務改善であれば切れ目も作れるか、企業活動に切れ目は無い。ずっと続けていかないといけないし、その中で変化していくことが求められる…それが早いか、遅いかは業務特性に依るが、その活動をスケールさせるためのソフトウェアの変化も、そのスピード感に依っているわけで。
アジャイル対ウォーターフォールという対立軸で見てしまうと、それは違うと思っていて、要は自分たちが必要としている要素に合致しているか否かじゃないかと思っている。
で、そんなことを考えながら『アジャイルサムライ』を読み直してみると、前半がもう全然アジャイルに固有ではない、普遍的なソフトウェア開発のノウハウの話だった
『アジャイルサムライ』を読み直しているけど、前半はほとんどアジャイルは関係無くて、普遍的な「ソフトウェア開発を成功させるための要素」が書かれている
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
仮に、『できる!ウォーターフォール開発」って本が書かれても前半はほぼ同じになると思うんだけど
ウォーターフォールは計画の変更に関わるコストが大きくなりがち(ドキュメントなど付帯成果物が多い)、そのコストを細切れにしてリスクを小さくして、変更・手戻りと見せないところにアジャイルのポイントがあるわけでは
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
権限が適切に委譲されてて、メンバが自律した自走組織を形成していて、顧客がしっかり参加していて、計画変更が折り込まれていて…そりゃ成功するよね!! https://t.co/yxfqQCCioh
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
ウォータフォールだったら開発チームに権限はなくてもいいとか、チーム間は縦割りでもいいとか、顧客は参加しなくていいとか、自己組織化されていなくていいとか、メンバはプロフェッショナルでなくてもいいとか、熱意はなくてもいいとか、そんなことを言う人はいないと思うんですよね。プロジェクトスタイルの方法論ではなく、プロジェクト運営の問題をウォータフォールというラベルで代用していませんか?という話で(というか、この本の中でもべつにウォータフォール批判はされていないんですよね)。
というわけで、自分のプロジェクトがアジャイルかどうかは関係なく、読んでみるといいなと思います。後半はよりアジャイル向きのプラクティスになっていきます。
とはいえ、プロジェクトの可視化、テストコード、リファクタリング、継続的インテグレーションなどは、アジャイルとは切り離しても有効なプラクティスになってきているので、実質は「第8章アジャイルな計画づくり:現実と向きあう」と、「第9章イテレーションの運営:実現させる」「第10章アジャイルな意思疎通の作戦」くらいだったりしますが。
あと、なんとなくですけど、あんまりこの本で語られているアジャイルって、自社サービスというより、コンサルティング会社やSIerみたいな、業態が受託でソフトウェアを作るシチュエーションが暗黙の前提になっているなーって感じました。同じ会社に居るプロダクトオーナーが非協力だったら、そもそも事業を運営する体裁が整っていないだけかなと。その辺は実は自社サービスのアジャイルは、また違うような気もします(よくアジャイルは自社開発じゃないと無理みたいな論調もありますが、そうとも限らないと、この本を読んで思いました)。
なお、この本でぜひ読んで欲しいところといえば「5.4 何を諦めるのかをはっきりさせる」です。
最近有名な「荒ぶる四天王」こと、「時間」「予算」「品質」「スコープ」のトレードオフについての話題です。
はるか昔、とある方に「我々は、”まだどのくらい品質を落とせば、どのくらいコストが落とせるか”、という相関関係をコントロールできるような技術は持っていない」と言われたことが強く記憶に残っていて、この本でも書かれている通り、品質は高い水準で維持するしかないんです。
バグの数を5%増やせば、コストが10%低下する、その際の事業リスクは最大で10万ドルです、みたいな計算式は作れないのです。
最後に、昔オンプレ主体の時代だと、そもそもインフラの購入・設置・構築にすごく期間がかかり、その前段のアーキテクチャ検討も含めてプロジェクトスケジュールの基礎がそこに依存していたプロジェクトも多かったと思うんですけど、そんな時代のアジャイルはどんな風景だったんでしょうね。イテレーションゼロの時点でどこまでインフラを揃えていたんでしょうね。ちょっと実体験をしていた方々に聞いてみたいところです。
というわけで10年経っても色褪せない名著なので、未読の方はぜひ読んだ方がいいですよ。きっとあと10年後でも役に立っていると思える1冊です。
『ハンズオンNode.js』、みっちり詰まっている一冊
- 作者:今村 謙士
- 発売日: 2020/11/17
- メディア: 単行本(ソフトカバー)
GWはJavaScriptを学び直そうと思って、『ハンズオンNode.js』を買ってきた。
なんかもうみっちり詰まってて、サーバサイドのJavaScriptを学ぶにはいい感じの密度と、リズムだなって。
あと、表紙が好き。
一貫性…長くメンテナンスをするために、大事なこと
昨日のエントリーは随分たくさんの方の共感を得られたようです。みんな頑張っていきたいですね!
そのあと考えてみたのですが、エラー処理と並んで大切なことに「一貫性」があるのではないかと思い至りました。
保守するにしろ機能改修にしろ、内容を素早くざっと把握するためには全部を見てるとキリが無いので、驚きを最小にするためにも一貫性が保たれていることが作られた時点で保証されてると安心できますね。
一貫性!一貫性!一貫性!
— magnoliak🍧 (@magnolia_k_) 2021年5月6日
あっちはこう、こっちはこう、じゃなくて、まずは一貫性!
業務要件でもアーキテクチャ設計でも、一貫性が貫かれていれば「こうなっているはず」が効いて、スピードが上がる
もう一回言うけど、一貫性は超大事!
いいこと考えた!の前に、既存との整合性、一貫性を考えよう!
もうみんなコードの記述スタイルでいちいち議論するより一貫性が担保されてることの方が大事だって学んだじゃないですか
— magnoliak🍧 (@magnolia_k_) 2021年5月6日
アーキテクチャだって業務要件だって、まずはプロジェクトとしての原理原則、方針が決まっていて、それぞれの設計は特別の理由がない限り、それに沿ってる一貫性の有る状態を作る https://t.co/tmyiTEOrFe
運用に耐えられるコードを書くために
オブジェクト指向とか、DDDとか言う前に、「落ちる時は速やかに落ちる」「原因がきちんと解析できる情報を出す」「リトライポイントが用意されている」「最終的な結果の正当性、整合性を確認する方法が用意されている」っていうコードをですね.... https://t.co/I5bIfhZYN8
— magnoliak🍧 (@magnolia_k_) 2021年5月3日
異常系への対処がちゃんとできているコードが書けるようになってこそ一人前、みたいな、そんな価値観
— magnoliak🍧 (@magnolia_k_) 2021年5月3日
いや、その手前の「つべこべ言わず、エラーが起きる可能性があるところは全てエラーコードをチェックする」なんだよ https://t.co/zmJBWR0ybX
— magnoliak🍧 (@magnolia_k_) 2021年5月3日