«« 即席で組もう!データ解析、4つのパターン | vhdtoolを用いたHyper-Vのvhd/avhdディスク修復 »»
業務で後輩と話をしていて、ふとITシステム開発は漠然とものを作るのではなく、以下3つの要素を抑えて物事を進めるのが大事かなとふと思った。
1.できるだけ他者がどのようなものを開発しているか知り、記録し、すぐ呼び出せるようにする
2.できるだけ他者の力で実現できないか考える
3.できるだけシンプルで、かつ効果は最大限を狙う
1.できるだけ他者がどのようなものを開発しているか知り、記録し、すぐ呼び出せるようにする
自分が作れるものは、たかが知れている。
既存技術や、オープンソース、業界の流れ、検索で引っかかった気になる対処法のまとめ記事等に目を通し、自分の仕事につかえる時に備えて貯めておき、いざという時にはすぐに引き出せるようにすることが大事だ。
自分の場合、ソースがネット媒体なら、はてなブックマークへタグとコメントを付けておくか、evernoteへ転送させて、必要になったらそこから検索して呼び出します。
(evernoteへ転送しておくのは、参照元が消えた時の魚拓用です。)
ソースがアナログ媒体の場合は、携帯で写真を取ってevernoteに送っているかな。
なお記憶に入れるだけの場合も多いですが、昔からそういうのは大抵すぐに忘れてしまうので、「アレアレ、え・・・なんたら、最後に『~デザイン』がたしかついていたような気がするけど。」とアバウトな返答しかできないアホな展開になるので毎回凹みます。
2.できるだけ他者の力で実現できないか考える
自分の考えはつくづく大したことはない。
というか自分が考えたこと-特に各パーツについては既に誰かが具現化して、オープンに無料でソースが公開されていることが多いとホント痛感します。
しかも自分で作ったものには大抵余計なバグが入っていたりしますし。
車輪の再発明は、個人の趣味ならそのプロセスもそれで勉強になって為になりますが、時間がお金に直結している業務としてはまずいので、積極的に活用するのが重要です。
ただ「既に誰かが具現化して、オープンに無料でソースが公開されている」ものについては、余計な機能までついていて、自分が案件へ転用するには重いっ!とか、良くライセンスを見たら面倒くさそうだった。ということもあるので要注意です。
あと別の視点として、自分に割り振られそうな仕事についてもできるだけ他人に振って、自分の仕事をできるだけ減らすよう心掛けるというのもポイントです。
多く仕事を引き受けたからといって多くお金がもらえるわけでもないのに帰る時間は遅くなるし(そんな中加えて残業するなといわれるし)、あと責任が発生したら他人も巻き込むことでできるだけ自分への負担を薄くするのだ!・・・というセコイ話だけではありません(正直それもありますけど)。
既存案件のノウハウは文章&チェックリスト化して後輩を教育することで、自分の業務は後輩へ振れるようにし、自分が集中しなければならない新規案件への時間などを増やすことは大事です。
自分自身まだ全然できてないけど!
3.できるだけシンプルで、かつ効果は最大限を狙う
とはいえ、力を借りる他人がいくら自分より優れていても、他人もやっぱり間違えます。
間違わないようにするには・・・そもそもアルゴリズムを考える時点で「できるだけ工程を減らし、最小限のことしかやらないで結果を出す!」ように組むこと。
それを怠け者っぽくない綺麗な言い方にしたのが「工程をできるだけシンプルにする」ということです。
(逆に怠け者っぽく言うなら「働いたら負け」)
何かルーチンを聞いていて仕組みが複雑になってきているな・・・と直感したら、大抵図に書きなおした上で議論をすると(時間に余裕がある場合はさらにアイデアを一旦寝かすことも有効)なんかおかしいというかそもそもこの工程は不要なんじゃないか?と気が付いたりします。
プログラマーの3つの素質として「a.短気」「b.怠惰」「c.傲慢」だと、Perlを開発したラリー・ウォール氏が言ったらしい。
先の3つについて無理やり当てはめるとbが1と2、cが3に当てはまるかもしれない。
まあ、エンジニアとしてはともかく、人間性としてはあまり自慢できない態度だとは思うが。
投稿者 kuze : 2015年3月14日 22:05
«« 即席で組もう!データ解析、4つのパターン | vhdtoolを用いたHyper-Vのvhd/avhdディスク修復 »»
コメント