ソフトウェアエンジニアとしてプロダクト開発に携わって丸10年、ようやくスタート地点に立ちました

ソフトウェアエンジニアとしてプロダクト開発に携わって、丸10年が経ちました。

この記事は、その10年を振り返りながら、今の私がプロダクト開発とどのように向き合い、何を考えているのかを整理したものです。自分自身の現在地を言語化する、いわば自己分析のような意味合いもあります。また、未来の自分が振り返れるように書いている部分もあるため、やや長く読みにくいところもあるかもしれませんが、その点はご了承ください。

10年が経過し、私自身が「良い」と思うプロダクト開発やソフトウェア開発、そしてその中で大切にしていることを、少しずつ言語化できるようになってきました。そのため、この記事ではそれらを整理して書いてみるとともに、そこから自分のこれからの方向性についても考えてみたいと思います。

なお、ここで書く内容は、あくまで私個人の経験と解釈にもとづく整理です。間違いや、今後考えが変わることも十分にあり得ます。その前提で読んでいただけると嬉しいです。

0. 導入：10年経ってようやくスタート地点

私がソフトウェアエンジニアとして、プロダクト開発において最も大切にしていることは、 「良いプロダクトを作ること」 です。（これはあくまでソフトウェアエンジニアとしての前提の話であり、一個人としては、プロダクト開発を通じて、その先にある社会課題の解決につながってほしいという想いも持っています。）

そもそもの「良いプロダクト」とは何か、そしてそれをどのように作るのかについては後述していきます。ただ、この10年を通して、目の前の 一つの断片的なコードが、どのようにして良いプロダクトにつながっていくのか を、大まかには描けるようになりました。

しかし、それはあくまで 関係性の構造を理解できた という段階に過ぎません。構造が見えたことで、どのような知識や能力が必要なのかも見えてきましたが、同時に、それらに対して自分の学びがまだ十分ではないことも強く認識するようになりました。

つまり、ようやく 進むべき道が見えた という感覚です。そして今、自分はその スタート地点に立てた のだと思っています。

以降では、この10年で学んできた、プロダクト開発やソフトウェア開発について、私の解釈をまとめます。そして、その整理を通じて、これからの自分の進路を考察してみたいと思います。

1. プロダクトや関連する言葉の定義や整理

まず、私が考える「良いプロダクト」について書いていく前に、この記事で用いる言葉の前提を揃えておきたいと思います。プロダクト開発では、同じ言葉を使っていても、人によって思い浮かべている意味が異なることが少なくありません。特に抽象度の高い概念ほど、そのズレは起きやすいと感じています。

そのため、このセクションでは、この記事の中で用いる言葉の定義を先に整理しておきます。ここで示す定義は、読者それぞれの前提によって解釈が大きくズレてしまうのを防ぐためのものです。参考として読んでもらえたら嬉しいですが、あくまで私個人の整理に過ぎません。 プロダクト開発においては、まず全体で言葉の定義を揃えること自体が非常に重要 だと私は考えています。

1.1 プロダクトの定義

まず「プロダクト」の定義ですが、私は 「価値を提供する手段」 だと捉えています。この定義は、 2020年版スクラムガイドの日本語訳 にある以下の記述をベースにしています。

プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。

ここで私は、「提供する」という動詞が取りうる「誰に」という目的語は、「明確に定義されたユーザーや顧客」を指すと考えています。もちろん「既知のステークホルダー」にも、結果として間接的に価値がもたらされます。しかしプロダクト視点では、ステークホルダーはプロダクトを使って価値を提供する人（手段の実行者や支援者、利害関係者）だと思うので、「誰に」に含める必要はない、という考えです。

この前提に立つと、少なくとも「明確な境界」「既知のステークホルダー」「明確に定義されたユーザーや顧客」「提供したい価値」を定めることで、プロダクトの輪郭はかなり具体化できると考えています。たとえば医療という事業領域（明確な境界）において、医療事業者（既知のステークホルダー）が、皮膚の異常に苦しむ人（明確に定義されたユーザーや顧客）に、皮膚が健康な状態（提供したい価値）を提供したいとなれば、その手段として皮膚科クリニック（プロダクト）が考えられるでしょう。

だからこそプロダクト開発において大事なのは、 「明確な境界」「既知のステークホルダー」「明確に定義されたユーザーや顧客」「提供したい価値」を定義して認識を合わせること だと考えています。

また、この中でも「提供したい価値」はまだ抽象度が高いので、少し深掘りしてみます。

1.2 価値の定義

アジャイルなプロダクトづくり という本の中で、 「プロダクトとは、問題と解決状態の一致を作るための存在」 という表現が使われています（P89）。

スクラムガイドの「価値を提供する手段」とは言葉遣いは異なりますが、根底にある考え方はかなり近いものだと捉えています。私の理解では、「問題と解決状態の一致を作る」は、「価値を提供する」を一段具象化した表現だと捉えています。「価値を提供する手段」という表現は抽象度が高く、プロダクト全体を広く捉えやすいため、前節ではプロダクトの定義としてこちらを採用しました。

一方で、「価値」という言葉自体は抽象的で、人によって解釈がブレやすいと感じています。そこで本記事では、「価値」をもう少し具体的に捉えるために、「問題」「解決状態」「一致」という表現を補助線として使います（そのため同書を引用させていただきました）。「価値を提供しましょう」と言うと抽象的ですが、「ユーザーが抱える問題に対する解決状態を定義し、それを一致させましょう」と言い換えると、取り組む対象がかなり明確になるのではないでしょうか。

また、仮に解決状態を定義できていたとしても、実際にその状態を問題に対して一致させられなければ、価値を提供できたとは言いづらいでしょう。先ほどの皮膚科の例で考えると、皮膚が荒れている原因を特定できたとしても、それが治癒された状態に至らなければ、その皮膚科に価値を感じにくいはずです。さらに言えば、原因自体を特定できなければ、価値はより感じにくくなると思います。

このような理由から、この記事では一旦、 「価値」を「問題と解決状態の一致」 と定義します。

補足として、同書では続けて「問題が確かに存在し、解決に値するものでなければ成り立ちもしない」とも述べられています。プロダクトの存在意義を、非常に端的に表した表現だと感じています。

2. 良いプロダクトとは

ここでは、私が目指している「良いプロダクト」を定義します。私は良いプロダクトを、 「多くのユーザーに多くの価値を、必要な期間にわたって提供し続けられるもの」 だと捉えています。

この定義は、大きく次の2つの観点に分解できます。

• 価値の提供量（どれだけ多くの価値を提供しているか）
• 持続性（どれだけの期間、価値を提供し続けられるか）

前者は、「プロダクト＝価値を提供する手段」という定義から自然に導かれる観点です。一方で後者をあえて含めているのは、価値は「一時的に提供できれば良い」のではなく、ユーザーにとって必要な期間にわたって提供し続けることが重要だと考えているからです。

たとえば皮膚科を例に考えてみます。先生の人柄が素晴らしく、居心地はとても良いです。しかし根気よく治療を続けても、全く改善しなかったら、どれだけ体験が良くても「良い」とは感じにくいでしょう。多くの場合、ユーザーは完治という目的で通院しているでしょう。その期待に応えたときに、良いと評価されるはずです。

検索エンジンのようなサービスの場合、ユーザーが期待する「必要な期間」は、半永久的になると考えています。そのため、最初の数年程度は非常に使いやすかったとしても、その後に時代の変化に追いつけず、たとえばAI検索などに対応できなくなって使いにくくなれば、ユーザーは不満を覚え、次第に使わなくなっていくでしょう。半永久的に使えることを期待しているからこそ、後半で価値を提供し続けられなくなったとき、プロダクトとしての評価も下がってしまうと考えています。

このように考えると、 価値の提供量 と 持続性 の2つの観点は、プロダクトの「良さ」を評価するうえで欠かせない要素だと考えています。

2.1 「良い」のイメージ

言葉だけでは伝わりにくい部分もあるので、ここではグラフを使ってイメージしてみます。下のグラフは、単位時間あたりの価値の提供量を表したものです。

私がイメージしている良いプロダクトは、このグラフの 面積が大きい、つまり価値の総量が大きいもの です。同じ前提条件で、もう一つ別のパターンも用意しました。面積を比べると、およそ 1.5 倍ほどパターン1のほうが大きくなっています。どちらが良いプロダクトかと問われれば、多くの人が直感的にパターン1を選ぶのではないでしょうか。

ただし、プロダクトが提供すべき期間が半永久的だとしたら、この時点で単純に面積を計算することはできません。将来どのように価値の提供量が変化していくかは分からないからです。そのため、良いプロダクトを作る上で大事なのは、現時点の面積だけを見るのではなく、 将来に向けてこの面積がどのように広がっていくかを想像しながら取り組むこと だと考えています。

なお、ここまでの話を踏まえると、 「良さとは、時間軸で積分した価値の提供」 と定義できるかもしれません（これは後述する Googleのソフトウェアエンジニアリング における言い回しを、少し拝借した表現です）。

2.2 大切なこと

ここまでに示した図や例は、あくまでイメージを掴むためのものです。現実には同じプロダクトは存在しないため、価値の総量を面積として厳密に比較することはできません。仮に似たようなプロダクトがあったとしても、何を価値と捉えるかはプロダクトごとに異なります。

