ぼくが教育担当の新人や、自分の配下の部下に対して、必ずと言って良い程の確率で言う、
システム開発エンジニアにとって最も大事だと思う心構えを３つほど書いてみます。
（基本的にプログラマ目線）
これらは、ぼくが実際に言われて育った事だったり、或いは自分自身の考え方として持っている事だったり、色々あります。 もしかしたら＠ITのPressEnter*1あたりで読んだ事だったかも知れません。
先に言っておきますが、当たり前の事しか言ってませんよ。
(*‘▽’) よんでガッカリすんなよ！
【１】どんな些細な事でも、機械化・自動化をまず考えろ
システム屋ならば
我々はエンジニア、システム屋です。
何かしらの業務や作業をシステム化する事で、機械化・自動化する事で価値提供するのが仕事です。
であれば、顧客業務や一般の作業の前に、まず自分自身の作業をシステム化出来て然るべき。 それが出来ない奴がまともにシステムを作れる訳がない。
システム化をするのが仕事だと言うのに、自分の作業は泥臭い単純作業を黙々とこなしている、なんてエンジニアの仕事とは到底認められない。
少なくとも、その為の努力をしないのは最早エンジニアではない*2。
機械化・自動化する事の利点
まぁ、わざわざ改めて言うまでも無い事ですが、機械化・自動化する事で以下の利点が得られます。
- 作業時間の短縮
- 作業の正確性向上
- 繰り返し実行性
- 再利用の可能性
作業時間の短縮
当然の事ですが、人間がどんなに頑張って早く作業しようとした所で、機械には絶対に勝てません。
作業の正確性向上
これもまた当然の事ですが、機械はミスしません、与えられたプロセスを間違いなく忠実に実行します。 もし機械が間違える事があれば、それは指示を出した人間が1000％悪いです。
繰り返し実行性
機械化・自動化しておけば、作業の繰り返し実行性が得られます。
例えば、ちょっと要件が変わったとか、客から追加要望があって作業対象が増えたりとか。 そういう小さなレベルで作業内容がブレる事はままあると思います。
そんな時に、もし一つ一つ真心込めて手作業していては、追加作業は100％コストになりますし、既存の成果物に手戻りが出る可能性もあります。
これは決して気分の良い話ではありません。
（もちろん、程度によっては追加見積・追加費用という事になるかも知れませんが、それで目の前の作業が消える訳ではありませんしね）
しかし、作業を機械化・自動化しておけば、そのような多少のブレに関しては、割と簡単に吸収する事が出来ますし、その場合の対応工数は物凄く小さくなります。
追加見積・追加費用を取る事になったとしても、本来必要な作業工数を正直に申告しておき、機械化・自動化した分でオツリで悠々自適に有休でも取得すりゃあ良いのです。
再利用の可能性
今回ツールを作って作業を機械化・自動化しておけば、今後似たような事をやる時に、一部または全部が再利用できる可能性があります。 そうなれば美味しいものです、機械化・自動化に掛かるコストが下がり、更に効率よく作業を進める事が出来るでしょう。
また、もしそのツールの利用性・汎用性が高くなれば、より積極的にチームやプロジェクトに導入する事で、全体的な効果が得られ、必然的にそれは自分の成果となります。
ひとつひとつ真心を込めて手作業でやっていたのでは、せいぜい人よりもちょっとだけ早くおにぎりを握れる程度の効果しか得られません。
怠惰を求めて勤勉に至れ
纏めると、この言葉の通りです。
作業を作業のままバカ真面目にやるな、それは真面目ではなくバカのやる事だ。 作業は基本サボりたいのだ、その作業をサボる為にどうやって工夫するかに頭を使え。
と言う事です、我々は賢いので。
「仕事は増やすもの、作業は減らすもの」と言うのが基本的な考え方です。
【２】コメントには基本的に「何故」だけを書け
５Ｗ１Ｈ
中学か高校の英語の授業で「５Ｗ１Ｈ」と言う物を習った事があると思う。
When：いつ, Where：何処で, Who：誰が, What：何を, Why：何故, How：どのように.
詳しくはWikipedia先生にご教授願おう。
５Ｗ１Ｈの中で得られない情報
これらのうち、ソースコード及びバージョン管理システムなどの情報源からは得られない情報がある。
それは「何処で：場所」と「何故：理由」である。
場所に関してはあまり興味が無い*3のでどうでも良いが、情報の中で最も重要である「理由」が得られないと言うのが大きい。
故に、「理由」だけは別で補完しなければならない。
ソースコードコメントやコミットメッセージと言う形で、それ以外からは得られない「理由」と言う情報を残しておく必要がある。
コメントやメッセージはその為に存在する。
逆に言うと、それ以外の情報は何かしら別な所から得られる、無駄な情報と言う事になる。
ましてや、ソースコードの一行一行に対して和訳・直訳したかのような毎行コメントを書き込む事の不毛さは改めて言うまでもない事。
ソースコードを書き換えたが、その周囲のコメントをメンテナンスしない、と言うのもプロのエンジニアとしては二流以下です。
コメントの使い分け指針
コメントには理由だけを書けと言うのはつまり、コメントには、コメントからしか得られない情報だけを書け、と言う意味のイディオムとして理解してくれれば良い。
逆に言えば、コメント以外からは得られない情報であればウェルカムである、と言う事だ。
なお、ドキュメンテーションコメントと通常コメントである程度の使い分けと言うか、住み分けは必要だと思う。
ぼくの場合、以下のように切り分けてます。
- ドキュメンテーションコメント： 利用者向けの情報
プログラムやクラスの利用者向けの情報を記載。 - 通常コメント： 開発者向けの情報
そのコード自体を読む、或いは書き換えたい人向けの情報を記載。
ってな感じ。
どちらを書くにしても、最も重要なのは「理由」です。
【３】何をやるにしても「理由」を考えろ
作業をするにあたっては、常に理由を考えて作業すべし。
そして、理由のない作業はするな。
理由がないと「気付き」が無い。
作業の理由、つまり作業の目的ですね。
それを考えながらやらなければ気付きが無い。
つまり、作業の改善に繋がらない。
理由がないと「反省」が無い。
理由を考えて作業しないと、ミスった時に反省しないし、反省の適用先もない。
考えなしに作業したのでは頭を使わないし、自分のやり方がマズかったとは思わず、ただミスっちまったテヘペロとしか考えなくなる。
反省出来ないと言う事は、また同じミスを繰り返すと言う事になる。
即ち、理由がないと「成長」が無い。
改善にも繋がらず、反省もされない、つまり、一切成長する要素が無いと言う事。
せいぜい、繰り返しやれば多少の「慣れ」が得られるが、それだけ。
ちなみに、「慣れ」は「成長」とは言わない。
何故なら、慣れは慣れたその作業に対してのみ有効な経験値でしかなく、それ以外に応用が利かないからだ。
そして成長しないと言う事は、時間の無駄と言う事だ。
そういうのは、システム化によっていち早く「奪われる側の仕事」のやり方だ。
エンジニアである以上は「奪う側の仕事」をしろ。
エンジニアと言う仕事の本質は、システム化によって「誰かの仕事を奪う仕事」なのだから。
あとがき
ぼくが「教育」する場合、恐らくこの３つは誰に対しても必ず言ってると思います。
あと他にも「必ずじゃないけど良く言う事」シリーズもありますね。 電話よりメールを使った方が良いとか、確認したメールは必ずすぐに返信しろとか、TODO/FIXMEには必ず完了条件を明記しろとか、単一責任原則を遵守しろとか、、、。 その辺の話もいずれ書こうかなぁ。
