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

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

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

 経験によると、IBMのようなきわめて先進的な企業では、以下で述べる9種類の測定をすべて行っている。

いやしくも先進的な企業といわれるためには、9種類のうち少なくとも5種類の測定を運用していなければならない。

非常に後進的な企業では、たかだか2種類の測定しか運用していない。

全く測定を行っていない企業もあるが、これらの企業の将来は暗く、企業活動は長続きしないだろう。倒産か吸収合併が待っている。

自分が10年以上見てきた社会では、ソフトウェアの品質等に関する測定なんてほとんどやっていなかった。

現場レベルでなんとかやっていたとしても、経営層や他の部署からはほとんど関心を持たれる事は無かったなぁ。

我々エンジニアにプレゼン力が無かったせいもあるだろうけど、そもそも経営層が開発の事に興味無いんだったらそんな事業やめちゃったら良いという想いもあり、自分から抜けてしまった。

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

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

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

人間の活動を正確に測定してみると、スペシャリストはジェネラリストを凌駕する場合が多い。

1,000人以上のソフトウェア技術者を擁する大企業を見ると、専門化の進んだ企業のほうが生産性が高い。

1000人以上だから専門化を進めた方が良いのか、専門化を進めたからこそ生産性が上がって大企業になれたのか。これはどっちなのだろう。

この本はなかなかタメになる内容が多い。

文章がとても簡潔で要点がまとまっている。

内容が濃い上に、ページ数も多い。

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

AIを使って文章から性格診断をしてくれるサービス

Personality Insights

IBMのAI「Watson」を使って、文章から性格診断をしてくれるサービス。

ツイッターのアカウントを登録して分析とかもしてくれるようです。

英語がベースになっているらしく、日本語はちょっと変です。

ちなみに私の性格診断結果は以下のようなもの。

表現に富むタイプであり、また活発なタイプです.

冒険的なタイプです: 新しい経験をすることを熱望しています. 哲学的なタイプです: 新しいアイディアに興味をそそられ、進んで受け入れ、探求することを好みます. また、自分に自信があるタイプです: 冷静で自信があるように感じる傾向があります.

現代性を意識して意思決定するタイプです.

伝統と生活を楽しむことの両方にあまりこだわりません. 人が通った道よりもわが道を行くことを大切にします. また単なる個人の楽しみよりも大きな目標を伴う行動を優先します.

さらに「個性」「欲求」「価値」と言う項目で特性を表示してくれる。

意外…でもないけど協調性が低めなのが気になる。

「自由主義」が92%で、「現状維持」が3%というのは、次の仕事を決めないまま無職になっちゃうあたりに現れまくっている感じがした。

遊んでみてはいかがでしょうか。