#450 エクストリームプログラミングの原則見てたら、人生の原則も見えてくる

この番組は「エンジニアの成長は楽しい学びから」をモットーに、昨日より少し成長できる学びを届けるエンタメ系テックラジオです、ということで。

はい、お願いします。

えーっと、ちょっとエピソードの順番どうなってるか分かんないんですが、続いてるか続いてないかは、まあ僕ら次第っていうところで、エクストリームプログラミングの話をしようかなと思います、XP。

ああ、頑張って編集します。

いや、まあ続けなくても大丈夫です。で、えっと、まあ前、エクストリームプログラミングの話をしたときに、というよりはちょっと、もう少しここから聞き始めた人にも優しいように進めるんですけど、えーと、エクストリームプログラミングという、まあケントベックさんが書いてる、ケントベックさんだけじゃないのかな？ 2人ぐらい。

2人ぐらい名前あった気がするな。

そうですね、ケントベックさんと、シンシア・アンドレスさんかな、ちょっと読み方合ってなかったら申し訳ないんですけど、が書いた、まあエクストリームプログラミングという、えー本を読んでましてですね。

はいはい。

うん。で、まあAIがソフトウェア開発の現場に入ってきて、で、我々は変革を求められるなあと思っていて、まあそんな中、まあ改めてエクストリームプログラミングというものが求められてるんじゃないかと勝手に思って、えーこの本を読みつつ話してるんですけど。

うん。うん、でも古い本なんすよね。

うん、ちょっと前。いつだろう。

1999年すね。

うん。第一版そんな前なんすね、これ。

うん。すげえ。

で、まあその中でですね、まあちょっと今日、その中でですね、前回は、えーエクストリームプログラミングで重視するべき価値っていう、まあエクストリームプログラミングやるんだったらもうこれを重視して、えー活動をしていこうぜみたいなところをちょっとお話ししたんですが。

はい。うん。

で、エクストリームプログラミングって、その前回お話しした価値と、えーよく言われるCI/CDとか、えー自動テストとかのプラクティス、と、あと今日お話しする原則っていう、まあ3つ、なんかざっくり大きい要素があって。

うん。うん。

で、この価値を目指してやるぜ、そのためにはこのプラクティスが一旦いいと思うぜ。で、ただプラクティスはチームによって合う合わないあるし、えー新たなプラクティスを考える必要もあると思うから、それを考えるときにはこの原則を守りながら、プラクティスを考えながら価値を追求していこうぜっていう、まあ立ち位置で価値、原則、プラクティスがありますと。

はい。うーん。

で、まあ今日は原則の話をしていければなと思うんですが、えーなんとこの原則15個あってですね。

多いなあ。

おー、ちょっと多いんですよ。で、これをぎゅっと3つにしましたって言えればいいんですけど。

うん。

うん、まあこれは全部で15個だなと僕は思ったので。

全部全然違うんだ。

うん。

なるほどね。

へー。

まあ全然違うわけじゃないかもしんないですけど、ちょっと僕はこれは、あの、縮めるのは、ちょっとケントベックに申し訳ないなと思って。

なるほど。リスペクトありきの15個ね。

はい。友達みたい。はい。

泣く泣く15個、今日はお話しするわけではなく、気になった、えー、み、4つ、ちょっとピックアップしつつ、最後に残り11個ポコポコって紹介して終わるようなエピソードにしようと思ってます。

おー、ありがとうございます。

はい。で、じゃあ早速原則のほうに入っていこうかなと思ってるんですけど。

はい。

この本、あの、エクストリームプログラミングという本、これ名前出してもいいと勝手に思って名前を出すんですが、以前ポッドキャストに出ていた、出いた、僕の会社の吉田さんという先輩の方、あの人エクストリームプログラミングの本大好きな人で、はい。吉田さんが、まあよく、よく言うって言ったらあれですけど自己紹介でよく言ってるのが、人生に大事なことは全部アジャイルから学んだということを言っててですね。

ああ、本のタイトルみたい。

すげえ。かもしんないっすけど、まあでも本のタイトルじゃないんですけど。で、ここも非常にこのエクストリームプログラミングの精神が溢れるなっていう、もうすごい原則を守った上での発言だなと僕はちょっとこの本を読んで改めて思ってですね。

あ、そうなんだ。

