きれいに終わらせることの難しさ

Yusuke Shinyama
Product Run
Published in
May 10, 2023
Photo by Nolan Issac on Unsplash

こんにちは。Tanzu Labs でエンジニアをやっている Yusuke です。

「きれいな終わり方」を阻むもの

何事も始めるのは簡単だが、終わらせるのは難しい。
— 読み人知らず

すこし昔の話ですが、「PCの起動時間を早くする」というチューンナップが流行ったことがありました。具体的には電源投入後、5秒程度でシステムが起動し、デスクトップが操作可能になるというものです。そのテクニック自体は技術的にいろいろ興味深いのですが、むしろぼくが印象に残ったのは「システムの起動を早くするよりも、システムの終了を早くする方が難しい」という報告でした。

「システムを終了するなんて、電源を切るだけなんだから、なにが難しいの?」と思われる方もいるかもしれません。実はシステムを「きれいに終わらせる」のは結構手間のかかる作業です。大きなシステムはたいてい複数のモジュールから成り立っており、各モジュールの間には依存関係があるからです。

モジュールの依存関係

たとえば、多くのウェブアプリはデータベースを使って(データベースに依存して)おり、データベースを終了するためにはまずアプリを終了する必要があります。しかし、まだアプリを使用中のユーザがいる場合、アプリはすべてのユーザが使用を中止するまで終了できません。

連鎖的な依存

かといって、システムを正常に終了せず、中途半端な状態で電源を切ってしまうと、データが消えてしまったり、さらに悪い場合は整合のとれていない不正なデータが残ってしまうことがあります。こうなってしまうと、システムをもとの正常な状態に戻すために多くの泥臭い努力が必要になります。

これに比べれば、モジュールを開始するのは比較的簡単です。モジュールの起動時には、(当然ながら)そのモジュールを使っている人はまだ誰もいません。あるモジュールの起動後に、それを利用する(それに依存する)モジュールを起動していけばよいからです。

モジュールの起動順序

多数のモジュールが存在する複雑なシステムでは、モジュールの終了順序は非常にやっかいな問題になります。たとえば、以下のようなモジュールの依存関係をもつシステムを考えてみてください。システムを「きれいに終わらせる」には、どのような順序でこれらを終了すればよいでしょうか?(ヒント:答えは複数ありますが、最初に終了すべきモジュールは5か10です)

どこから最初に終わらせるべきか?

実は同じことが人間にもいえます。ソフトウェア開発をやっていると、なにかと現実社会とのソフトウェアとの類比を考えてしまうものですが、モジュールに依存関係があるのと同じように、人にも依存関係があります。ある人が突然いなくなると、残された人々は非常につらい思いをすることになります。なぜならたいていの人は誰かを必要としており、また誰かに必要とされているからです。かといって「誰からも必要とされない人」にみずからすすんでなることは難しいでしょう。ソフトウェアにしても人生にしても、「きれいに終わらせる」ことは簡単ではありません。

人間にも依存関係がある

アジャイル開発に終わりはあるのか

さて、ここで私たちの業務であるアジャイル開発について考えてみます。よく知られているように、アジャイル開発は「実装 (ビルド)」→「計測 (メジャー)」→「学び (ラーン)」というサイクルを繰り返してソフトウェアを完成させていく方法です。ここで質問ですが、ソフトウェアが「完成する」とはどういうことでしょうか? よくある開発では、特定の機能の実装が完了した時点で開発が終わります。アジャイル開発の場合でも、決められた期間までイテレーションを繰り返した時点で開発を終えることもあります。しかしアジャイル的な考え方を突き詰めれば、ユーザのニーズはつねに変化しており、ユーザをとりまく環境も変化していることから、厳密に考えればユーザが存在する限りアジャイル開発は継続するということになります。

アジャイル開発のサイクル

上の見方はあくまで「開発プロセス」を軸に考えたものですが、もうすこし別の見方をしてみましょう。プロダクトマネジメントの観点では、アジャイル開発は「ユーザの問題が解決されれば終了する」という見方もできます。

問題と、その解決策

ちなみに、このような解決策は、ひとつとは限りません。複数の解決策が見つかる場合もあります。

複数の解決策

しかし実際には、これほど単純にはいきません。多くの場合、ある問題を解決したことによって、別の新たな問題が生じることがよくあるからです。たとえば、ある業務を効率化したことによって、それに関連する業務が追いつかなくなり、新たなボトルネックが生まれる、などといった例が考えられます。

ある問題の解決策が新たな問題につながる

さらに一歩引いた視点で考えれば、そもそも「問題←解決策」というサイクルが繰り返されること自体が「問題」だ、という見方もできるでしょう。

「問題←解決策」という「問題」

このように考えていくと、こうした問題の連鎖がいつか本当に「終わる」のかどうかわかりません。それらがすべてソフトウェア開発で解決できるわけではないにしても、私たち開発者が取り組む問題には終わりがないように見えます。

このサイクルは終わるのか

「きれいな終わり」は必要なのか

以上、PCの起動時間を端緒として「終わらせること」の難しさを考えてみましたが、そもそも私たちは本当に「きれいな終わり」を望んでいるのでしょうか。ソフトウェアの世界とは違って、現実世界では、あることの「終わり」はそれほどはっきりとは定義されていないことのほうが多いように思います。多くの問題解決は「終わる」のではなく、問題そのものが薄れていき「消える」ものなのかもしれません。個人的に師と仰ぐコンサルタントのジェラルド・ワインバーグ氏は、以下のような言葉を残しています。

本当の問題が何だったのかは、実は決してわからない。
たとえそれが「本当の問題」が解決したあとでも。
— ジェラルド・ワインバーグ著
「ライト、ついてますか — 問題発見の人間学」

以上で、この記事は終わりです。ちっとも「きれいな終わり方」ではありませんが、お読みいただきありがとうございました。

--

--

Yusuke Shinyama
Product Run

Passionate programmer and teacher, or something else.