※本記事は、2021年3月に公開された内容です。

【ご登壇者】

• Sansan株式会社 執行役員／CTO　藤倉 成太 氏（モデレータ）
• 株式会社トラストバンク CTO／開発部長　山崎 賢 氏
• ナレッジスイート株式会社 取締役執行役員 DXビジネスユニット 開発部門管掌 兼 先進技術開発部部長　雄川 賢一 氏

2021年2月18日に開催されたCTOmeetup。今回は「リファクタリングから読み解くサービス成長」をテーマにディスカッションを行いました。
注目される3社がどのように技術選定やソースコードのアップデートを行っているのかをはじめ、失敗しないリファクタリングの方法などさまざまなエッセンスをお届けします。

登壇者のご紹介

出会いからイノベーションを生み出す Sansan

株式会社オージス総研でシリコンバレーに赴任し、現地ベンチャー企業との共同開発事業に携わる。帰国後は開発ツールなどの技術開発に従事する傍ら、金沢工業大学大学院工学研究科知的創造システム専攻を修了。2009年にSansan株式会社へ入社。現在はCTOとして、全社の技術戦略を指揮する。

Sansan株式会社 執行役員／CTO　藤倉 成太 氏（以下、藤倉）：Sansan株式会社のCTOを務めている藤倉と申します。入社したのは12年ほど前です。当社は「出会いからイノベーションを生み出す」というミッションを掲げており、メイン事業であるクラウド名刺管理サービス「Sansan」や名刺アプリ「Eight」を通じて、人と人との出会いを可視化してきました。

また、最近は新たにクラウド請求書受領サービス「Bill One」という事業を立ち上げました。SansanやEightが個人同士の接点を記録していたのに対して、Bill Oneは会社同士の接点を記録することがコンセプトとなっています。「月次決算」や「請求書」といったワードが出てくるのでFintechと思われることもあるのですが、Bill Oneはあくまで会社同士がどんな取引をしていて、どんな関係性があるのかを管理するサービスとして育てていきたいと考えています。

さらに少し宣伝させていただきたいのが「Builders Box」という情報サブスクリプションの取り組みです。

藤倉：日本の素晴らしいエンジニアリングをよりグローバルに戦えるレベルへ発展させていきたいという私の個人の強い思いもあり立ち上げました。直近では、ロバートC.マーチン氏にクリーンアーキテクチャについて解説いただきました。
「Builders Box」へ登録いただいた方にはオンラインコンテンツの紹介やイベントへの招待などをさせていただきます。

ナンバーワン規模のふるさと納税の総合サイトを運営するトラストバンク

1976年生まれ。2020年5月からCTOとして株式会社トラストバンクに入社。それ以前においても他企業でCTOや開発マネジャーを努め、組織改革／アーキテクチャ刷新など多くのプロジェクトを遂行。常に事業課題と開発組織を紐付けて最適化していくスタイルで開発組織を牽引している。

株式会社トラストバンク CTO／開発部長　山崎 賢 氏（以下、山崎）：株式会社トラストバンクでCTOを務める山崎と申します。僕はSIerからキャリアをスタートし、ヤフーに入社してオークションやショッピングなどEC系のエンジニアとして活動しました。その後ベンチャー企業を経てリクルートに入社し、ホットペッパービューティやホットペッパーグルメ、じゃらんなどの開発責任者及びマネージャーを務めました。前職ではアソビューのCTOでした。トラストバンクには2020年5月にジョインしています。

トラストバンクには「自立した持続可能な地域を作る」という大きなビジョンがありふるさと納税が当社の事業の柱になっています。

山崎：特に「ふるさとチョイス」というふるさと納税総合サイトは現状全国1570の自治体が掲載中で、お礼の品は30万点超にものぼります。ふるさと納税のサイトの中ではお礼の品掲載数・契約自治体数ナンバーワンの規模を維持しており、流通額は2017年時点でZOZOTOWNに次ぐ2100億円です。
このほか、例えばガバメントクラウドファンディングで首里城復興の寄付金を10億円以上集めるなど、地方の課題に対していろいろなチャレンジを行っています。

先進技術の研究開発を積極的に行うナレッジスイート

