道具を持った愚か者は増幅された愚か者である

ツールはソフトウェア開発者の能力を高めることができますが、非効果的または不適切なツールの使用は、ソフトウェア開発者の欠点も増幅します。

Freepik 上の KamranAydinov による画像

私の友人のノームは木工の専門家です（上の写真のノームではありません）。彼は建物自体も含めて自分の木材工場を設計し、建設しました。彼の店には数え切れないほどの手工具や電動工具があり、それらをいつどのように適切かつ安全に使用するかを知っています。専門のソフトウェア エンジニアは、使用する適切なツールとそれらを効果的に適用する方法も知っています。

おそらく、ソフトウェア エンジニアの Grady Booch が語った「ツールを持った愚か者は依然として愚か者である」という言葉を聞いたことがあるかもしれません。それは寛大すぎます。ツールは、自分が何をしているのかよくわかっていない人に、より迅速に、おそらくより危険な方法でそれを実行する方法を提供します。その影響力は彼らの非効率性を増幅させるだけです。すべてのツールには利点と制限があります。最大限のメリットを得るには、実践者はツールの概念と方法を理解し、適切な問題に正しく適用できるようにする必要があります。

と言うと 道具 ここで私は、一部のプロジェクト作業 (見積り、モデリング、テスト、コラボレーション) を促進または自動化するソフトウェア製品と、ユースケースなどの特殊なソフトウェア開発テクニックの両方を指します。昨今ではAIもツールと言えるでしょう。 AI の機能と限界は、多くの分野でまだ調査中です。さまざまな AI ツールはソフトウェア開発の貴重なアシスタントとなり得ますが、魔法や絶対確実なものではありません。 AI からの結果の正確さや有効性に過度に依存すると、実際に愚かさが増幅される可能性があります。

ツールは熟練したチームメンバーの生産性を向上させますが、訓練を受けていない人々の生産性を向上させることはできません。能力の低い開発者にツールを提供しても、開発者が適切かつ効果的に使用しないと、実際には生産性が低下する可能性があります。人々がテクニックを理解し、それをいつ使用するか、いつ使用しないのかを理解していなければ、それをより速く、より美しく実行できるツールは役に立ちません。

ツールは価値を付加する必要がある

私はツールが非効率的に使用されている例を数多く見てきました。私のソフトウェア グループはかつてプロジェクト計画に Microsoft Project を採用していました。私たちのほとんどは、Project がタスクの記録と順序付け、期間の見積もり、進捗状況の追跡に役立つと考えています。しかし、チームメンバーの一人が調子に乗ってしまいました。彼は、3 週間の開発反復を伴うプロジェクトの唯一の開発者でした。彼は各イテレーションの開始時に数日を費やして、そのイテレーションの詳細な Microsoft Project 計画を 1 時間の解像度まで作成しました。私は計画を立てることには賛成ですが、これは時間を浪費するやりすぎでした。

ハイエンドの要件管理 (RM) ツールを購入したものの、ほとんど恩恵を受けなかった政府機関を知っています。彼らは、プロジェクトの何百もの要件を従来の要件仕様書に記録しました。その後、それらの要件を RM ツールにインポートしましたが、ドキュメントは最終的なリポジトリのままでした。要件が変更されるたびに、BA はドキュメントと RM ツールのデータベースに保存されているコンテンツの両方を更新する必要があり、余分な作業が必要でした。

チームが活用した唯一の主要なツール機能は、要件間のトレーサビリティ リンクの複雑なネットワークを定義することでした。これは便利ですが、後で、彼らが生成した広範なトレーサビリティ レポートを誰も使用していないことがわかりました。この機関の非効率的なツールの使用は、かなりの時間と費用を費やしましたが、ほとんど価値を生み出しませんでした。

モデリングツールは簡単に悪用されます。アナリストやデザイナーは、モデルを完成させるために過度の労力を費やすことがあります。これは「マウスアラウンド」と呼ばれることもあります。 私はビジュアルモデリングの大ファンです 反復的な思考を促進し、間違いを明らかにするためですが、人々は選択的にモデルを作成する必要があります。すでによく理解されているシステムの部分をモデル化し、最も詳細な部分まで掘り下げても、プロジェクトに比例した価値は追加されません。

自動化ツールに加えて、特殊なソフトウェアの実践も不適切に適用される可能性があります。たとえば、ユース ケースは、ユーザーがシステムで何をする必要があるかを理解し、実装に必要な機能を推測するのに役立ちます。しかし、私は、それがプロジェクトで採用されている要件テクニックであるという理由だけで、既知のあらゆる機能をユースケースに強制的に当てはめようとした人を何人か知っています。必要な機能についてすでに知っている場合は、完全なユースケースを持っていると誇らしげに宣言するためだけにそれを再パッケージ化する価値はほとんどありません。

ツールは賢明に使用する必要があります

