「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その12。
保守費用は、実のところは追加、修正のコード量に左右されるのではなく、修正アプリケーションの規模、経過年数、複雑度、潜在欠陥量に大きく左右される。
修正しようとする内容の影響が少ないというのは直感に反する事実なので、面白い知見です。
運用エンジニアの目標として、既存コードの複雑度を減らすというのは良いかもしれないですね。複雑度を減らした結果上がるという「保守担当量」も計測して目標に据えるのは良いかもしれない。
ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?
「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その11。
ソフトウェア要因が1,000人程度の中規模ソフトウェア組織は、コスト超過、スケジュール遅延など最も問題をはらんだ組織である。
この規模の組織にあっては、速やかに専門化する必要があるが、多くはジェネラリスト重視の姿勢を引きずっている。
そのため中規模組織は最低の生産性と最悪の品質レベルを示す事が多い。
この規模の企業でも洗練された企業は以下に示すように幅広いスペシャリストを擁している。
ジェネラリストよりも専門家を置いた方が生産性は高いというお話。
小規模の会社では一人が多くの事やらざるを得ないが、1000人以上の会社では専門家が多い体制だと良い。
直感的にも、専門家のほうが良い仕事ができると思う。
ジェネラリストというと聞こえは良いが、ただの素人集団という場合が多い。というのは個人的意見。
ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?
「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その10。
西暦2000年問題は世界中で運用されているアプリケーションの最大75%に影響した。
根本原因は単純であったがユーロ通貨問題とは異なり、この問題は経営情報システムのみならず医療機器、電話交換システム、プラントなどに組み込まれたコンピュータにも影響した。
（ユーロ通貨への対応とあわせて）ちなみにこの2つの問題のために1999年と2000年には世界のソフトウェア技術者の65%以上が、さまざまな保守と機能拡張に従事したとされる。
2000年問題って騒がれたけど結局何もなかったよね～。
という声をたまに聞くので引用してみた。
プログラムの保守の仕事は増え続けている。今後も増え続けるのでしょう。
ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?
「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その9。
開発手法ごとの生産性と欠陥除去率の一覧データが掲載されいてる。
表を全部引用するのはちょっとアレなので、得られた知見のみメモ。
生産性と欠陥所率がともに高いのは「TSP/PSP＋スクラム」または「CMMレベル5＋シックスシグマ」という手法の組み合わせでした。
これは次に何を勉強すべきかの道しるべになりますね。
開発手法は、プログラミング言語とほとんど同じくらい急速に開発されている。
1985年からデータを収集しているが、新開発手法はほぼ2か月に1つの割合で発表され続けている。
とのこと。
開発コンサル等はよく「新しい手法」「話題の手法」を現場に適用し、混乱を招き、現場の人が必死に混乱を修正して出した結果を「コンサルの成果」としてかっさらい、経営は舌先三寸に丸め込まれて「新しい手法」を信じ、絶望に打ちひしがれたプログラマーが転職していく。
という地獄のループをいくつか経験した。
「開発手法」もコロコロを新しい物に手を出さない方が良いきがする。
ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?
「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その8。
開発のためのプログラミング言語を選択するプロセスはきわめて主観的である。
最も一般的な選択は、単に現在利用できる言語を選択することである。
アプリケーションニーズに合った言語を慎重に分析し選択することもあるだろうが、最も一般的には、組織のプログラマは訓練を受けた言語をそのまま用いる。
多くのアプリケーションが大規模とんった現在、生産性や品質に対するプログラミング言語の影響は、10%未満と小さい。
プログラミング言語の増殖について、視点を変える時である。
新しいプログラミング言語は、ソフトウェア技術者、特に老朽化アプリケーションの保守と機能拡張にかかわるソフトウェア技術者が直面する問題である。
開発言語やフレームワークの選定にはあまり時間をかけず、得意なものを使いましょう。
「流行っているから」とか「イケてるあの企業が採用している」とか「有名人が進めている」という理由で選ぶのは本当にやめてほしいが、けっこうそういう事が多いので嫌になりますね。
ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?
「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その7。
ソフトウェアプロジェクトにつきもののサービス残業もあいまいさを増す要因である。
ソフトウェア業界はかなり厳しい仕事の部類に入り、サービス残業は状態化している。
平日は平均約60分、週末には半日から4時間のサービス残業が当たり前となる場合もある。
「危機に瀕した」プロジェクトでは休暇や休日は先送りされるであろう。
納期に追いまくられ、働き詰めで休暇もままならず、週末は、実に12時間のサービス残業をする場合もある。
上記の引用はアメリカの人が書いた文章の翻訳です。
この部分は、「日本人は働きすぎ」「アメリカ人は残業しない」「アメリカ人は必ず定時で帰る」とか言っている人に直視してもらいたい。
日本人もアメリカ人もハードに働いている人はいる。日本にもアメリカにもみんなが定時で帰る会社はある。
特に許せないのが、海外から日本に働きにやってきた人が「私の国ではみんな定時で帰るのに」とかいうウソをつく人がいる事。
まあ騙される人はほとんど居ないのだが、指摘しても「文化が違う」としか言わないので手に負えない。
日本語に翻訳された海外の本を読んでいると、そういうウソに気づきやすくなるので良いと思います。
まあ、「平均」で言えば日本の労働者の残業時間がアメリカと比べて長いのは事実。
あくまで平均という事を念頭に置くこと。
ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?
「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その7。
経験則によれば、設計を開始する辞典でソフトウェアのの要求定義は通常75%しか決まっていない。
コーディングの開始時点では、設計は通常50%そこそこしか完成していないし、プログラミングが20%程度しか終了していない時点で統合化やテストが始まり、ユーザ用文書の作成は、通常コーディングが50%ほど終了した時点から始まるといった具合である。
こういったソフトウェア開発の曖昧を受け入れて開き直ったのがアジャイル開発手法なのかなぁとか思ったりする。
個人的には、結果として現場はストレスまみれになったと思う。開発手法には、人間性という意味での性格の合う合わないというのもあるだろうと思う。
ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?
