アプリやウェブサイトを開発するインドの小さなソフトウェア会社の技術的負債の増大: 誰が責任を負うのか?

私はインドのソフトウェア サービス業界に 10 年間携わっており、その間ずっと、優れたプロジェクトが完成し、驚くべき成果を上げているのを見てきました。 私は骨の折れるチームが、地球の反対側の人々に愛されてきた製品を作るために、苦しい状況の中でたゆまぬ努力をしているのを見てきました。 この 10 年間、いくつかの素晴らしいプロジェクトに取り組んできた素晴らしい思い出がありましたが、さまざまな理由でプロジェクトが下り坂になり、ソフトウェア製品がすべてうまくいかなかったのも目撃しました。 私の周りや、この10年間で知っている人々の周りで、私が望んでいたよりも多くのことが起こりました.

プロジェクトの失敗について多くのことが語られてきました。 ミームは、階層全体がジャングルの食物連鎖のようにお互いを追いかけている方法のインターネットに群がっています. プログラマーがバグのあるコードを書いていると非難する人もいれば、実現不可能な非現実的な約束をしたことで経営陣をののしる人もいます。 一部の人々は、この業界の技術的な前提条件と依存関係を理解し​​ていないことでクライアントを非難することさえあります. しかし、技術的負債やコード負債について話し、お互いに非難することなく文明化された方法でこの問題に対処している人はほとんど聞いたことがありません。 周りの人から、または参加したイベントや、読んだ地元のブログから、この用語の技術的負債に出くわしたことは一度もありません。

私がこの用語に出会ったのは、米国のシリコン バレーのブログやジャーナルを読んだときだけでした。 これは、インドの小規模および中規模のソフトウェア開発会社で働くほとんどのプログラマーおよびソフトウェア エグゼクティブが、今までこの用語を聞いたことさえなかったことを意味します。 それでは、用語自体の説明から始めましょう。 技術的負債、またはコード負債は、ソフトウェア開発における概念であり、時間のかかるより良いアプローチを使用する代わりに、現在簡単な (限定的な) ソリューションを選択することによって生じる追加の再作業の暗黙のコストを反映しています。

簡単にするために分解してみましょう。 それを構築する最良かつ最も効率的な方法を選択するのではなく、特定のモジュールまたはシステム全体を構築する簡単なオプションを選択したために発生した可能性のあるプログラミングおよび設計の問題を解決するためのコストを計算するという概念です。 ソフトウェア開発の分野では、怠惰と遅刻が戻ってきて尻を噛むというこの現象は、他のどこよりもはるかに頻繁に発生します。 Karma は、プログラマーによって意地悪であるという社会的表現を得たようです。

どうか、誤解しないでください。私は、すべてのコードの負債をプログラマーのせいにしているわけではありません。 インドの小規模なソフトウェア開発会社のプロジェクトの 90% 以上で確実に発生するコードの負債に責任を負うエンティティが複数存在することは確かです。 それらのいくつかを簡単に説明してみましょう。

1. せっかちで過度に賢いクライアント

はい、餌を与えるその手を噛むことから始めて、容赦なくそうします。 小規模な外部委託ソフトウェア開発プロジェクトの市場は巨大で、非常に細分化されています。 このグローバル化された市場を完全に正当化する真に優れた企業もあれば、規制も管理もされていないという理由だけで、この完全に優れた取り決めを食い物にするパラサイト企業もあります。