そう。で、最初のちょっと紹介したいのがその自己掃除性っていう原則があってですね。

ほう。

で、まあこれ何を言ってるかというとですね、ソフトウェア開発ってフラクタル構造なんですよということを言ってます。

フラクタル構造。

難しい単語が出てきました。フラクタル構造。

はい。

フラクタル構造は普通に知ってるよね、多分じゅんぺい。

この、この問いかけ怖いな、ちょっとやばいな。

高校の化学とか？

え、分かんない、雑学だと思ってる。

あれ？

えっとー。

ふら、ちょっとなんか、い、六角形みたいな感じが頭に出てきてます。全然そういうことじゃない。

うん、多分違う。 大丈夫ですか。三つうろこみたいなやつじゃないですか。

うわ、知らないそれ。

な、何を言ってるんですか。

あのー、ロゴです、会社の。

ちょっとますます分かんない。

どういうこと？

あ、う、1枚のうろこが3つ重なってるみたいな話をしてますね。

あ、え、なん、なんか三角形だけで三角形を作って、それをつなげて大きい三角形にしてるやつ？

あ、ゼルダの伝説ってことですか。

近い。あ、ゼルダの伝説もそんな感じだった気がする。

うん、近い近い。近い、近い、近い、近い。あー、まあ、そう、一部そう。

気になる。

けど、なんかもっと、なんかよく言われるので言うと、えーと、野菜で、えーと、ろ、なんだっけ？

野菜？

野菜、あの、ブロッコリーじゃなくて。

玉ねぎに含まれてるフラクトオリゴ糖ですか。

違います、違います。

違います？

ちょっと似てる。

ロティサリーじゃなくて、ちょっと待ってくださいね。ロ、ロマネスコ？ロマネスコか？

あ、ロマネスコ？あのー、おいしくないカリフラワーみたいなやつ？

あ、そうそうそう。あーそう、ロマネスコ。はい。

はい。

ちょっと、どこまでカットしてるか分かんないけど。そう、フラクタル構造といえばロマネスコなんですよ。

いやいや、それはちょっと知らん。

えー？

で、ロマネスコって分かるかな、ちょっと分かるか分かんないかギリギリの野菜なんすけど。

いや、分からないな僕は。

俺スーパーで1回ぐらいしか見たことないよ。

ちょっとね、細かいふきのとうみたいなやつなんすけど。

そうね。

このロマネスコってやつ、あのサラダとかに入ってるのはとき、塩、塩水型みたいなのがあるんすけど、塩水型みたいな形多分入ってるんですけどロマネスコって。

うーん。

ちっちゃいのが。このロマネスコちょっとググってもらったら。

はい、調べてみます。

あ、見たことあるってなるかもしんないですけど、このロマネスコをどんだけズームしてもロマネスコなんすよ。

いやいやいや。

言ってる意味分かります？

いや分かんないっす。

なるほど。

え？

そうなん？

いや分かります。

ロマネスコってズームするとちっちゃいロマネスコが付いてるんですよ。

ズームしたいんだよ。

画像を見たら、はい。なるほど。

そう。これがフラクタル構造っていうやつで。

うーん。

まあ。

あー、はいはい。

なんて言うんだろうな。書籍の中で言われてた例を出さずにあえてロマネスコ出して、書籍の例は出さないんですけど。

うん。

ソフトウェア開発って、だからズームしても同じ構造なんすよ。ズームって何を言ってるかというと、1つのコードを書くという小さいものも、四半期単位のソフトウェア開発という営みも、フラクタル構造ですと言ってるんですよ。

粒度が分からんな、まだピンと来てないぞ。

で、まあ何を言ってるか、まあもう少しブレイクダウンしていくと、今、今まではちょっとフラクタル構造の話だったんですが、ソフトウェア開発のリズムって基本的に、基本的にというか、まあよく正解だと言われるリズムとして、実装のときにまずテスト書いて、で実装して、テストできた、よしみたいなのが、まあ開発のリズムとしてあると思うんですけど。

うん。

えっとテストを書いて、コードを書いて、でそれでテストが動くようになりましたっていう流れって何をしてるかっていうと、まず最初にテストを書くことで、今から作るものってこういうもんだよねの定義をしてるわけです。

うん。

