生産性とは何か
生産性とは何か
生産性 とは一単位時間内にどれだけの成果を出したかです。 ソフトウェア開発においては、例えば「私は一か月にC#言語で6,000ステップのコーディングができます」などと言います。 「この生産性で開発をお願いします」と元請け会社から言われることもあります。 生産性は定量的に測定（表現）できなければなりません。
開発に携わる者は、自分の生産性を正確にではなくともある程度把握していなければなりません。 スケジュールを自分で引くにしろリーダに引いてもらうにしろ、線が短すぎれば残業前提となりますし、線が長すぎれば遊んでしまいます。
生産性項目
ソフトウェア開発の生産性は、「生産量÷測定期間」あるいは「実施数÷測定期間」で表します。測定期間は月単位の場合が多いです。 会社によって使いやすい単位を使ってください。
生産／実施対象 |
生産性 |
|---|---|
ドキュメント作成 |
ページ数/月 |
ソースコード製造 |
ステップ数/月 |
テスト項目立案 |
テスト項目数/月 |
テスト実施 |
テスト項目数/月 |
課題解決やタスクの実施はその生産性を測定しません。 これらはソフトウェア開発の主業務ではないからです。 もし測定するのであれば、活動時間全体の中の何割を占めるかとなるでしょう。 他のプロジェクトと比較して突出して課題解決に時間を割いているならば、問題プロジェクトと認定して良いのではないでしょうか。
ステップ数に代わる項目
「いつまで生産性を表す項目としてステップ数を使い続けるのか」と思っているプログラミングを主業務にしている方々も多いと思います。 開発環境がある程度ソースコードを生成してくれるようになっており、自分がコーディングしたステップ数を数えるのも難しくなってきています。 ステップ数に代わる項目は、あるのでしょうか？
最も有力なのが、ファンクションポイント（FP）だと思います。 FP法は見積手法の一種です。 所定の算出方法を使えば、経験豊富な人もそうでない人も、あまり変わらない見積をすることができます。 FP法は全体工数を算出する手法で、機能Aを実現するための工数は算出できますが、機能Aの設計工数、製造工数、テスト工数を分けて算出できません。 これは、設計：製造：テスト＝３：２：３などと割合を使って解決するしかないかもしれません。 会社の中でプロジェクトデータを蓄積していき、最適な割合を見つけてください。
生産性向上策の検討
ソフト開発の生産性を向上するための工夫にはさまざまなものがありますが、代表的なものとして以下があります。 近年はツールの活用が多くなってきています。
パッケージの使用 [高リスク高リターン]
業務に合うシステムを作らず、既にあるパッケージソフトを使って業務をパッケージに合わせる方法です。 パッケージと既存システムの連携部分のみ作り込むこともあります。 パッケージは当該業務の標準的な機能や流れを実現しているため、自社業務を世間の標準に合わせられ結果として効率化が図れるメリットがあります。 しかし、パッケージ選定フェーズ時の調査が甘いと、採用してみたものの大規模ユーザでは遅くて使えなかったり使わない機能がありすぎて過剰な投資になってしまったりすることもあります。 既存システムとの連携が煩雑になり使いづらくなる面もあります。
部品・パターンの使用 [低リスク低リターン]
過去に作ったソフトから部品や処理手続きを拾い上げて、今度開発するソフトに流用する方法です。 流用部分は過去にテスト済みであり、その部分は流用先ではテスト不要となります。 流用度はあまり高くはならず、得られる生産性向上は限定的です。 しかし、まずはここからスタートしてみたら良いと思います。
ソースコード自動生成 [低リスク中リターン]
設計内容を指定すると、その内容からソースコードを出力してくれるツールを使用する方法です。 UMLやER図からソースコードを生成したり、画面レイアウトからHTMLやリソースを生成します。 ツールは買う必要があります。高機能なものは値段もお高いです。 評価してみて、自社で使えると思ったら導入する（進言する）と良いでしょう。 経営の安定しているベンダのツールを使用しましょう。ベンダまたはツールが将来無くなっては意味がありません。
来店型開発 [低リスク高リターン]
今まではベンダに来てもらって要件定義などの打合せをしていましたが、逆にベンダに顧客が行ってその場で開発をするサービスがあります。 画面項目を決めると、その場でテーブルレイアウトができ動くものができます。 適用できる業務は限定的ですが、はまると圧倒的なスピードで開発が完了します。 ネットが使える環境でのみ動作し、オフライン環境では使えず組み込みシステムにも使えません。