最近僕が悩んでいるのが、メンバーの教育。
前にディスカッションに関して書いたのもその一つ。
技術力を身につけるのはある程度容易であり、チャレンジさせてくれる会社に居ればある程度学べる。しかし、システムを作るとなると違う。これをどう身につけてもらうかが僕の悩み。
例えばシステムを作る際にデータベース設計って凄く基本だけど、この基本がとても難しい。アジャイルチックに一つ一つの機能をイテレーションして作って行っても良いのだが、データベース設計は後で変更が効き難いためイテレーションでまわす為には相当なスキルが必要。ある程度の規模のシステムが出来た後に
じゃぁ、こういう統計データをとって！
とか言われた時に、統計に合ったデータを収集してなければあらゆるテーブルから必要な情報を集めるバッチを作ったり今の処理を変えない為に既存テーブルに近い構成の統計用のテーブルを用意したりする事がある。
そう考えると、この基本的なテーブル設計がシステムの全てを司るといっても過言ではない。（DB、NoSQL、memcache、solr...と言う具合うにデータの一元管理が出来ずにミドルウェアが増えてきた時には要注意）
で、この能力を育てるのはどうすれば良いのだろうか？というのが僕の悩み。
今考えているのが、表題にある説明力。
人に上手く説明できる能力って、人の事を良く見て考えれる人だと思ってる。その理由は聞く人の事を考えれない人は説明能力もたかが知れている。また、説明する為にはある程度自分の中で知識を体系化して話せる必要がある。
という事は、この能力を昇華させてシステムに対してプログラムやテーブル設計をする場合はシステムの事を考えてやってくれるのではないかなー。と思ってる。
まぁ、これだけではないんだけど。
僕としてはこの能力が高いとコードレビューが楽になるなーと思ってる。
僕と一緒に働いているメンバーのコードがたまに難解なコードを書いてくるんだけど、大抵はコードが纏まってないだけで資料をまとめてもらうと資料が纏まらず。そういうときはコードのレベルがまだ未熟で改良の余地がある場合が多い。
だから、だから、この説明力を育てる事が良いシステムを作る第一歩なんだろうな。
P.S.
ちなみに、最近思うんだけど。フレームワークとかってとっても良いんだけど。ルールとかってとても良いんだけど。誰が入ってきても作れるような体制って実は一番未熟な組織構成な気がする。一人一人が考えて作れる組織に育てる事が重要なんじゃないかな。
誰が入ってきても作れるプログラムなら、仕様を考える人にプログラムを書かせれば良いんだよ。今のプログラム言語をそれなりのアーキテクトが組み立てれば不可能な事ではないと思うんだ。僕にはそこまでの力は無いけど、僕は仕様策定者が決めたいと思われる部分はYMLで外に出す事によって細かい打ち合わせを無くしてる。
前にディスカッションに関して書いたのもその一つ。
技術力を身につけるのはある程度容易であり、チャレンジさせてくれる会社に居ればある程度学べる。しかし、システムを作るとなると違う。これをどう身につけてもらうかが僕の悩み。
例えばシステムを作る際にデータベース設計って凄く基本だけど、この基本がとても難しい。アジャイルチックに一つ一つの機能をイテレーションして作って行っても良いのだが、データベース設計は後で変更が効き難いためイテレーションでまわす為には相当なスキルが必要。ある程度の規模のシステムが出来た後に
じゃぁ、こういう統計データをとって！
とか言われた時に、統計に合ったデータを収集してなければあらゆるテーブルから必要な情報を集めるバッチを作ったり今の処理を変えない為に既存テーブルに近い構成の統計用のテーブルを用意したりする事がある。
そう考えると、この基本的なテーブル設計がシステムの全てを司るといっても過言ではない。（DB、NoSQL、memcache、solr...と言う具合うにデータの一元管理が出来ずにミドルウェアが増えてきた時には要注意）
で、この能力を育てるのはどうすれば良いのだろうか？というのが僕の悩み。
今考えているのが、表題にある説明力。
人に上手く説明できる能力って、人の事を良く見て考えれる人だと思ってる。その理由は聞く人の事を考えれない人は説明能力もたかが知れている。また、説明する為にはある程度自分の中で知識を体系化して話せる必要がある。
という事は、この能力を昇華させてシステムに対してプログラムやテーブル設計をする場合はシステムの事を考えてやってくれるのではないかなー。と思ってる。
まぁ、これだけではないんだけど。
僕としてはこの能力が高いとコードレビューが楽になるなーと思ってる。
僕と一緒に働いているメンバーのコードがたまに難解なコードを書いてくるんだけど、大抵はコードが纏まってないだけで資料をまとめてもらうと資料が纏まらず。そういうときはコードのレベルがまだ未熟で改良の余地がある場合が多い。
だから、だから、この説明力を育てる事が良いシステムを作る第一歩なんだろうな。
P.S.
ちなみに、最近思うんだけど。フレームワークとかってとっても良いんだけど。ルールとかってとても良いんだけど。誰が入ってきても作れるような体制って実は一番未熟な組織構成な気がする。一人一人が考えて作れる組織に育てる事が重要なんじゃないかな。
誰が入ってきても作れるプログラムなら、仕様を考える人にプログラムを書かせれば良いんだよ。今のプログラム言語をそれなりのアーキテクトが組み立てれば不可能な事ではないと思うんだ。僕にはそこまでの力は無いけど、僕は仕様策定者が決めたいと思われる部分はYMLで外に出す事によって細かい打ち合わせを無くしてる。