それでも私がこの見方を採用している理由は、「短期の最大化」と「長期の最大化」を同じ土俵で考えやすくなるからです。良いプロダクトを作るには、 今この瞬間にどれだけ価値を提供できているかだけでなく、将来に向けて価値の総量をどれだけ伸ばせるかまで含めて意思決定すること が重要だと考えています。もちろん、プロダクトの置かれた状況やフェーズによっては、将来の価値提供量をある程度犠牲にすることを理解したうえで、今を優先する判断もあり得ます。

また、この「良いプロダクト」の定義は、ステークホルダーによって変わるものです。ここで述べている定義を押し付けたいわけではありませんし、むしろ、組織や事業ごとに「何を良いとするか」を言語化し、揃えておくこと自体が重要だと考えています。それは、おそらく掲げているミッションやビジョンから導き出せるはずです。プロダクト開発に関わる全員が同じ方向を向いて進んでいけるように、 良いプロダクトの定義、もしくはプロダクトのゴールを明確にしておくこと が大切だと考えています。

2.3 補足：価値の総量は売り上げではない

ここまで述べてきた私なりの定義に基づくと、目指すべきものは価値の総量を増やすことになります。一方で、多くの企業では事業目標として売り上げが置かれているため、価値の総量を売り上げと同一視したり、売り上げを上げることがそのまま良いプロダクトにつながると誤解してしまうことがあります。

私は、 価値の総量は売り上げ（または GMV など）では近似できない と考えています。その理由をいくつかの観点に分けて整理します。

2.3.1 売り上げは何を表していて、何を表していないか

売り上げは事業において重要な指標ですが、それはあくまで「金銭の支払い」を表しているに過ぎません。「ユーザーが得た価値」そのものを直接表しているわけではありません。

たとえば皮膚科を例に考えてみます。価値の総量を売り上げだと捉えてしまうと、あえて治療を長引かせることで売り上げを伸ばすことも可能でしょう。しかし、その結果としてユーザーが得る価値は明らかに下がっています。売り上げは増えていても、プロダクトとしては劣化している状態です。当然ながら、それは良いプロダクトとは言えません。

このように、売り上げは「結果として支払われたお金」を表す指標であって、「どのような価値が、どの程度提供されたのか」までは語ってくれません。

ただし、売り上げを見なくてよいと言いたいわけではありません。事業を存続させ、プロダクトを持続的に提供していくためには、売り上げはステークホルダーにとって重要なニーズの一つでしょう。ただし、盲目的に売り上げを追うのではなく、売り上げという指標が「何を表していて、何を表していないのか」を理解したうえで扱うことが大切だと思います。

以下の記事は GDP を題材にしていますが、売り上げという指標にも通じる話だと感じたので、興味があれば参考として読んでみてください。
その指標は何を見逃しているか？ーBeyond GDP

2.3.2 価値の総量を数値で近似するということ

価値の総量は、「問題と解決状態の一致」の積み重ねだと捉えています。そのため、解決状態を定義できなければ、価値の総量を数値として表すことは難しいと考えています。

それでも価値の総量を定量的に扱いたいのであれば、 まず「明確な境界」「明確に定義されたユーザーや顧客」「提供したい価値」を定義し、そのうえで、どの数値指標を使えば価値を近似できるかを丁寧に考える必要があります 。単一の指標で捉えるのは難しいため、複数の指標を組み合わせる前提で考えるほうが現実的でしょう。

（想像にはなりますが）皮膚科であれば、新規患者数、改善率、治療中断率、一定期間内の再発率、レビューやアンケートの満足度などで、価値の総量を近似することになるかもしれません。

2.3.3 数値をゴールにしないという考え方

ここで私が特に重要だと思っているのは、 数値をゴールそのものにしない ことです。数値はあくまで「観測のための手段」に過ぎません。

この点を説明する考え方として、 グッドハートの法則（Goodhart's Law） があります。これは「ある指標が目標になると、その時点でその指標は良い指標ではなくなる」というものです。

たとえば皮膚科で売り上げを目標に設定してしまうと、治療を長引かせるという歪んだ行動が生まれるかもしれません。また、数年前には車の修理事業において、わざと車を壊して修理代を水増しする不正が発覚し、社会的な問題にもなりました。数値を目的化すると、このような歪みが起きやすくなると感じています。

私は、プロダクトは価値を提供することそのものが目的だと捉えています。そのため、 価値を提供することを目的に行動し、その結果を数値で捉える という順序が良いと思います。目的や目標と指標の立て方については、 OKR という手法が参考になるかもしれません。
OKR シリコンバレー式で大胆な目標を達成する方法

3. 良いプロダクトを作るには

ここからがこの記事の本題です。ここまで整理してきた考えを踏まえ、私が考える「良いプロダクトの作り方」を、順を追って書いていきます。

まず、ここまでの重要なポイントを整理します。

• プロダクトは価値を提供する手段である
• プロダクト開発において大事なのは、以下を定義して認識を揃えること
  • 明確な境界（事業領域・スコープ）
  • 既知のステークホルダー（提供する側・利害関係者）
  • 明確に定義されたユーザーや顧客
  • 提供したい価値（問題と解決状態の一致）
• 私が考える良いプロダクトとは、多くのユーザーに多くの価値を、必要な期間にわたって提供し続けられるもの
  • 価値の提供量（どれだけ多くの価値を提供しているか）
  • 持続性（どれだけの期間、価値を提供し続けられるか）

ここに挙げたものは、すべて「目的」にあたります。次に、この目的を満たすために、私が有効だと考えている「手段」を挙げます。

• 上記のプロダクトの目的を明確に定義する
• ユーザーに会い、問題や解決状態を学ぶ
• プロダクトの具体的な実現方法を考える（店舗、サービス、ソフトウェアなど）
• プロダクトを作るための体制や進め方を考える（体制、役割、開発プロセス）
• プロダクトを作る

私が重要だと考えているのは、この 順番を守ること です。上に挙げた項目を省いたり、あるいは下の項目から始めてしまうと、意図しない方向に進んだり、結果として的外れなプロダクトになりやすいと考えています。

3.1 プロダクトの目的を明確に定義する

先ほど挙げたとおり、ここで決めるべきことは多岐にわたります。ただし、 このフェーズにどれだけ時間と意識を割けるかが、その後のプロダクトの質を大きく左右する と考えています。この解像度が低いまま進むと、完成したプロダクトが提供する価値も必然的に曖昧になります。

もちろん、最初からすべてを高い解像度で定義するのは難しいでしょう。ユーザーに会い、実際にプロダクトを開発していく中で、初めて見えてくるものも多くあります。そのため、一度決めた内容を放置せず、何度も立ち返りながら解像度を上げていくことが重要です。ただし、それは最初の解像度を妥協してよい、という意味ではありません。その時点で出せる 最大限の解像度を目指す ことが大切だと考えています。

このプロセスを支援する手法としては、インセプションデッキやリーンキャンバスなどがよく知られています。ただし、重要なのは「どの手法を使うか」ではありません。 プロダクトの目的を明確にすることそのものが本質 であり、手法はあくまでそのための補助に過ぎないと考えています。

3.2 ユーザーに会い、問題や解決状態を学ぶ

目的を定義できたら、実際にユーザーに会いましょう。前提として、 私たちは知らないことが多い という認識を持つ必要があり、それを教えてくれるのはユーザーです。

特に、「私は知っている」と感じたときほど注意が必要です。たとえ自分自身がそのユーザーであったとしても、それはあくまで一人分の経験に過ぎません。自分の感じている問題は、自分だけの問題かもしれません。母数は 1 です。だからこそ、できるだけ多くのユーザーに会い、直接学ぶことが重要だと考えています。

では、ユーザーに会わないことが正当化される場面はあるでしょうか。コストを理由に、ユーザーに会わない判断を正当化しようとする場面を見かけることがあります。しかし一般的には、ユーザーに会うためのコストよりも、プロダクトを開発するコストのほうが十分に大きいのではないでしょうか。ユーザーに会わず、想像だけでプロダクトを作り、結果として的外れなものを作ってしまうリスクを考えると、ユーザーに会うほうが、プロダクトの成功確率を高められると私は考えています。

もちろん、これはリスクとリターンのバランスを踏まえた話です。ユーザーに会うコストが極端に高い、ユーザーに会ってもプロダクトにほとんど影響を与えない、失敗しても大きなコストがかからない、あるいはユーザーに会わなくても（何らかの理由で）良いプロダクトを作れてしまう、といった条件がそろうのであれば、会わない判断が正当化されることもあるでしょう。

また、ユーザーに会うのは一度きりでは不十分だと考えています。世の中の変化は早く、ユーザーが抱える問題や、理想とする解決状態も時間とともに変化していきます。たとえば近年では、生成 AI の登場によって、一部の人の働き方や生活が大きく変わりました。以前は専門家に依頼していた情報収集が、生成 AI によってある程度自己完結できるようになり、その結果、問題の形自体が「どうやって情報を集めるか」から「信頼できる情報かどうか」といった別のものに変化しています。

だからこそ、 ユーザーに会うことを前提にしながら、問題と解決状態を継続的に更新し続ける必要がある と考えています。

3.2.1 危険な勘違い

ユーザーに会わず、想像だけで作ったプロダクトであっても、ローンチがうまくいくケースはあります。私は、このケースこそが最も危険だと考えています。うまくいってしまったがゆえに、 「私たちは分かっている」と勘違いしやすくなる からです。