これにより、クライアントは、ニーズに基づいて提携する適切な会社を選択する際に間違いを犯すことになります。 適切な審査スキルを持っていないことは彼らのせいではありませんが、ゴミ会社と本物の会社を識別する基本的なストリートスマートを持っていないことを責める者は誰もいません. 今、彼らは才能のないチームを前に進めることに同意すると、彼らの非現実的な期待とタイムラインを窒息させます. それだけでなく、彼らの中には、デザインやプログラミングに独自の提案を持ち込むことで、彼らがいかに頭が良いかを示しすぎてしまうことさえあります。 (#notallclients)

あなたがソフトウェア開発会社のクライアントである場合は、彼らに任せて、彼らの仕事を任せてください. 医師や弁護士のところに行って、あなたがググったことと、あなたの問題について何を言ったかを伝えて、彼らの顔の反応を見てみましょう. 自分の分野の専門家は、初心者から自分の分野についてアドバイスを受けることを好みません。 ソフトウェアエンジニアも例外ではありません。

優れたソフトウェア開発チームを見つけて、有望そうに見える場合は、彼らにスペースを与えてください。そうすれば、彼らは手抜きをしたいという衝動を感じなくなり、プロジェクトのコード負債が少なくなります。 そして、ほとんどの場合、そのコードの負債を支払うのはあなた方です。 「変更依頼」という言葉を聞いたことがありますか? 私はあなたのほとんどが持っているに違いない！ 理想的なシナリオでは、人生でそのような言葉を聞くべきではありません。 しかし、それはめったに起こりません。 そして、その言葉を何度も耳にするほど、ソフトウェア会社のクライアントとして失敗したことになります。

2. 怠け者でよこしまな管理者

ここで言うマネージャーとは、ソフトウェア開発会社側のプロジェクト管理職のことです。 プロジェクト マネージャー、チーム リーダー、デリバリー ヘッド、または会社の所有者であっても、プロジェクトをまとめて支払いを回収するためだけに手早く手を洗おうとしたことがあるなら、あなたは当事者です。あなたのプロジェクトにおけるこの多額の技術的負債のせいでもあります。

ここで最も悲しいのは、皆さんが膨大な量の技術的負債を支払うことは決してないということです. クライアントが標準以下の製品を使用してお金を払っているか、それをきれいにするために実際により多くのお金を払っているかのどちらかです. そして、それがクライアントではない場合、要求されている以上の無限の時間を働かなければならない貧しいプログラマーがその代償を払っているのです。 しかし、これらの中間者はめったにありません。したがって、私によると、彼らはこの技術的負債のトピックで最も責任のあるエンティティである必要があります.

彼らを採用する場合、彼らが持つべき最大の資質はモラルです。 彼らのモラル コンパスが正しい方向を指している場合、彼らは説明責任を負い、プロジェクトに有利な正しい決定を下すでしょう。これにより、最終的には技術的負債のコンパイルが少なくなります。 これは、正しいリーダーの下で働くことを選択することについて語ったジャック・マーの有名な引用を思い起こさせます。 ここのこのシナリオに非常に適しています。

3. プログラマー

そうそう、皆さんを責めてこの話題を終わらせるつもりはありません! でもねえ、#notallprogrammers でしょ？ ええ、でもプログラマーのほぼ 94% です。 少なくとも、Tech Mahindra の CEO である CP Gurani は、IT 卒業生の 94% がこの仕事に適さないという衝撃的な事実を数年前に明らかにしたとき、そう考えています。 彼がどのようにしてその数字にたどり着いたかは正確にはわかりませんが、インドのエンジニアリング カレッジの出身者であり、過去 10 年間にわたって IT エンジニアリング エコシステム全体を目の当たりにしてきた私は、Gurani 氏が述べたことに同意する傾向があると言えます。

私はそれが 94% なのか 90% なのか 80% なのかを議論しようとしているわけではありません。 でも例えると、生地を作るのに小麦粉、水、塩ひとつまみ、チャパティを作るのにめん棒が必要なことは、ほとんどの人が知っているようです。 しかし、実際に食べられるチャパティを作れる人はほとんどいません。 それは非常に単純なプロセスですが、それを上達させるには、ある程度の才能と大量の練習が必要です. プログラミングの場合も同じです。 私たちは皆レシピを知っていますが、実際に袖をまくり上げて手を汚し、その技術を習得するのにかかる限り練習した人はほとんどいません.

したがって、平均的なプログラマーがプロジェクトを委託された場合でも、技術的負債が組み込まれたコードを知らず知らずのうちに作成し、後になって初めてそのことに気付くことになります。 そして、ほとんどのプログラマーがこの仕事に不向きであるにもかかわらず、業界が全体的にどのようにうまく機能しているのか疑問に思っているなら、それは有能なマネージャーと苦労して物事を学んだ経験豊富な先輩たちのおかげです。 彼らは、最適なコードを書くという危険な道を進む際に、これらの新鮮な手と心を助け、プロジェクトの出荷を実現可能にし、負担のかかる負債から解放します。 そして最終的には、適切な身だしなみとトレーニングを行って新人が仕事を上手にできるようになるか、IT 業界に別れを告げることになります。

したがって、結論として、このコラボレーションの 3 つの主要な関係者はすべて、コードの負債をコンパイルする責任を共有していると思います。 繰り返しますが、この作品を、業界のすべての問題を否定するものとして受け取らないでください。 それは、ホラーとヒーローのかなりの割合を持つ世界の他の業界と同じです. これを10年続けた後でも、私は自分の人生で他に何もしません。 私はこの仕事が大好きです。世界中のクライアントからのエキサイティングなプロジェクトに取り組んでいる小さな会社であることをとても気に入っています。

その目的は、3 人の利害関係者全員がより説明責任を負い、誤ったコラボレーションによって彼らに打撃を与えていたこの根本的なソフト ロスについて知ってもらうことでした。 ソフトウェア開発チームが技術的負債を正確に計算して測定したい場合は、アジャイル手法やウォーターフォール手法に基づく厳密なプロセス モデルに従うことができます。 その規律あるアプローチに従うと、これらの修正スプリントと修正スプリントを個別にマークすることができ、フェーズの終わりに、必要なスプリントの数を正確に計算して、簡単に目標に到達できるようになります。その理由。

最後にサミュエル・ベケットの言葉を引用して締めくくります。