ソフトウェア開発の定量化手法 第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版 ?生産性と品質の向上をめざして?

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

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

成功している大企業の定量化計画の9ステップとして紹介されている項目をできるだけ短くまとめる。

1. 運用環境の測定 … コンピューターの利用率やダウン時間など。1950年代から一般的に測定されている。
2. 開発中のプロジェクトの測定 … プロジェクトの計画値と実績値など。1950年代からかなり一般的に測定されている。
3. ソフトウェア資産とバックログの測定 … ソフトウェアにかかっている費用など。
4. 顧客満足度の測定 … ユーザーインタビューも大事。1950年代後半から1960年代にかけて測定がはじまる。
5. 完了プロジェクトの測定 … 完了したプロジェクトのFP（ファンクションポイント）など。1980年代から一般的になってきた。
6. ソフト要因の測定 … 開発と保守の手法、スキル、ツール、組織、環境についての調査。1980年代から成熟した。
7. ソフトウェアの欠陥の測定 … 欠陥率や欠陥除去率の測定。「IBMなどのような真のリーダーのみが測定している」らしい。欠陥と顧客満足度には強い相関がある。多くの企業にとって1990年代の課題。
8. 企業内従業員統計の測定 … 従業員のスキル、人数など。「技術者」でひとまとめにしてはいけない。
9. 企業内の意識調査 … 専門家による社員の意識調査が必要。うまくしないと人に誤解を与えたり傷つけたりする。

「欠陥」「従業員統計」「意識調査」のあたりが難しく、実践できている企業が少ないということらしい。

自分の経験では、「意識調査」は形としてはやっていても、結局は経営者の意図にそぐわない社員を見つけるためにやっているというパターンがあって、まさに「人を傷つける」結果になっている。

「従業員統計」に関して、「技術者」でひとくくりにしている会社は多い。エンジニアの分類や評価を上手くできる人は限られていますね。

「ソフトウェアの欠陥の調査」は、技術者は重要性に気づいているが、調査結果を事業計画に反映できない事が多い。

欠陥への対応よりも目先の利益を生み出す企画にリソースが回されてしまい、技術者は負債に苦しむことになる。

と思いました。

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