先月末から、半年振りにプログラムを書いています。
ここで勘違いしないでほしいのが、プログラマーに降格されたとかそういうことではなく、ただ単にプロジェクトにいるメンバーが少なく管理負担が減った分をプログラムの時間に回している、ということなのです。
さて、小規模な開発の場合、作成依頼者からさくっと要件を聞いてプログラムを書くことが多くなります。
その「さくっと」要件を聞いてプログラムを書くと、結果として次の3タイプのものが出来上がります。
- 要件を満たせてない
- 要件通りにまとまる
- 要件以上のものに花開く
1番目、これは悲しい。こうなってしまう理由として、私が思いつくのは「ちゃんと話を聞けていない」「経験、特にパターンが頭の中に少ない」「書いている間に締め切りになる」と大きく分けてこの3つになります。
まず「ちゃんと話を聞けていない」のは、依頼者が求めている方向感を捕らえられるまでちゃんと話し込むべきです。ただ、要件を固めようと話し込むのではないことをお忘れなく。
「経験」、これは精進の数だけ存在しますので、ぜひ精進されてください。
「時間」、これは集中力の場合と技術力の場合があるので、実行後よく自分自身を分析して解決する必要があります。
さて、僕が話したいのは2と3です。
2番目。私はこちらに属する人です。方向感は依頼者のストライクゾーンにぴたっと入っている、早速これを足がかりに大規模なプログラムを書くか、より商品性を高めようという話につながります。
しかし、これでは普通です。依頼者に対して「感動」を与えるまでは行かないのです。ここ、ポイント。
3番目。これは依頼者がもっとも「喜ぶ」結果です。
依頼者自身が当初想定していたイメージを超えて、さらに良いものが仕上がっているのです。こういうプログラムを書ける人は、おそらく想像力が高い方なのでしょう。SEとしてお客様へ提案するときも、喜ばれること請け合いです。
さて、ここまでの話から「それじゃ君は普通のプログラマだったのかい？」と思われている方もいるはずです。
僕は3番目の人にはなれなかったのですが、その分を別のところで勝負しています。
それは「プログラムの書き方」です。
最初、要件(＝この場合はアイディア)をプログラムを起こすときに、いきなり主となるプログラムを書かずにライブラリ(使い回しが利く共通プログラム)を書いてしまうんです。
そして、ライブラリはとても細かい単位で起こしていきます。
これはどんなメリットがあるかといいますと、
- プログラムがより発展するときに再構築しやすい(リファクタリングしやすい)
- 別の場所で使い回ししやすい(再利用しやすい)
- 主のプログラムに一杯命令を書くよりも分けておくと仕事が明確になってプログラムが読みやすい(可読性があがる)
- バグが出ても仕事別にプログラムが分かれているのでバグ発生場所が突き止めやすい(対応力が上がる)
- 何よりもほかの人に引き継ぎやすい(僕が楽ちん！)
なのです。
問題があるとすれば、これは依頼者にプログラムを収めるときには、ほとんど日の目を見ない結果なんですね。だから、すぐに結果を出したいと思う人には向きません。
その代わり、後々自分の行動しやすい、そしてプログラマとして安定した信用と信頼を勝ち取るにはなかなか手堅い方法であります。
言い換えますと、すぐに結果が出せる人は「すぐに」結果を出し続けなければ生き残りづらい環境となります。しかし、手堅くやるときははじめ評価を勝ち取りづらくても、後々は安定した評価を勝ち取りながら、より自分の仕事がしやすい環境で動き続けることが可能になります。
どんな結果が『継続して』出せるかは、上に書いてある5つの項目そのものだと考えていただいて問題ありません。
ここで、賢い方は突っ込まれるはず。
おそらく「安定した評価を勝ち取るまでにどうすればよいか？」と聞かれる方が多いかと思います。
僕は「一生懸命やる姿勢を見せる」これ以外思いつきません。人は、短期?長期まで、様々な尺度で人を評価しますから、あせらなくても何とかなるものです。それに、一生懸命やっている人を悪く評価することは、見る人も人の子ですからよっぽどのことが無い限り無いはずです。また、この段階で見切りをつけられるようであれば、その環境は自分自身に向かない、なぜなら「すぐに出る評価＝短期」のみしか見ていないから、とも考えることができます。
ぜひ皆様、勝負は人と同じ土俵ではなく、自分で作った土俵でされてください。誰かと違うことができるから、自分自身がより活きてくるのですから。
そのために、僕はプログラムを書くときはどんどん書くし、マネージャーに徹するときは情報を足で稼ぐために走ります。