神は細部に宿る

「神は細部に宿る」なんて良く言います。軽く検索したところ、誰が最初に言ったかは分からないようですが、割と昔から言われている言葉のようです。意味は、大体皆さんの想像通りですが、

  • 本物・優れたものは、細部まで手を抜いていない
  • 本物と偽物の違いは、細かいところに現れる

といったところでしょう。

この手の諺というか格言には大体正反対の意味を持つものもあり、今回で言うと

「木を見て森を見ず」

辺りがそうでしょうか。

実生活や仕事での話で言うと、結局はバランスだと思うので、

全体を俯瞰して物事を判断しつつ、細かい仕上げにも気を配るべき

といった当たり前の結論に落ち着きます。（当たり前の事を当たり前のようにやることが実は難しかったりもするのですが、その辺りはおいておきます。）

前振りはこの程度にして、今回は仕事における詰めの重要さについて書いていきます。

完成させることが大切

完成とは

ソフトウェア開発の現場では、システムなり機能をまず完成させることが大事です。当たり前ですね。

では、「完成」の定義とはなんでしょうか。私は以下のように考えます。

  • 受託システムなら、納品可能な状態
  • 自社サービスなら、リリース可能な状態
  • 機能追加なら、その機能が利用可能な状態
  • pull request なら、マージ可能な状態

逆に、以下のような状態は、全て未完成だと考えます。

  • ×: 裏側の実装はほぼ終わってるけど、その機能を呼び出すボタンが実装されていない
  • ×:実装もテストケースも書き終わっているが、テストデータが用意されていない
  • ×:3つの小さな機能追加を含む PR で、1つの機能だけ完成していない

上の未完成のどのケースでも、残作業の量は大したことは無いかもしれません。ただ、そこで「大体出来たから」と次に進んでしまうか、最後まできっちり詰めて終わらせるかで、結果として「未完成のまま」か「完成」か、という大きな違いとなります。

なぜ「完成」が重要か

なぜ「完成」がそこまで重要なのでしょうか。それは完成させないと、以下のような結果となるからです。

  • お金がもらえない
  • サービス・機能が使えない（＝価値を提供出来ない）

ビジネスとして成り立たないことは明白でしょう。

個別のタスクという観点で見ても、あるタスクが完了しないと、

  • 後続の依存関係のあるタスクが開始出来ない
  • プロジェクト全体の進捗率が増えない（計測の仕方にもよる）

といった弊害があります。

どう「完成」まで持っていくか

与えられた仕事なりプロジェクトを、なんの問題も無く「完成」まで持っていければ苦労は無いのですが、実際には予定のスケジュールより遅れたり、スコープが膨らんだりという事が良くあります。

そうしたときに使える方法がいくつかあります。

  • 未完成部分を別のタスクに切り出す
  • 「完成」を見据えつつ、1つ1つ終わらせる

1つ目ですが、終わっていない部分を別のタスクとして切り出して、終わりそうな部分だけまず終わらせるという方法です。

前の方で挙げた「3つの小さな機能追加を含む PR で、1つの機能だけ完成していない」（※）という例であれば、未完成の機能だけ別の PR に切り出して、残りの2つだけ先に「完了」に持っていくという方法です。

※複数の機能追加を1つの PR にするのは、一般的には良くないことです

この場合の注意点として、2つの機能が残りの1つとは独立して動作しないと、結局、残りの1つが完成するまでは全体として完成では無い、とみなされてしまう可能性があります。

例えば、自動車の納品プロジェクトであれば、一旦標準仕様の車を納品して、後からレカロのシートに変更する、ドライブレコーダーを設置する、痛車塗装をする、というのはお客様にとってOKの可能性が高いですが、ハンドル無しの車を納品して、後からハンドルを取り付けるとかは恐らくダメでしょう。

「『完成』を見据えつつ、1つ1つ終わらせる」についてですが、仕事は「1つ1つ終わらせる」のが基本だと思います。

理由としては以下の2つです。

  • マルチタスクの弊害を避けたい
  • 未完成の仕事＝お金を生まない

マルチタスクの弊害とは、タスク切り替えの際に無駄な時間・脳のエネルギーが必要となる事を指していますが、ここでは詳細は省略します。

未完成の仕事がお金を生まないことについては、前述の通りです。単純化すると、完成すると100円を生み出す仕事が3つあったとして、3つとも80%の状態（未完成）では生み出すお金は0円ですが、1つ1つ取りかかって2つを完成させていれば、200円になります。

「『完成』を見据えつつ」の部分についてですが、先ほどの自動車納品のプロジェクトを例に取れば、車として最低限動作するタスクを優先して1つ1つタスクを終わらせるという事です。エンジンやハンドルの取り付けを優先し、ドライブレコーダーや痛車塗装は後回しにします。

品質について

「神は細部に宿る」に戻ると、細かいところまで手を抜かない、品質を高める、というのが重要そうです。では、どこまで品質を高めれば良いのでしょうか。

適正品質と過剰品質

プロジェクト管理（や生産管理などでも多分）には「適正品質」と「過剰品質」という用語があります。

一般には、適正品質が善で過剰品質は悪なので、適正品質まで持っていく事が仕事における「完成」になります。

「適正」、「過剰」は相対的なもの

ところが、何が「適正」で何が「過剰」かというと、そこは難しいところです。

例えば、あるサービスのクローズドβ段階であれば、デザインはそこまで凝る必要も無く Bootstrap 等のテンプレートをそのまま使えば良いかもしれません。ただ、その後の一般公開の段階ではそうでは無い事の方が多いでしょう。プロジェクトのフェーズによって「適正」が変わる一例です。

あるいは、iPhone 最新版のカメラには多数のレンズが付いています。私にとっては不要で「過剰」なものですが、高画質に価値を見いだす顧客も多数います。対象顧客にとって、「適正」や「過剰」が異なる一例です。

どこまで目指すか

上述の通り、プロジェクトの種類や状況に応じて「適正」は異なりますが、もばらぶでの仕事の方針としては

  • 「適正」を見極める
  • 制約の範囲内で「適正」を上回る品質を求める

というものになります。

まとめ

仕事は詰めが重要です。

仕事は「完成」まで持っていかないとお金が発生しないことが殆どですし、品質に関しては「適正品質」を上回っていないと「完成」とみなされません。

今後も、きっちり仕事をして、お客様に満足して頂けるように努力しようと思います。