ゼネコンの設計部で社会人をスタート。IT業界に転身後、システム開発の上流工程から下流工程まで規模や分野を問わず様々な案件を担当。PG、SE、アーキテクト、ITコンサルティング、PM等幅広い経験を有する。2013年にナレッジスイート株式会社に入社、現在は技術部門を統括する取締役としてエンジニア組織のマネージメント及び技術戦略の立案等を担当する。

ナレッジスイート株式会社 取締役執行役員 DXビジネスユニット 開発部門管掌 兼 先進技術開発部部長　雄川 賢一 氏（以下、雄川）：ナレッジスイート株式会社の雄川と申します。僕は2013年に同社に入社し、2018年に技術部門を統括する立場として取締役に就任。現在は2020年10月に発足した先進技術部門の部長職も兼任しております。

当社は「脳力をフル活用できる世界へ。」というコンセプトで事業展開しており、SFAやCRMなどのクラウドサービスを提供しています。創業は2006年10月、現在の従業員数は連結で178名です。

社名と同じ「Knowledge Suite」という当社の主力製品はグループウェアとSFAが一体となったサービスで、中小企業をターゲットに低価格で提供させていただいてます。

今、売り出しているのは「VCRM」というWeb商談ツールです。リモートワークが増えている昨今の情勢でリモート商談を支援できるサービスだと考えており、会社として初めてCMも放映しました。現在無償キャンペーン中ですので、この機会に是非使ってみてください。

雄川：また、最近発足した先進技術開発部はリアルタイム系の技術をはじめ、コンテナオーケストレーションやフロントエンド、IoTデバイスなどさまざまな技術の研究開発を行っている部門です。絶賛採用募集中なので、興味のある方はHPからご応募いただければと思います。

なぜ技術の選定やリファクタリングが重要なのか

各社の技術責任者が定義する「リファクタリング」

藤倉：では早速ディスカッションをスタートします。まず、テーマを考えたときにリファクタリングといってもいろいろな意味合いがあると思ったんですよね。前提部分をすり合わせるために、みなさんにとっての「リファクタリングとは何か」をお伺いできますか？

山崎：ビッグワードですよね。ちょっとしたソフトウェアの改修からドラスティックな技術の変更まで広い範囲がリファクタリングに含まれると思います。もちろんエンジニア視点で見たときに単純に「このソースコードを書き換えたい」と思うのもリファクタリングの一部です。

ただ、僕にとっては「中長期的にビジネスにどう貢献するか」をベースとしながら、ソフトウェアのあるべき姿を探る未来志向の考えがリファクタリングであるという理解です。

藤倉：雄川さんはいかがですか？

雄川：技術視点と経営視点でかなり異なってくると思いますね。技術者から見た場合はとにかくきれいなソースコードや仕組みにしたいという部分が強く出てくると思うのですが、経営者から見たリファクタリングは「リスクの解消」だと考えています。
リスクというのは、例えばソフトウェアが人に依存した作りになっていたり、いわゆるスパゲティコードになっていて保守に対する工数が膨れ上がり、費用がかさんだりするといったことです。

藤倉：ありがとうございます。お二人が言及されているようにコードをきれいに書き換えるのもリファクタリングの一つです。あとは例えばAWSの新しいサービスが出てきたからアーキテクチャを変更したい、ドメインモデルを変更するために大規模に手を入れていかなければならない、基盤をオンプレからクラウドに変える、プログラミング言語を書き換えるといった話もリファクタリングに含まれるかもしれません。
ですが、我々の立場としては「事業を運営する上でどういう意味があるのか」というのがリファクタリングにおける非常に重要な要素ですよね。

リスクを取りに行く技術選定ができるシーンは限られている

藤倉：そもそも新規でプロダクトを作る際、技術選定を間違えるとリファクタリングしなければならないタイミングがかなり前倒しになってしまうと思います。みなさんが技術選定で気を付けていることはありますか？

雄川：技術選定とリファクタリングの方針はセットだと思っているので、技術選定についても基本的に「リスクをどう解消するか」という視点で選びますね。

藤倉：我々の立場からすると経営上のリスクは可能な限り少なくする、あるいはどうヘッジするかをあらかじめ考えることが必要ですよね。
とはいえリスクを取りに行くケースももちろんあると思いますが、このあたりについてどのように考えていますか？

