ソフトウェア開発の定量化手法 第3版。タメになる言葉9。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その9。

開発手法ごとの生産性と欠陥除去率の一覧データが掲載されいてる。

表を全部引用するのはちょっとアレなので、得られた知見のみメモ。

生産性と欠陥所率がともに高いのは「TSP/PSP＋スクラム」または「CMMレベル5＋シックスシグマ」という手法の組み合わせでした。

これは次に何を勉強すべきかの道しるべになりますね。

開発手法は、プログラミング言語とほとんど同じくらい急速に開発されている。

1985年からデータを収集しているが、新開発手法はほぼ2か月に1つの割合で発表され続けている。 

とのこと。

開発コンサル等はよく「新しい手法」「話題の手法」を現場に適用し、混乱を招き、現場の人が必死に混乱を修正して出した結果を「コンサルの成果」としてかっさらい、経営は舌先三寸に丸め込まれて「新しい手法」を信じ、絶望に打ちひしがれたプログラマーが転職していく。

という地獄のループをいくつか経験した。

「開発手法」もコロコロを新しい物に手を出さない方が良いきがする。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉8。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その8。

開発のためのプログラミング言語を選択するプロセスはきわめて主観的である。

最も一般的な選択は、単に現在利用できる言語を選択することである。

アプリケーションニーズに合った言語を慎重に分析し選択することもあるだろうが、最も一般的には、組織のプログラマは訓練を受けた言語をそのまま用いる。

多くのアプリケーションが大規模とんった現在、生産性や品質に対するプログラミング言語の影響は、10%未満と小さい。 

プログラミング言語の増殖について、視点を変える時である。

新しプログラミング言語はソフトウェア工学問題の解ではない。

新しいプログラミング言語は、ソフトウェア技術者、特に老朽化アプリケーションの保守と機能拡張にかかわるソフトウェア技術者が直面する問題である。

開発言語やフレームワークの選定にはあまり時間をかけず、得意なものを使いましょう。

「流行っているから」とか「イケてるあの企業が採用している」とか「有名人が進めている」という理由で選ぶのは本当にやめてほしいが、けっこうそういう事が多いので嫌になりますね。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉7。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その7。

ソフトウェアプロジェクトにつきもののサービス残業もあいまいさを増す要因である。

ソフトウェア業界はかなり厳しい仕事の部類に入り、サービス残業は状態化している。

平日は平均約60分、週末には半日から4時間のサービス残業が当たり前となる場合もある。

「危機に瀕した」プロジェクトでは休暇や休日は先送りされるであろう。

納期に追いまくられ、働き詰めで休暇もままならず、週末は、実に12時間のサービス残業をする場合もある。

上記の引用はアメリカの人が書いた文章の翻訳です。

この部分は、「日本人は働きすぎ」「アメリカ人は残業しない」「アメリカ人は必ず定時で帰る」とか言っている人に直視してもらいたい。

日本人もアメリカ人もハードに働いている人はいる。日本にもアメリカにもみんなが定時で帰る会社はある。

特に許せないのが、海外から日本に働きにやってきた人が「私の国ではみんな定時で帰るのに」とかいうウソをつく人がいる事。

まあ騙される人はほとんど居ないのだが、指摘しても「文化が違う」としか言わないので手に負えない。

日本語に翻訳された海外の本を読んでいると、そういうウソに気づきやすくなるので良いと思います。

まあ、「平均」で言えば日本の労働者の残業時間がアメリカと比べて長いのは事実。

あくまで平均という事を念頭に置くこと。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉7。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その7。

経験則によれば、設計を開始する辞典でソフトウェアのの要求定義は通常75%しか決まっていない。

コーディングの開始時点では、設計は通常50%そこそこしか完成していないし、プログラミングが20%程度しか終了していない時点で統合化やテストが始まり、ユーザ用文書の作成は、通常コーディングが50%ほど終了した時点から始まるといった具合である。

こういったソフトウェア開発の曖昧を受け入れて開き直ったのがアジャイル開発手法なのかなぁとか思ったりする。

個人的には、結果として現場はストレスまみれになったと思う。開発手法には、人間性という意味での性格の合う合わないというのもあるだろうと思う。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉6。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その6。

この本の2章ではFP（ファンクションポイント）をソフトウェアを計測するための指標として絶賛している。

FPの計算にはコストがかかる。つまり費用と時間がかかる。

精度は劣るものの代わりとなるとされる手法が紹介されているのでリストをメモしておく。

• アジャイルストーリーポイント
• ユースケースによる手作業による計算
• MarkIIの手作業による計算
• IFPUGの手作業による計算
• NESMAの手作業による計算
• COSMICの手作業による計算
• 自動計算
• ファンクションポイントLite
• NESMA FP試算法
• LOCからの逆算法
• パータンマッチング

下に行くほど1日当たりのFP計算量は増える。コストは下がる。

 この中ではパターンマッチングのアプローチが将来を期待された手法で、実験段階ではあるがコストと精度に期待できる。とのこと。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉5。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その5。

FP（ファンクションポイント）を計測する事で役に立つことリスト。

• ソフトウェア開発についての研究 … FPあたりのコストや作業時間。一人当たりのFP。
• ソフトウェア利用についての研究 … 開発・リース・購入、外注か自社開発かの判断。自社の保有するFP量など。
• ソフトウェア品質についての研究 … FPあたりに必要なテスト量。FPあたりの要求、設計の欠陥数。文書の欠陥数など。

テストとかってどこまでやるかは技術者の経験や哲学に基づくような、直感に頼る場合も多いように思う。FPに基づくデータで決めるというのは個人的には良いと思う。

しかしボトムアップで現場に導入するのはほとんど無理だろうと思う。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉4。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その4。

過去45年の間に、ソフトウェアは20世紀におけるもっとも定量化されていない工学分野という悪評を得てしまった。

改善を望みながらも測定を行っていない企業は、状況に翻弄されるだけで、可能性がないわけではないが発展は期待できないであろう。

定量化は発展の鍵を握る。今やソフトウェア業界はこの基本的な教訓を学ぶ時である。

就職先を選ぶときはソフトウェアの測定をどれだけ行っているかというのは見るポイントになると思う。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?