うん。で、実際にコードを書いて、テストが通ったらそのタスク完了。タスクっていうのはその本当に、1チケットっていう単位じゃなくて、1回このテストの分の実装を終わらせるっていうタスクが完了。

うんうん。

で、これがまあ例えば最小単位だとしたら、少し広げて、じゃあ1週間のスプリントの中でやることで言ったら、チケットに完了条件書くんすよ。

うん。

そのタスクの背景とか完了条件とか書く。だからつまりタスクの、これができたらオッケーっていうのを定義して1週間かけてやって、で完了条件を満たすものができたらおしまい。

うん。

っていうのは、テストを書いて実装するっていう、構造と一緒なんですよ。

まあ手段は違うだけっていう。

そうっす、そうっす、そうっす。

うーん。

で、それをもっと広げて四半期単位とかにすると、結局じゃあこの四半期の中で、戦略的にはここのタイミングでこういうことをやっていきたいよねみたいな、のを描いてやっていく。

うんうん。

で、その元々描いてた、なんでしょう、そのどんだけ粒度が大きかったとしても、このテーマというかこの開発、エピックではここまでをこうしたいみたいなのは最初に定義すると思うので。っていう話があってですね。

うんうん。

で、今あくまでソフトウェア開発の話をしたんですけど、こんな感じで、まあフラクタル構造的に物事なってますよというふうに言っていて。

はい。

で、僕はちょっとここは、あの、まあ拡大解釈なのかもしんないんですけど、今から言う原則って割と、まあやっぱり普段の生活に生きるというか、だから何事もそうじゃねみたいな、うん、ことをまあ言っていくわけなんですけど。

ああ、なるほど。

人生は単純なんですね。

単純なのかな。まあ単純ということなんかもしんないし、まあ結構抽象的なことが並ぶので。

うんうんうん。

うん、まあぎゅっとして、ぎゅっとしたらこうなるみたいなのはあるかもしんないですけどね。

はい。

うん。っていうのでやっぱ、じゃあこの、ここで学んだものをどこに生かせるかなとかっていうのをちょっと考えながら聞いてみると、なんか開発してる人もそうじゃない人もまあ楽しいエピソードかなと思います。

なるほどね。

はい。

だからこそアジャイルですべて学べたってことか。

はい、っていうことなんだと。

はいはいはい。

勝手に解釈してますが本当は知りません。

うん。

そうっすね。

はい。

うん。

あの今僕が適当なこと言ってるだけです。はい。はいということで1個目の自己掃除性紹介したんですけど、えー次いきますね。で、えー原則15個ある中で最初に書かれてるのが次にお話しする人間性の部分になります。

人間性。

はい。

おー。

まあ大事な順なのかは分かりませんが、まあ結構厚めに書かれてるんで大事なんだろうと思ってます。

まあでもね、本書くときそうなる、なりがちだよね多分。

うん。

うん。

そうあってほしい、さすがに。

うん。

で、まあこれもね当然なんすけど、ソフトウェア開発においてエンジニアの人間性はすごい大事ですというふうなことが書かれてですね。

うん。

うん。まあただ、あの、まあ何も考えないでやっちゃうと、まあ人間性ないがしろにされがちだということが書かれてます。

ほー。

うん。で、もうこれちょっと僕、なんか反省じゃないけど、自分を省みたことがあって。

はい。

まあまず、まあ多くのソフトウェア開発は人間の欲求を満たしてないですよということが書かれてます。で、これどういうことかというと、ソフトウェア開発というプロセスは、えー、まあ人間の弱さを認めていないプロセスになっていると。

なるほどね、はいはいはい。

はい。まあこれ、まあもう少しブレイクダウンして言うと、これは別に書籍に書かれてないんですけど、なんだろうな、なんか締め切りが決まってるけどやることが増え続けるとか。

うんうんうん。

うん。あとはウォーターフォール的にね、やっちゃうと急に要件が変更されてみたいなことがあったりとか。

うん。

ああ、そういうことか。で、なおかつそれって結局人間が、まあなんか寝坊って言ったらあれですけど、気持ちが折れちゃうかもしれないじゃないですか、それって。

うんうん。

そう。そういうところを認めずに、なんか割とね、まあサイボーグ対応が求められるっていうんですか。

はいはいはい。

メンタル的な意味では。

あれっすよね、あのスラムダンクのさ、あの赤木っすよね。1、2年のとき。

