00:03
はい、5月7日日曜日ですね。時刻は朝9時15分になりました。
ゴールデンウィークも最終日というところで、まあゴールデンウィークっていうか普通に日曜日ですよね。
ゴールデンウィーク自体は金曜日までだと思うんですけど、まあまあ今日までが一応ゴールデンウィークと、世間いっぱいで多分言われるでしょうね。
はい、みなさんいかがでしたでしょうか。
なんかあいにくの東京の方は雨ですね。昨日からちょっと天気が崩れ始めてて、今日はやっぱり雨降り始めちゃったなって感じですけどね。
はい、まあ月曜日仕事の前の最後の日曜日ですね。ゆっくり休んでいただければと思いますが。
ではでは早速入っていきましょうかね。おはようございます。
イメミドッキー、ヒースコドクワハラです。
それでは本日の朝活を始めていきたいと思います。
えー本日はですけれども、ちょっと時間がやっぱりスタートが毎回毎回遅くなってしまったので、
要は短めの記事ですね、ちょっと読んでいこうかなと思っております。
タイトルにあります、「Steel threads are a technique that will make you a better engineer」という記事ですね。
まあなんかエンジニアのあり方みたいな記事だったと予想しながらですけど、ちょっと読んでいこうかなと思っております。
はーい。
では早速入りましょう。
スチールスレッドっていうのは強力でありながら無名のソフトウェアの設計手法ですと。
あ、設計の話なんですね。
スチールスレッドについて学ぶことで、あなたはより良いエンジニアになれます。
スチールスレッドを使うことで、統合の問題などよくある問題を回避することができます。
またシステム設計の複雑さを解消するために使用することもできますと。
っていうのが一応冒頭の話でした。
僕はそのスチールスレッドっていうのは全然知らない設計手法なんで、
そもそもこの記事のタイトル見たときになんじゃこれってなって、
今日は読んでいこうと思った次第なんですよね。
まずは早速入っていきましょう。
2013年にウィキペディアで削除されたほどの無名なものだと。
スチールスレッドっていうのはどれくらい知られているのかと。
この概念は2013年にウィキペディアから削除されました。
このアイディアはソフトウェア工学の中で注目されるものではなく、注目すべきソースから大きなカバーを受けていないっていうのが大きな理由ですと。
カバレッジに加え、なぜそのような有用なアプローチであるか、その理由も含めてお話をしていきましょうと。
削除されたけど、この筆者の方は有用なアプローチだというふうに思っているので、今回は改めてアピールをしたいということですね。
じゃあスチールスレッドってなんでしょうかってことですけど、
スチールスレッドとはソフトウェアシステムを貫く機能の非常に薄いスライスのことですと。
ソフトウェアシステムの様々な部分を織り込み、重要なユースケースを実装するため、スレッドというふうに呼ばれます。
スレッドが後の改良のための強固な基礎となるためにスチールと呼ばれますと。
そういうことを表現したことなんですね。
スチールスレッドのアプローチでは、システムの境界を越えて重要なユースケースをカバーする最も薄いバージョンを構築するんですよと。
なんかアトミックデザイナーアトムズみたいな思想かなって、なんとなくちょっと聞いていいよねと思いました。
続いて従来の問題視されていたアプローチの例です。
例えばモノリシックなコードベースの一部を書き換えるために新しいサービスを構築するとします。
この場合最も一般的な方法は次のようになります。
合計6個になります。
1つ目が古いコードを見て新しいシステムの必要性を把握する。
03:02
2つ目に必要な機能を提供するAPIを設計し構築する。
3つ目に古いコードに入り新しいAPIを使うようにリファレンスを更新する。
それをフィーチャーフラグに隠れて行いましょう。
4つ目、機能フラグを使用してカットオーバーする。
5つ目、必要であればフィーチャーフラグをオフにし古いコードパスに戻ることもできます。
最後、6つ目ですけど安定したら古いコードパスを削除しましょうということですね。
まあという流れで基本的にはやっていきますと。
合理的に聞こえるでしょう。
しかしこの方法には多くの地雷がありますよっていうのでその地雷の話がここから続いていく感じですね。
このプロジェクトではどのような問題を予想されるでしょうかっていう話ですけど大きく2つあるらしいですね。
1つ目ですけど、旧システムと切り離した形で新サービスを構築するのは魅力的かもしれません。
何しろデザインはより純粋に感じられるかもしれません。
しかし構造的な変更を大幅に導入することになり、旧システムとの統合を一切行わずにこれらの変更を行うことになってしまいます。
これは統合の痛みを大きくします。
私の予想ではこのプロジェクトの見積もりは全て非現実的です。
そしてたとえ出来上がったサービスが一般的に良いデザインであったとしてもプロジェクトが完了した後は失敗とみなされることを期待します。
っていうのがまず1つ目でした。
2つ目は新システムの切り替えには問題があると思います。
切り替えの際に問題が次々と発覚し、古いコードのパスに戻したり、プロジェクトの最終段階で問題を解決するために集中的に作業する必要も出てくるでしょうと。
一応2つの問題があると思います。
いずれも大規模なカットオーバーを行わないことで回避できることですよと。
なお機能フラグで新サービスへのトラフィックを1%以上カットすることもカットオーバーのアプローチにはなります。
なぜでしょうか。
その1%のトラフィックを全ての変更点に同時にカットオーバーするんです。
やはりうまくいくとは思えませんね。
あなたは大きすぎるステップを踏んでいるんですよと。
ここが結論というか、この筆者の方の言いたいことの1つだということですよね。
要はデカすぎたものをデカいままでやってしまうというのが大きな問題だということですね。
かつデカいのに加えて、段階的ではないし、かつ完全に切り離してやるというのがその大きな問題だというふうにおっしゃっていますと。
それはあるかもしれないですね。
まあ移行作業も大変なので、どっかでいいやガツンとやるっていうやり方もわからないですよね。
ないし、僕も何度かやったことありますけど、経験もしましたけど、往々にしていろんな問題が発生しますね。
じゃあスチールスレッドを使用した例をお話ししていきましょう。
この方はスチールスレッドも経験されているということですね。
そのやり方とスチールスレッドのやり方を比較してみましょうと。
あなたが構築しようとしている新しいシステムについて考えてみてください。
システムにとって有用な機能は網羅しているが、全てのユースケースを扱えるわけではない。
あるいは何らかの制約があるなど、システムのスチールの意図を象徴するような狭いユースケースをいくつか思い浮かべてください。
続いて可能な限り狭い範囲で何らかの価値を提供するユースケースを選びます。
例えば新しいサービスの一部になると思われるAPIを一つ選ぶと良いでしょう。
続いてその新しいAPIを新しいサービスの中で構築をします。
06:01
その狭いユースケースのためだけにそれを機能させるんですよと。
それ以外のユースケースには従来のコードパスを使用します。
それを本番でフルに使えるようにしましょうと。
ヒントは新しいコードパスと古いコードパスの両方を行い比較することも可能です。
そして必要な機能を全て新しいサービスに移行するまで徐々にユースケースを追加していきます。
それぞれのユースケースは本番で使用しますと。
それが終わったら古いコードとフィーチャーフラグというのを取り去りますと。
常に新しいシステムで動いているんだからこれは全く危険なことではありません。
これはストロングラーというパターンでもあるんじゃないのっていう指摘ですね。
これはまさしくそうですね。
でもこれは新しいプロジェクトにももちろん使いやる。
グリーンフィールドの例についてこちらを読み下さいと別の記事のリンクが貼られています。
要は小さく作って小さく本番にリリースをしていってくださいと。
でちょっとずつ移行とか向き先を変えてくださいと。
何かあったら問題パスを戻せばいいだけですよねって話でした。
まあそうだよね。
では続いてCLスレッドのネジは統合の痛みを回避しよう。
より高い信頼性というのを提供しますというのが次のセクションですね。
プロジェクトのどたん場で問題が発生する大きな要因の一つが統合の痛みですと。
新しいシステムに切り替えたとき必ず予想外の問題が発生するものです。
これは本当そうだよね。
でカットオーバーともなるものは疑ってかかるべきでしょう。
物事は小刻みに進めます。
CLスレッドは最初から統合されているので統合のための多くの痛みを経験することはむしろないですと。
その代わりに小さな統合の痛みをずっと抱えていますと。
またサービス開始前にテストを行う必要はありません。
なぜならサービス開始までに段階的にテストを行うからですと。
本番の負荷に対応できることはわかっているはずです。
ネットワークのレイテンシーもその意味をするところは理解しているはずですと。
すべてのサプライズは前倒しされサービスを徐々に展開する方法の一部として段階的に処理されるんですよと。
重要なのは機能する統合されたシステムを持ちそれに取り組みながらそれを機能させ続けることです。
そして時間をかけてより良いものにしていくんですと。
CLスレッドというのは小さく作っても小さく本番リリースしてしまっていますので、
本番リリースするということは段階的にテストもやっているはずですし、
それも含めてパフォーマンスとかを実際の本番のシステムで見てみてみますので。
それが問題ないというところで本番前の従来の新しいシステムのときにやるようなことを最初から前倒しで小さく小さくやっているよというところですね。
テストをかけるコースとか回数もバンバン増えていくし、
それの修正というところのコースも増えるっちゃ増えるんですけど、
ただシステム以降のところのデカいペンよりは小さい方がいいんじゃないのっていう話は確かにあるなと思っていて、
それをこのCLスレッドという設計手法はやっているという感じですね。
では続いてCLスレッドの意図というのは複雑なものを切り開くのにも役立ちますという話でした。
システムを設計するときあなたは複雑なロットを持っています。
新しいシステムのための一連の要件を構築することは困難な取り組みとなります。
CLスレッドアプローチを使用すれば中核となる要件をいくつか選び、
09:00
それをシステムのレイヤーを切り裂くような形で表現し、設計を行使していきます。
これはシステム全体の骨格構造のようなものを提供します。
そしてそのCLスレッドの実装がさらなる要求を構築するための骨となります。
このようにCLスレッドはシステム要求事項のサブセットになると。
うーん、なるほどでした。
まあでもこれだけパッと読むと、要は小さく作っているだけに過ぎないと思ってたんですけど、
ちゃんとそのサブセットとしての役割っていうのも満たしているのは確かにいい話ではあるんですけど、
流度っていうのと、なんですかね、いわゆるチケットが増える気がしていて、
それの管理方法とかが逆に気になりますね。
どこまで細かくやるのかと、その管理コストの相談というかビジネスインパクトというと、
どこまであるのかっていうのがすごい気になってきますけど、
まあでも小さく作っていくってことは確かにいい話であるというか代わりはないし、
小さければ小さいほど問題が起きたときの原因特定だったりリカバリーも絶対早いので、
ほんとそれはいい話だなと思ってますね。
まあ最後その統合とか結合屋さんが出るかどうかっていうのはちょっと気になりますね。
小さくした分、どこまで把握できているかって結構大きな問題になると思いますので。
はいはい、では続いてSteel Thread次のセクションはですね、
Steel Threadというのはグリーンフィールド作品でも使用可能ですよっていう話です。
例えばスラックのクローンを実装しているとしましょう。
それは大変そうだな、まあ例えばですね。
最初のSteel Threadというのは以下のようなものになるでしょうと。
認証されていない人なら誰でもハードコードされたアカウントのジェネラルルームにメッセージを投稿することができます。
メッセージはページ更新後も持続すると。
この最初のSteel Threadがいかに限定できてあるかというとこに注目をしてみてください。
認証やユーザー、アカウントというのは使えません。
しかしメッセージの書き込みとそれを映像化する処理というのは行えます。
まあ本当に最低限の機能って感じですね。
この2つ目のSteel Threadはシステムより便利なものにするために動かすことができます。
例えばメッセージ投稿者が投稿する名前を選べるSteel Threadというのを用意することができます。
このSteel Threadというのは実は大したことはしてないんですよ。
認証もアカウントもユーザーという概念さえも実はまだないんですね。
しかしあなたは十分に機能するチャットルームを作ったのでそれを使い始めることができます。
またシステムのすべての部分にSteel Threadというのを通していないことにも注意してください。
しかしユーザーとアカウントという概念を切り離したことによってでもなります。
まあまあ最初のスタートとしてはそんなところだったんですね。
続いてSteel Threadによる早期フィードバックですね。
このSlack Chromeの例ではまだそこまで構築していないにも関わらず
構築中のシステムに対するフィードバックを早期に得ることができるということにも注目してください。
これもSteel Threadを使う強力な理由です。
この2つのスレッドだけであなたのチームはチャットルームをフルタイムで使い始めることができます。
このシステムを使うことでチームがどれだけ多くのことを学べるかということにも考えてみてください。
これは実用的なシステムなんですよ。
ユーザーとアカウントのシステムを構築し全てを接続し最後にチャットルームを構築するためにもなんだかと比較してください。
確かに本質的にはチャットができるというところが今回のSlack Chromeの本質ではあると思うので
そこに至るまでそしてユーザーが使ってそこのフィードバックを得て改善できるまでのスタートがかなり遅いですよね。
12:02
アカウントシステムをしっかり実装してユーザーの概念をしっかり実装して最後に接続テストしてでリリースするというよりも全然早いので
それはいい話だと思いますが
単純にスタートのスピードだけで考えると後からどんどん実装を加えるとなると初期の設計があまりにも考慮不足だったりすると
要は秘伝の垂れとかその上に乗っかってシステムを構築していかなきゃいけないので結局積み木みたいな感じですよねシステムって
でなると初期の設計がそこまで考えられてない場合はなんか闇をどんどん積んでいく気もしているので
なんか僕これ読んでるだけだとスチールスレッドだけだとあんまり良いのか本当に良いのかなっていうのがなんか僕は見えないなと思いましたね
まぁちょっとついでに読んでみましょうか
スタートウィズスチールスレッドなのでスチールスレッドから始めてみましょうという話です
スチールスレッドっていうのはプロジェクトを設計する際にしばしば良いスタートを切る場所となります
このスレッドはこれから行う作業の骨格を作るものになります
でシステムの核となる部分に釘を刺すことで自然に肉付けができるようになりますと
ぜひスチールスレッドのアプローチに挑戦してみてください
きっとあなたのプロジェクトに変化をもたらすことができると思いますし
あなたの経験談を逆に私は聞いてみたいと思いますと
でラストですねスチールスレッドと他のパターンの一応関連の話です
でスチールスレッドは特に新作で行う場合
トレーサーブレット
ダンですね弾の方です
トレーサーダンとも呼ばれたりしますと
でまたウォーキングスケルトンのアプローチとも呼ばれていたりします
あーね
でマイグレーションプロジェクトで使用する場合は
ストラングラフィーバターンと呼んだりしますとか
いろんな呼び方があるし文脈によって名前が変わるんですね
でスチールスレッドはパーチカルスライスと密接な関係がありますと
マイルストーンに関する投稿でその概念説明してますので
そのマイルストーンに関する記事も見てみてくださいと
でスチールスレッドはソフトウェアを垂直方向にスライスして提供する
ソフトウェア設計手法になりますと
でこの用語はシステムの最初の垂直スライスの説明するために使用される傾向があります
両者は密接に関連した概念ですが完全に同じものではないですよ
というので本記事は占められておりました
まあ一応スチールスレッドの画像的なものもこうペッと貼られておりますし
概略的な説明も以上は貼られてるんで興味ある人は見てみてくださいと
以上ちょっと短いですけどね本記事はいかがだったでしょうか
まあスチールスレッドっていうお話を
しかも本記事はですね今年の3月5日に改めてこの人は投稿してるので
気にはなりますけどスチールスレッドのやり方であったりとか
進め方パターン的なものとかマニュアル的なものが
もし何かあるんだったらそれ読んでみたいですね
今のところ概念の話しか説明されてなかったので
具体的にどうやって動いていくかっていうと
いつも通りのチケット駆動でやればいいじゃないっていう気が僕はしているのと
MVPを決めてそれを早いサイクル
いわゆるアジャイル的な開発でやればいいんじゃないのっていう話の
別名にしか聞こえなかったんですけど
やってないものに関して評価をしたりとか
何癖つけるのよろしくないと僕は思っているので
まずやってみたいと思いますが
でも具体的なやり方がわかんないので
15:01
やりようがないなっていうのが
ちょっと今面食らってる感じではありますね
もしご存知の方とかスチールスレッドっていうパターンを知ってる方
いらっしゃいましたら教えていただくとすごく嬉しいなと思います
はいちょっと他の記事のリンクも貼られてますし
その文脈的なところまで僕は理解してないまま
本記事だけを読んで今お話をしているので
他の記事リンク貼られてるのはざっと読みながら
改めて考えてみたいなとちょっと思いました
ので皆さんの方でも読んでいただければ幸いです
では短いですけど
今日の朝活は終了していきたいかなと思っております
今日は改めましてしゅうゆうせんさんと読み方合ってるか分かんないんですけど
Tゾウグさんって読むんですかね
ゾウグさんですかね
はいご参加いただきありがとうございました
まあ明日もですねまたなんか緩く記事読んでいきたいと思いますので
参加いただければ幸いです
ちょっと明日どうしようかな
なんか組織論とか採用回りの記事
ログミーの記事でちょっと読み溜めてるというか
to doに残したやつがあるので
その辺読んでいきたいかなと思ってます
まあちょっと日本語のインタビュー記事なので長いかもしれないですけど
というところでまた明日もですね読んでいきたいと思いますし
明日からまた仕事をスタートの皆さんが多いともいらっしゃいますと思うので
最後日曜日ですね
今日ゆっくり休んでいただければなと思います
それじゃあ朝活終了したいと思います
お疲れ様でした
