394.プログラミングは仕事か？
初回：2024/12/11
今回は、プログラミングは仕事かどうかについて考えたいと思います。
P子「そんなの、仕事に決まってるでしょ？」※1
前回、私は JavaもPythonも仕事ではなく趣味だと書きましたが、そうは言ってもお給料をもらっている限り、好き勝手にプログラミングするわけにはいきません。ここでは改めて『仕事』としてのプログラミングって何？というのを考えてみたいと思います。
P子「好き勝手にプログラミングしてたじゃない」
1.一般的な指標
仕事としてプログラミングを行う上で、重要な指針として『QCD』があります。Q:品質、C:コスト、D:納期 でしょう。最近では『QCDS』として、S:サービスも項目に入ってきています。
P子「S:安全性(セーフティ)という考えもあるわね」
個人的には、さらに、S:セキュリティ という項目を追加しても良いと思っています。安全性は、ユーザーがどのような使い方を行っても危険な目に合わないようにするという感じで、セキュリティというのは、外部から悪意のある攻撃を受けてもそれに耐えうる機能という感じです。
P子「全部まとめて、QCD3S ってどう？」
さて、サービス、セーフティ、セキュリティですが、これらは実現すべき要件として定義されます。つまり、企画段階である程度、定義づけされて、どこまで実現させるかがあらかじめ決まっているという事です。なので、プロジェクトとしてはこれらを実現するために、QCDを管理することになります。
この、Q:品質、C:コスト、S:サービス については、利用者、顧客がその製品を判断する材料となり、顧客満足度に直結してきます。安全性やセキュリティも最終的な評価につながりますが、即効性はあまりないので、評価しにくい指標ではありますが、長期的には、ブランド力向上など、メーカーとしての信頼性に関係してくる重要な項目です。一方、製品開発においては、Q:品質、C:コスト、D:納期 が重要で、しかも顧客満足度での指標とは別の観点での判断が必要だと思っています。
P子「別の観点での判断って、どういう事？」
それは後で説明します。
まずは、基本的な所から説明すると、Q:品質、C:コスト、D:納期 は、独立した要素ではなく、それぞれが関連しています。品質を高めようとすれば、コストがかかり、納期もかかります。また、納期短縮するため、開発者を増やしたり外注すればコストがかかりますし、逆に少人数で開発すれば納期が長くなります。なので、通常のプログラミング開発においては、ある程度の想定品質を満足させることを前提に、人員割り当てを行い、納期とコストが算出されると思います。
P子「人月単価ってやつね」
実際の所、人の数よりその人の持ってるスキルの差の方が、大きいんですけどね。
P子「新人もベテランも関係なく直間比率から標準的なチャージを求めて、人月単価を計算するのよね」
実際、人によってそのパフォーマンスはけた違いのケースがあるので、アサインされた人物によってはプロジェクトが赤になったり黒になったりするので、人に応じて開発コストと納期を調整して、プロジェクト単位に赤黒でないようにしたりしてるケースも見られます。
P子「まあ、会社によって異なるかも...だけどね」
2.仕事としてのプログラミング
さて、QCD について、顧客満足度に直結する品質と、開発における品質の違いについて説明しておきます。
顧客満足に対する品質というのは、簡単に言うと目に見える品質です。プログラムで言うと、それなりの速度で動けばなんでもOKです。内部プログラムがコピペの嵐とか変な関数呼び出しをしていても顧客には見えません。
実際、昔いた開発者はプログラミングがものすごく早く、納期も短くきちんと動作するので上司からの信頼もあり出世していきましたが、ソースコードはぐちゃぐちゃで、コードを引き継いだ人達はメンテナンスに非常に苦労していました。少しの修正も神経を使う(どこでどの変数がどういう使われ方をしているか判らないとか、ある修正を入れる場合、あちこちに散らばっている箇所を修正しないといけないとか)ので機能追加なども時間がかかるので、引継ぎ担当者は嫌がっていました。当然、上司はその程度の修正に、なぜ時間がかかるのか？とか、修正後にバグが見つかったり(修正漏れなど)すると、引継ぎ担当者の責任にされてしまいます。
P子「作った本人はメンテしないの？」
上司が新しい物件があればそちらにアサインしていくので、既存のプログラムのメンテは別の人物が行う事になります。新しい物件の方が利益が大きいので、そちらに注力する方が良いという判断でしょう。そうしてメンテナンスが難しいプログラムが量産されていくという悪循環に陥ります。
P子「上司の人は、プログラムのコードは見ないの？」
見ないし、プログラム自体に興味のない人だったので、プロジェクトとQCD しか見てなかったと思います。
さて、そうなってくると、プログラムを『仕事』ととらえた場合の内部品質は、どれくらい確保すべきか問題が発生します。納期...個々のプログラムごとの開発期間をフルに使って、出来るだけきちんとコードを書くべきか、動けばOK として、コードを書いて早くできるほど優秀とみなされるべきか、となった場合、コードを読まない上司が判断するのは、外部品質を確保していて、出来るだけ早くコードが書ける人物を評価することになります。
そういう環境でプログラミングを行う場合、きちんとしたコードを書く人ほど損をすることになり、一度作ったシステムはメンテナンスが困難な状態で時代の変化についていくことができなくなり、何年か後に完全に作り直すことになります。
P子「仕様書とかも不備で、どんな機能が必要なのかコードを追いかけないと判らないのよね」
コメントもまともに書かれていない(書かれていても信用できない)コードを追いかけるのが大変で、しかもそれらの機能を顧客が実際に使っているかどうかも判らないので、非常に時間がかかります。
3.趣味としてのプログラミング
与えられたゴールに向かって、いかに早く作るかレースが私は嫌いだったので、自然と、共通部分...フレームワーク的な所を作るようになっていきました。当然上司が与えた命令ではないので、自宅開発的な感じで、ある程度完成した所で『こういうのを使ってはどうですか？』と持ち込みした感じです。
P子「昔は今と違い、そういう所はルーズだったものね」
フレームワークの開発は、必要と思える機能を先に作ることができます。というか納期も関係ありません。コストと言っても私の人件費だけです。これを使った開発を行う事で、全体のプロジェクトの開発工数が短縮されるので、フレームワークの開発費は必要経費的に認められたのでしょう。
そして、Q:品質 は自分で決めることができますし、D:納期 は先行開発的に行うので、これも自分で決められます。QCD すべてが自分でコントロールできるので、ほとんど『趣味』と同じ状況になりました。
前の職場では顧客対応というのがあるため、全員が『趣味でプログラミング』と言う訳にはいかないかもしれませんが、標準的なパッケージ製品の開発であれば、『仕事』より『趣味』でプログラミングする方が、より良い製品が開発できるのではないかと思っています。
4.まとめ
あくまで個人の考えですが、『仕事』＝『プロフェッショナル』という考えは一部の人にしか適用できない言葉だと思っています。多くの人は与えられた『仕事』を単にこなすだけ...なので『趣味でプログラミング』している人より、品質が劣っていると思っています。
といって、プログラミングを趣味だと思えない人も多くいると思いますので『与えられた仕事をこなすだけのどこがいけないんだ』という意見も聞こえてきそうですが、そういう人達は日々の努力を行っていないので、趣味プロの人達と比べて力の差が開いていく一方です。
P子「ただし、その差を上司は正確に把握できないのよね」
プログラム開発者全員に『趣味でプログラミング』しろとは言いませんが、せめて『仕事』でやるなら『プロフェッショナル』を目指してほしい所です。
ほな、さいなら
======= <<注釈>>=======
※1 P子「そんなの、仕事に決まってるでしょ？」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。