同じ日に、私はコンサルティング クライアントのサイトにいて、そのチーム メンバーの 1 人が購入したばかりの変更要求ツールを構成していました。私は、変更リクエストを収集し、そのステータスを長期的に追跡するツールの使用など、賢明な変更管理メカニズムを支持します。ただし、チーム メンバーは以下のものを使用してツールを構成しました 二十 考えられる変更要求ステータス: 送信済み、評価済み、承認済み、延期など。たとえ論理的に賢明だとしても、20 個のステータスを使用する人はいないでしょう。 6 つまたは 7 つあれば十分です。これを非常に複雑にすると、ツールのユーザーに非現実的な負担がかかります。ツールをまったく使用する気をなくし、価値があるよりも面倒だと思わせる可能性さえあります。

あるとき、ソフトウェア エンジニアリングのベスト プラクティスに関するクラスを教えていたとき、私は生徒たちに、lint などの静的コード分析ツールを使用しているかどうか尋ねました。プロジェクト マネージャーは、「はい、私の机には PC-lint が 10 部あります。」と言いました。私の最初の反応は、「開発者に配布したほうがいいかもしれません。開発者が机上で役に立たないからです。」でした。ツールがその恩恵を受ける人々の手に渡らなければ、そのツールは役に立ちません。

別の会社で静的コード分析について同じ質問をしました。ある学生は、チームがシステムのコードベースで lint を実行したところ、約 10,000 件のエラーと警告が報告されたため、二度と使用しなかったと述べました。大規模なプログラムが自動チェッカーを一度も通過したことがない場合、多くのアラートがトリガーされる可能性があります。レポートの多くは、誤検知、重要ではない警告、またはチームが無視することを決定する問題でした。しかし、騒音の中に紛れて、そこにはおそらくいくつかの本当の問題があったのでしょう。些細な問題に気を取られすぎず、本当に関心のある項目に集中できるようにツールを構成します。

ツールはプロセスではありません

人々は時々、良いツールを使用すれば問題が解決すると考えることがあります。ただし、ツールはプロセスの代わりにはなりません。プロセスをサポートします。私のクライアントの 1 人が問題追跡ツールを使用していると話したとき、私はそのツールがサポートするプロセスについていくつか質問しました。問題の報告を受け取って処理するための定義されたプロセスがなかったことを知りました。彼らはツールしか持っていませんでした。実践的なプロセスが伴っていない場合、人々がツールを適切に使用しないと、ツールは混乱を増大させる可能性があります。

ツールは、人々に自分が実際よりも良い仕事をしていると思わせる可能性があります。自動テスト ツールは、そこに保存されているテストよりも優れているわけではありません。自動回帰テストを迅速に実行できるからといって、実行されるテストでエラーが効果的に検出されるわけではありません。コード カバレッジ ツールはステートメント カバレッジの高い割合を報告できますが、重要なコードがすべて実行されたことは保証されません。ステートメント カバレッジのパーセンテージが高くても、テストされていないコードが実行されたときに何が起こるか、すべての論理分岐が両方向でテストされたかどうか、または異なる入力データ値で何が起こるかはわかりません。また、ツールが人間の労力を完全に置き換えるわけでもありません。ソフトウェアをテストする人は、テスト ツールに読み込まれた問題を超えた問題を発見するでしょう。

私は、要件を要件管理ツールに保存しているため、プロジェクトが要件に関してうまく機能していると主張する人々と話をしたことがあります。 RM ツールは多くの貴重な機能を提供します。ただし、優れたレポートを生成できるからといって、データベースに保存されている要件が適切であるとは限りません。 RM ツールは、古いコンピューティング表現 GIGO (ガベージ イン、ガベージ アウト) を鮮やかに示しています。ツールは、要件が正確であるか、明確に記述されているか、完全であるかどうかを知りません。不足している要件は検出されません。

各ツールの機能と制限の両方を理解しておく必要があります。一部のツールでは、一連の要件をスキャンして競合、重複、あいまいな単語がないか確認できますが、その評価では要件が論理的に正しいかどうか、あるいは必要であるかどうかはわかりません。要件ツールを使用するチームは、まず要件を適切に引き出し、分析し、指定する方法を学ぶ必要があります。 RM ツールを購入したからといって、熟練した BA になれるわけではありません。自動化する前に、テクニックを手動で使用する方法を学び、それが自分にとって効果があることを証明する必要があります。

ツールとプラクティスを適切に適用すると、品質と生産性が向上し、計画とコラボレーションが向上し、混乱から秩序がもたらされるため、プロジェクト チームに大きな価値を加えることができます。しかし、たとえ最高のツールであっても、弱いプロセス、訓練を受けていないチームメンバー、困難な変革への取り組み、組織の文化的な問題などを克服することはできません。そして、次のいずれかを常に覚えておいてください ウィーガーのコンピューティングの法則：「人工知能は本物の代わりにはなりません。」それはいつか真実ではなくなるかもしれませんが、現時点ではまだ当てはまります。

---

著者: カール・ヴィーガース

この記事は以下から転載されています ソフトウェア開発の真珠: 50 年間のソフトウェア経験から得た教訓 カール・ヴィーガース著。 カールは他にも数多くの本の著者です。 ソフトウェア要件の要点 (キャンディス・ホカンソンと)、 ソフトウェア要件 (ジョイ・ビーティと)、 日常のものの無思慮なデザイン、 そして 成功するビジネス分析コンサルティング。