序章 問いとしての品質 (version-alpha)
「工学の目的は品質である。」 バートランド・メイヤー (コンピュータ科学者)
ソフトウェアエンジニアとしての仕事は品質を作り込み、品質を維持し続けることだと私は考えています。
次の文章を読んでみましょう。
封を切り、一本のボールペンを手に取る。
指先に伝わる軸の太さは、細すぎず太すぎない。滑らないのに、肌を邪魔しない。紙に触れた瞬間、インクはためらわずに出る。
力を入れなくても線は途切れず、止めたいところで止まる。
書き出しも、方向転換も、こちらの意図に遅れがない。書いているあいだ、ペン先から余計な音はしない。
紙の上を滑る感触だけが続き、思考が遮られない。
文字を書く行為が、意識から少しずつ消えていく。書き終えて見返すと、線は均一で、滲みもない。
「うまく書こう」としなくても、結果が整っている。ペンを置いたとき、特別な感動はない。 ただ次も、無意識にこの一本を選ぶだろうと思う。
それが、このボールペンの品質だ。
問い：この時の品質とはボールペンにあるのか、あるいは使用者にあるのか。
エンジニアリングの現場
「品質が大事だ」
エンジニアであれば、この言葉を一度も聞いたことがない、という人はいないでしょう。 設計レビューでも、コードレビューでも、品質指標でも、品質改善活動でも。 品質という言葉は、私たちの仕事のあらゆる場面に登場します。
しかし、ここで少し立ち止まって考えてみてください。 あなたにとって、品質とは何でしょうか。
バグが少ないこと？ 性能が高いこと？ 要件を満たしていること？ それとも、ユーザーにとって使いやすいこと？
どれも正しそうで、どれも少しずつ足りない気もします。
品質は「答え」なのか
現場では、品質はしばしば「評価されるもの」「満たすべき基準」として扱われます。 テストを通過しているか、規格に準拠しているか、数値が基準値を超えているか。
こうした扱い方は、決して間違いではありません。 むしろ、品質を実務に落とし込むために不可欠な視点です。
けれども同時に、こんな違和感を覚えたことはないでしょうか。
仕様通りなのに、なぜか「良くない」
指標は達成しているのに、納得できない
数値化できない何かが、確かに存在する気がする
もしそうなら、それは品質を「答え」として扱いすぎているサインかもしれません。
品質は、問いから始まる
品質とは、本来「これで本当に良いのか？」という問いから生まれるものではないでしょうか。
この設計は、誰のためのものか
この実装は、どんな未来を前提にしているか
この判断は、何を犠牲にし、何を守っているか
品質は、完成した成果物の中に静かに宿るだけでなく、 意思決定の瞬間瞬間に現れる「問いの痕跡」 でもあります。
つまり、品質とは測る対象である以前に、 考え方であり、姿勢であり、思考の流れなのです。
エンジニアと品質観
エンジニアは、問題を解く訓練を受けてきました。 要件を分析し、制約を整理し、最適解を導く。 その過程で「正解」を出すことに慣れています。
ですが、品質に関しては、必ずしも唯一の正解は存在しません。 文脈によって、立場によって、時間軸によって、 「良い品質」は姿を変えます。
それでも私たちは、日々判断を下し、設計を選び、実装を積み重ねています。 その背後には、言語化されていない個々人の品質観が必ず存在しています。
あなた自身は、どんな品質観を持っているでしょうか。 それは、いつ、どのように形づくられたのでしょうか。
本書が目指すもの
本書『品質の体系学』は、品質を定義する本ではありません。 チェックリストやフレームワークを提示する本でもありません。
本書が扱うのは、品質をめぐる思考の道筋です。
探究し、思索し、洞察し、練磨し、叡智へと至る五つの道。 それは章立てであると同時に、 エンジニアが経験を通して知を深めていく過程そのものでもあります。
読み進める中で、 「自分は品質をこう考えていたのか」 「なぜあのとき違和感を覚えたのか」 そんな再発見が生まれることを願っています。
品質とは何か。 その問いに、急いで答えを出す必要はありません。
まずは、問いとしての品質を、 一緒に見つめるところから始めてみましょう。
第一章 探究：問いの生成
品質について考えようとすると、私たちはつい「定義」から始めたくなります。 品質とは何か。 良い品質、悪い品質の違いは何か。
けれども、本章ではあえて定義を後回しにします。 その代わりに、問いが生まれる瞬間に目を向けてみましょう。
品質の思考は、答えからではなく、 多くの場合「小さな違和感」から始まるからです。
違和感は、どこから来るのか
たとえば、こんな経験はないでしょうか。
設計レビューで「問題ない」と判断されたが、なぜか不安が残った
テストはすべて通っているのに、リリースしたくない気持ちがあった
他人のコードを見て「動くけれど、美しくない」と感じた
このとき、あなたは明確な理由を説明できたでしょうか。 多くの場合、できなかったのではないかと思います。
それでも、その違和感は確かに存在していました。
品質をめぐる探究は、 説明できない感覚を、無視しないことから始まります。
問題ではなく、問いとして扱う
エンジニアは違和感に出会うと、それを「問題」として解決しようとします。 原因を特定し、修正し、再発を防ぐ。 これはとても重要な姿勢です。
しかし、品質に関しては、 違和感をすぐに問題化しないほうがよい場合があります。
なぜそう感じたのか。 何と比較して違和感を覚えたのか。 もし別の選択をしていたら、何が変わったのか。
これらは、解決すべき問題というより、 育てるべき問いに近いものです。
問いとして扱うことで、 思考は一気に広がり始めます。
問いは生成される
問いは、どこかに完成形として存在しているわけではありません。 考え、試し、振り返る中で、少しずつ形を変えながら生成されます。
なぜこの設計を「良い」と思ったのか
その判断基準は、いつ身についたのか
その基準は、今の文脈でも有効なのか
問いを立てた瞬間、 私たちは自分自身の思考を観察する立場に立ちます。
これは、単に技術的に正しいかどうかを判断する態度とは異なります。 自分がどう考えているかを考えるという、一段メタな視点です。
品質の探究とは、この視点を獲得していくプロセスでもあります。
良い問いは、不安定である
良い問いは、すぐに答えが出ません。 むしろ、答えを出そうとすると逃げていくような感覚すらあります。
それは不親切なのではなく、 問いが「思考を動かすため」に存在しているからです。
正しさと良さは、同じなのか
局所最適と全体最適は、どこで衝突するのか
将来の変更容易性は、今どれだけ犠牲にしてよいのか
これらの問いに、唯一の正解はありません。 しかし、問い続けることでしか見えない景色があります。
探究するエンジニアという姿勢
探究とは、知識を増やすことではありません。 視点を増やすことです。
品質を探究するエンジニアは、 「判断を保留する力」を持っています。 そして同時に、 「問いを手放さない力」も持っています。
問いを持ち続けることは、ときに不安を伴います。 ですが、その不安こそが、 品質を単なるチェック項目から解き放ち、 生きた思考へと変えていきます。
この章では、あえて結論を出しません。 問いは、まだ生まれたばかりだからです。
次章では、 ここで生成された問いを手がかりに、 品質という概念を少しずつ深めていきます。
問いを抱えたまま、 次の「思索」の章へ進んでください。