00:00
お疲れ様です。ゆるテク第12回を始めていきましょう。ソフトウェアエンジニアをやっている三長です。
はいお疲れ様です。ソフトウェアエンジニアをやっている博多家です。
よろしくお願いします。
よろしくお願いします。
はい、ということで第12回ですね。
はい、これは2023年の一発目ですね。
一発目良かったです。2023年もとりあえず始められることができて。
いやーもう一回でもやったので、これは目標達成ですね。
目標達成ですね。ゆるく進められそうですね。引き続き。
はい、じゃあ2023年一発目のテーマなんですけども、
今回はですね、私が年末年始、コロナにかかりながら読んだ
さらっと、はい。
継続的デリバリーのソフトウェア工学っていう本を読んだので、
ぜひそういう話を博多家さんとできたらいいなと思ってます。
はい、これは流行りの本ですね。
そうですね、最近だと結構あれですよね、読んだよーみたいなのがツイッターで流れたりとか
ブログ書かれてる方がいらっしゃったりって感じですよね。
そうですね。
じゃあ、私が気になった点とかを、今日2人で「こうじゃない」「ああじゃない」って話ができればいいかなと思ってるんですけども、
ひとまず、本当にざっくりとした全体的な感想を少し共有というか話をさせてもらうと、
なんとなく、特別真新しいものが紹介されている書籍ではなかったなっていうのはまず第一印象でした。
大体、聞いたことあるな、見たことあるなっていう話が多かったんですけど、
それがどこからのものなんだろうっていうのを、ちょっと自分の中で思い出してみると、
その「LeanとDevOpsの科学」っていう本と、
あと「Team Topology」っていう本と、
あとおそらく「エリック・エバンスのドメイン駆動設計」っていう3つの本で紹介されている内容を
おそらくだけど、筆者の実践経験をもとに点と点を線で繋いで説明しているような印象を受けた書籍です。
ちなみに明確に「ここはこの本からの引用です」みたいに書いてあるわけではなかったんですか?
引用ですっていうよりは、ここの本でもこう言われているようにみたいな表現はちょこちょこあってですね。
なので、引用といえば引用なのかもしれないですね。
じゃああれなんですね。よくあるように、本の最後に参考図書みたいな感じで書かれているよりは、
03:02
ちょっと強く、強めに関連性がありそう。
そうですね。あと「Accelerate」のDevOpsレポートとかもちょこちょこ引用されているような感じですかね。
なるほど、なるほど。なんかもう我々の大好物みたいな分野ですね。
そう、大好物みたいな分野。
なので、もしかすると一冊一冊を単独で読んだ時に、
なんとなくその点になっている知識がメインだったけど、
この本を読んでから読み直すと、
全体を通してこういうことを言ってたんだなとか、こういうところで使えるんだなっていう気づきは得られそうだなと思いました。
なるほど。
はい。あとこれはちょっと賛否両論というか、いろんな人の意見があるかもしれないんですけども、
私個人の感覚としては、DevOps、リーンとDevOpsの科学っていう話をさっきしたんですけど、
DevOpsって、なんとなくXPの後継というか進化系というか、進化系というと違うかもしれないんですけど、
XPの後継みたいなイメージを持っている人なので、私が。
なるほど。
なので、この本を読んでからXPを読み直しても、楽しいというか気づきが得られるんじゃないかなとも思っています。
なるほど。自分がアジアルとスクラムラ編から入った感じなんで、
実はXP、エクストリームプログラミングみたいな、その本自体も読んだことないですし、
そうなんですね。
そうなんです。ちゃんとした個々のプラクティスとかもよく知らない感じなんですよ。そんな感じなんですね。
なるほど。ぜひぜひ、読んだことない人とかがいれば、じゃあXPも読んでみようかなってなると、より楽しくなるのかなと思います。
読んでみよう。早速なりました。
ありがとうございます。っていうのがまず率直な感想で、その他の気づきというか、こういうことなんだなっていうのはやっぱり、
ソフトウェア工学という表現が本のタイトルにもあるので、ついついコーディングとか、技術的なプラクティスみたいな話によっていくものなのかなって思ってたんですけど、
案外そうじゃなくて、ソフトウェア工学という考え方って、組織論にもつながっていくんだよっていうような切り口でした。
今、博多家さんと見てる、私がまとめたやつを見ているんですけども、引用で一つ書いてるんですけど、
本書で私が工学という言葉を使うときは、特に限定しない限りソフトウェア政策に関わるすべてを指しているということ、
プロセス、ツール、文化、どれもそのすべてに含まれますっていう話があったので、
ソフトウェア工学って、作るとこだけじゃないよねっていうのが興味深かったです。
プロセス、ツールともかく文化も含まれる。
06:01
です。
はい。で、あと最後の感想として、これも個人の意見なんで何とも言えないんですけど、継続的デリバリーのソフトウェア工学っていう表現よりも、原初のモダンソフトウェアエンジニアリングの方が内容的にはしっくりきたなって思いました。
何かでも見たな、これ。確かに継続的デリバリーってつけなくていいっていうのは。
はい。というのも、これはもしかすると、私自身が継続的デリバリーっていう捉え方をすごい狂気な意味で捉えちゃってた。
なるほど。
例えば、分かんないですけど、継続的デリバリーってCI/CDのどこの話でしょ、みたいな。すごく狭い意味で捉えてしまったから、捉えてこの本に入ったから、全然継続的デリバリーだけの話じゃないじゃんってなったのかもしれないなって思ってます。
もっと広い意味での、何か分かんないけど、なんだろう。顧客に価値を継続的に届けるぐらいの意味だったら合ってるかも、みたいな。
そうですね。顧客に継続的に価値を届けるためのエンジニアリングってどういうことなの、どういうものなのっていう意味だと、そうかもってなります。
なるほど、なるほど。そういうことでは、じゃあいいのか。
はい。なので、この言葉の単語の意味をどう捉えてるかによって、結構入り口違うんだろうなって印象ですね。
確かに、完全に自分もそういう考えで見て、えーって思ってましたけど、そうなんですね。
ですです。というのが、簡単な全体の感想でしたと。
あとは、一部記憶に残っているところ、いくつか抜粋してきたんですけど、時間が許す限り紹介していきたいな、博多家さんと話したいなと思ってます。
はい。
全部で4部構成に分かれていて、一部がソフトウェア工学とは何ぞやって話で、2部が学びの最適化、3部が複雑さの管理、最後第4部がソフトウェア工学を支えるツールっていう4部構成なんですけど、
なんとなく、ここってさっき紹介した3冊の書籍でいうと、この本なのかなみたいなやつをカッコ書きで書いておきました。
はいはいはい。
全部全ての本のエッセンスは入ってるんですけど、特別ここの引用が多かったかなっていう印象で書いてます。
第1部、ソフトウェア工学とは何ぞやっていうところで、なんとなくここってLeanとDevOpsの科学の引用とかが多かったイメージ、あそこで言ってる話が中心っぽいなっていう感覚だったんですけど、
09:08
ちょっと面白かったのが、工学と工芸っていうお話が出てきていて、
別にどちらかを否定してどちらかを挙げるっていう話では全くなくて、工芸というものがものづくりに対して非常に重要なアプローチであるっていうことを、
こちらの本の中では紹介していて、
その文面としては職人の方が職人芸ですごく品質の高いものを作るとか、みたいな話が紹介されてたんですけど、
なんとなく三長の私の理解で、現場で言うと工芸になりそうなところってどういう話なんだろうみたいなことを考えてたんですけど、
なんとなくプロダクトとか開発現場特有の秘伝のたれテクニックみたいなものとか、
あとはクラフトマンシップにあふれるすごい尖ったエンジニアなのか、それ以外の役割の方かもしれないんですけど、
その方だけが出せるような個人レベルの個人スキルの成果みたいなものが、今の現場で言う工芸っぽいとこなのかなってちょっと思いました。
これ、現状とかだとなんとなんなんでしょうね。
ああ、現状。 アートとかそういう系なのかな。ちょっと見てみよう。 現状持ってたりします?
今一応出せるんで。 素晴らしい。 後で見てみようかな。
ぜひぜひ、もし何か出てきたら教えてください。 アートとかそういう系なのかな。
ああ、確かに。 確かに工芸の。 工芸ってなんだろう。
見てみますわ。 そういう感覚で私は捉えていて、
本の中で、とはいえ工芸には限界がありますみたいな。
その限界って何なのっていうところで言うと、
工芸で培ったとか、工芸で出せるような成果というか、ものって再現性とか、スケールを考えた時に大変じゃないですかみたいな話があったりとか、
常に一定の品質を保つのも大変ですよねっていうお話になってきました。
バラツキがだから出ちゃうってことですよね。 そうですね。バラツキもあるし、人によって違うから結局再現性もできないし、
12:05
スケールしようと思った時に同じ人集められるわけもないし、みたいなところなのかなと思ってて。
じゃあその工芸の限界って述べているところに対して、どういうふうに解決していけばいいんだろうっていうので、工学なんだよっていう入りでしたね。
はい、これはちょっと引用ですけど、じゃあその工学って何っていうところで、ソフトウェア工学とはソフトウェアの現実的な問題に対する効率的経済的な解を見つけるための経験的科学的なアプローチの応用のことである。
うん、なんか敵が多いって思う。 抽象的だな。
それを読んで、とりあえず捉え方として、個人の捉え方としては、おそらくというか、これってじゃあその作り方とか製造の仕方っていう、
手を動かすところの部分に対してフォーカスしてる話じゃなくて、それをどういうふうに構築していこうかっていう、その設計の部分に対する部分を科学していきましょうみたいな話をしてるんだろうなって思ってます。
なるほど、そういうことか。
個人的な解釈ですけど。
じゃあそういうことを科学していくために、ソフトウェア工学を実践するエンジニアってどうしなきゃいけないのかっていうと、学びのエキスパートにならないといけないし、複雑さの管理のエキスパートにならないと、それって難しいですよっていう流れでした。
複雑さ管理。
ここがちょっと新鮮だったんですけど、なんとなくエンジニアが何かやるときっていかにそれをシンプルにするかみたいなところも大事だとずっと考えていて、
なので基本シンプルにするってずっと考えてたんですけども、ただ実際マイクロサービスとか、マイクロサービスを開発するチームとかいろんなそういうものに携わってきて思うのは、
やっぱ一定の複雑性って、多分紐解くことって不可能なんだなって思ってて。
複雑なものは複雑なまま受け入れなければいけないことがあると。
そうですね。
なのでそういった面で、いかに複雑なものを低コストで効率的に管理できるのかっていうところが今度重要になってきて、
じゃあそういうことのエキスパートにならないとソフトウェア工学って実践できないんだよって話をしてるんだと思います。
15:03
なるほど。
なんとなく。
なんか繋がったというか、論士の展開というかは分かりました。
はい。というふうに私は捉えてますと。
で、いうのが一部でちょっとこう、なるほどな、そういう解釈なんだなって思ったところ。
で、そこからじゃあ学びのエキスパートってなんだよっていうのが第二部になってきてっていう感じで本が進んできますね。
はいはいはいはい。
はい。
で、じゃあその第二部の学びのエキスパート、学びの最適化っていう部分なんですけども、
これ多分博崎さんも何かしらで見たことがあるのかもしれないなって思ったのが、
学びについて大事な項目っていうのはこういうものなんだよっていうところで反復的な作業とかフィードバックとか、
前進主義、経験主義、実験主義が大事なんだよっていうのが紹介されてました。
はいはい。これはそうですね、アジャイルだとか、それ系の話ではもう、
よく見る気がするっていう。
そんな感じですね、インテレーションだし、フィードバックを得て、経験主義で。
そうそう。
久々にその前進とか経験とか実験とか見たので、ざっくり簡単に表現すると、前進主義ってとりあえずちょっとずつ進める系で、
なんとなく経験って実験のエビデンスに基づいて進める系で、実験は仮説立てて実際に実践してそれを分析する系みたいな感じで捉えてて、
実際確かにプロダクトとか回すときってこういうところがグラデーションして全部合わさってやってるものなんだなっていうのは感じますよね。
どれか一個が抜け落ちることもあんまりない気がしますよね。
そうですね。
なるほどな、そうだよなっていう解釈で、
詰まるとこ、ここで言いたいのって、
アジャイルとかXPの思想について述べてる印象だなっていうところ。
結構本の中で推してたのは、継続的デリバリーとか、継続的インテグレーションって表現は確か使ってなかったと思うんですけど、
継続的デリバリーでとにかく素早くフィードバック得ようよっていうところと、
あともう一つはTDDを使って素早くフィードバック得ようよっていう部分が結構印象的でした。
18:02
個別手法が出てきましたね。
TDDって、これは後になってですけど、ちょうど今年のRSGTに、
先週あったRSGTに参加してきたんですけど、
その中のDay1の基調講演で、
名前を忘れてしまいました。
デイビッド・バーンスタインさんか。
基調講演で、SCRUMでソフトウェアを構築するための5つのプラクティス、
っていうタイトルで基調講演してくださったんですけども、
とにかくその中でも、すごくTDDとかTest Firstを押してたなって印象があります。
なるほど。
とにかく好きなんだろうな、ことあるごとに出てくるなって思いました。
ファンなんでしょうね。
ファン、実践してきてる方なんでしょうからね。
というところで、TDDって結構私はテストっていうよりは、
どっちかというと設計のプラクティスに近い印象を持ってて、
そのTest FirstとかTDDをやって、
自分たちの設計がいけてるのかいけてないのか、
保守しやすいのかどうかみたいなフィードバックを、
とにかく早く得るんだよ、みたいな話なのかなって思ってます。
で、RSGTでもそんな話は出たし、
この継続的デリバリーソフトウェア工学の中でも出てきたので、
結構Test First、TDDって、
当たり前なプラクティスというか、
基礎的な部分になってくるのかな、
なってきたんだろうなって印象でしたね。
まだTest Firstできてないですってことは、
実際国内だと多いと思うんですけども、
割とブレることのない効果があるんだよっていうプラクティスの一つなんだなって印象でした。
なるほど。
これが、だから学びの最適化にはやっぱり、
素早くフィードバックを得ることが大事みたいな結論というか、
一番言いたいことはそんな感じですかね。
はい、私の解釈としてはそういう感じ。
で、なんちゃら主義っていう部分に関してはそこに対してどう進めるのか、
こういうふうにやっていくとかっていうところがもう少し詳細に書かれてるというか、
じゃあ実験主義やるときってこういう感じだよねとか、
っていう紹介があったりしますね。
なのでこの辺もどうでしょうね。
21:02
Lint DevOpsとかXPとか、
読んだことがある方、あるいはそのアジャイルな書籍、
何かしらこう読んだことがある方は、
「ああ、なんか聞いたことあるな」みたいな話が、
多いのかなと思いますね。
そうですね。フィードバック。
ちなみになんかこう振り返り的な話題ってあるんですか、これ。
どうだったかな、振り返り。
振り返りっていう表現は出てきてなかったと思うんですけど、
ただそのフィードバックから、
次を考えるっていう部分の要素自体が正直振り返りかなって思ってるんですよ。
振り返り自体も結局っていうとあれか、
データを集めてそれを分析というか分析して、
次どうしようかっていうのを考えるプロセスじゃないですか。
なのでフィードバックっていうデータを得られたときに、
次このフィードバックを元にどうしていくかっていうプロセスって、
小さな振り返りみたいなものなのかなっていう解釈ですね、私は。
なるほどです。
振り返る前提なのかなって。
そうですね。
分かりました。
第2部で学びの最適化、学びのエキスパートになるにはこういうことを知らなきゃダメなんだ、
こういうふうに学んでいかなきゃダメなんだっていう話が終わって、
第3部になると複雑さの管理の話になってきます。
なんかここが肝な感じがするというか。
肝な感じがするんですが、しますね。
第2部まで読んだときに、
結構普通に一般的な書籍として読んでたんですけど、
第3部になった途端、コードが出てきました。
実際のプログラミングのコードが。
そうです。
複雑さの管理については、こういう項目が大事なんだってところで書いてるんですけど、
モジュラー性、凝縮度、関心の分離、重症化、カップリング。
キーワードからしていかにもDDDなキーワードが。
DDD本で結構このキーワード見たな、書いてたなっていうのがいっぱい出てきました。
なるほど、そんな感じなんだな。
ここに関しては、コードが出てきたパターンで言うと、
よくある、このコードって凝縮度高すぎないとか低すぎない、
24:00
じゃあこうすると改善されるよねっていう、ケーススタディというか、
例を紹介してくれるので、多分、
関心の分離ってコードでどう書くんだよって分からない時に、
結構優しい、丁寧な説明だなっていう印象ですかね。
なるほど。
ここの第3部で私が印象に残ってるのって、やはりコードのところよりも、
冒頭の全体的な感想の話でも少ししたんですけど、
ソフトウェア工学の考えって組織の考え方にもつながってくるよなっていうところ。
がまさに、この第3部だったなって印象があってですね。
というのも、例えば、関心の分離とカップリング、結合度ですかね。
っていうことって、組織構造でも同じだよねっていう話がありました。
はいはい。
実は、私の経験の中でこういう感じだなって思ったのは、
複数の自分たちのプロジェクトに複数のチームがありますと。
複数のチームがお互いに関心ごとの分離ができていなくて、
かつチーム間で、すごい疎結合じゃなくて密結合になってた時ってどうなっちゃうんだろうなって考えたんですよ。
はいはい。
密結合になってるとか関心の分離ができてないってことは、
自分たちのチームだけで物事を完結できない可能性が高いじゃないですか。
そうですね。
何かこれを新しく追加しよう、それってAチームも関係してるからAチームと設計を確認しなきゃだよねとか、
Bチームも同じところ触るからリリースするタイミングは調整しなきゃだよねとか、
っていう部分がめちゃめちゃ同じじゃんって思ったんですよね。
はいはい。
これがチームトポロジーの書籍とかで言われてる、いわゆる逆コンウェイの話に近いものなのかなって思いました。
確かチームトポロジーだとコンウェイの法則があって、自分たちが構築したい形にする場合は逆コンウェイで考えて、
そういう形になるチーム編成にしましょうみたいな流れだったと思うんですけど、
逆コンウェイのとこってまさにこの関心の分離とか素結合とかを考えてるとこだったんだなっていうのはちょっと繋がった感じでしたね。
ちなみにその分け方はそうだとして、チームとチームの関わり方みたいな、チームトポロジーもいくつか書いてあったじゃないですか、
27:06
Xアザサービスとかファシリテーションかな、コラボレーションだっけ、3つぐらいありましたよね。
ありましたありました。ちょっとパッと出てこないんですけど。
そういう系の話ってありました?ここに。
詳しくはなかったけれども、少しだけ言及されていた気がしてて、
これしっかり読んでる人がいたら教えてほしいぐらいなんですけど、
とはいえコミュニケーションする場はちゃんと作るべきだみたいな話は確かにあったんですよ。
ただそれが、例えばスクラムガイドのような感じで、1週間に1回こうやるべきだとか、そういう話はしてないですね。
なるほど、イベントの型が決められているわけではないんですね。
ただなるべく関心ごとを分離して素手図号にすると、お互いに依存せずにまず動けますよね。
そうするとチーム間とかプロジェクト内のコミュニケーションパスって、
必要最低限って言うとちょっと合併があるかもしれないんですけども、
不必要に増えることはないよねって話ですね。
この中でちょっとだけ出てきた表現というか紹介されてたのは、私読んでないから、
今日の全体の感想を特に上げなかったんですけども、人月の神話の話もちょこちょこ出てきてましたね。
なるほど。
よく聞くけど読んだことはないっていう本です。
人月の神話はなんか自分も読んだことなくて、
ブルックスの法則みたいな、人を増やしてもみたいな。
それ系の話が書いてあるんだろうなーの想像ぐらいしかしてないですね。
そうそう。
9人人がいても、9ヶ月のやつが1ヶ月になるとは限らないとか、
そういうことを言ってるんだろうなっていうぐらいの感覚ですよね。
どういう言及がしてあったんですか。
人月の神話の中の一部のキーワードというかを引用していて、
さっき原文そのままで紹介すると、
女性が9人いれば赤ん坊が1ヶ月で生まれるわけではないみたいな。
よく聞くやつ。
多分現代でそういう表現すると結構問題になってくるのかなみたいな。
それって要はここで紹介している部分でいうとカップリングのところかな確か。
カップリングの部分でも実はそういう話って同じなんですよっていう紹介がされてましたね。
30:01
なるほどな。
はいはい。
それで、
例えば三つ結合になっている状態だと、
シンプルに人を導入したとしても、
じゃあその増えた人の分結局三つ結合だから、
コミュニケーションとか連携めっちゃ取らなきゃいけないから無駄に時間かかっちゃうじゃんってことを言ってるんだと思ってます。
なるほど。
それがうまく素結合だったら、それぞれに人を増やすであったりとか、
新しくチームを作るってなった時に、
そこに対して全部独立して並立で動けるから、
早く動けるよねみたいなことを言ってた気がする。
なるほど。
はい。
あとは正直結構DDDで説明されている内容をしっかり実践のもと説明してくださってたんですけど、
私も正直DDD読んだけど、しっかり理解してるかっていうと怪しいので、
まだその辺はあんま語れないですね。
DDDは、自分はあれですね、エヴァンスのDDDのやつは読んだことないですね。
青いやつですよね、確か。
そうです、あの500、600ページぐらいあるやつ。
いやー、読まないと思う。
何でしたっけ、一時期初めてのDDDじゃなくて、
日本の方がDDDの入門書みたいなやつを書いてくださっていて、
結構流行ってた時期があったと思うんですよね。
何だっけな、タイトル忘れちゃいましたね。
なんかあれかなーって思い浮かぶやつが3冊ぐらいあります。
そんなにあります?
何だっけな、ドメイン駆動設計入門だったかな。
本の名前覚えていない。
とかからまず読んでみると、もしかするといいのかもしれないですかね。
そういう意味だった、DDDなんだろうなって思った時に。
なるほどな、DDDはあれなんすよね、ドメイン駆動設計じゃないですか。
なのにあんまり設計の方じゃない方とかも書かれている本とかいっぱいあったりとか。
あーなるほど。
するし、なんだろうな。
まあ、なんか、いっか、ちゃんと読まなくて。
気持ちで、やる時が来たら読もう、ぐらいの気持ちですね。
33:00
何回読んでも分かる気がしないというか、
何回も何回もいろんなタイミングで読み直さないと理解できない気がするなと思ってます。
なるほどな、なんかもうざっくり、ドメインエキスパートみたいな人と話し、同じ言葉で会話し、
ドメインは育てるのが大事とか、
なんかそういう個別のなんか大事そうなキーワードぐらいしか覚えてないから。
あとよく覚えてるキーワードはなんか境界づけられたコンテキストとか。
個別それがどういうことを表しているかみたいな説明はちょいちょい読むから、
なんか分かるんですけど、全体として体系だってちゃんと学習したことはないですね。
私も学習はしたけど、やっぱりじゃあ実践までちゃんとできてるかって言われると、点々ですね。
そういった部分を筆者の実践経験をもとに説明してくださっているので、
もしかするとDDDから入るよりも少しこういう感じなんだっていうのが入ってきやすいかもしれないですね。
そこでもし興味を持って、
元のDDDの方って何書いてるんだろうってなったら読んでみるのもアリだと思いますしね。
分かりました。
というところで学びの話と複雑さの管理って話が終わり、
最後ソフトウェア工学を支えるツールっていうタイトルで、
ここはちょっと章が少なめの2章ぐらいだったりするんですけど、紹介してくれてますと。
印象に残ったのは、ソフトウェア工学を支えるツールのところでも結構DDDを推してきたなっていう。
なるほど、大好きですね。
これも引用ですけど、
DDDはソフトウェア工学に対する工学的アプローチの土台であり、必要不可欠です。
本書の考え方に沿って私たちの優れた設計を生み出す能力を後押しし、
強化してくれるプラクティスとして、私はDDD以上のものを知りません。
っていう力強いメッセージが。
なるほど。
ここまで言われたら、DDDも読むしかない気がしました。
36:00
読んでますけどってのはありますけど、やっぱそのDDDって結構重要なものなんだなって再認識ですかね。
そうですね。DDDは安心感がありますね、やると。
確かに変更に対しての不安感はなくなりますよね、結構。
なんか割と、言葉としては最近聞いたんですけど、受入れ駆動テストみたいなのあるじゃないですか。
BDDでしたっけ?それはBEHAVIORか。
そうですね、アクセプタンスだから多分ATDDかな。
結局こうなったらいいよねーの最終形から逆算するんで、
最後になって動かないみたいなことがないんで、ちょっとずつ進んでる感じがして、自分は結構好きですね。
ですよね、それにこうなったらいいよねーのこうなったっていう部分をまず、一番最初みんなで同じ認識を持った上で設計ができるわけだから、そこの手戻りも少なくなりそうですもんね。
そうですね。
っていう意味でも、一言にTDDって言っても、その奥深さってまだ全然活用しきれてないし、理解しきれてないんだろうなって思いますよね。
工学的アプローチの土台であり、必要不可欠とまで言われたらですよね。
確かにフィードバックを得るのにも必要だし、設計を確認するのにも必要だしっていう意味だと、間違いなく必要ですって話ですもんね。
そうですね。
ここでもしっかりTDDを推してきてくださったんだなっていうのがまず一点と、あとは知らなかったからとりあえずここでも書いてみたってやつで、OBAPモデル。
これ初めて聞きました。
私もです。と、BAPOモデルっていうものの対比というか、紹介というかされていて、Oがオーガニゼーション、組織、Bがビジネス、Aがアーキテクチャー、
Pがプロセスっていう頭文字を取って、モデルを構築してるっぽいんですけど、
簡単に言うとこれ、何かをやるときにどういう順番で決めてきますかっていうことだと思って。
39:04
組織決めてからビジネス決めてアーキテクチャー決めてプロセス決めるのか、ビジネス決めてアーキテクチャー決めてプロセス決めて組織決めるのかみたいな。
順番なんだこれ。
本の中だとBAPOの方がいいんじゃないのっていう話をされてますと。
これもまさに逆コンベで設計してるような話なんだろうなって思ってて。
特段ここに対してなんか語れるわけではないんですけど、とりあえず組織から決めるパターン、そのOBAPと呼ばれるモデルだと、
どういうことがこれまで自分の経験の中で大変だったろうなって考えてみたんですけど、
なんかよくあるのが、何でしょうね、プロジェクトがあって、
なんかもうチームも決まってます。
で、
例えば昨日、市販機に1回目標とかミッションをプロジェクトで決めますってなったときに、
ミッションとかビジョンを決めた後に、
そこのチームを変えようっていう視点がないから、
じゃあこのミッションとビジョンをどうやってこのチームに当てがおうかって考えちゃうみたいな。
なるほど。
で、Aチームってこういうこと得意だけどこういうことできなくないとか、
Bチームはこれ得意だけどこっちできなくないっていうのがいろいろ出てきちゃうと、
結局そのチームのスキルセットとかチームの状況が制約になって、
やりたいことできないみたいな。
なるほどな。
ケースが、そのOBAPって呼ばれる方だし、
自分が過去に経験したことがありそうな場面って多分こうだったんだろうなっていうのがあったので、
ちょっとここで紹介しておきたかったって感じですね。
なるほどな。組織が最初に来るか最後に来るか。
組織。なんかでも、組織か。組織っていうとそんな感じですけど、
これをチームってすると、なんかあんまりほらチームって、
解散しない方がいいというか、生えない方がいいみたいな話はあるじゃないですか。
なので、そのBAPOモデルで最後にチームが来た時に、
ビジネスとかアーキテクチャプロセスに合わせてチームを再編とかしていると、
42:00
確かにその、制約から考えるといいのかもしれないですけど、
なんかあれですよね、なんだろうな、その、
元からあるチームが自分たちにできることは何だろうから考えることはできなさそうですよね。
確かに。そうすると、ここで述べているその組織っていう捉え方って多分もっと大きいものの方がしっくりきますよね。
なんかそんな感じです。会社というかもうそんな感じですね。
わかんないけど、なんちゃら部門があってみたいな。
そのぐらいだとなんか、ナッティングするというか。確かに。
そうなるとチームまで考えた場合に、このモデルがフラクタルになっているかというと、
ちょっと何とも言えない怪しい感じがしますね。
大きいところでは当てはまるけど、もっと詳細になってきたところでは、
ずっとこの形が小さくフラクタルになっているわけではなさそうですね。
フラクタルで成り立つパターンももちろんあるし、でもそれだけじゃなさそうって感じでしたね。
そうですね。
はい。というところで、あれですね。感想というか気になったところでした。
なるほどな。
へぇー。やっぱり複雑さの管理はやっぱり分割統治なんだな、結局。
うーん。でも難しいですよね。
そうですね。
へぇー。なるほどな。
なんか、確かにあれですね。へぇーそうなんだみたいな新しい話はあんまりだったかな?
うーん。まあ、そのー。
どうなんでしょうね。
ものづくりのプロセス全体像を紹介している書籍って結構あると思うんですけど、
はい。
その中でも、非常にソフトウェアっていうかエンジニアリングの方に、分野にフォーカスした切り口で説明しているって感じなんですかね。
うーん。なるほどなるほど。これちなみにページ数どのくらいでしたっけ?
えーと、私は紙で買ったんですけど、
はい。
350ページくらいですかね。
あー、絶妙。なるほど。
45:00
絶妙です。
350か。なるほどな。で、4章か。
でも結構正直途中の読み飛ばしちゃいけなかったかもしれないですけど、モジュラー性とか凝縮度のところってサーッと読んじゃいました。
あのコードの書き方のところは軽く読んでおくぐらいにしようって思って。
それでもいいかも。
工芸、工学、この辺はちょっと面白そうだな。
学びと最適化。逆に自分はあれですね、XP読みたくなりましたね。
マジXP読んだ方がいいですよ。
なんか水田さんが無茶ぶりする時の喋り方になってますけど。
いやー、すごい、私結構メンバーと話す時に、XP読んだことない人に結構な確率でXP進めてます。
XPって個別のプラクティスですよね。
個別のプラクティスも結構紹介してますね。
XPの、なんだっけ、1日に10回デプロイするとかいう話でしたっけ。
とかもありますね。デプロイというか、デプロイだったかな、CIするだった気もするけど、XPの中だと。
10分で納めろとかそんな感じでしたっけ。
そういうのもありますね。
あー、それ系か、はいはい。全然読んでないことがわかるでしょう。
XPだと多分ボリュームもそんなに多くないというか、200ページあったかな、どうだったかな、ちょっと。
今手元に本がないからあれなんですけど。
このエクストリームプログラミングってやつ。
ですです。
確か何版か出てるから間違えないように。
そうなんだ、なるほど。
これ電子書籍あるかな。
あるっぽいですよ。
じゃあ買おう。
本だと181かな。
本当だ、これか。
でも何でしょ、何度も読み直してる気がします。
これ今のお話ってXPに返ってくる話だなって思いながら読み直してる気がします。
結構だからこれを読んでその影響を受けた人がそれだけ多いってことなんでしょうね。
あーそうかもですね、確かに。
そういう人たちがやっぱりそのエッセンスとかを自分で解釈し直して本とかに書いたりとか。
これはこれ読もう。
あーまたツンドクが増えた。
ぜひぜひ。
あれなんですよ、減らしたんですよ。
そうなんですか。
あれ言ってなかったかな、自分は読む本、ツンドクをイシューズで管理してるんですよ、GitHubイシューズで。
48:05
はいはいはい。
これいいよって言われたらとりあえず買うでもいいんですけどとりあえず買ってたらマジでお金ないんで。
とりあえず一周に登録するっていうのをやってるんですよね。
いいですねいいですね。
誰からのおすすめとか、TwitterだったらTwitterのリンク貼って。
はい、なるほど。
っていうのでやってるんですけどそれが150になってたんですよね。
で、これは読み切れんと思って年始だし整理しようと思って。
確かに。
70ぐらいまで減らしました。
70だと、あれ1年って何週でしたっけ。
52とか3とか。
じゃあ一週間一冊でも終わんないやつですね。
そうなんですよ。
でも分かんないですよ、分量少なくて1週間3冊ぐらい読めちゃうかもしれないですよ。
あーつらいね。でも去年があれなんですよ、24だっけ5だっけぐらいで、
なんだろう月1,2冊なんですよねやっぱり。
私もそれぐらいでした、集計してみたら。
70とか絶対無理です。
全部似たような本だったら後半に行けば行くほどブーストかかるんですけどね。
確かにそうっすね。
まあ読んでいこう。
お互い、ぜひ早めに読んでみるといいんじゃないかなって思ってます。
これも前に言ったかもしれないですけど、
ここで話すともう読んだつもりになっちゃって、読まないってのあるんで。
でも実際ここで話すとエッセンスわかるからもういいかなって思うんですよね。
ちゃんと正しく読んだ側が説明できてるというのですけど、ちょっと私そこ自信が弱いので。
大丈夫です。なんだっけ、読んでない本について語るみたいな話で、
人から聞いただけでも、ちゃんと自分で読んでも全部覚えてるとは限らないので、
その人から説明されただけでももう読んでるって言ってよいみたいな、
拡大解釈をするとそういうことが書いてあった気がするんですよね。
なるほど、確かに、オブサーバビリティエンジニアリングでしたっけ。
読んだんですけど、めっちゃ博多家さんがまとめてくれたところに戻りますもん。
あの人こういうこと言っちゃったなーって。
なんか、あれはそうだったと思います。
はい、というところで、第1回はそろそろお開きにしますかね。
51:04
そうですね、2023年の第1回ですね。
そうですね。
すげー、めっちゃ長く話しましたね。
そう、なんか第1回だからですかね。
ちょっとやる気があふれてるんですかね。
ちょっと待ってくださいね、締めの提携文今出すのでちょっと待ってください。
あったあった。
はい、じゃあ今回以上ということで、質問や感想はマシュマロに投げてください。
お待ちしています。
Twitterでは#アルファベット小文字でゆるテクをつけてツイートお願いします。
今日はありがとうございました。
ありがとうございました。