山崎：ビジネスの中心部に関してはやはりリスクを取らない選択をすると思います。例えば新しいアーキテクチャを選んだら楽しそうでも、まだ利用者が少なく人柱になってしまうような技術であれば選択しません。ある程度ナレッジが蓄積されており、今いるメンバーが対応可能かどうか判断します。
一方で、ある程度切り離された小さな部分であれば、チャレンジとして新しい技術を選定することもあり得ます。ビジネスに対するインパクト次第で考え方を変えるかもしれませんね。

藤倉：雄川さんはリスクの取り方についていかがですか？

雄川：ほぼ山崎さんと同意見です。どうしても新しい技術を採用したいケースも出てくると思いますが、そのときはどこに適用すれば一番リスクが少ないかを考えながら導入することになるでしょうね。あとは、リスクを取りに行くときは対応できる人がいるかどうかや、リスクを取れる環境かどうかが大きな判断基準になります。

SIと事業会社ではリスクの取り方が異なる

藤倉：僕は前職がSIerでいわゆる受託開発をしていましたが、SIと事業会社ではリスクの取り方が違うと思うことが多いです。例えば自分がSIを運営するなら、複数のプロジェクトを同時並行で走らせますよね。もし一つのプロジェクトで何か想定外のことが発生すれば横から人を持ってきて、トラブルが解消したらまた戻す。こうした取り組みで成功率を上げていくことになるので、「この人にしか解決できない」という問題はあってはいけません。
一方で我々のような事業会社の場合、複数のプロジェクトで人を行ったり来たりさせるようなリソースマネジメントはSIに比べて少ないので、2～3人しか扱えないような技術領域でも多少は手を伸ばせる余地があると思っています。
SIの方は「会社から認められていないから技術的なチャレンジができない」というフラストレーションを抱えていることが多いのですが、そこはやはり業態や会社の経営方針に依存してしまうなと感じます。

山崎：おっしゃる通りですね。リファクタリングによってビジネスに貢献しなければいけないのはもちろんなのですが、我々は事業会社なので、「働いているエンジニアがきちんとスキルアップできるか」という視点もあります。リスクを取った新しいチャレンジを継続的に外部に発信し、組織で働いているメンバーの市場価値を高めるという側面でもリファクタリングには意味があると思っています。

リファクタリングを行うタイミング

藤倉：今回視聴者の中にはどんなタイミングでリファクタリングをするのがいいか悩まれている方も多いと思うのですが、何か基本的な考え方や方針はありますか？

山崎：企業規模にもよりますが、リファクタリングは例えるなら数年に1回行う車検のような、義務的なイベントであってほしいですね。ビジネスを継続している限りソフトウェアは必ず劣化するものなので、最初から決め事としてリファクタリングの工数を確保しておくんです。工数を常に薄く設定しておくのか、3年に1度大きなターンにするのかは考え方次第ですが、こういったことを経営とネゴシエーションするとやりやすいのかなと思います。

雄川：僕の場合はエンジニアからリスクに関する報告を受けて、それにどう対処するかを決める感じです。リスクを放置した結果損害が出そうならなるべく早く片付けなければいけませんが、財務状況的に厳しいケースもあります。ですから最終的にリファクタリングするかどうかは、報告を受けた後にリスクと予算のバランスを見ながら判断することになりますね。
ただ、ある部分を共通モジュールに変えるといった小さなリファクタリングは、機能改修のついでにやれたりします。

リファクタリングをすべきかどうか、正しく判断するには？

山崎：リファクタリングで難しいなと思うのが、個人のエッセンスが含まれてしまうことです。基本的にエンジニアはきれいなソースコードでソフトウェアを書きたいと思うのですが、Aさんの作ったソフトウェアがBさんにとってもきれいだとは限らない。「このソフトウェアは複雑だから直したい」と言われたときにそういう要素を踏まえて正しい判断をしなければならないので、非常に苦労しています。藤倉さんや雄川さんは現場からそういった案件が上がってきたらどう判断していますか？

藤倉：「書き換える意味を理解できるか」「筋が通っているか」という判断基準があるかなと思います。「今回の改修でついでに同じファイルにある別のメソッドを書き換えました」と言われたら「なんで？」ですよね。でもこれが例えば「チームの方針として次のプロジェクトでここを共通モジュールにしておきたいので、一旦ワンクッション置くためにこの書き方にそろえています」と言われれば是とされると考えます。