ちょっと詳しく、詳しく。

あの赤木、あのちょっとスラムダンク1から話すとですね、小北高校という高校があって。

はい。だいぶ1だな、はい。

で、まあそこに赤木ってゴリって呼ばれてるね。あのー、まあ。

ああ、ゴリか。

すごい背でかくて、あのバスケうまいやつがいるんですよ。

うん。

で、そいつは努力の男で、あの1、2年生のときとかは、あの、えーと、まあそこの努力でこうめきめき頭角をのし上がっ、あの見せてきたんすね。

うん。

その才能を。

はい。

なんですけど、あのそいつ頑張りすぎて、周りにも頑張れよって言い続けたせいで部員たちが離れてってしまって。

ああ、そう。

うん、そう。っていうことが起きてたんすけど。そういうことっすか。

そういうこと、そういうこと。

はい。

ゴリです。

ゴリですね。

はい。

はい。

はい。で、本当にまさしく同じこと書かれてて。

うん。

こういう人間の欲求を満たさないと離職率が高くなっちゃうとか。

うん。

まああとはもうクリエイティブな行動の機会損失とか、まあ要するにビジネスにとって好ましくないんですよ。

うんうんうんうん。

ゴリもチーム作りによっておいては結構マイナスだったと思うんすよ。

そのときはね。

うん、そのときは。だから最終的にね、ちょっと、あの、何、無駄が省かれたメンツが残ったと言えるのかもしれない。

まあまあまあ確かに。

そうなのかな。

うん。

そういう感じではなかったけど。

まあそっか。

うん。

はい。

っていうので、まあチームとしてというかソフトウェア開発のそのやり方、進め方として、まあ人間の弱さを認めつつ強さを活用したような、まあそんな、まあチーム作りというかが必要だ。

うん。

ってことを、まあ言ってるんですね。

うんうん。

いやー。

はい。

え？

ここで言う自分らしさは何かというと、これは仕事だけじゃなくてプライベートも込み。

はいはいはい。

で、で、まあなんでしょうね、なんかまあプライベートで問題も起きないし、仕事をしてても、まあ帰属意識はちゃんと芽生えてるし、成長の機会があるし。で、チームメイトもまあある程度親密な関係で。で、各々が自分らしくいるからこそハイパフォーマンス出るよねみたいな。

はいはいはい。

のをゴールにすると。

いやーすごいな。

うん。

もう20世紀からウェルビーイング言ってるじゃん、もうこの人。

ああ確かにそうっすね。ウェルビーイングの話。20世紀からウェルビーイングですね、まさしく。

ねえ。

まあちょっとこの記述まるまるその第一般のものかっていうのはちょっと自信ないんですけど。

確かに。

はい。

それはそうかもな。

うん。

うん。だから順番入れ替わって人間性が1個目に来た可能性もある。

うんうんうん。

それは人間の弱さを考慮してこうよって言っていることになるんですか。そんなことない。

人間の弱さを考慮してこうよっていう、人間の、うん。人間の弱さは認めていこうよっていうことにはなるんじゃないですかね。

ああ、みんな。

そのなんだ、プライベート込みで、全員が自分らしくあれるようなものを目指す。それが原則だと言っている。

うん。ああ、なるほど。認めるのであればなるほど。

うん。

うん。なんかプロジェクトがこう遅れるってな、まあ大体遅れるじゃないですか。そこの弱さを。

まあ分からんでもない。うん。

考慮して、なんか計画を立てようよだったら結構不可能じゃねと思ったんですけど。まあ遅れちゃうのしょうがないよね。ベストは尽くしたよみたいな感じなら、なるほどなっていう。

まあちょっと話を進めると、まあ計画はやっぱり遅れることはあると。

うん。

だからこそアジャイルっていうのが非常に重要で。

おお。

1か月のプロジェクトは2週間遅れることはあるけど。

うん。

1週間のプロジェクトは2週間遅れないんすよ。

はいはいはい。なるほど。

うん。っていうので、まあちょっと人間性の部分とはちょっと外れるかもしんないですけど。

うん。

まあでも人間らしくあるために、じゃあ我々はどうしたらいいんだっけっていうのに立ち返ったあとに、ああじゃあちょっと1回のプロセスというかなんだ、タスクの粒度を縮めてみたら、なんかもう少しみんな人間性を、人間性を保った仕事の仕方できんじゃないっていう話し合いになるっていうのがまあ原則のポジションですね。