最初のローンチがうまくいくこと自体は、決して不思議なことではありません。一定の論理性があれば、ユーザーが抱える問題に対して、ある程度の解決手段を提供することはできます。しかし、ユーザーの声を聞かないまま開発を進め続けると、少しずつズレが広がっていきます。

たとえば、「空き時間に簡単にできる仕事を探したい」という問題に対して、「仕事を検索できる Web サービス」を作ったとします。一定の利用はされ、「検索ニーズがあるはずだ」と思い込んだ結果、詳細条件の検索機能を次々と追加しました。しかし実際にユーザーが求めていたのは、「楽に仕事が見つかること」であり、検索機能の高度化そのものではありませんでした。やがて、生成 AI が仕事を推薦してくれる別のサービスへと、ユーザーが移っていくことは容易に想像できます。

また、ユーザーに会わない組織でよく見られる安直な戦略として、「数打てば当たる」という考え方に基づき、大量の機能リリースに頼るケースがあります。先ほどの例で言えば、詳細条件の検索機能を増やし続けるような状態です。ユーザーが求めていない機能が積み上がると、プロダクトは不要な機能で溢れ、使いづらくなり、不満が増えて離脱が進みます。

「数打てば当たる」という戦略は、外したときのリスクが小さい、あるいは一つのヒットが非常に大きなリターンをもたらす場合でなければ、成立しにくい戦略です。たとえばテレアポ営業のように、一本の電話が大きな契約につながる場合であれば、この戦略は成り立つかもしれません。しかしプロダクト開発において、不要な機能は決してリスクが小さくありません。ユーザーの離脱を招くだけでなく、開発リソースや運用コスト、さらには撤去コストまでも発生します。

3.3 プロダクトの具体的な実現方法を考える

ユーザーに会い、問題と理想的な解決状態を学んだら、次はそれをどのように実現するかを考えます。

ここで私が特に大事だと思っているのは、 プロダクトの実現方法を最初から固定しないこと です。私はソフトウェアエンジニアなので、「Web サービス」や「スマホアプリ」といった手段に思考が寄りがちですが、手段を先に決めてしまうと、選択肢は一気に狭まります。スクラムガイドにも「プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある」と書かれているとおり、ユーザーが本当に求めているのは ソフトウェアそのものではなく、問題が解決されること だからです。

例として、「ゲーム好きな友達が周りにいなくて、パーティーゲームができない」という問題を考えてみます。この問題に対しては、次のような解決手段が考えられます（上に行くほど、理想的な解決状態に近いとします）。

• パーティーゲーム制作会社と協力し、交流イベントを開催する
• 友達を見つけるためのオフラインコミュニティを作る
• オンラインでゲーム友達を見つけられるソフトウェアを作る

現実的には、コストや制約の関係で実現できない選択肢もあるでしょう。ただし、社内にソフトウェアエンジニアがいるからといって、安直に三つ目の手段を選ぶのは望ましくありません。もしかすると、過去にイベント事業やコミュニティ運営の経験を持つ人が社内にいて、二つ目のほうが成功確率が高いかもしれません。

だからこそ、 「何が作れるか」ではなく、「ユーザーが理想とする解決状態は何か」を基準にし、その上で実現できそうな手段を選ぶこと が重要だと考えています。

3.4 プロダクトを作るための体制や進め方を考える

プロダクトによって、必要な体制や進め方は異なります。たとえばソフトウェアプロダクトであれば、エンジニアだけでなく、デザイナーやデータサイエンティストなどが関わることも多いでしょう。プロダクトの性質に応じて適切な体制を構築する必要がありますし、もしそれが難しい場合は、そもそもの実現方法を見直す必要があるかもしれません。

また、体制を整えたからといって、それだけでプロダクト開発がうまく進むわけではありません。進め方が整理されていないと、時間を浪費したり、結果として質の低いプロダクトになってしまう可能性があります。

私は、プロダクト開発は本質的に 検証と学習のループ だと考えています。具体的には、次のような流れです。

• 仮説を立てる（何が問題で、何が解決状態か）
• 小さく作る
• 確かめる（ユーザーに使ってもらう）
• 次の意思決定を行う

このループをソフトウェアプロダクトにおいて具体化した例として、 株式会社スタディスト が公開している プロダクト開発プロセス が分かりやすいので引用します。「リサーチ → デザイン → プロトタイプ → 実装 → リリース → フィードバック」という一連の流れが示されています。

もちろん、このプロセスがすべてのプロダクトにそのまま当てはまるわけではありません。私がここで伝えたいのは、 「ユーザーに価値を提供する」ために、検証と学習が回り続けるプロセスを意図的に設計し、不確実性を下げること が重要だという点です。

なお、このような検証と学習を中心に据え、不確実性を下げる考え方はリーン思考に基づく考え方で、例えば リーン・スタートアップ という書籍でも体系的に整理されています。仮説を立て、小さく試し、学びをもとに次の意思決定を行うという姿勢は、プロダクト開発全体を貫く重要な前提だと感じています。プロダクト開発の進め方に悩んだときや、「なぜ検証と学習が必要なのか」をもう一段深く理解したいときには、参考になる一冊だと思います。

3.4.1 シフトレフト

この文脈で、「 シフトレフト（Shift Left） 」という考え方も紹介しておきます。これは、 問題の特定をできるだけ早い段階で行い、結果としてコストを下げる という発想です。時間軸で見ると、問題の発見をできる限り左側、つまり開発プロセスの初期に寄せていくイメージになります。

たとえば、SNS アプリを作るケースを考えてみます。ユーザーの投稿をどのように表示するかといった機能に目が向きがちですが、SNS は会員登録しなければ投稿できません。そのため、会員登録体験もプロダクトの重要な一部です。ここを見落とし、会員登録の導線が分かりづらいまま進んでしまうと、ローンチ後に「広告を出してもあまり登録してもらえない」といった、致命的な問題につながりかねません。

もしローンチ前に、一部のユーザーに動作テストをしてもらえていれば、投稿機能に到達する前の会員登録で詰まっていることに気づけたかもしれません。さらに言えば、プロトタイプの段階でユーザーに触れてもらっていれば、大きな実装のやり直しを避けられた可能性もあります。場合によっては、デザインやリサーチの段階で問題に気づくこともできたでしょう。

このように、問題に気づくタイミングが早ければ早いほど、修正コストは小さくなります。開発プロセスの初期段階で問題を発見できるのが理想です。そのためにも、シフトレフトの考え方を常に念頭に置いておくことをおすすめします。

3.4.2 開発手法やフレームワーク

体制や役割、やるべきことが決まっていても、実際の進め方で迷うことは少なくありません。責任範囲や優先順位、ゴールに対する進捗確認が曖昧なままだと、プロダクト開発は不安定になりやすいからです。

開発手法やフレームワークは、その 不安定さを減らすための「進め方の土台」 だと考えています。

たとえばソフトウェア開発であれば、アジャイルやスクラムが代表的な例でしょう。これらの考え方を採用すると、大切な価値観ややるべきこと、各々の責務がある程度整理され、意思決定や進行を肩代わりしてくれます。その結果、個々人が本来向き合うべきプロダクト開発そのものに集中しやすくなります。また、広く使われている手法であれば経験者も多く、オンボーディングのコストを下げられるというメリットもあります。

一方で、フレームワークは万能ではありません。プロダクトや組織に合っていない場合、かえって思考や行動を縛るロックインになってしまい、見直そうとすると大きなコストが発生します。そのため、採用する際には、まずそのフレームワークが何を前提としていて、何を助け、何を助けないのかを理解したうえで、本当にプロダクト開発に役立つのかを吟味する必要があります。トレードオフを納得したうえで選ぶことが重要だと考えています。

私はこれまでスクラムを長く使いながら、プロダクト開発においてさまざまな改善を重ねてきました。スクラムについては、このあと別のセクションで改めて取り上げます。アジャイルについては、 アジャイルソフトウェア開発宣言 が基本的な価値観と原則を端的に示しており、一読の価値があります。

3.5 プロダクトを作る

プロダクトの作り方は、どのような実現方法を選ぶかによって大きく変わるため、ここでは具体論には踏み込みません。私の専門であるソフトウェア開発については、後ほど別のセクションで扱います。

ここでは、実現方法によらず、私が常に意識している考え方を紹介します。それは、 プロダクトと実現方法を分けて考える ということです。ユーザーの問題や解決状態、そして解決状態に導くための手段はプロダクトの話であり、実現方法とは切り分けて考えたほうが良いと考えています。

たとえば、「空き時間に簡単にできる仕事を探したい」という問題に対して、すでに「仕事を検索して探せる Web サービス」ソフトウェアが存在しているとします。ユーザーリサーチを通じて、「空き時間には限りがあり、できるだけ手間をかけたくない」という問題の詳細が見えてきました。このとき、解決手段を既存の実現方法とセットで考えてしまうと、「検索機能をもっと高度にすれば、簡単に仕事を探せるのではないか」といった、既存の実現方法に引きずられた発想になりがちです。しかし、ユーザーが本当に求めているのは「自分で探すこと」ではなく、「楽に仕事が見つかる状態」です。

