エンジニアの職務経歴書で短命な開発運用は「スクラップアンドビルド」と書こう

エンジニアの職務経歴書で短命な開発運用は「スクラップアンドビルド」と書こう

エンジニアが転職するとき、短期間のアプリ開発ばかりで職務経歴書でアピールしにくいと悩むことがあります。

そのんなときは「スクラップ・アンド・ビルド」という言葉で経歴を書いてみましょう。

「スクラップ・アンド・ビルド(scrap and build)」とは、直訳すると「壊してから建築する」という意味です。

この言葉は、主に工場の設備や組織などに関して、古くなったり効率が悪くなったりしたものを捨てて、新しいものに入れ替えることを指します。

例えば、石炭産業や繊維産業などでは、技術革新や競争力向上のために、断続的に「スクラップ・アンド・ビルド」を行ってきました。

経営理論における「スクラップ・アンド・ビルド」

この言葉は、1950年代後半から1960年代にかけて、イギリスやアメリカで使われ始めました。

当時は、第二次世界大戦後の復興期であり、産業界では急速な発展と変化が起こっていました。

その中で、古くなった設備を破棄して新しいものに入れ替える「scrap and build」は、効果的な経営手法として注目されました。

日本では、1960年代から1970年代にかけて、「スクラップ・アンド・ビルド」というカタカナ語として広まりました。

「スクラップ・アンド・ビルド」のデメリット

「スクラップ・アンド・ビルド」という手法は、生産性や収益性を向上させるために、いまや多くの企業や行政が採用しています。

しかし「スクラップ・アンド・ビルド」にはデメリットも指摘されています。

まず、1つ目のデメリットは、コストがかかることです。

既存の設備や組織を廃棄する費用や新しい設備・組織を構築する費用が必要です。 これらの費用は、短期的には収益にマイナスですし、長期的にも回収できるかどうかは不確実です。

例えば小売業界では、店舗を閉鎖したり、移転したりすると、その地域の顧客を失ったり競合店に流れる可能性があります。

また、工場や行政機構では、設備や人員を削減したり変更したりすると、ノウハウが失われる可能性があります。

次に、2つ目のデメリットは、抵抗が強いことです。

設備やサプライチーンを刷新することは、既存の設備やサプライチーンに関わっている人々の利益や感情を損なうことになります。

そのため、関係者からの反対や批判が強く予想されます。

例えば、小売業界では、店舗を閉鎖したり移転したりすると、その店舗の従業員や地域住民からの反発が起こることがあります。

また、工場や行政機構では、設備や人員を削減したり変更したりすると、その設備や人員の労働組合や利用者からの反対運動が起こることがあります。

リーン・スタートアップ

このように「スクラップ・アンド・ビルド」には、コストがかかったり、関係者からの抵抗が強かったりするデメリットがあります。

こうしたデメリットを避け、よりスムーズに経営革新を実現する考え方として「リーン・スタートアップ」という考え方が生まれてきました。

「リーン・スタートアップ」とは、低コスト・短期間で作成した最低限の製品(MVP: Minimum Viable Product)で顧客の反応を見ながら開発するマネジメント手法です。

つまり、完璧な製品を作る前に、早く市場に出してフィードバックを得ることが重要だという考え方です。

「リーン・スタートアップ」では、最低限の製品で市場に出します。 そのため、失敗しても大きな損失にはなりません。 また、失敗から学んで次に活かすことができます。

一方、「スクラップ・アンド・ビルド」では、完璧な製品を作ってから市場に出します。 そのため、失敗した場合は大きな損失になります。また、失敗から学ぶ機会が少なくなります。

「リーン・スタートアップ」は「スクラップ・アンド・ビルド」に比べて、コストを低く抑えることができると考えられています。

デザイン思考

「スクラップ・アンド・ビルド」のデメリット(コスト、関係者からの抵抗)を避ける経営改革の手法として、近年注目されているものの1つに「デザイン思考」があります。

デザイン思考は、AppleやGoogleなど世界的な企業が採用している方法です。

「デザイン思考」では、「スクラップ・アンド・ビルド」とは逆に、最初から最後までユーザーの視点を忘れずに開発を進めます。

そのため、ユーザーにとって価値のある製品やサービスを作り出すことができると考えられています。

デザイン思考は、以下の5つのステップからなるプロセスで行われます。

このプロセスは線形ではなく、反復的に行うことができます。

つまり、テストのあと再びエンパシーに戻ったり、定義やアイデア出しを見直したりできます。

観察と共感

ユーザーの視点に立って、彼らの感情や動機、ニーズや課題を理解することです。

ユーザーと対話したり、観察したり、インタビューしたりすることが有効です。

定義

前段階で得られた情報を分析して、ユーザーの本質的なニーズや課題を明確に定義することです。

定義するためには、問題文やポイント・オブ・ビュー(POV)ステートメントという形式で表現することが有効です。

アイデア出し

定義されたニーズや課題を解決するためのアイデアを自由に発想することです。

アイデア出しでは、量より質を重視し、批判せずに積極的に発言することが大切です。

また、他の人のアイデアに乗っかったり、組み合わせたりすることも有効です。

試作

アイデア出しで生まれたアイデアを具体化することです。

紙や段ボールなどの手軽な素材で作ることができます。

完璧でなくても構いません。目的は、アイデアを試すことです。

テスト

試作品をユーザーに使ってもらい、フィードバックを得ることです。

テストでは、ユーザーの反応や感想を観察したり、質問したりすることが大切です。

テストの結果をもとに、プロトタイプやアイデアを改善できます。

短命な開発運用は「スクラップアンドビルド」と職務経歴書に書く

さて前置きが長くなりましたが、エンジニアが転職するときに、短期間のシステム開発ばかりで職務経歴書でアピールしにくいことがあります。

システムが「短命」つまり「短期間でそのシステムの開発・運用が終わってしまった」というと、「システム開発のレベルが低いと思われるかもしれない」などと気にして積極的にアピールしない人もいます。

一方で、ここまで見てきたように、事業企画(経営学)の視点からすると、短期間で製品を作り直すプロセスはイノベーションに不可欠な工程でむしろ「最先端のアプローチ」ともいえる手法です。

「スクラップ・アンド・ビルド」を繰り返すプロセスに「付き合ってくれる」エンジニアのニーズは確実にあります。

ですので「短命」のシステム開発が多いことを恥じることはありません。 「スクラップアンドビルドを繰り返してきた」と堂々と職務経歴書に盛り込みましょう。

「スクラップ・アンド・ビルドの繰り返しに付き合うえること」があなたのエンジニアとしての「強み」なのです。

関連記事

職務経歴書に「キャスト」「クルー」と書くべき?「スタッフ」「同僚」「メンバー」ではなく

スタッフという言葉は、複数の人が一緒に仕事をする場合の担当者を指す一般的な言葉です。しかしスタッフと言わずに「キャスト」「クルー」と呼ぶ会社もあります。 そうした会社に勤めていた場合、職務経歴書にも「スタッフ」「同僚」「メンバー」ではなく「キャスト」や「クルー」と書くべきでしょうか?

目次
メインメニュー