うん。

うん。

なるほど。

ただ一方でちょっと僕気になるのがですね。

はい。

いやいやみんなそんなに勤勉じゃないぞっていうところあるかなと思ってて。

はい。

ほう、え、あ、はいはい。あ、なんかそういう話なんじゃないのかな、これって。

うーんと。

なんとなく。

なんででしょうね。

これを読んで、読んでというかその話を聞いてて思ってたのは、あのー、まあ正論パンチじゃ物事は解決しないですよとか、あと生き生き働ける職場を作ることによってパフォーマンス上げてくみたいなことを言ってるのかなと思ったけど、そういうわけではない。

いや、合ってますが。

あ、はい。

とはいえ、なんか生き生き働ける職場を用意したらそこ居心地いいなって言ってゆっくりしちゃおうっていう人出てくるんじゃないのかなって。

ああ。

まあちょっとこれはかなり全時代的な、非常に良くない意見なんですけど。

いやーでもありえるかも。

すごい自立心求められるんですよと思ってて僕これ。

はいはいはいはい。

なんだろうな。だから僕はこの解決方法採用しかないんじゃないかってちょっと思ってたりするんですけど。

うーん。

どう思います?

いやこれは日本だからってのもあるかもしんないな。

ああ、ちょっと詳しく。ちょっと分かりますけど。

あのー、要は終身雇用で、ほ、あのー簡単にクビになんないじゃないですか。

はい。

だからこそなんか居心地良くなって、あのサラリーマン根性でぶら下がってやるぜみたいなパターンが発生しうるけど、なんかこれアメリカで生まれたって考えると、向こうってなんかパフォーマンス発揮しなかったら全然普通にレイオフありえるから。

うん。

うん。なんて言うんだろうな。働きやすさとそういう勤勉さみたいなのが、こういいバランス取れるのかなってちょっと思ったというか。

ああ、なるほど。

うわー、そんな気するっすね。

うん。

確かに。ね。

うん。だからちょっと日本独自の何かは必要なのかもしんないなってのはちょっとふと思いましたね。

確かに。

なるほど。

いやー、ちょっとね、ほんとになんかクビにはなれ、されたくないんですけど。

うん。

別に人材は流動的にいいんじゃないかなと思っています。

うんうんうんうんうん。

個人的には。

うん、それは思う。

うん。

クビにはされたくないんすけどね。

分かる。

うん。

クビにはされてなくないんすけど、まあでもそのときはそのときですね。

うんうんうん。

はい。いやー確かになーって考えるとやっぱり日本だとね、ちょっとどうやっていけばいいんでしょうねっていうのはまあ、考える必要ありつつ、まあでもね、ウェルビーイングはね、大事なんで。

うんうんうん。

うん。はい。っていうのが1つ目、人間性でした。

はい。2つ目。

で、2つ目、えーと経済性ですね。

経済性。経済性、はい。

経済性。これは、えっと経済性をまあ意識してない、認識してないソフトウェア開発は、なんか終わったときに、成功して終わったときに、技術的な成功という空虚の勝利に終わる危険性があると。

うーん。

言ってて。まあまあ開発してもうかんないもの作るのって、まあそれはそれでリスクだよという。

うんうんうん。

話だと思ってます。

なるほどね。

で、まずそもそもちょっと順平に質問なんですけど、順平とのりさんに質問なんですけど。

はい。

ソフトウェア開発における経済性というか、なんか、なんだ、その売上?

うんうん。

貢献? って。こ、コーディング? コーディング、いやソフトウェア開発だな。ソフトウェア開発における売上、貢献ってどういうのがあると思いますか。その自分たちの売上貢献。

プログラマーとしてってことですか。

プログラマーというか開発チームとして。

うん。

まあ開発チームがある会社かもしんないけど。

うんうんうん。あん、想定してた工数より早めに開発が終わる。

ひょっとしたら売上減るかもしんないですね。そんなことはないか、けど、うん。

コストは下がるか?

そっか、売上、売上。

コスト下がる。

まあでも、まあ大体は売上が上がるのかな。どうなんだろう。売上は変わんないんじゃないですか、早く終わっても。その、じゅ、契約次第ですけど。