雄川：僕も基本的には同じ考え方です。やはりリファクタリングをすることで何が解決されるのかが基準になりますね。山崎さんもおっしゃった通り誰かが「きれいに作りたい」と言ってもそれが他の人にとってもきれいかどうかはわかりませんが、誰がやっても問題が解消されるのであれば、リファクタリングは成功です。そもそもリファクタリングはソースコードを書き換える時点でリスクがありますから、慎重に考えますね。

山崎：ありがとうございます。成長しているビジネスのソフトウェアは基本的にどうあがいても複雑なのだろうと思うんです。単純にソフトウェアのクラス設計を見直すなら現場でやればいいのですが、大きなリファクタリングをするなら社内全体を巻き込んだ上で、その仕様が本当に必要なのかどうかから紐解いていく必要があります。そうでなければ、本当にきれいなソフトウェアにはできません。そこが悩みどころですね。

雄川：大規模な場合は仕様も含め、サービス自体を見直すレベルですよね。

山崎：とある論文では「ソフトウェアで表現しているものの8割は動かないコードだ」と言われているのですが、これは誰かが入れた仕様を削ぎ落としていないから、ずっと存在してしまうということですよね。リファクタリングで必要な仕様だけに落とすことができたらいいなと思います。

雄川：既に提供されているサービスの仕様を削ぎ落とすのは難しくないですか？

山崎：おっしゃる通りです。そこがリファクタリングの課題なのかなと思います。

リファクタリングから読み解くサービス成長

上司にOKと言わせるリファクタリングプロジェクトの立ち上げ方

藤倉：事前質問でもいただいている内容ですが、上司に対してリファクタリングすることをどう説得するのかという視点があります。お二人は部下からの説得を受ける立場だと思いますが、どういうケースはOKで、どういうケースはNGになるのでしょうか？

山崎：僕はシステムをこのまま継続したパターンとリファクタリングしたパターンで損益分岐点を指し示し、経営にジャッジしてもらったことがあります。求める数字は、例えば機能追加をする際にシステムの複雑性がどれくらいの係数になるのか、あるいは障害が現状のパーセンテージで発生したら対応のためにどの程度の工数が必要になるのかといったものです。2、3回同じように稟議を通すことで信頼感に加えて「リファクタリングは必要な工数である」という共通理解が生まれるので、その後はやりやすくなります。
リファクタリングを実施する背景には、エンジニアがビジネスに対する価値の定量化にチャレンジする必要があるのかなと思いますね。

雄川：同感です。先ほどもお話した通り、経営視点で見たリファクタリングというのは「リスクをどう解消するか」がポイントです。
同リスクがどれくらい高いのか、いつまでに解消しなければいけないのかといった情報を経営層に渡すことが、説得への近道になります。

リファクタリングによってドメインモデルやインフラ基盤に成功した例

藤倉：失敗談は先ほど少し触れていただきましたが、逆に成功した経験はありますか？

雄川：6年程かけてリファクタリングした話は成功経験でもありますね。長かったですが、全て書き変わったときは気持ち良かったです。

藤倉：僕も一つご紹介します。Sansanに入社した当初、法人向けのプロダクトの中心は「名刺」でした。同じ人物の名刺が複数枚あった場合に人物と名刺は1体ｎの関係になるのですが、そもそもデータベースに「人物」というテーブルが無かったんです。
しかし当時、我々のプロダクトの本質は「名刺」ではなく「人と人とのつながり」ではないかと議論されていました。そして新たに「人物」という概念を組み込まない限りこのプロダクトは発展しないということで、データベースのスキーマを変えるプロジェクトが立ち上がりました。僕はプロジェクトをリードするために入社したわけです。ドメインモデルを変えるためのリファクタリングですね。
当時の開発エンジニアは5～6名だったのですが、入社してから3ヶ月ほどで僕がプランを立て、あとは丸一年、エンジニア全員が新規開発を止めてリファクタリングを行いました。性能の問題がありリリース自体は1ヶ月ほど後ろ倒しになったものの、それ以外は計画通りに進められたので良かったと思っています。

山崎：僕はリクルート時代にインフラを移行するプロジェクトに参加したことがあります。当時のリクルートはオンプレミスでサーバー運用をしていたのですが、新たにAWSの基盤を構築し、リクルート内にある情報のルールを吸収できる環境を展開しようとしていました。
その基盤が現在もリクルート全体で使われているそうなので、価値ある仕事にチャレンジできたと感じています。

リファクタリングに失敗しないコツは「範囲を限定して完遂すること」

