2023年9月25日、和田卓人さん（t-wadaさん）をお招きし社内講演会を開催しました。
和田 卓人さん / プログラマー、テスト駆動開発者
学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。
『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ「power-assert-js」 作者。
Twitter: @t_wada GitHub: @twada
開催のきっかけ
カケハシでのシステムの質とスピードの前提知識を理解し、改めてシステムの質についてチームで会話するきっかけになればと開催を決定しました。
講演中の熱気
約150名を超える参加者が t_wadaさんの言葉を熱量を持って受け止めます。
講演中、t_wadaさんが書籍を引用するタイミングでその本を本棚から取り出すと「実際の本がでてくるのおもしろい」「自分のチームの必読書です！」とチャットが盛り上がりました。
また、お話が深まるにつれメインタイトルの「質とスピード」が「〇〇とスピード」といった風に次々と変化していき感嘆の声が上がりました。
t_wadaさんが提起するキーワードに熱い反応
社内のチャットにキーワードについて感じたことが次々と書き込まれます。
一部をご紹介します。
品質とは何か
「事業会社でコストや予算が正しく認識されている例をあまり見たことがないですね。
この辺りSIerの方がきちんとトレードオフを見ていますね。」
「適応度関数の構築も実践が難しい ...」
品質特性は、内部品質と外部品質の境界を明らかにしていない、コンテキスト次第
「自分たちで議論して整理してく必要」
「明言するとそれが力を持ってしまう。確かに、逆に視野が狭くなってしまいそう。」
普通の判断として「利用時の品質」を犠牲にして納期に間に合わせることは考えにくい
結果、調整コストが低い「内部品質」を犠牲にしている
「「利用時の品質は犠牲にしない」ということでしたが、これはちょっと個人的には疑問に感じてます。動かなくてもいいから（何かしらの約束があるから）動かないことを知っててもリリースしようということが今まで結構ありました」
「とても耳が痛いです」
「自己犠牲すると調整コストが安くすむ…たしかにやってしまいがち」
「顧客側の受け入れ部署と、「納品してその案件を成功判定にする」を中心にして共犯関係になる話はあるかも
（この手の共犯関係は契約形態やプロジェクト状態がどうであれ、いくばくか見られると思う）」
保守性を犠牲に捧げるとどうなるか
「あとでクリーンにすればいいよ、という考え」
「短く狭く前提で動かしてたものが長く広く使われた時の社会的責任はやばそう」
「全部書き直したこともある。でも、利益が出ると確信したから書き直せるんだよね。」
「その時にクリーンだと思っていても半年後に見返したらクリーンでないと思ってしまう。
ケイパビリティが依存している」
公開版の資料にはない少し刺激の強い内容のスライドも使いながら説明がされて、多くの共感の反応がありました。
スピードを落とせば保守性はあがる？（＝十分時間を与えれば良いコードを書いてくる？）
「スピードを追い求めた結果スピードが損なわれていくみたいな逆説的な論理って、当事者には実感を伴って理解しやすいんだけど当事者でないと想定以上にめちゃくちゃ認知負荷が高くなりがちなんだよな」
「品質の高いコードを書くことができないのを誤魔化すために時間がないことを言い訳にしているんじゃないの？ってことが(自分に対して)言われているようで胸が痛い」
「ディレクトリ構造とかドキュメンテーションの整理とかも同じこと言える気がしてるんだよな…」
「薬局の患者が急いでるからと監査をすっ飛ばすアレだな。薬局でも急いでなくても結局その人は監査しないんだよな」「薬剤師的にも耳が痛い話」（薬剤師）
スピードおよび質とトレードオフなのは、教育、成長、多様性への投資（＝人数を増やして解決、ではない）
「人月の神話は古典なのに、アジャイルチームのスケールは単に新しいチームを立てる（人を増やしているだけ）が多いんですよね。。。」
「スタートアップだと（特に初期）、未来はもっといい人を取ればいいから今のエンジニアは必ずしも成長しなくていい、という考えの人もいるのが気になってます
（カケハシには多分いないけど）」
「人の成長はスタートアップでも必要ですよ」
t_wada さんに質問コーナー
講演後、t_wadaさんに質疑応答のお時間をいただきました。一部をご紹介します。
質問その１
「保守性の高いコードを書くかどうかはスキルによるというお話があったので、根本的には人の入れ替えや教育が必要と理解しましたが、実際に調整できることは内部品質向上のためにとる時間を増やすことだけでしょうか？」（エンジニア）
t_wada さん回答
教育済みの人を採用できればショートカットできる。ただ、それだけだと育たない組織になる。やはり自分たちの組織の中に教育を built-in しなければならないという話になってくる。
たとえば、内部品質向上のために一定時間を確保して教育・研修に時間をかける。
ペアプロ・モブプロみたいに接触時間を長くしていくとどんどん若手が伸びていく。若手、ジュニアエンジニアをひとりにしないで一緒に開発していくと成長し戦力になり組織が健全化していく。
また、講演会事前の質問にも「リファクタにどれくらいの時間が必要か？」とあった。「開発の一定割合を内部品質の改善のためにしか使わないという枠を定期的に用意しておく」のが、唯一機能するやり方である。
社内の反響
「教育は「組織が破綻しない程度に若手を入れる」のが良さそうに思ってます」
「20%改善活動に時間を使うと決めて取り組んだことがあったけど、メインの開発が押して実質バッファみたいな枠になって機能しなかった」
「そもそも、用意した工数と対象のサイズが合わないと、放ったらかしになるんですよね」
「枠もとって、気軽に、息を吸うようにやるしかないんだろうなぁ」
質問その２
「スピード」と「品質」の両立できる開発チームだとPdM的には超嬉しいんですが、そのために必要なエンジニアのスキル/経験って何ですか？組織としてどういうことをしていくと、そのようなエンジニアが沢山いるもしくは組織的に担保できる組織になるでしょうか？（PdM）
t_wada さん回答
ソフトウェア開発における「設計の判断力」をどうやってつけるのか？ということと同義。設計の判断力は「ソフトウェア開発のライフサイクルを最初から最後まで経験する」とついてくる。対象システムの大きさというより、ライフサイクルの経験の数が重要。設計、開発、運用まで全部やる。「自分で判断したものがどうなるか、自分で目撃する」回数、密度がソフトウェアエンジニアの能力にかかわってくる。
このため「なるべく最初から最後まで、つまり設計から運用までを経験する機会をどうやって組織内に作るか」が重要。これをうまく作ることができると、設計の判断力のあるエンジニアがじわじわと増えてくる。また、コントロールしている状態で若手に失敗の経験を成長の機会として与えることも大切。
社内の反響
「自分の開発物に反省したときが一番記憶に染み付きます ...」
「お客様から怒られる含めて経験した重みが今を作っている気はする。」
「自分の意思決定で失敗したときが一番反省するし、改善策を本気で考える」
「近道はないけど、機会を奪わないようにすることはできる気がする」
質問その３
開発者のスキルという点では、サービスの成長に開発者の成長が追いつかず、いつの間にか質の低いコードしか作れなくなってしまった経験が何度かあります。このようなケースではどう対処していくべきなのでしょうか。
t_wada さん回答
自分の成長速度でしか成長できないので、外から連れてくるしかない。そうなる前までに、人を増やしても悪影響の及びにくいアーキテクチャや組織構造に投資する。
社内の反響
「そういうエンジニアになれば外でも価値がでますね！」
「つよつよエンジニアを外から引っ張ってくればいいのはその通りだなと思うけど、各社この考え方がいき過ぎて焼畑農業みたいになってるなって感じる。「誰も若手を育てていないのである！」みたいな」
「エンジニアが成長する組織システムとして設計できる人が少ないというか難しいですからね。」
質問その4
自分自身エンジニア経験はないが判断をしないといけない立場かつ0から作っているので背景がなんとなくわかっている状況下で、エンジニアからコード品質が、、、リファクタリングしたい、、、そのためには時間/リソースが必要という話がある。一方、スタートアップというある種、時間をお金で買っている中で、どこまでエンジニア側の話を取り入れるべきか？どういう判断軸を置くべきか？(PdM)
t_wada さん回答
今日の講演全体が一つの回答になっている。ただ、この問いからコミュニケーションの不足を感じる。そもそもが「同じ状況を共有しているチームの中でロールだけが違う環境」であって、納得感を持って判断を一致させていく必要がある。取り入れる、取り入れないという話の前段として、議論して決めましょうという話。
社内の反響
質問その5
「戦略的に技術的負債を積極的に取る必要があるとも言われますが、ここで対象となる技術的負債というのは、保守性の観点以外という理解でいいでしょうか？（「質とスピードがトレードオフではない」ということは理解しつつ、「戦略的に技術的負債を取る必要もある」とも思っており、一見相反する考えについてうまく整理できていないため質問しました）」
t_wada さん回答
「負債のメタファー」 Ward Cunningham （ウォード・カニンガム）を翻訳してブログにあげたもの（https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor）がある。本当の意味での技術的負債とは「自分たちのやりたいこととソフトウェアの間のずれ」である。ビジネスが育ったりドメインに詳しくなっていくと「もっとこうやるべきだ」とわかったものとソフトウェアがそうなっていないというところの差が技術的負債である。
それをどうやって克服していくか。技術的負債を取るとは、現状の自分達の理解でソフトウェアを作って、理解が育ったら現状の方がソフトウェアより先に行く。これが技術的負債。「自分達の理解とソフトウェアをどうやって同期させていくか」が技術的負債の本来の考え方である。
社内の反響
「戦略的に技術的負債を積極的に取る、とは言うものの
戦略的と行っておきながら返済計画とか体制が伴っていなことが多いですね
自分の収入に見合ったローンの返済をするのと同じ話なのに」
講演後の資料
多くの反応があり、時間が足りずに答えきれなかった質問もありました。
後日、共有をもらったスライド資料に、答えきれなかった質問に関するスライドなどを加えて共有していただきました！！
講演後の社内の反響とアンケート
講演を終えて「この講演は沢山されているので、過去の動画を見た上でQAをする、とかもやり方としてありかもあったのかと思っていましたが、リアルタイムでお話を聞いた上でみんなの考えがSlackでやり取りできるのは気づきが多いですね！」
「聞き終わった後の疲労が過去一でした」
との声がありました。講演を集中して聞きながら考えをSlackでやりとりした濃い時間となりました。
講演内容の満足度を教えてください？
講演内容は業務に活かせそうですか？
講演後の社内の反響 〜 業務に活かしたいポイントは？ 〜
アンケートから一部をご紹介します。
品質を削らない・人を増やしても解決しない。 意外と「合理的に考えたらこの選択になってました」みたいな場面が多いように思うので、この2つを意思決定するときに都度思い出したいと思いました！
「品質、スピード」は「会社、メンバーの成長や学習時間」トレードオフと言う点、とても大事だなと思いました。私は社内のフロントチーム用のシステム管理をしているので、「なる早でリリースしてほしい」という話が来ることが多いのですが、要件を詰めきれてないところや影響範囲が曖昧にな状態で要件整理をしてしまって、後で他の修正の時の管理負荷が増えてしまうことや、メンバーへの学習のためにお任せしたい部分が引き継げない属人化などの課題があります。スピード重視の作業の判断によって、最終的に後々の作業やに響いてしまう、ということを今回学べたので今後のチームの進め方を見直しして、今回の内容を活かしていきたいと思います。
最初の「品質とスピードはトレードオフできるか」という問いのスタートから、品質とスピードの関係性、定義のレベルを揃えてお話いただいたことで、普段もやもやしていた部分がスッと腑に落ちました。片方を犠牲にしていると、知らないうちに品質も犠牲になっていると言う点にも共感できました。
最後の「「品質、スピード」「会社、メンバーの成長や学習時間」」との関係性も個人的にとても納得していて、それを改善するためには「自分で開発したシステムを長い間メンテ、運用し続けることでエンジニアの設計の判断力が培われていく」というところについては、これから特に弊社に大事なポイントだなと思いました。
「設計力」ではなく「設計の判断力」、という言葉を使っていただいたところが目から鱗でした。
私はデザイナーですが、質＆スピードのテーマはエンジニアリングに閉じず、さまざまな現場で共通する課題だと感じ、デザインワークで時間があればもっとよくできるんですという言い訳をしていないか自戒しました。また、負債の生まれる構造についても、あの時ああしていなかったのは失敗だった。。という思考ではなく、必然的に生まれるものとしてどう向き合っていくかという思考に改めて切り替えるきっかけとなりました
質とスピードがトレードオフではない」というところ。Slack上で薬剤師Aさんがコメントしていた通り、薬剤師で考えたときにも同じような考え方ができるのではと思いました。 （薬剤師B)
技術広報 メッセージ
講演会を終えて
２時間という長丁場の講演でしたが非常に内容が濃くて時間があっという間でした！これだけの長丁場だと参加している数も途中で減っていくと思うのですが、最後までほとんど人数が減らずに150人以上の人が参加してくれました。
エンジニアも非常に盛り上がっていましたが、非エンジニアの人からも感想のフィードバックなどでも非常に好評を頂きました。
ビジネス系メンバーの声の１つに、途中で他の会議で抜けなければならなくなったが、講演に戻りたいと思いながら会議をしていたという話も聞いて、エンジニア以外からも価値を感じて頂けたようで嬉しく思いました。
このような企画ができたことを非常に嬉しく思っています！
こういう方にカケハシに来て欲しい
講演の中に言われていた中の１つに「仕様や技術的な意思決定をしたものが、ユーザーに利用されたときやシステムの運用したときどのような影響を受けるか体験して、良かったことや良くなかったことを学び、次の意思決定に活かせる経験を持つことが成長に良い」という話がありました。
質とスピードは相反するのではなく、その力を持つには経験の回数が大事。スタートアップで医療というドメインの業界を良くしようとする施策を目指す中で、来て頂きたい人には質の高い実装をスピードを維持できる形で実現できて、技術領域では強い意思決定の経験がある、開発をリードすることに自信のあるエンジニアに来ていただきたいです！
質とスピードを使って最速で日本の医療の世界を良くすることを目指しませんか？
株式会社カケハシ 採用サイト
テックブログ
募集一覧