でもその機能が、なんか市場にとって破壊的なもので、先行者利益があるなら売上上がるよねっていう感じだよね、多分。

うんうん。売上か。

まあ、ちょっとくくりむずいっすけど、ね。その、サービスの売上はちょっと置いといてください。企画側の売上として。開発工数的な意味で。まあちょっと答え言っちゃうんすけど、大きく2つあって。

うん。

まず開発することによるお金を稼げる。

はい。

なんか発注受けてる的な意味で。

ああ、はいはいはい。

はい。まあ事業会社だったとしても、多分企画部門から開発部門に、多分お金を払ってはないんですけど、お金を払ってる扱いになるっていうんですか。コストとしてかかる。

うんうん。

で、そのコストからその従業員の給料が出るんで。で、そういう貨幣のタイムバリューっていう言い方が書籍でされてたんですけど。

うーん。

それで稼げるっていう。で、もう1つが将来のオプションバリュー、バリューって呼ばれるもので。えー、今開発した機能を将来の機能に流用できるんだったら、その流用した分将来のお金浮くっていう意味で、儲けがあるよねと。

うん。

いうことが書かれてました。

うーん。

で、ちょっとのりさんにここで聞きたいんすけど。

はい。

のりさん結構シビアに、あのー、ソフトウェア開発に経済性問われてるのかなと思ってて。

そうですね。

なんか従業員時代と今で、なんかこのソフトウェア開発における経済性への考え方ってどう変わったとかあります? 特になく。

いや、めちゃくちゃありますよ。

それ気になる。

めっちゃあれ、あるけどなんだろうな、うーん。結局利益どう残すかみたいなのめっちゃ考えてるかもしれないな。

売上じゃなくて利益ですね?

うん。

売上もね、売上は売上でまたなんか別の、もうなんだろうな、あのー、開発レイヤーのところでは考えてないというか。

うん。

どうやったらお金もらえるんだろうっていう、なんか根本の部分になってくるというか。

うん。

なんだろうな。開発でどうこうとかじゃなくて、なんかアイデアの部分から考えなきゃいけないことが多くて。

うんうんうん。

あんまり開発単体で分けて考えてないかもしれない、そもそも。

うん。じゃ、どんだけ利益残すかって考えるときに動かせるものってなんだろう。パラメーターってなんなんですか、動かせるパラメーター。

えー、まあ売りが決まってる場合はもうほんとに支出いかに抑えるかじゃないですか。

のりさん今、経営層だから、あのー、稼働時間でコスト変わんないっすよね?

僕は変わんないっす。

で、だからツール使うお金みたいなこと? あ、まああとは人材雇うなら。

外注する場合とかだったらそこもあるよ。

ってことっすね。

うん。

それって、じゃ、のりさんが今の、のりさんが会社員に戻ったときに、ソフトウェア開発における経済性を、まあ意識する上で、なんか働き方どう変わりそうです?

うーん、そうだなあ。あのー、SESとかフリーランスの外部パートナーの方を、例えば採用、採用というか、えーっとジョインさせるときに、すっげー慎重になると思います。

ほう。その心は?

いや、やっぱね、人、人が動くって結構やっぱすごいお金が発生するなっていう感覚がすごいというか、今。

うんうんうんうんうん。じゃあ、まあこの人ほんとにこの価値に見合うのか、金額に見合うのかみたいなところは、前より気になるようになったんですね。

と思いますね。

なるほどなあ。

多分、あのー、会社で働いてたときで、まああのー、なんでしょう、事業会社にいたときに別にその外注するエンジニアの、えー、まあ発注するかどうかの意思決定することはなかったんですけど。

はい。

多分そのままそのポジションになってたとしたら、まあ優定でもやっぱ一緒に働いてみないと分からんべぐらいの感覚で選んでたと思うんですけど。

うん。

今やったらもうちょい慎重になってると思いますって感じっすかね。

いや、しみるなあ。しみます。まあ僕も面接することはあって。

うん。

で、別にあの、まあ働いてみなきゃ分からんしは、まあ正直ちょっと思ってますけど。

うん。

まあとはいえね、ちゃんとチェックしてますよ。

うんうんうん。

まあだけど、まあただそののりさんほど重みないんで多分。

ああ。