藤倉：みなさんの中で、リファクタリングに失敗しないコツのようなものはあるのでしょうか？

雄川：しっかり目標を定めてリファクタリングすることですね。また、無理が無い形で少しずつ進めるのも手だと思います。途中で挫折すると共通モジュールで作ったものが生き残って2本になってしまうので、やり遂げる気持ちが必要です。

山崎：全く同意見です。手を出す範囲を限定的にした上で、必ず完遂することを目標にする。これが前提です。
また、長い間裏側でリファクタリングしていると表側で機能追加したときに追従しなければいけなくなるので、少しずつ新しいものに置き換えていける仕組みをセットで考えることも大事にしています。

藤倉：アーキテクチャなんかを書き換えようと思ったら、最長で6年は取り組むつもりで向き合ってほしいという感じですかね。

山崎：途中で終わると技術負債が倍になりますからね。

雄川：リファクタリングをするとバグが混入するケースもありますよね。テストでどのように品質を担保するかもセットで考える必要があるかなと思います。

仕様を削るかどうかの議論にはビジネスサイドも巻き込みたい

藤倉：仕様を削ることができるかどうかについて先ほどは決着がつきませんでしたが、みなさんは実体験として仕様を削ってでもリファクタリングをした経験はありますか？

山崎：ビジネスとしてほぼ使われていない決済手段を外した経験はあります。

雄川：僕は仕様を削ったことはありません。仕様は変えないまま進めるケースが多いです。

藤倉：実は僕も仕様を削った経験はありません。現場から「この仕様が理由でメンテナンスや機能追加ができないし、パフォーマンスも出ない。もう削りましょう」と言われても、別の案を考えたら意外とクリアできてしまうんですよね。仕様を削らなければどうにもならないような状況は、あまり見たことがありません。
山崎さんがおっしゃった例は削らざるを得なかったというよりは、「使われなくなっているから切り離してきれいにしよう」というポジティブなケースだと思います。

山崎：理想としては、ビジネスサイドと会話がしたいんですよね。ビジネスとエンジニアの間で共通言語をそろえる必要がありますし、例えばドメインモデルの定義をはじめ、今ある仕様の中でどれを残してどれを捨てるのか、同じフィールドで議論できたらいいなという思いがあります。リファクタリングという活動がエンジニアだけではなく、会社全体のものになったいいなと。

雄川：そういう状況だとエンジニアも前向きに取り組めますよね。

あらかじめリファクタリングの「工数予算」を確保しておくと楽

藤倉：新規開発とリファクタリングにかける工数はどんな割合ならいいのかという話もよく出ると思うのですが、考え方やコツはありますか？

雄川：例えば機能開発もセキュリティリスクを下げるためのリファクタリングも、同列で考えて進めています。分けるとどうしても機能開発に偏ってしまう気がするので、あえて差をつけずに判断するようにしているんです。

山崎：僕も同じですね。一気に変えなければいけないようなケースを除外して考えると、リファクタリングは継続的な活動として少しずつ良くしていく方がいい。そのためには、リファクタリングをビジネス側からは見えない工数として聖域化することが結構あります。インフラエンジニアの開発が工数に入らないのと同じように、リファクタリングの工数を10～20％ほどあらかじめ分けておくんです。都度ビジネス側の承認が必要なくなるので楽ですよ。

藤倉：うちも山崎さんの考えに近いかもしれません。エンジニアは1日8時間働いていても、その全てを開発業務に充てているというわけではありませんよね。全社会議に出ていたり、面接官をやっていたりもします。そこであらかじめ、「60％～70％は開発の工数である」という計算をします。人数で合算すると数千時間が開発に使えるリソースだということですね。ここから例えば、プロダクトの未来を作るような案件や営業やコンサルタントがどうしても実現したい案件に使う割合を決める。こういった「工数予算」と呼ばれるものをきっちりクォーターごとに作っていき、その中にリファクタリングも含めます。工数予算と実績が乖離していないかどうかが経営に対するレポートにもなっています。

Youtubeライブでリアルタイムに質疑応答

大規模なリファクタリングは薄皮を剥がすように少しずつ取り組むべし

質問者：共通モジュールが入り組んでおり大規模な改修が必要な場合に、手を入れて失敗してしまった例はありますか？