プロダクトの視点だけで考えると、まず「手間をかけずに仕事を見つけるにはどうすればよいか」「ユーザーが何もしなくても仕事が見つかる状態が理想なのではないか」といった形で、抽象度の高い手段を検討できます。そのうえで、「ユーザーの職種や経歴に応じて、こちらが代わりに仕事を探すのはどうだろうか」といった発想につながるかもしれません。そこから初めて、「まずは手作業で探してメールで紹介することができそうだ」「すでにあるソフトウェアを使って自動化できそうだ」「ユーザー情報をもとに適切な仕事を推薦するアルゴリズムを作れそうだ」といったように、手段を具体的な実現方法へと落としていくことができ、理想的な解決状態を実現できます。

なお、事前に「この仕事検索サービスに、高度な詳細検索機能をつけるのはどうでしょうか」とユーザーに聞いていた場合でも、肯定的な反応が返ってくる可能性もあります。それは、ユーザー自身が理想的な手段をうまくイメージできなかったり、言語化できなかったりすることがあるからです。また、ユーザー自身も「検索」という既存のソフトウェアに縛られて考えてしまっている場合があります。だからこそ、私たちがプロダクトと実現方法を意識的に分けて考えることで、 ユーザー自身も気づいていなかった、より本質的な価値につながるプロダクト を生み出せると考えています。

私は、次の順番で考えると、ユーザーにとって価値のあるプロダクトを作りやすくなると感じています。

1. ユーザーの問題を学ぶ
2. その問題の解決状態を考える
3. 解決状態に導く手段を考える
4. それを実現する方法を考える

3 と 4 を区別する際の一つの目安として、 実現方法を想起させる言葉が含まれていないか を確認すると良いでしょう。たとえば「メール」「ページ」「画面」といった言葉です。3 の手段を考える段階でこれらの言葉が入ってしまうと、実現方法がソフトウェアに強く縛られてしまいます。手段を考える際は、できるだけユーザーが日常的に使う言葉や、ユーザーにそのまま説明できる言葉で考えることをおすすめします。

3.5.1 余談：「探す」と「検索する」の違い

「探す」と「検索する」は、似ているようで役割の異なる言葉です。前者はプロダクトの言葉であり、後者は実現方法の言葉だと私は捉えています。

「検索する」と言った瞬間に、私たちは無意識のうちに、スマートフォンや PC、ブラウザ、入力フォームといったソフトウェアの存在を前提にしてしまいます。その結果、思考が「どんな検索 UI にするか」「どんな検索条件を用意するか」といった実装寄りの方向に引っ張られやすくなります。もしこの二つの言葉を混同して使っていると、先ほどの例のように、ユーザーが本当は求めていない検索機能を一生懸命作ってしまうことになりかねません。

一方で「探す」という言葉は、実現方法を限定しません。人に聞くことも、勝手に届くことも、誰かが代わりに見つけてくれることも含みます。日常生活で人が「探す」という言葉を使うときも、必ずしも能動的に操作する行為を指しているわけではなく、「目に映る」「結果として見つかっている」といった状態を含めて使われているように思います。だからこそ、「探す」という言葉で問題や解決状態を捉えていれば、検索という手段に縛られず、より広い選択肢の中からプロダクトを考えることができます。

これは、私がクラウドソーシングサービスで「仕事」と「仕事がしたい人」のマッチングという領域を扱っていたときに、強く実感したことでもあります。言葉の選び方一つで、プロダクトの発想の幅は大きく変わると感じています。

3.6 良いプロダクトを作るために大切なことのまとめ

ここまで、「良いプロダクトを作るにはどうすればよいか」を、順を追って整理してきました。ここで一度、要点をまとめます。

• 良いプロダクトとは、多くのユーザーに多くの価値を、必要な期間にわたって提供し続けられるもの
• そのためには、まずプロダクトの目的を明確に定義することが重要
• ユーザーに会い、問題と解決状態を継続的に学び続ける必要がある
• 実現方法を先に決めず、解決状態から手段を考える
• 検証と学習が回る体制と進め方を設計する
• プロダクトと実現方法を分けて考え、最後に実装へ落とす

私が一貫して大切にしたいのは、順序を守ること です。下流の話（体制、開発、実装）から始めてしまうと、どれだけ頑張っても的外れなプロダクトになりやすいと感じています。

余談になりますが、私は最近「人間中心設計入門」という本を読みました。読んでみて、ここまで書いてきた内容と思想的にかなり近いと感じましたし、自分の考えをより整理し、ブラッシュアップしてくれる体験でもありました。プロダクト開発に興味がある人にとって、人間中心設計という概念はとても参考になると思います。

以降のセクションでは、これらを実現するための具体的な進め方として、私が長く向き合ってきたスクラムやソフトウェア開発について触れていきます。

4. スクラム

私はこれまで、スクラムに真剣に向き合ってきました。スクラムガイドを何度も読み返し、いわゆる「なんちゃってスクラム」の状態から抜け出し、プロダクト開発のフレームワークとして機能させるところまで試行錯誤してきた経験があります。このセクションでは、そうした実践の中で私が感じたポイントを、あくまで私なりの解釈として書いていきます。

なお、ここではスクラムそのものの説明は最小限にとどめます。そのため、スクラムについて体系的に理解したい場合は、公式リファレンスであるスクラムガイドを読むことをおすすめします（以下は日本語訳です）。
2020年版スクラムガイドの日本語訳

また私は、ソフトウェアプロダクト開発において、開発者としてスクラムチームに参加してきました。ちなみに、スクラムマスターの資格は持っていません。ここに書く内容は、あくまで実務経験にもとづく解釈です。そのため、解釈に誤りが含まれる可能性がある点は、あらかじめご了承ください。

4.1 私がスクラムを使用する目的

私がソフトウェアプロダクト開発でスクラムを使う目的は、 良いプロダクトを作るため です。スクラムは、もともとソフトウェアプロダクト開発を前提として作られたフレームワークであり、その点で相性の良さを感じています。とはいえ、他の開発手法やフレームワークの経験が多いわけではないため、このあたりはあくまで私個人の主観にもとづく意見です。

私がスクラムに良さを感じている点は、次のとおりです。

• シンプルで、枠組みを理解しやすい（簡単という意味ではない）
• プロダクトのゴールに向き合い続けられる
• スプリントという区切りによって、変化に対応しやすく、学びのサイクルを回しやすい
• 各々の責任に集中しやすい
• 認知度が高く、経験者が多い

もちろん、これらの点は他の開発手法やフレームワークでも実現できるでしょう。開発手法やフレームワークには、それぞれ目的や影響範囲があり、単純な良し悪しで比較することは難しいと感じています。むしろ、何かを補完するために組み合わせて使われることも少なくありません。スクラム自体もリーン思考を取り入れていたり、実際の現場では、カンバンなどと組み合わせて使われることも多いのではないでしょうか。

私の印象では、 スクラムはコミュニケーションや自己管理を重んじる枠組み です。そのため、複雑性や不確実性が高く、中長期にわたって持続的な開発が求められる場合に、特に相性が良いと感じています。一方で、次のような状況では合わない可能性もあります。

• コミュニケーションを最小化し、決められた作業を忠実に実行したい
• 短期で作り切ることを最優先したい
• 自律性よりも統治を重視したい
• プロダクト開発経験が豊富なメンバーのみで構成されており、あえて型を外して進めたい

私は、良いプロダクトを作るための手段としてスクラムには肯定的ですが、 自分たちの目的や状況に合っているかを見極めたうえで導入することが大切 だと考えています。

4.2 スクラムを使う上で大切なこと

スクラムが自分たちの目的に合っていると分かったうえで導入を決めたとしても、実践は決して簡単ではありません。フレームワークそのものはシンプルですが、実際に機能させるには、考え方や行動を揃え続ける必要があります。

ここでは、私がスクラムを実践する中で、特に大切だと感じているポイントを書いていきます。

4.2.1 スクラムガイドに則る

スクラムを実践するうえで、まず大事なのは、 スクラムガイドを基準にする ことだと考えています。もちろん例外はありますが、基本的にはガイドを基準にしたほうがよい、という立場です。

スクラムガイドにも、次のような記述があります。

スクラムガイドの⽬的
（中略）
スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の⽬的があり、スクラムで実現される全体的な価値や結果に⽋かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に⽴たなくなることさえある。

スクラムの定義
（中略）
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。

ガイドから逸脱すると、次のようなデメリットが生まれやすいと感じています（ここで言う「ガイドから逸脱する」は、スクラムの不完全な部分を補完するという話ではなく、ガイドに沿わずに運用する状態そのものについてです）。

• 独自に「正しさ」を都度定義し、合意し、保守していく必要が出てくる
• 正しさの判断が偏った経験値に委ねられやすくなる
• 学習やオンボーディングのコストが増える（スクラム経験者においても、独自要素のキャッチアップが必要になる）
• 独自要素が増えるほど複雑性が上がり、プロダクト開発に集中しづらくなる
• 汎用性や再現性がなくなる

例えるなら、初心者エンジニアが自作したフレームワークを運用するようなものです。本来は 安定した土台が欲しかったはずなのに、むしろ不安定になってしまう 状態ではないでしょうか。

また、「ガイド通りにやっているが、成果が出ないため従わない」という判断も、私はあまり良くないと思っています。多くの場合、問題はスクラムそのものではなく、理解不足や実践不足にあると感じるからです。そもそも目的に見合わない形でスクラムを導入している場合（組織としてスクラムが強制されている場合など）は別として、一定の成果は出るはずだと考えています。

もちろん、ガイドを理解したうえで逸脱を検討すること自体を否定するものではありません。私としては、次のような条件がそろっている場合に、初めて検討できるものだと思っています。