そこはね、やっぱ大事に、大事だなというか気にしてったほうがいいなと改めて思いました。

うん。

ありがとうございます。うん、はい。っていう、まあ、なんだっけな。売上はすべてを癒すみたいな言葉もありますけど。

うん。

ソフトウェア開発やってる人こそ、ね、ちゃんと経済性意識しながら開発できる、はい、開発できると良いのかなと改めて思ったので紹介しましたと。

あ、そうだ。あともう1個いいっすか。

はい。

安売りしないの大事だなってなんか思ってます、最近。

うーん。自分たちを、自分を。

あ、自分たちをというか、まあその、自分たちが提供できる価格をあんまりこう安く見積もらないほうがいいんじゃないかなって思ってますね。

うんうんうん。

シンプルに後悔します。

いやー、そうだよね。

うん。

加減むずいっすよね。市場を見るべきなんすかね、そういうのってね。なんか、えっと、市場に合わせるタイプと合わせないタイプあるじゃないですか。

はいはい。

なんかめっちゃキャラ立ちしてたらライバルいないから、値段上げても頼んでくれる人は頼んでくれるかもしんないけど。

うん。

そのブランドが確立してないと、その単価って上がれないじゃないですか、多分。

うん、そうそうそうそう。

そこのバランス感覚むずいっすよね。

いや、バランスむずいんだけど、えっとね、多分高く入って低くするのはできて、低く入ったら高くできないんだよな、多分。

うん。まあね、先方の社内の倫理とか通せないっすからね、普通に考えててあんまりね。

そう。

うーん。

なんで安売りしないってのも大事だなってちょっと今思ったんで、差し込んでおきました。

ありがとうございます。

はい。

分かるけど難しいんだよね。

もうそこは勇気っすね、多分。

加減が。

が、なるほどね。

ある程度。

うん。

はい。じゃ、ちょっと最後。

はい。

これも僕激刺さりしたんで、最後の紹介。えー、責任の引き受けっていう原則なんすけど。

うんうん。

これは責任は割り当てるものじゃなくて、引き受けることしかできないですと。誰かがあなたに責任を担わせようとしても、責任を持つかどうかを選ぶのはあなたですと。

うん。

うーん。いう原則で、まあ最終的には責任を引き受けられるようになりましょうという話なんですけど。

うん。

ただ、責任っていうのは引き受けないと。

うん。

引き受けられない。え、ちょっと言ってる、言ってること分かんないな。

むずいぞ。

伝わります、なんか。

むずいぞ。

えーと。

えっと。

じゃあ、のりさん、これやっといてって言ったときに、僕は責任を渡してるつもりでも、のりさんがそう思ってなかったら、のりさんは責任持ってないんすよね。

なるほどね。あ、じゃあ、これはやっときますねって言ってタスクだけもらってるけど、失敗したとき、いやー、でも、うーん、やれって言われただけだからなーみたいな。え、そういうこと?

あ、そう。あ、そう、そう、そう。人間そういうもんだよねっていうところがまず前提にありますと。

うーん。

で、その上で、なんか仕組みで、仕組みでっていうのもちょっとおかしいんですけど、仕組みで責任を引き受けやすくするような、まあプラクティス。例えば、えー、なんだろうな。分かり、我々に分かりやすいソフトウェア開発の話で言うと。

はい。

DevOpsあるじゃないですか。

DevOps?

DevOpsやると、質のいいコードができるのは、自分たちで運用するからみたいな。

あー。はいはいはい。

それって運用の火の粉、火の粉、火の粉が自分たちにかかるから、そこの責任をまあ自分たちがまあ引き受ける状況ができてて。

なるほどね。

で、それゆえ責任を引き受けてるから、質のいい仕事ができるみたいな。

痛みを分かっちゃう設計ってことっすか。

まあ、はい。まあただこれは、あのー、なんだろうな、このエクストリームプログラミングの原則、価値観に合致はしてないんですけど、そのやらされてるっていうのは。

うんうん。

本当にあるべきは、責任はまず自分が受け取るものだっていうことを全員が理解して、で、渡された仕事をちゃんと責任を引き受ける。

うん。

うん。っていうことをやりましょうと。

うん。

いう話で。で、こっからはなんかフリーディスカッションなんですけど。

はい。

責任引き受けない人まあまあいるんじゃないかという。

うん。

話。

あれ。