山崎：山を登りきれなかったことはありますね。誰もが知るような巨大なサービスだったのですが、共通モジュールが全てのモジュールに依存しており、複雑な仕様を全て抱え込んでいました。そこが常にボトルネックになっていることは全エンジニアがわかっていたのですが、そこにメスを入れるのが非常に難しかった。最終的に本当に重要な機能だけは切り離したものの、共通モジュール本体をなくすことはできませんでした。やるなら全部作り直しになるレベルでしたし、今も違う方法を考えられるかどうかは悩むような失敗談ですね。

雄川：僕は前職でそれなりに大きなシステムを見ていて、やはり山崎さんのような状況でした。そのときは少しずつ改善してやりきりはしたのですが、6年程かかりました。

藤倉：やはり我々が扱うシステムは常に新陳代謝していかなければいけませんよね。そうでないと、いつかどこかで完全に書き換える必要が出てきます。
山崎さんのケースも、本当に少しずつ薄皮を剥がすように改善を繰り返す方法しか無いのだと思います。それができるかできないかという話ですね。

「目的を決めない」「手段の目的化」はアンチパターン

質問者：リファクタリングのアンチパターンはありますか？

雄川：「このぐらい時間があるからとりあえず実施しよう」という形で進めるのは厳しいと思います。やはり「ここを変えていこう」というリファクタリングの目的がないと破綻しますし、期間を決めると突貫になってしまいます。

山崎：人によるかもしれませんが、手段を目的化したリファクタリングはアンチパターンだと考えています。リファクタリングの多くは生産性に寄与するものだと思いますが、生産性というものはソフトウェアを作るだけではなく、どんな仕様にするかはもちろんどれだけテストを簡単にできるかなども大きく関わります。例えば教科書に乗っているようなマイクロサービスの分け方をそのまま取り入れてみたら、「こんなつもりじゃなかった」という事態が発生しがちです。きちんとシステムの現実と前後関係を見るのは、アンチパターンを作らない考え方として大切にしています。

藤倉：しっかり目標を定め、計画を立てた上で確実にやりきるということですね。

リファクタリングにおいてテスト自動化は必須条件

質問者：リファクタリングする際のテストの考え方や方法論などはありますか？

山崎：うちの場合はWebサービスなので、リファクタリングするのであればテストはほぼ自動で回るような仕組みをセットで提供するのが大事かなと思います。テストコードをセットで書けばCIで自動的に回るとか、E2Eのように外から叩くテストが定常的に回るといった仕組みを整えてからでないと、怖くてリファクタリングできません。

雄川：テスト自動化ができていないと、手動で全件テストするのが厳しくなったときにバグが残ってしまうんですよね。6年間かけてリファクタリングしたときも完全にテストを自動化していて、45万ケースほどテストを組ませていました。新旧両方叩いて完全に一致するかどうかまで見ていたと思います。

藤倉：ユニットテストとE2Eテストは可能な限り常時用意されているのが理想ですよね。それが無いとすれば、リファクタリングのプロジェクトの一環としてまずテストを書くことから始めるのが重要かもしれません。

最後にひとこと

ゴールに至るための道筋を立てればリファクタリングは成功する

藤倉：では最後皆さんから一言ずつお願いします。

雄川：何度もお話ししましたが、リファクタリングは何を解消するのかを明確に定めてブレないように進めれば実行できると思っています。定めた目標を上司に提案すれば必要な対応をしてくれるはずなので、ぜひ試してみてください。

山崎：ゴールに至らないリファクタリングは何も生み出さない作業になってしまうので、自分たちできちんとゴールまでの道筋を考えるのも重要です。今日ご参加された皆さんがリファクタリングをするのであれば、ぜひ「この期間でここまでやりましょう」というところまで社内で議論していただけたらなと思います。

藤倉：お二人に完全に同意します。視聴者の中にはリファクタリングをプロジェクトとして立ち上げきれなかった苦い経験がある方もいるかもしれませんが、僕は「変えたほうがいいのでは」という気付きが非常に重要だと思っています。
とはいえ、最初から自分の感覚を理路整然と整えられるわけではありません。立ち上げに失敗してしまったという場合は、「なぜ自分はそれを美しくしたいと思ったのか」を言語化し、経営が理解できる数字やストーリーを紡ぐ努力が足りなかったのかもしれません。ぜひエンジニアとしての嗅覚は大事にしてほしいと思います。
では、ディスカッションは以上とさせていただきます。本日はありがとうございました！