緩いコード規約でプログラムを書く事。
そして、内容を共有すること。
書いたプログラムは書いた人に説明をするようにした。
当たり前かもしれないが、これを頻繁に行うようにすれば
人に伝える事を前提としたプログラムになっていく。
書いたプログラムを頻繁に説明するようになると「伝えるのが面倒」になっていく。
となると「説明しなくても良いプログラム」を書かなければ、説明は何時までたっても終わらない。
この説明しなくても良いプログラムというのは、教える所を少なくするようにしていくので
一定のパターンが出来上がっていく。
同じプログラムを２度書かないという事のメリットが理解できる。
同じコードを２度書いていれば、説明は２箇所に増えるからだ。
説明を短くするには
分かりやすく、シンプルに努めなくてはいけない。
説明や変数名も明確にして行かなければ説明は増える。
変数名が「number」なのに入っているのは「名前」となっていれば、説明しないと分からない。
こうしてプログラムを自分で考え、書いていく。
という流れが出来る。
確かにそれぞれ自由に書いていくと全くクセの違うプログラムになる危険性は秘めているものの
共通で使うプログラムさえクセを揃えれば、大きな問題にはならない。
個別の処理に関して言えば、たとえクセが違ったとしても
はじめて読むプログラムであることに変わりはない。
ユニークなプログラムは
何かのルールに則っていても、則っていなくても一度は読まなければいけない。
その１つのプログラムに関してルールから学ぶのか、
それともそのプログラムを読むだけで理解が出来るのか。
作業効率が変わってくる。
１つ１つのプログラムが「読んだら分かる」意思を持って作られていると、初見であっても理解が出来る。
仕様書も最低限でいい。
そうなれば創る事に集中できるので、仕事をやっている充実感はかなり高いだろう。
自由に自分の意思でプログラムを組んでもらうことによって、メンバーはそれぞれ「自分の中の目標」を持つようになった。
あるメンバーはスマートフォンサイトを以下に効率化するかという事
あるメンバーは自分のフレームワークを作る事
あるメンバーは汎用的な管理画面をつくる事
そのため、ほぼ毎日モチベーションが高く仕事をしてくれていた。
作業ではなく自分の目標達成の一部としてプログラムがあることで
結果的にはパフォーマンスのよいプログラムが量産されていった。
そしてそれぞれ独自のノウハウを作り上げ、それをチームで共有することで
自分に無かった視点でプログラムに向き合う事になる。
新しい発想にインスピレーションを受け、それぞれの目標へ前進する。
チーム内で出来たノウハウはかなり強力なものとなっていった。
そうして、長期の視点で見た時にさらに恩恵が出る。
