生産性向上の鍵

稼働率と生産性はイコールではないが、無関係でもない！
生産性があがるとモチベーションがあがりゾーンに突入する。
ゾーンに入ると、同じ作業を行っていても集中力が違うためスピードは上がり、ミスも少なくなる。
すると時間に余裕ができるようになり、次のステップに進みやすくなる。この一瞬は稼働率は下がるが、スキルアップするために、行える仕事が多くなる。
それにより上位者が行っていた仕事を変わりに行えるようになり、待ちが発生しなくなる。
かなり強引だが、以下の公式が成り立つ。

生産性向上→モチベーションＵＰ→学習意欲向上→スキルアップ

最終的に「稼働率up」へとつながる。
風が吹けば桶屋が儲かる的な話だが、あながち眉唾でもない。

では、生産性を上げるには、どうしたら良いのだろうか？
まず、生産性の定義を決めておく！
生産性は「開発生産性」と「保守（生産）性」の両方を含むものとする。
立場にもよるが、開発と保守の両方をお粉なっている人も少なくないはず。
モチベーションを上げるには、開発生産性だけではなく保守性も向上しないことには、まったく意味が無い。
よって、ここでは生産性は「開発」と「保守」の両面を含むものとして定義する。
以下に生産性を向上されるための鍵となる「稼働率」を向上させるためのルール（規約）を上がる。

・ルーチンワークの排除
　ルーチンワークは単純なものが多くモチベーションを下げる。　ルーチンワークはマニュアルで行わずに、プログラムで行う。　それを実現する環境（ソフト、ハード、人）を用意する。　＊人がマニュアルでやっている事には、何らかのルール(判断基準)　　 がある事が多い、そういう作業はプログラムの方が得意。

・既存機能のコピー＆ペーストを廃止
　テンプレートを利用する分には可とする。　＊理由は、既存の機能には固有のロジックが含まれている場合が 多いため、開発中半・後半に障害が発生する場合が多い。

・プログラム開発は小さい機能から作成し、常に稼動確認出来る状態で開発する。
　ＢＬは一気に完成系のものを作成しようとすると、バグが混在しや　すい、且つバグの発見にコストがかかる。　但し、ＢＬを含まない画面遷移は、一気に作成したほうが効率が　良いため可とする。

・設計の段階でデータストアへのアクセステスト(SQL等)は、先に行っておく（DBが存在する場合）
　設計の段階で開発言語が顔をだすのは、良くない事かもしれない　が、実装の段階で問題を発覚するぐらいであれば許容範囲

・同じ機能は2度作らない（同じことは2度行わない）。
　時間が経過してから、同じものが必要になった場合は、その時に　共通化を行うべき。別システムであったり、本番導入の関係上　共通化できない場合は、2つめ以降を共通かし、その後は同じ機能　を開発しない。　開発時間、テスト時間の削減と、ノウハウの蓄積につながる。　プログラムもドキュメントも。。。　つまり、DRY(Don’t Repeat Yourself)に生きろ！

・実装前に想定される共通機能、テンプレート作成しレクチャーする。
　画面のビューに関してはシステムのテーマがあるため装飾や　フォントおよび配置などを機能毎(エントリー画面や一覧照会画面)　にテンプレートを用意しておく。　画面の機能（ボタンやリンク押下時の動き）についても、スクリプト等を埋め込んだ「タグ」をテンプレートを用意しておく。

・担当者割り当てをユースケースレベルから機能単位に変更する。
　1ユースケース(サブシステムの機能)単位で、人を割り当てるので　はなく　開発する機能(プログラム)のレベルで担当者の割り当てを　行う。単純なマスター系であっても、その1部の機能が複雑であれ　ば、その箇所はレベルのあった別担当者に任せる。　スキルアップを目指すためにレベルにあっていない開発を行うこと　は、担当者もプロジェクトも不幸になる。　レベルにあったプログラムが完璧になったら次のステップに行く。

・ソースレビューを行う。
　初めはこまめに行い。少しづつ大きな（単一機能）レベルで行う　ようにする。　大勢でおこなうのではなく、1対1で行うようにする。行う場所は　レビューを受ける人の端末で行うようにする。