• プロダクト開発そのものへの理解がある
• さらなる成果を狙いたい、あるいはプロダクトにより最適化したいという明確な目的がある
• 何を変えるのか、なぜ変えるのかが言語化されている
• トレードオフを理解したうえで、期待されるリターンが廃止コストやリスクを上回る
• 変更後のやり方を、継続的に見直し、保守していく覚悟がある

まずはガイドに沿って運用し、必要になった段階で、意図を持って調整する 。この順番が、最も現実的で失敗しにくいと私は考えています。

4.2.2 スクラムの価値基準を学ぶ

スクラムガイドでは、スクラムの価値基準として次の 5 つが挙げられています。

スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）

私は、スクラムの定義や各要素のふるまいは、これらの価値基準を前提として組み立てられていると理解しています。スクラムガイドにあるイベントや役割、成果物といった構造だけを真似ても、この価値基準が共有されていなければ、スクラムはうまく機能しないと考えております。

だからこそ、現場で迷ったときや意思決定に悩んだときほど、 この価値基準に立ち返ること が重要だと考えています。価値基準をもとに問い直すことで、判断の軸がぶれにくくなります。

4.2.3 スクラムはシンプルだが簡単ではない

スクラムはシンプルです。公式リファレンスであるスクラムガイドの日本語訳は、A4 サイズで 18 ページしかありません（原典はさらに 4 ページ少ないです）。フレームワークとしては驚くほどコンパクトで、定義されているのは本質的な要素だけです。

しかし、この シンプルさゆえにこそ、実践は簡単ではない と私は感じています。私はこれまでスクラムについての対話や実践を何度も重ねてきましたが、それでも解釈のズレや形骸化を繰り返してきました。それでも続けていくうちに、徐々にスクラムの意図が体感として分かる瞬間が増えてきました。今もなお学びの途中ですが、だからこそ「簡単ではない」という感覚を強く持っています。

スクラムは「経験主義」と「リーン思考」に基づいています。だからこそ、 不明瞭なところは経験をもとに理解を重ねることが重要であり、その経験から得られた知見によって、はじめてスクラムが理解できる のだと思います。スクラムフレームワークが意図的に不完全に設計されているのも、この前提に沿っていると感じています。本質的に重要なことだけを定義し、細かい手段はチームに委ねることで、プロダクト開発そのものに集中させようとしているのだと私は捉えています。

またスクラムは、プロダクトゴールに向かって進むためのフレームワークでもあります。私自身、「良いプロダクトを作る」という視点を軸にしているため、このゴール志向の考え方は非常に相性が良いと感じています。目的はシンプルで明確です。ただし、そのプロダクトゴールを満たした状態に到達することは決して簡単ではありません。だからこそ、透明性を確保し、検査し、適応するというサイクルを愚直に回し続けることが重要になります。

4.3 スクラムチームについての解釈

スクラムでは、プロダクト開発は少人数のチームで進めることが前提とされています。スクラムチームは、1 人のプロダクトオーナー、1 人のスクラムマスター、そして複数の開発者で構成されます。これらは役職や職種ではなく、 「責任」によって 3 つに分類されている と理解しています。

具体的な定義や役割については、スクラムガイドに詳しく書かれているため、ここでは踏み込みません。以降では、それらを前提としたうえで、実際にプロダクト開発の現場でスクラムチームとして動く中で、私がどのように解釈し、何を意識してきたかについて書いていきます。

4.3.1 プロダクトオーナー

スクラムガイドでは、プロダクトオーナーは「プロダクトの価値を最大化することの結果に責任を持つ」とされています。これを踏まえると、私は、 プロダクトオーナーの仕事は意思決定し、責任を取ること だと考えています。まさしくオーナーです。そのため、決まりきった業務があるというよりも、今の状況に対して何をすべきかを常に考え、行動し続けることが求められる役割だと思っています。

では具体的に、プロダクトオーナーは何をすればよいのでしょうか。私の考えでは、問題と解決状態の解像度を上げ適切な意思決定を行うために、多くの場合はユーザーや専門家から学ぶことが中心になると思います。加えて、その学びをチームに共有したり、ステークホルダーと調整したりすることも必要になるでしょう。

チームによっては、プロダクトオーナーがソフトウェアの仕様など、実現方法まで細かく決めているケースもあると思います。オーナーとして意図的にそう判断しているのであれば、それ自体は問題ではありません。ただ、私は基本的には委託を前提に考えたほうが良いと思っています。チームには、実現方法に詳しいプロとして開発者がいるはずですし、問題と解決状態の解像度を上げるだけでも時間がかかります。プロダクトオーナーは、時間がある限り、できるだけその解像度を上げることに集中したほうが良いと感じています。

さらに、最初は一つのチームで回る小さなプロダクトであっても、規模が大きくなれば複数チームになります。大きなプロダクトを 1 人で見続けるほど、プロダクトオーナーの時間は足りなくなっていくはずです。実現方法の意思決定を担う場面は当然あると思いますが、それ以上はなるべく委託し、プロダクトオーナーが本来やるべきことに時間を使える状態を作ることが重要だと考えています。

プロダクトオーナーは必ずしもプロダクトマネージャーではない

プロダクトオーナーにプロダクトマネジメントに近いスキルが求められる場面も多いですが、私はそれが必須だとは考えていません。 プロダクトオーナーに求められる本質は意思決定すること であり、そのために何を自分で行い、何を委託するかを状況に応じて選べればよいと思っています。

もちろん、適切な意思決定を行うために、プロダクトマネジメントに関する知識や視点が役立つことは多いでしょう。ただし、それはあくまで手段であり、 プロダクトオーナーは、「プロダクトの価値を最大化することの結果に責任を取ること」が目的 です。プロダクトマネジメントのスキルを使うかどうか自体が目的になるべきではありません。

また、組織によっては、プロダクトオーナーとは別にプロダクトマネージャーという役割が存在する場合もあります。私は、この二つの違いは「責任の違い」にあると考えています。プロダクトオーナーはスクラムの概念であり、スクラムガイドで定義された責任を負います。一方で、プロダクトマネージャーは職種として使われることが多く、その責任範囲は組織や文脈によってさまざまでしょうが、名前のとおりプロダクトをマネジメントする責任、 言い換えると価値の最大化を支援する責任 になるのではと考えております。結果責任ではなく、それを求められ意思決定をするのはプロダクトオーナーだと考えております。

上記はあくまで私の考えであり、両者が同時に存在する場合には、どこまでが誰の責任なのかを明確にしておくことが重要だと考えています。それによって意思決定が滞ることを防ぎ、プロダクトの価値最大化のためにお互いに良い関係が築けると考えています。

4.3.2 スクラムマスター

スクラムマスターもまた、とても難しい役割だと私は感じています。スクラムガイドでは、「スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ」とされており、担う範囲は非常に広いです。私の理解では、 スクラムが機能し続ける、つまりは価値提供をし続けられるように全体を支援する人 だと思っています。スクラムガイドでは「真のリーダー」とも表現されており、その力量は、チームが提供できる価値に大きく影響します。

一方で、実際の現場ではスクラムマスターを置いていない組織も多いと思います。スクラムマスターが不在の場合、次のような状況が起きやすいと感じています。

• メンバーがそれぞれの責任に集中できなくなる（本来スクラムマスターが担う役割が分散し、そのたびに取り決めを行うコストが発生する）
• イベントや成果物が形骸化し、スクラムから逸脱しやすくなる（誰にも明確な責任がなく、改善や是正が行われない）
• 組織としてスクラムが理解されず、プロダクトオーナーがオーナーとして振る舞えなくなり、結果として価値提供が阻害される（意思決定の権限がない、体制やルールによる過度な制約が生まれる）

だからこそ、私は スクラムマスターがいないと、スクラムは成り立たない と感じています。「リーダー」や「マスター」という言葉が、重要性を端的に表していると思います。

スクラムマスターを置いていない組織では、そもそもスクラムの意義が十分に理解されないまま導入が進んでしまっている可能性もあります。本来は、その理解を支援するためにこそスクラムマスターが必要なのですが、「知らないからこそ必要性に気づけない」という大きな壁が存在すると感じています。組織としてスクラムを使ってプロダクト開発をうまく進めたい、そして価値提供に再現性を持たせたいのであれば、スクラムマスターを専属で置くことを、私は強くおすすめしたいです。

4.3.3 開発者

開発者の役割は、比較的イメージしやすいかもしれません。所謂エンジニアやデザイナーと呼ばれる職種の人が担当することが多いでしょう。スクラムにおける開発者は、抽象的な解決状態を具体化し、インクリメントとして形にしていく役割だと私は捉えています。

開発者として特に大事なのは、 タスクをこなすことではなく、スプリントゴールに向かって前に進めること です。スプリントプランニングで決めたタスクに引きずられがちですが、ゴールを達成するために必要であれば、計画を見直すこともありますし、場合によってはプロダクトバックログアイテム自体を入れ替えたほうがよいこともあります。重要なのは、ゴールに照らして価値のある、有用なインクリメントを作ることです。

そのため、開発者にとって私が大事だと思うのは、問題や解決状態を理解したうえで、最適な実装を考えることです。日頃からリファインメントを通じて、プロダクトバックログアイテムの背景まで理解しておくことが重要だと感じています。また、ユーザーに会う機会に同席するなど、開発者が普段からプロダクトの視点で物事を捉えていると、より有用なインクリメントを作れると考えています。

