製造vsソフトウェア開発[終了]

ソフトウェア業界は製造業に比べると未熟だとよく言われます。具体的には、プロセス主導であること。

質問：開発者は製造業のプロセスから学ぶことができますか？彼らのプロセスを採用することで、ソフトウェア開発の成功率を上げることができますか？

私の見解：製造において、製品の作成はプロセス主導型です。各人が特定の一連のタスクを実行する工場があるとします。作業者（またはロボット）は、一日中ねじを締めることがあります。次に、プロセスの次のタスクが次のスペシャリストによって実行されます。ワーカー（およびロボット）は、プロセスを妨害したり、「その場で」何かを作成したりしません。部品はプロセスを経てチャーンし、出力は完成品です。それはうまく機能し、企業は99.99966％の欠陥のない製品を実現します。企業は時間の経過とともに非効率を解消します。これは印象的であり、成熟した産業の兆候である可能性が非常に高いです。

定義されたプロセスの製造では、文字通り完成品を作成できます。これはソフトウェアには当てはまらないと思います。ソース管理、コードレビュー、チェックインシート、要件収集、SDLCなどのプロセスがある場合があります。ただし、これらのプロセスを実行しても、それ自体では完成品は作成されません。これらのプロセスは有益かもしれませんが、実際の作成とは直交しています。

あなたの会社が、何百万もの画像を検索して犯罪者の顔を見つけるソフトウェアを作成するように契約しているとします。重いプロセス主導の環境にもかかわらず、開発者は「オンザフライ」で物事を作成することに従事しなければなりません。その場で物事を行うことは、製造の精神に反しています。ロボットに意識されることなく、良い製造工程を実行できます。

人間の頭の中ではまだ十分に理解されていない複雑なアルゴリズムを作成するためには、その場で物事を作成する必要があります。ソフトウェア開発とは、プロセスの後に続くものではなく、コンピュータによって実行されるプロセスの作成です。それは根本的な違いです。開発に関係する直交プロセスがいくつあっても、作成に関しては常に「オンザフライ」で実行します。

私が話をする誰もが製造の考え方に同意しているようです。私は私の考えの中で一人ですか？

ソフトウェア開発と製造の基本的な違いは、ソフトウェアの場合、設計段階が事実上すべてであることです。実際の生産（従来の製造における組立ラインのパーツ）は、いくつかのファイルをコピーすることです。ソフトウェアでは、製品設計は製品です。

つまり、製造プロセスから学ぶことができますが、生産フェーズではなく設計フェーズを検討する必要があり、多くの製造プロセスが高価な生産チェーンの特定の制限に対処するために構築されていることを念頭に置いている場合に限ります。 、これはソフトウェアには適用されません。

ソフトウェアでは非常にうまく機能するが、製品設計ではひどく失敗することが多いプロセスモデルの1つの例は、反復設計です。最小限のプロトタイプから始めて、反復ごとに機能を追加します。新しいリアウィンドウのノブデザインがどのように見えるかを確認するためにプロトタイプの車を作るのはばかげていますが、ソフトウェアではそれは理にかなっています（F5を押して数秒待つだけです-ほら、試乗の準備ができています）。

製品設計プロセスを見てみると、調べるのに最適な業界は次の2つのカテゴリに分類されます。

• 商品レートで生産を実現できるもの; たとえば、レコード業界（CDの価格の1％以下がベーキングおよび印刷です）、グラフィックメディアなどです。
• 数量が非常に少ないために設計段階が最も顕著なコスト要因であるもの（高級品、高度にカスタマイズされた製品、ニッチ市場など）

物理的な製造からソフトウェア開発までのプロセスを試して適用することは基本的なエラーです。ソフトウェア開発は反復的ではなく（自分の仕事の場合は、別の仕事を見つけてください）、部分的にしか予測できず、物理的な制限はほとんどありません（ハードウェアの速度が1つであること、および採用されたアプローチと結果の両方が非常に個人的なものになる場合があります。組立ラインの哲学を基本的に分析的で創造的な思考の問題に適用することは、壊滅的な影響を与える可能性があります（そしてしばしばそうします）。

同じ正確なソフトウェアを（単にコピーするのではなく）何度も何度も作成したい場合は、アセンブリラインを介して非常に効率的に行うことができます。

