「利用者に価値提供をしているか」この意識があるかないかが分かれ目である。
重要な三つの事実
①作っているだけでは意味がない。作った物が利用され、価値を提供できてはじめて意味がある。
②速く作って、速くデプロイし、速く成果を提供できる。というのが最も重要な指標。
③改良ではなく改悪し、利用者に迷惑をかけるのは最悪の行為。
補足
③：利用者がどう利用しているのかを知らずに開発を行うのは良くない。まず利用者を知るところから始める必要がある。知らない状態で開発し、UI・UX・ユーザビリティを低下することが現実多い。
③：バージョンアップ案件で自信満々でリリースしたが、頻繁に使う機能が使いにくくなったり、特に欲しくない機能や利用しない機能が増えて複雑な印象になっていることがある。これで自信満々でドヤ顔している人もいる。これは自己満であって、価値より害を増やしてしまっている。実際にこういうケースが多い。
②：軽微な修正を行うだけなのに、開発環境を構築するのに時間が掛かる、エディタを開くまでに時間が掛かる、コンパイルに時間が掛かる、リリースまでに時間が掛かる・・・という開発環境は悪。品質管理とのトレードオフではあるが、成長の必要性があるサービスではこれが大きな阻害要因となる。成功する可能性がある事業であっても、優先すべきポイントを見誤ってしまうと、事業自体が失敗してしまう。モダンで先進的でエンジニア業界で誇れる開発環境であっても、自己満である可能性はとても高い。本質的な構築作業ではなく周辺作業に多くの時間が使ってしまっている場合は、疑問をもつべきである。レガシーは悪・モダン最先端であるべきという態度を示すエンジニアに多い傾向。これも自己満。そういった姿勢の人程利用者に対しての価値提供の実績は薄い傾向がある。やはり内部指向・自己満である。
②：ソフトの設計はそれを行う組織の構造（特徴）をそのまま映し出すといわれる「コンウェイの法則」。その通りで、遅い組織が作ったソフトウェアの応答や処理速度も遅くなる。遅いソフトウェアは利用者の不満をもたらす。これは良くない。だから速いことは大切なのである。
①優れた技術力を持っていることや熟練度が高いこと自体は素晴らしいことである。でも持っているだけでは外部的には意味がない。その能力を活かして成果物が創出され、その成果物を使った利用者が満足した時に外部的な価値提供ができたことになる。これを忘れて技術力があることを主張しても仕事としては意味がない。こういうケースでは、なんで評価されないんだ。という気持ちを抱えている人が多い。あいつより学んでるしできるのに！という考えを持っている。利用者に与えた価値を比較して説明してあげる必要がある。