なお、開発者は複数人で構成されますが、スクラムにはサブチームや階層の概念はありません。そのため、「開発者リーダー」のような役割を置くことは良くないと私は思っています。階層を作ることで複雑性が増し、不要な関心事やコミュニケーションパスが増えやすくなるからです。「リーダーが必要だ」と感じる背景には、自己管理の難しさがあることも多いでしょう。しかし、リーダーを置くことで、開発者自身が自己管理を学ぶ機会を失ってしまう可能性があります。自己管理の課題については、スクラムマスターの責任のもとで、スクラムマスターが支援しながら解決していくのが望ましいと、私は考えています。

4.3.4 マネージャーについて

スクラムチームの中にマネージャーがいるケースもありますが、私はおすすめできないと考えています。組織全体で見れば、プロダクト開発を円滑に進めるために、マネージャーが担うべき仕事は確かに存在します。ただし、それらは必ずしもスクラムチームの「中」に置く必要があるものではありません。

チーム内にマネージャーが存在すると、自己管理よりもマネージャーの指示が優先されてしまったり、意思決定にマネージャーの意向が強く影響したり、当事者意識が薄れたりといった副作用が起きやすくなります。特に、マネージャーが人事評価を担っている場合、安全に失敗できなくなり、透明性の高い議論や改善のための対話が萎縮してしまうリスクがあります。これは、スクラムが前提としている自己管理と相性が良いとは言えません。

一方で、スクラムチームの中にマネージャーを置くことによる明確なメリットは、私にはあまり思い当たりません。チーム内で起きる多くの課題は、スクラムマスターの責務として十分に支援・解決できると考えています。そのため私は、マネージャーはスクラムチームの外側から組織としてチームを支える存在であり、スクラムチームの中には置かないほうが、自己管理が機能しやすく、結果として良いプロダクト開発につながると考えています。

もし「評価しやすい」という理由でマネージャーをチーム内に置いているのであれば、評価の仕組みそのものを見直したほうがよいかもしれません。本来の目的であるプロダクト開発を阻害してしまっては、本末転倒ですし、 手段と目的が逆転している状態 と言えると思います。

4.4 スプリントゴールについての解釈

スプリントでは、唯一の目的としてスプリントゴールを掲げます。ここでは、スプリントゴールについての私なりの解釈を書いていきます。

スプリントの最初に行うプランニングでは、プロダクトオーナーが「このスプリントで何を達成したいか」を提案します。それをもとにチームで「このスプリントがどんな価値につながるのか」を考え、スプリントゴールとして言葉にします。ここでのポイントは、 スプリントゴールが「何を作るか」ではなく「なぜそれが価値になるか」を示していること です。価値は「問題と解決状態の一致」なので、例えば「このスプリントでは、〇〇という問題に対して、△△という解決状態の一致を作る」といった表現が適していると私は考えています。

例えば、オンラインでゲーム友達を見つけるプロダクトにおいて、「同じゲームを遊んでいるユーザーが見つけられず、交流が生まれない」という問題があったとします。これをこのスプリントで解決したいと提案された場合、チームとしては「同じゲームを遊んでいるユーザー同士の交流を作る」といったゴールを置くイメージです。ここで「ユーザーがどのゲームを遊んでいるか分かるようにする」「好きなゲームをプレイしているユーザーが分かるようにする」といった手段をゴールにしてしまうと、手段は実現できたものの交流が生まれなかった場合に、 ゴールは達成したが価値は生まれていない、という本質を見失った状態 になってしまいます。また、スプリント中に「数日に一度、一つのゲームをテーマにしたオンラインイベントを開く」といった別の手段が思いついた場合でも、手段をゴールに掲げている場合は採用できず、価値提供の機会を失うことがあります。

もし掲げたスプリントゴールが曖昧だと感じたら、「なぜこのゴールを掲げるのか」と問い直してみると良いでしょう。正しいゴールであれば「問題を解決するため」と答えられるはずですが、手段の場合は「解決に導くため」といった表現になりやすく、そこから違和感に気づけることがあります。

スクラムガイドのスプリントバックログの説明には、スプリントゴールの位置づけが分かりやすく示されています。

スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実⾏可能な計画（どのように）で構成される。

手段はプロダクトバックログアイテム（何を）であるため、スプリントゴールそのものではないことが分かります。これまで私は「問題」「解決状態」「手段」「実現方法」という言葉を使ってきましたが、対応づけるなら、問題と解決状態は「なぜ」、手段は「何を」、実現方法は「どのように」と考えると整理しやすいと思います。「なぜ」「何を」「どのように」を常に区別して考えられるようになると、より有用な価値提供につながると感じています。

なお、「プロダクトバックログアイテムは必ずインクリメントにしなければならない」という強迫観念を見かけることがありますが、それは正しくないと考えています。プランニング時には想定していなかったプロダクトバックログアイテムを、スプリントの途中で追加することもあるでしょう。また既存のプロダクトバックログアイテムをゴール達成に必要ないと判断することもあります。

その分、「プロダクトバックログアイテムをインクリメントにすればゴール達成」という単純な見方はできなくなります。だからこそ、ゴールを達成できたかどうかの評価は難しくなりますし、そこにこそ本質があると私は思います。むしろ、 ゴールを達成したかどうかという真偽そのものよりも、ユーザーにどれだけ価値を提供できたかのほうが重要 です。 問題と解決状態の一致は簡単ではないからこそ価値がある ので、スプリントレビューなどを通して、腰を据えて話し合うことが大切だと考えています。本質に目を向けていきましょう。

4.4.1 スプリントゴールをロードマップから落とし込むことについて

プロダクトゴールの達成に向けて、ロードマップを作っているチームも多いと思います。ロードマップは、プロダクトゴールの解像度を上げ、方向性を共有するうえで、とても有用なものです。

ただし、 ロードマップに従ってスプリントゴールを機械的に落とし込むことには注意が必要 だと私は考えています。スプリントで提供できる価値は、環境の変化によって日々揺らぐからです。

例えば、オンラインでゲーム友達を見つけるプロダクトを考えてみましょう。もし Discord のようなサービスが登場した場合、「ゲーム友達を見つけるための専用ソフトウェア」を作り続けること自体が、もはや最適な価値提供ではなくなるかもしれません。その場合、ソフトウェア開発を続けるよりも、Discord 上でコミュニティを作るほうが、ユーザーにとって価値の高い選択になる可能性があります。

ここまで大きな変化でなくても、当初の仮説と現状がズレることは、プロダクト開発では日常的に起こります。だからこそ、ロードマップを前提条件として扱い、そのままスプリントゴールに転写するのではなく、「今このスプリントで、どんな価値を提供するのが最も妥当か」を都度考えることが重要だと思います。

ロードマップを描くこと自体は、とても良い取り組みです。ただし、それを固定された計画書にしてしまうのではなく、学びや環境の変化に応じて更新され続けるものとして扱うことが、スクラムやスプリントゴールの考え方と相性が良いと感じています。

4.4.2 スプリントの中止について

スプリントゴールが役に立たなくなったと判断した時点でスプリントは中止されます。たとえば、先ほどの Discord の例のように、「価値になりそうだ」と思っていたものが、実際には価値にならないと分かった場合です。近年は変化のスピードも速く、生成 AI の登場などによってユーザーの行動が短期間で変わることも珍しくありません。無駄だと感じた時点で、プロダクトオーナーは早めに中止を検討したほうがよいと私は考えています。

一方で、スプリントゴールの達成可否が人事評価に影響する組織も少なくないと思います。そのような環境では、スプリントゴールを中止せず、後述するように変更や縮小で済ませたくなるでしょう。しかし、最優先すべき目的はユーザーへの価値提供です。そのため、私はスプリントゴールの中止を優先することをおすすめします。

これは、人事評価の仕組みを見直す良いきっかけにもなると思います。組織が人事評価を設ける本来の目的は、価値提供を最大化することにあるはずです。だからこそ、スプリントゴールの中止を肯定できるような仕組みへと改善していくべきだと考えています。なお、スプリントゴールを達成したかどうか自体は本質ではないため、そこを評価指標に含めないほうが良いと私は思います。

4.4.3 スプリントゴールの変更について

スクラムガイドには明示的には書かれていませんが、スプリントの途中でスプリントゴールを変更する、という考え方が語られることがあります。無駄だと感じたら軌道修正する、という姿勢自体は良いと思います。

ただし私は、変更するよりも、 スプリントを中止して、次のスプリントを早く始める ほうが良いと考えています。ユーザーへの価値提供を軸に考えると、価値を再定義し、プランニングをやり直したほうが、結果として価値のあるものを作りやすいからです。ゴールを変更したまま残り期間だけで進めると、スプリントの価値が曖昧になるだけで、明確なメリットを私は感じません。

業務上の理由で、スプリントの開始日を月曜の朝などに固定している場合は、この決断ができないかもしれません。ただし、本質はユーザーに価値を提供することです。そのため、状況に応じてスプリントを柔軟に切り替えられる体制を整えておくほうが良いと私は思います。

4.4.4 スプリントゴールの縮小について

スプリントゴールを「縮小しよう」という判断が出てくることも、ときにはあるかもしれません。ただし、ゴールはスプリントの価値そのものであり、価値とは問題と解決状態の一致です。そう考えると、「縮小」という言葉が何を指しているのかは、実はかなり曖昧です。

