効率を優先して生み出された成果物が必ずしも最適であるとは限らない

効率を優先して生み出された成果物が必ずしも最適であるとは限りません。むしろ、後々になって再検討や修正などが発生して、長期的な視点では非効率になるケースがあります。

最短経路で進まず、一見、非効率に思える準備・検討を事前に行うことで、最適な成果物を生み出すことができるようになります。

一時停止、遠回り

一時停止や遠回りをしたほうが、安全に利用できる成果物を出すことができます。

【実例】ユーザインタフェース設計

ユーザが次のアクションを素早く行うことができるように、UIを簡略化しすぎると、操作ミスに繋がることがあります。

操作ミスが発生すると、リカバリするためのパッチ当てや、再発防止策の導入に工数が取られます。

デザイン・フロントエンドの開発工数は増えますが、操作ミスを防止できる＋αの作り込みを行っておいたほうが、長期的には工数が少なく済むことがあります。

発散

意見を発散させた上で、集約したほうが、最適な成果物を出すことができます。

【実例】仕様検討

効率を優先して十分な検討をせずに開発着手してしまうと、後になって「検討漏れが見つかる」「改善・修正が必要になる」などの手戻りが発生するケースがあります。

検討を行う際には、その時点では不要となる内容でも意見を出し合うことで、検討漏れを防いだり、将来の機能追加を想定した仕様に落とし込むことができるようになります。

抽象化

具体的な指示について、抽象化も合わせて提示することで、継続的に運用できる成果物を出すことができます。

【実例】手順書

手順書など引き継ぐ可能性のあるドキュメントでは、記述レベルに注意しないと、機能追加などに伴って、修正コストが発生することがあります。

ドキュメントに、手順・手順だけでなく、仕様・目的も記載しておくことで、引き継ぎ先でもメンテナンスが行える状態にしておくことができます。

まとめ

作業効率だけを優先して、最短経路で物事を進めると、後々、非効率になることがあります。

リリースしてからも、継続的にサービスを提供するためには、一見、非効率に見える検討・準備を予め行っておくことが大切です。