しかし、ソフトウェアの作成は反復的な作業ではなく、各モジュールは一意です。そのため、製造との比較は無効です。

あなたが探している答えはここに当てはまるか現実的だと思います。あなたが知りたいと思うのは、どのように私たちのプロセスを製造業のように設定できるかということです。代わりに、本当の問題は「製造業や他の産業が高品質の製品を製造するために何をして、何を学べるかを知ること」になると思います。または「ソフトウェア業界は品質を向上させるために何ができますか？」

残念ながら、ソフトウェア業界自体はまだ答えを知らないため、これに対する答えは不明です。これに答えられるようにするには、ソフトウェア業界は何が機能し、なぜ機能するかについて調査する必要がありますか？たとえば、テストドライブデザイン（TDD）が品質の向上につながることを示す研究があります。生産性の問題はまだ答えられていないようですが、少なくともまだ完全には理解されていません。これまでに証拠が示している限り：

• コードレビューは優れており、ほとんどのバグを見つけることが示されていますが、レビューの効果は、最初の1時間でかなり急激に低下します。平均的な人は1時間に数百行のコードしか読めないことを考えると、開発者は変更を細かく分割する必要があることを示唆しています。
• バグを見つけるまでに時間がかかるほど、修正に費用がかかります（時間と費用）。したがって、コードの記述中に開発者がそれを見つけた場合、コストは1であると言います。ユニットテストで後でそれを見つけた場合、コストは10です。EVTでそれを見つけた場合、コストは100などです。
• 要件が複雑になるほどソリューションが複雑になり、ソリューションが複雑になるほどバグが発生する可能性が高いことを示唆する証拠がいくつかあります。

数年前にこれについていくつか素晴らしい講演をしたグレッグ・ウィルソンという男性がいます。講演へのリンクは次のとおりです。GregWilson Talk

これに加えて、私はあなた自身の作品を振り返って、あなたが導入したエラーのタイプとあなたが苦労している部分と一緒にテーマを見つけると言います。これらの結果をコンパイルしてから、チェックリストを作成して、プロセスのさまざまな場所に挿入し、より良い仕事を行えるようにします。個人的に、過去数年間の私の仕事を振り返ってみましたが、私が紹介する問題にはいくつかの共通のテーマがあることがわかりました。特に私はそれを見つけました

• ビルドを壊す原因となったすべてのバリアントをビルドしたことを覚えていないことがよくあります。
• 多くの場合、変更ごとに次のことを考えません。良いケース、悪いケース、そして例外的なケース。
• 起こり得るすべての可能なシナリオ。それらがたくさんあるので、これは本当に難しいことに注意してください。

エラーのテーマをいくつか見つけたので、スクリプトに挿入したため、自動的に使用するチェックリストを作成しました。これらの問題を回避するのに役立ちます。この「チェックリストマニフェスト」と呼ばれる本について書かれた本があり、それらをどのように有効に活用できるかを詳しく説明しています。個人的には非常に洞察力に富んでいると思いました。

「彼ら」のプロセスを採用することではありません。それは、「いくつかの」プロセスを採用することに関するものであり、創造的な努力のために組立ラインのプロセスを使用することの通常かつ十分に認められた不利益はありません。ここで注意すべき最も重要なことは、プロセスの品質が製品の品質に直接つながるという考えです。

そのための最良のプロセスまたは製品は、手袋をはめたような意図された使用シナリオに適合するプロセスです。考えるべきことは、実際のコードの記述部分は、少なくとも巨視的レベルでは唯一の反復部分ではないということです。バージョン管理、バグ追跡、計画、見積もり、測定など、他のすべての側面があり、標準的で調整された実証済みのプロセスを使用すると、少なくともこれらの領域で役立ちます。

したがって、ソフトウェア開発プロセスは、組立ラインの生産に例えることはできません。したがって、「それらのプロセス」はOKではありませんが、製造業界における製品の生産設計/製品設計フェーズからインスピレーションを得られます。

質問：開発者として、製造業界のプロセスから学ぶことはできますか？彼らのプロセスを採用することで、ソフトウェア開発の成功率を上げることができますか？