だからこそ、縮小を考えた時点で、一度立ち止まり、なぜそう判断したのか、何が要因なのか、それは何を意味しているのかを整理したほうが良いと思います。私自身は、変更の場合と同じく、スプリントを中止し、次のスプリントに移りゴールを立て直すほうが健全だと考えています。

もし「縮小」が必要だと感じた背景には、そもそもゴールを目的ではなく手段として設定してしまっている可能性があります。例えば、「プランニング時に計画した 3 つのプロダクトバックログアイテムをインクリメント化する」といったゴールであれば、確かに縮小という発想は成り立ちます。しかし、スプリントゴールはプロダクトバックログアイテムのインクリメント化そのものではありません。そのような場合は、スプリントを中止し、次のスプリントで正しいスプリントゴールを立て直すことをおすすめします。

4.4.5 スプリントゴールは一つに絞る

私の意見としては、スプリントゴールは 一つに絞ったほうが良い と考えています。ゴールが二つあるだけで判断軸が二重化し、会話や調整のコストが増えやすくなります。その結果、スクラムの価値基準である「確約」や「集中」を損ねてしまいやすいと感じています。

スクラムガイドにも、次のような記述があります。

スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものでもある。

ゴールが複数ある状態は、この記述が示す理想的な状態とは言えないでしょう。やりたいことが多くあるのは自然なことですが、優先度を付けたうえで、スプリントで提供する価値は一つに絞り、その最大化に集中したほうが良いと思います。

もしスプリントゴールが二つになってしまっている場合、背景にはいくつかの可能性があります。例えば、プロダクトバックログアイテムが不足している、あるいは優先度を決めきれていない、といった状況です。いずれも、プロダクトの解像度がまだ低い、もしくは言語化しきれていないことの表れだと思います。その場合は、タスクを増やすよりも、プロダクトに向き合う時間を増やすほうが健全でしょう。

それでも頻繁にゴールが二つになってしまうのであれば、スプリントの期間が長すぎる可能性もあります。その場合は、スプリントを短くすることで解決するかもしれません。また、開発者のリソース配分の問題でゴールが分かれているのであれば、スクラムチームを分けることも検討したほうが良いでしょう。

4.5 スプリントゴールを立てたあと

ここまでの前提がそろっていれば、あとは実行に集中する段階です。スクラムには、ここまで触れていないイベントや作成物もありますが、私としては、ここまで理解できていれば、その先を細かく語ることはあまり多くないと感じています。

大切なのは、スクラムのイベントやルールを正しくなぞることではなく、 スクラムの目的を第一に置き続けること です。理論や価値基準を大事にしながら、チームで対話を重ね、学びながらプロダクト開発を進めていきましょう。

ただし、人は慣れると形骸化しやすいものです。スクラムが「回っているだけ」にならないように、スクラムマスターの支援のもと、定期的にスクラムガイドを読み直すなど、学び直しの機会を意識的に作ることをおすすめします。それによって、自分たちのスクラムが今も目的に沿って機能しているかを、立ち止まって見直せるはずです。

5. ソフトウェア開発

ここからは、これまでのプロダクトやスクラムの話とは少し切り口を変えて、ソフトウェア開発そのものの話をします。

ソフトウェアプロダクトを作る以上、良いプロダクトを作るためには、良いソフトウェアを作る必要があります。私が考える「良いソフトウェア」とは、 プロダクトを忠実に表現できているソフトウェア です。ここでいう「忠実」とは、ユーザーの問題に対して適切な解決状態を提供できていること、ユーザーが解決手段として迷わず使えること、そしてそれを長期にわたって提供し続けられるよう、持続的な開発が可能であることを指しています。

私はソフトウェアエンジニアなので、このセクションでは、ソフトウェア開発の中でもソフトウェアエンジニアリングに近い話を中心に書いていきます。ただし、ソフトウェアエンジニアリング自体も非常に広い分野であり、ここに書く内容は、あくまで私自身がこれまで向き合ってきた領域や経験にもとづくものです。その点はあらかじめご了承ください。

また、ソフトウェア開発について語るにあたり、私が独自の理論を打ち立てたいわけではありません。むしろ、 良いソフトウェアを作るための考え方やプラクティスは、世界的に評価されてきた名著の中にすでに体系化されている と考えています。私自身も、それらの本を一つの「正」として学び、実践してきました。

そのためこのセクションでは、個別のテクニックを断片的に紹介するのではなく、 本を軸にして、私がソフトウェア開発において何を大切にしたいのか を整理する形を取ります。以降では、私が特に影響を受けてきた数冊の本を取り上げ、それぞれが「良いソフトウェア」、そして「良いプロダクト」にどのようにつながっているのかを説明していきます。

なお、ここで紹介する本の内容について、私自身がそれらを完全に理解しきれているとは到底思っていません。むしろ、良いソフトウェアを作るにあたり、これらの本を思考の軸として向き合い続けていきたいという意思の表れです。私の解釈が間違っている可能性も大いにあるので、その点はご了承ください。

5.1 エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

ここで エリック・エヴァンスのドメイン駆動設計 を取り上げる理由は、 良いプロダクトをソフトウェアとして実現し続けるための、重要な考え方 を書いていると感じているからです。

本記事ではこれまで、「良いプロダクトとは何か」「どうすればそれを作り続けられるか」という観点で、プロダクトやスクラムの話をしてきました。しかし、どれだけプロダクトの目的や価値が明確でも、それをソフトウェアに落とし込む過程で歪みが生じれば、ユーザーに価値は正しく届きません。実際のプロダクト開発では、プロダクトの意図とソフトウェアの構造が少しずつズレていくことがよくあります。

本書が扱っているのは、まさにこのズレです。本書は、 プロダクトの問題や解決状態といった抽象的な概念を、ソフトウェアとしてどう表現し、どう保ち続けるかを考えるための思想 だと思います。さらに重要なのは、 ソフトウェアを作る過程で得られた知見を、プロダクトそのものにフィードバックし、プロダクトの解像度を高めていく点 にあります。私はこの双方向性こそが、本書が良いソフトウェアプロダクトにつながる理由だと考えています。

そのため本書は、ソフトウェアエンジニアだけのための技術書ではありません。 ソフトウェアプロダクト開発に関わる全員にとって、プロダクトをどう理解し、どう共有し、どう育てていくかを考えるための土台になる内容 だと思っています。もちろん、書籍全体にはソフトウェアエンジニアリングの話も多く、全員に精読を求めるものではありません。ただ、良いソフトウェアプロダクトを作りたいのであれば、少なくとも根幹にある考え方には触れておいたほうが良いと感じています。本書の前書きや第一部は、エンジニアリングの前提知識が少なくても読める内容であり、本書を要約している重要な箇所なので、そこだけでも触れてみることをおすすめしますし、それ以外の部分については、エンジニアと対話しながら理解を深めていくのが現実的だと思います。

また私自身は、本書を特定の設計手法や実装パターンの集合だとは捉えていません。「ユビキタス言語」「実践的モデラ」「モデル駆動設計」といった重要な概念が示しているのは、プロダクトの問題や解決状態を、チーム全員が同じ言葉と理解で扱い、それをソフトウェアとして表現し、プロダクトにフィードバックし続けるための思考の枠組みです。設計パターンや戦略的設計は、その枠組みを表現するための手段の一部に過ぎません。

重要なのは、ユーザーの問題や解決状態、解決手段、つまりは価値を、ソフトウェアの構造や振る舞いに反映できているかどうかです。そして、その表現が本当に適切かを、ソフトウェアの視点から問い直し、より良いモデルを考え続けられているかどうかだと思います。だからこそ私は、本書を良いソフトウェアプロダクトを作り続けるための思考の土台として位置づけています。

5.1.1 余談：ドメイン駆動設計（DDD）を学ぶ上で私が失敗したこと

エリック・エヴァンスのドメイン駆動設計 は難しいと言われがちですが、私自身もその難しさを強く感じてきました（今でも理解できていません）。そのため、DDD を学び始めた当初、本書ではなく初心者向けの解説書や 実践ドメイン駆動設計（IDDD） から入ってしまいました。今振り返ると、これは明確な遠回りだったと思っています。

これらの本が悪いわけではありません。ただ、DDD をまったく知らない状態で読むと、「デザインパターンやアーキテクチャパターン」として理解してしまいやすいと感じました。その結果、「とりあえずバリューオブジェクトを作る」「とりあえずアプリケーション層を作る」といった、型の適用そのものが目的になってしまいました。特に IDDD は DDD の一つの解釈に過ぎませんが、先に読んだことで、その解釈（実践方法）に強く引きずられてしまいました。

だからこそ、これから DDD を学ぶのであれば、難しく感じるとしても、まずは本書から触れてみるのが良いと思っています。私が最初に読んだときは、10 ページ読むのに 1 時間ほどかかり、読み終わっても理解度は 1 割にも満たなかったと思います。それでも、この本を通して、プロダクトを忠実にソフトウェアで表現することがいかに難しく、奥深いかを腹落ちさせることができました。

この本を読んだことにより、モデリング、アーキテクチャ、デザインパターン、クラスやモジュール設計、プログラミング言語の特性など、ソフトウェアを作るための知識は広く深いものだと改めて知りました。これらを学び続けない限り、DDD の本質も理解できないと思いますし、これらを学び続けて、10 年後に読み返したときには、今とはまったく違う景色が見えるのだろうとも感じています。

