うちの会社の「開発力向上」をどう実現させるか


仕事じゃなかったら、めんどくさくて考えたくないが、現在、会社の方針で開発力の向上の為の案を考える事に。
後ろ向きな理由で大変不甲斐ないけど、まぁ、仕方ない。

で、

「開発力向上」って？

自分としての理解は、アウトプットの最適化が開発力を高める為の近道だと考えてるに至っている。
なぜか、それは、限りなく、何となく直感。
まずは、その何となくを切り口に深めてみる事にした。

最適化する為には、、、

えっと、

やはり、開発はより多くの時間を使いたい。
そして、出来れば効率的に使いたい。
結果、タイムマネージメントが重要性が語られる。
その為に、いろんなツールがあったり、やり方がある。

いろんなものを駆使して最短、最速、最大、最高のアウトプットを出す。
そして、良いも悪いも、評価を受ける。

ただ、そのアウトプットの為に、ついついオーバーワーク（つまり普段より多くの時間を使ってしまう）ことがある。
そして、最悪の評価を受ける事も多くある。

私は、これって非効率だと思う。
それは、自称「ソフトウエアエンジニア」だから？

オーバーワークって慰めの言葉の様な気がする。
私は慰めなんていらない。
自由で幸せな時間が欲しいだけ。
そして、ついでに稼ぎたいだけ。

本題からズレてしまったがぁ、、、、もやもやしながら、
開発者にとって何が一番のぞましい環境で、この会社がやれることは何か考えてみた。

それは、

**アウトプットを正しく評価すること**

つまり、より「短時間」でこんな良いものができると、アウトプットが通常より高く評価できる。
その逆は、評価もその逆。
絶対的な評価は難しく、軸を決めて、その軸で評価しないとやはり評価は客観性を欠いてしまう。
理屈ではわかるのだが、現実はなかなか難しいこともある。

何か無いか、軸。
分かりやすい、軸。
誰にも同等のもの。

やっぱり、時間がキーワードか。

なので、時間をコントロールするところから考えてみた。

「短時間」ってとても曖昧で文脈や相対的にしかイメージがわかない言葉なので、
**「限った時間」**として基準を設けることを考えてみた。

会社でコントロールができる時間、就業時間が一番わかりやすい。
**「限った時間」**が条件なので、まずその条件を準備することにしてはどうかと考えてみた。

**「限った時間」**で、時間に限りをつけて、高水準のアウトプットをどすうるかという前向きな考えになるはず。

タイム・フライズと言いながら、時間があると錯覚すると、ついつい余計なことをしがちだと考えている。（自分だけかな？）
事例や論拠は全くないし、たった数十年の経験則しかないが、限られた時間で集中してやることの方が効率がよいのではと仮説を持つことにした。

そして、最終的に、会社に利益が還元され、利用者に高水準のサービスが提供できればよいと考えていることにした。

ただ、ここに書き記したことが必ずしも正しいとも思っていない。
現実的か？実現可能か？改善されるべきは何か？を常に問うている。

思案中なので、変わる事もあると思うが、私なりの考えとしてまとめる事にしてみた。
時間を限る事で、如何に効率よく仕事を成立させるかと考えて行く事でより進化できるのではと考えている。

以下、（案）を考えてみた。

## 就業について
### オンサイト出社
* 週休3日 / 1日10時間労働
 * 会社の祝日は基本的に出社は不可
* 残業禁止
 * 残業はマイナス査定
* コアタイム制
* クォーターで査定面談
* 書籍、勉強会参加費用援助（仕事時間には含まない）
* 就業時のルール
 * 席を1時間以上外す時は、離籍状態を明確にする
 * メッセージツールでのレスは原則1時間以内

### オンライン出社
* 出社時間自由設定
 * 契約上の最低労働時間を基準に
 * 会社の祝日は基本的に出社は不可
* 残業禁止
 * 残業はマイナス査定
* クォーターで査定面談
* 書籍、勉強会参加費用援助（仕事時間には含まない）
* 就業時のルール
 * 席を1時間以上外す時は、離籍状態を明確にする
 * メッセージツールでのレスは原則1時間以内
 * 着席時が就業中

##評価
* 残業時間の評価
* アウトプットの量と質の評価
* パブリック情報共有と発信・発表の量と質の評価
* 勉強会参加と報告などの活動に対する評価

## 開発ルール
* 開発チームの価値を大切にする
* プログラム原則を大切にする
* 開発スタイルを大切にする

##開発チーム価値
* 労働時間を最大限に抑えアウトプットを最適化する
* 新しくてイノベーティブなものを開発する
* 高水準なパフォーマンスと品質を維持する
* オーナーシップをもって何事もチームで解決する
* パブリックで情報共有と発信を継続的に行う

##プログラム原則
* DRY
 * Don’t repeat yourself 同じ事を繰り返すな
* KISS
 * Keep it simple, stupid シンプルにしておく
* SOLID [参照](http://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63#1-11)
 * SRP Single Responsibility Principle（単一責務の原則）クラスを変更する理由は１つでなければならない」
 * OCP　Open/closed principle（開放閉鎖の原則）「クラスは拡張に対して開き、修正に対して閉じていなければならない」
 * LSP　Liskov substitution principle（リスコフの置換原則）「派生型はその基本型と置換可能でなければならない」
 * ISP　Interface segregation principle（インターフェース分離の原則）「クライアントが利用しないメソッドへの依存を強制してはならない」
 * DIP　Dependency inversion principle（依存性逆転の原則）「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。」 

##開発に関連する手法
> 色々とあるから整理しないと

* 納期・期限重視
* データドリブン（KPIは重要だよ）
* RDD [Readme駆動開発](http://qiita.com/syossan27/items/38e2f4b7f0dc74207dc9)
* TDD/BDD テスト・振る舞い駆動
* ChatOps（hubotとかslack）
* KDD カンバン駆動開発（trello）
* TiDD [チケット駆動開発](http://ja.wikipedia.org/wiki/%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA)
 * 作業はチケットを受け取ってから
 * レビューのコメントはチケットの履歴で行う
 * チケット無しのコミットは禁止
 * アサイン時に期限を必ず入れる
 * チケットのタイトルはゴールを明確に書く
* CI（Continuous Integration）
 * ビルド、テスト、デプロイの自動化
* ソフトウエア開発管理
 * [github-flow](http://qiita.com/tbpgr/items/4ff76ef35c4ff0ec8314) とか
* ソースコードリーディング
 * タグジャンプ
 * デバッガ
 * diff 更新差分
* バージョン管理（githubとか）
* A/Bテスティング
* プロトタイピング
* ワークフロー・開発プロセス
* ユーザーテスト



##残業に対する考え
* 残業は死語だぜ
* 仕事はいい感じでとっとと終わらせ、次の仕事に備えようぜ
* 効率よく稼ごうぜ
* 稼いだお金は、いい感じで使おうぜ
* 自分や家族の時間を有意義につかおうぜ
* ワークライフバランスの意味って、効率よく稼ぐって事だぜ
* 別に楽して、ぼーっと生活するってことじゃないぜ