ソフトウェア設計をしていたら仕様の違和感に気が付いた話

Wed, 10 Jun 2026 17:00:00 +0900

違和感のある仕様
違和感のある仕様通りに実装した場合
現時点の動作が同じなら、前者でも後者でもいいのではないか？
解決策
まとめ

ソフトウェア設計をしていたら、仕様の違和感に気が付いて、仕様を変更した話を書きたいと思います。

違和感のある仕様

ある画面 C は、画面 A と画面 B という二つの画面から遷移可能な画面でした。

画面 C には、戻るボタンがありました。

戻るボタンをタップすると、

「画面 A から遷移した場合は A に戻り、画面 B から遷移した場合は B に戻る」

という仕様でした。

この、何の変哲もない普通の仕様に、実は違和感が潜んでいました。

【補足】
今回の話は、非常に些細な点をとりあげます。
そのため、この話で出てくる例自体は、実際にはほぼ無害です。
しかし、簡単な例だからこそ、
どのようにソフトウェアが壊れていくのかを
誰が読んでもわかる例になっています。
それを知るきっかけとなるように、この記事を残します。

違和感のある仕様通りに実装した場合

Android で画面遷移を実装する場合は、 Navigation Component というライブラリを使用することが一般的です。

Navigation には、

一つ前の画面に戻る 場合には、

NavController.navigateUp() という関数が使えます。

一方で、 指定した画面まで戻る 場合には、

NavController.popBackStack(route = /* 戻りたい画面 */, inclusive = false)

という関数が使えます。

仕様では、「画面 A から遷移した場合は A に戻り…」とあるので、後者の関数を使って実装します。

前者の関数を使用して実装しても、現時点では同じ動作になりますが、将来的には同じとは限りません。

例えば、 A -> D -> C という画面遷移になった場合には、

演繹（えんえき）法から考える設計の本質

Wed, 10 Jun 2026 15:00:00 +0900

演繹法とは
私たちは日常的に演繹している
問題は前提が曖昧なときに起こる
設計とは何をしているのか
演繹法と設計の関係
まとめ

ソフトウェア設計について考えていると、「演繹法」という言葉に出会うことがあります。

しかし、演繹法と聞くと何か特別な思考法のように感じるかもしれません。

私自身、演繹法について改めて考えてみた結果、

「普段当たり前にやっていることに名前が付いているだけではないか？」

と感じました。

この記事では、演繹法とソフトウェア設計の関係について考えてみます。

演繹法とは

演繹法とは、

一般的なルール（前提）から、個別の結論を導く考え方

です。

有名な例として、

人間はみな死ぬ
ソクラテスは人間である
したがってソクラテスは死ぬ

というものがあります。

重要なのは、

前提が正しければ、結論も正しい

という点です。

私たちは日常的に演繹している

実はソフトウェア開発者は、日常的に演繹法を使っています。

例えば、次のようなインターフェースがあったとします。

interface PaymentRepository {
 suspend fun save(payment: Payment)
}

このコードを見たとき、多くの開発者は自然に次のように考えるはずです。

save は保存処理である
保存したデータは後で取得できるはず
保存したデータが勝手に壊れてはいけないはず

これはすべて、

save は保存する
↓
だから○○であるべき

という演繹です。

特別なことをしているわけではありません。

普段の設計レビューやコードレビューで当たり前に行っている思考です。

問題は前提が曖昧なときに起こる

ただし、演繹法には重要なポイントがあります。

それは、

前提が明確であること

です。

例えば、次のようなインターフェースを考えます。

interface PaymentRepository {
 suspend fun delete(id: Int)
}

これを見た多くの人は、

delete は削除処理である
削除したデータは取得できなくなるはず

と考えるでしょう。

しかし、実際には仕様として、

論理削除を行う

というルールが存在するかもしれません。

この場合、

delete は物理削除である

という前提を、利用者側が勝手に補っていたことになります。

つまり、問題は演繹法そのものではなく、

前提が曖昧であること