5.2 Code Complete

Code Complete 第2版 上　完全なプログラミングを目指して
Code Complete 第2版 下　完全なプログラミングを目指して

ここで Code Complete を取り上げる理由は、 良いソフトウェアをつくるためには、要求や設計を、実装として壊さずに具象化することが重要 と考えているからです。DDD 等をもとに、どれだけ正しくプロダクトを捉え、設計に落とし込んでていても、それが実装の段階で歪めば、ユーザーに届く価値は簡単に失われてしまいます。

この本が真正面から扱っているのは「コンストラクション」です。コンストラクションとは、コーディングやデバッグを中心とした、実際にプログラムを書き、作り込んでいく作業全体を指しています。ソフトウェア開発において、時間や工数の多くはこのフェーズに費やされますし、コードは書かれる時間よりも読まれる時間のほうが圧倒的に長いという事実があります。そのため本書では、 コンストラクションを単なる作業としてではなく、品質と生産性を大きく左右する中心的な活動として位置づけ、物凄い量の研究結果や実証データの引用をもとに、その意義やプラクティスを体系的に説明 しています。

また本書は、「コードを書くフェーズ」だけを切り出した本ではありません。本書では、「プロジェクトの成功の行方は、コンストラクションが始まる前におおかた決まってしまう」と述べられており、なぜコンストラクションの前の準備段階が必要なのか、それによって何が守られるのか、という前提が一貫して語られています。 課題定義や設計と実装は分断されたものではなく、連続したもの として扱われています。

私自身、この本を読むまでは、「設計」というものをここまで重要なものとして捉えられていませんでした。とにかくコードを書きたい、動くものを作りたいという意識が強く、コードを書く前のプロセスにこれほど意味があるとは理解していなかったと思います。本書を通して、コードを書くまでの思考や準備そのものが品質を決定づけ、その積み重ねが最終的にプロダクトの価値を左右するのだと腹落ちしました。

特に大きな学びだったのは、 抽象から具象へと段階的に思考レベルを落としていく重要性 です。要求や設計といった抽象的なものを、いきなりコードという最も具体的な形に落とし込むのではなく、途中に複数の思考の段階を挟みながら、少しずつ具体化していく。そのプロセスを丁寧に踏むことで、プロダクトの意図を壊さずに実装できるという考え方は、ソフトウェア開発だけでなく、プロダクト開発全体を見る視点にも強い影響を与えました。また本書で触れられている、「課題定義はユーザーの言葉で語られるべき」という考えや、「言語の中でのプログラミングではなく、言語の中へのプログラミング」という視点も、この抽象と具象を区別してる表現として印象に残っています。これらは、実現方法に引きずられずに問題や解決状態を捉えるための視点であり、これまで書いてきた「プロダクト」と「実現方法」を分けて考える姿勢と強くつながっています。

世の中には「リーダブルコード」や「良いコード／悪いコード」など、似たようなテーマの本も多くあります。それらも素晴らしい本ですが、私としてはまず Code Complete をすすめたいです。上下巻あわせて 1000 ページ近くあり、読むのは簡単ではありません。ただ、それだけソフトウェア開発の土台となる考え方が詰まっており、良いソフトウェアを作り続けるための強固な基盤になる一冊だと思っています。

5.3 Google のソフトウェアエンジニアリング

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

ここで Google のソフトウェアエンジニアリング を取り上げる理由は、 良いソフトウェアの重要な条件である「持続可能性」に正面から向き合っている本 だと考えているからです。良いプロダクトは一時的に価値を出すだけでは足りず、必要な期間において価値を出し続ける必要があります。そのためには、ソフトウェア自体が時間に耐えられる構造や運用を持っていなければなりません。本書は、その前提に真正面から立ち、持続可能性を中心にGoogleにおけるソフトウェアエンジニアリングの経験談を紹介している一冊だと感じています。

本書では、 持続可能性について意思決定するための軸として、「時間と変化」「スケールと発展」「トレードオフとコスト」という 3 つの観点を重視 しています。そしてそれらを、「文化」「プロセス」「ツール」というレイヤーごとに整理しながら、どのような選択が合理的だったのかを示しています。 「ソフトウェアエンジニアリングとは、時間軸で積分したプログラミングである」 という表現は象徴的で、ソフトウェアエンジニアリングの定義を端的に表しています。また本書では、「プログラミングについてのアドバイスはほとんど存在しない」と明言されており、エンジニアリング組織や開発プロセス、意思決定の構造そのものに焦点が当てられています。そのため、コンストラクションを中心に扱う Code Complete とは補完関係にあり、両者を合わせて読むことで、価値のあるプログラミングとそれを持続させるソフトウェアを作ることができると感じています。

私がこの本を読んで特に強く感じたのは、ソフトウェア開発において本当に難しいのは、コードを書くことそのものではなく、 時間を前提にした意思決定 だという点です。多くのソフトウェアは短期間で終わるものではなく、長い時間をかけて変更され、拡張され、保守され続けます。その現実を前提にすると、「今うまく動くか」ではなく、「将来にわたって扱い続けられるか」を考えた判断が不可欠になります。3.4.1 で触れたシフトレフトの考え方も、この本から学んだものであり、時間軸を評価軸として持つからこそ、問題やコストを前倒しで捉える意味が生まれるのだと理解しました。

また本書では、 「コードは債務である」 という考え方も繰り返し語られます。コードは書いた瞬間から、将来にわたって何度も読まれ、修正され、理解され続ける存在になります。そのため、コードを書くという行為は、将来に向けたコストを発生させる行為でもあります。十分に考えられていない設計、その場しのぎの実装、読みづらいコードは、往々にして未来の誰かが背負うコストになります。この本を通して、良いコードを書くことはエンジニアの美的満足のためではなく、 未来のソフトウェアのコストを下げるための投資 なのだと腹落ちしました。またこの考え方は、「数打てば当たる」戦略への違和感ともつながっており、プロダクトを実現するためにコードを書くこと自体にコストが発生するため、実装に正当な理由があるかを問い続ける必要性を強く意識するようになりました。

本書では他にも、エンジニアリング組織のあり方、リーダーシップ、ドキュメンテーション、テストといった、持続可能性を支えるさまざまな要素が扱われています。それぞれについて深く掘り下げる専門書は数多くありますが、この本はそれらを俯瞰し、「なぜそれらが必要なのか」「どのような文脈で効いてくるのか」を理解するための導入として非常に優れていると感じています。良いソフトウェアを作り続けるためには、今だけでなく未来に対しても誠実である必要があります。この本は、そのための視点と判断軸を与えてくれる一冊であり、結果として 良いプロダクトを長く作り続けるための土台 になると、私は考えています。

6. 今後の方向性

ここまで、「良いプロダクトを作る」というテーマで、プロダクトの捉え方から始まり、ユーザーとの向き合い方、実現方法の選び方、スクラム、そしてソフトウェア開発まで、私なりの考え方を書いてきました。

一貫して伝えたかったのは、良いプロダクトは偶然や一部の才能によって生まれるものではなく、 問題と解決状態に真摯に向き合い続け、その価値を必要な期間にわたって提供し続けようとする意思決定の積み重ねによって生まれる ということです。プロダクト、スクラム、ソフトウェア開発は、それぞれ独立した話ではなく、この意思決定を支えるための手段だと私は捉えています。

この10年で私が得た一番大きな変化は、目の前のコードを「コード」としてだけではなく、 ユーザーの課題から始まる一連の流れの中で捉えられるようになったこと です。ユーザーの課題という最も抽象的なところから、最終的なコードという具体的な生成物までが、どのようにつながっているのかを構造として描けるようになってきました。

しかし同時に、その構造を本当に機能させるためには、そこに含まれるすべての段階を深く理解する必要があることも見えてきました。問題をどう捉えるのか、解決状態をどう設計するのか、どのような手段で実現するのか、そしてそれを持続可能な形でソフトウェアとして表現するにはどうすればよいのか、またそれらを実現可能にする組織をどう作るのか。まだまだ学ぶべきことは多いと感じています。

だからこそ私は、最近になってようやく スタート地点に立てた のではないかと感じています。ここまで理解するのに10年かかりましたが、今ようやく、どこを深く学べば良いのかが見えてきました。

これからは、ユーザーの課題からソフトウェアに至るまでの一連のプロセスを、より深く学んでいきたいと思っています。特にソフトウェアエンジニアとして、 プロダクトを忠実に表現し、時間に耐えるソフトウェアを作る力 は引き続き自分の本丸として鍛えていきます。良いプロダクトは持続性が必要であり、ソフトウェアもまた持続可能でなければ価値を運び続けることはできません。設計、実装、運用、改善まで含めて、未来のコストに誠実な意思決定を積み重ねていきたいと思います。

また、これまで私は一つのやり方の中でプロダクト開発をしてきただけで、他のやり方や選択肢について十分に知っているとは言えません。時間は有限なので贅沢な話かもしれませんが、できるだけ多くの方法を学び、試してみたいという気持ちもあります。

ここまで長々と書いてきましたが、正直なところ、私はまだプロダクト開発の表面をなぞっただけだと思っています。それでも、ここまで理解するのに10年かかりました。だからこそこれからは、この一連のプロセスをより深く理解し、ソフトウェアエンジニアとして、そしてプロダクト開発に関わる一人として、より良いプロダクトを作るために学び続けていきたいと思います。