回答：はい、もちろんです。ソフトウェア開発は創造的なプロセスであるという事実にもかかわらず、ソフトウェア開発者が製造から学ぶことができる多くの教訓があります。ソフトウェア開発はそれ自体がプロセスであり、他の多くのプロセスが含まれます。これらのプロセスを定義および制御できるほど、ソフトウェア開発のプロセス全体をよりよく制御できます。これは、開発者が行うすべてのキーストロークを規定する必要があるという意味ではありません。これは、開発者が自然に特定の順序でタスクを実行し、それらのタスクを管理できることを意味します。ここではいくつかの例を示します。

• 欠陥追跡：バグが観察または報告された場合、それはどうなりますか？それを紙くずに書き留めて、「調査」スパイクに貼り付けますか？後でそれらのスクラップを1つずつ削除して調査し、最終的にそれらを「解決済み」スパイクに移動しますか？バグレポートを受け取るたびにそれを確実に行うと、明確で測定可能なプロセスが得られ、おそらく、面倒でハイテクな欠陥追跡システムを持っている人よりもはるかに優れているでしょう。一部のチームメンバーは他の方法でバグを追跡するか、まったく追跡しません。

• バージョン管理：作業中にバージョン管理を使用する可能性が高く、誰もが同じように使用する場合、バージョン管理は明らかに非常に便利です。

• 製品設計：付箋紙で覆われた壁にダーツを投げて、実装する機能を決定しますか？もしそうなら、あなたはプロセスを持っています。それが素晴らしいプロセスであると誰もが主張することはないと思いますが、少なくともそれは出発点です。プロセスを変更した場合、前後を測定しない限り、変更が実際に改善されたものであることを確実に知るにはどうすればよいですか できません。

• コードレビュー：レビューごとにレビュープロセスとコーディング基準が変更された場合、コードレビューは役に立ちますか？もちろん違います。

• ソフトウェア開発ライフサイクル：分析全体->設計->実装->テスト->メンテナンスサイクルは、明確に定義する必要があるプロセスです。

これらの各ケースで、プロセスを実施することで、入力と出力を測定し、加えた変更が意図した効果をもたらすかどうかを判断できます。プロセスを設定していないということは、仕事のやり方を改善しようとするときに推測しているだけということです。これこそが製造業の本質であり、製造業の一連の改良ツールを適切なときに借りることだけが理にかなっています。

ソフトウェアの作成と保守に使用されるプロセスの定義と改善に専念する分野全体があります。これはソフトウェアエンジニアリングと呼ばれます。CMMIについて読んでいる間に開発プロセスについて質問があるのも当然です。CMMIはSoftware Engineering Instituteの製品です。

ソフトウェア開発はすでに多くの製造コンセプトを採用しています：

• EOPとコンポーネントベースの開発の両方で、Eli Whitneyの交換可能なパーツの影響を見るのは難しいことではありません。

• ソフトウェア開発で使用されるプロジェクト管理手法は、製造用に開発されたものとそれほど変わりません。ほんの2つの例として、ソフトウェアの世界では、数十年前にトヨタで開発されたかんばんの概念を最近採用しました。ガントチャートは、最初の電子コンピュータが構築されるずっと前から製造に使用されていました。

• 製造用に開発されたシックスシグマのような品質管理方法論は、ソフトウェア開発に適応されています。

重いプロセス主導の環境にもかかわらず、開発者は「オンザフライ」で物事を作成することに従事しなければなりません。

誰かが自分で顔認識パッケージにパッチを追加することを決定し、追跡システムで問題を作成せずに設計をレビューせずに製品ビルドにパッチを追加することを教えてくれますか？コードをバージョン管理にチェックインするのか、それともテスト担当者に最初にそれを見てもらうのか？私たちのプロセスは、いくつかの非常に正当な理由のためにそれらのものを必要とします。「オンザフライ」で「プロセス外」を意味する場合、それは受け入れられません。

その場で物事を行うことは、製造の精神に反しています。

繰り返しになりますが、「オンザフライ」が「プロセス外」を意味する場合、そのとおりです。しかし、製造で問題を迅速に考え、創造的な解決策を開発する必要がないと考えるなら、それは間違いです。製造プロセスであらゆる種類の問題が発生します-カップケーキに十分なクリームが充填されておらず、塗装面がQAのスクラッチテストに合格しなくなり、完成した部品の20％に重要な止め輪がなくなっています。生地の混合システムが壊れています重要な部分...