#144 『0→1』と『1→10』の難しさの違いと評価のされやすさの理由
こんにちは。ITベンチャーエンジニアのこへいです。
昨日はシステムの受託開発事業における新規開発案件に関わることが評価されやすい理由について、『売上』への貢献が見えやすいこと、組織のTOPの個人的な興味関心や盛り上がりによって注目されやすいポジションであるという観点で考えてみました。
今日は、受託開発における『0→1』『1→10』フェーズの違いについて対応内容の違いから、『0→1』が評価されやすい理由について掘り下げてみます。
〇受託開発の『0→1』と『1→10』の違い
前回の記事では、受託開発の売上構成から下記のように整理しました。
①開発費
②利用料、運用保守費
①の開発費の中でも新規顧客への導入や既存顧客のシステムリプレースなどが一からシステムを構築するため、『0→1』に該当します。
システム導入済の顧客からの要望に合わせて新しい機能を開発することは『1→10』に該当します。
②の費用をいただき、運用保守の対応をすることも『1→10』に該当します。
では、『0→1』と『1→10』の業務内容の特性についても比較してみます。
『0→1』 ― 特性 ― 『1→10』
決まっている ― 開発期間 ― 決まっていない
決まっている ― 開発内容 ― 決まっていない
多い ― 人数 ― 少ない
多い ― アウトプット量 ― 少ない
狭い ― 求められる業務範囲 ― 広い
ざっくりとこんな感じです。
『0→1』の開発案件は決まった期間で顧客と合意し内容を多くのメンバーで対応します。そのため、一定期間内のアウトプット量が大きいため、評価を得やすいということを前回の記事で述べました。
関係者も多く、一定期間でのアウトプット量を最大化するために、効率化を重視し個々人の役割は限定されることが多く、エンジニアであればほとんど開発に専念することが出来ます。
一方で『1→10』の業務では明確な期限やゴールがありません。顧客からの問い合わせや事業目標の達成に対してやるべきことを状況に合わせて優先度を決め、いつまでに何をどこまでやるのかを自分達で判断する必要があります。また、花形の『0→1』にリソースが割かれるため、関係者が少なく一人一人に求められる業務範囲の幅が広いという特徴があります。
このように、『0→1』と『1→10』仕事の特性は全く違います。
〇『1→10』の難しさは見えにくい
『0→1』はとにかくアウトプット量が多いです。
そのために誰にとっても成果が見えやすく、どんどん進んでいる感が自然と演出されるため評価しやすいです。
多くのアウトプットを出すことが簡単というわけではありません。顧客の要望に応えることが技術的に難しい場合に、解決先を見つけ出し実装する能力が求められます。また、とにかく必要とされるアウトプット量が多いため、開発力やハードワークする力が求められます。
花形のポジションであり、失敗は許されず成功を請け負うことになるため、相応のプレッシャーに耐えられる強さも必要です。
一方で、『1→10』の難しさは見えにくいです。
過去に開発されたシステムを運用するには、システムへの深い理解が必要です。私が運用しているシステムのコード量は60万行を越えます。顧客からの問い合わせに適切に応えるには60万行のコードを理解ている必要があります。
また、顧客からの追加要望への対応には、どのような過去の経緯があったのか、顧客との関係性や自分たちのビジネスの在り方など、総合的な観点から最適に方法を選択し実現していく必要があります。
開発案件のようにチーム全体の短期的な共通目標がないために、立場や役割に応じて大切にする観点が違うため、関係者の調整も必要になります。
営業として顧客の要望に応えたい一方で、エンジニアとしては技術的負債を抱えない方法で価値を提供したい。など。
アウトプット量は少ないですが、アウトプットを出すために必要な検討事項が多く、広い視野や高い視座が求めらる難かしさがあります。
〇『1→10』で起きた問題でワイワイしにくい
『0→1』にしろ『1→10』にしろ、困難なシーンが出てきます。
例えば、『0→1』では解決の難しい顧客要望を突きつけられるような時であり、『1→10』ではシステム障害を起こしてしまったような時です。
『0→1』では「この要件やべー！！w」と比較的わいわいしながら対応しやすいです。
そして、やりきれば拍手喝采となります。
（実際とても大変なので、この状況でワイワイできる人はすごいです。そういう人は視座が高いのだと思います。）
一方、『1→10』でのシステム障害が起きている時は本当に笑えないです。なんとか対応が完了しても、障害報告や再発防止策を求められるため、盛り上がりにくいのです。
困難を乗り越えるということは同じでも、『1→10』のケースではマイナスをゼロにするため評価されにくいです。
〇『1→10』の価値を可視化する必要性
『0→1』『1→10』のいずれのフェーズの仕事も重要です。
『0→1』で失敗すると売り上げの拡大は見込めず、『1→10』フェーズの仕事の質が低いと顧客からの信頼が得られず、新たな『0→1』の案件の確保や『0→1』に割くリソースの確保も難しくなります。
仕事の特性は違えどいずれも難易度は高く、仕事の価値としてもどちらが上ということもありません。
私自身、両方の仕事を経験しており、『0→1』フェーズの開発案件で社内の最優秀案件として3回表彰された経験があります。それらの案件はいずれもタフなもので表彰いただくに値する仕事をしたという自負はあります。
『1→10』フェーズの運用も非常に難易度が高いと感じ、様々な困難を乗り越えてきましたが、運用で同様な高い評価を得たことはありません。
『0→1』ばかりが評価される状況では、不公平感が生まれてしまいます。
また、『1→10』を高いレベルで行える人を育てることの方が難しいと感じており、替えがきかないという点でも『1→10』フェーズの仕事をキチンと評価することは重要だと感じます。
この点は運用の仕事のアピールなど、まだまだやるべきことがやり切れていないので、やっていかねばというところです。
ということで、受託開発において『0→1』が評価されやすい理由について掘り下げてみました。
最後までお読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？