企画とエンジニアの
本質的な共通目的は売上

blogimage_20131101

■プログラマではありませんが、プログラマの話をさせてください
(via mixi Engineer’s Blog)

http://alpha.mixi.co.jp/2013/12015/

うーん、これは一見正しそうに見えるけど
どうかな。

たとえば、作ったアプリが
まったく会社の売上に貢献しなかったら?

もしくは、レビューで批判されたり
まわりからあのアプリ、クソだよねー
と言われてたら?

実際このアプリがどうかはわかりませんが

アプリを作った開発者はどう感じるでしょう。
エンジニアに関して
これには3通りあると思います。

1.とくに何も思わない人。
バグがなく、要件通りのアプリに
なっているのだから、と。

2.成功したらもちろん良いとは思うが、
失敗しても自分の役割を全うしたのだから
収益に関しては自分の責任外だ、という人。
つまり企画のせいとも思っている。

3.このアプリには何か足りないと思えば
(そう思える心の余裕がある)
自分でも何が足りないか考えて実現できる人。

簡単な機能でも、組み込むということはソースコードを一行以上追記することになるわけで、それは少なからず複雑性を巻き起こす原因となります。

3だったらもちろん対案を出すか、
現状で充分な場合その根拠を示すから、
きっと1か2か。
何が正義で悪、といったことはなくて
適所だとは思うんだけど、
ユーザに対してサービスを作るんだったら結局は
ものすごい情熱を持って作るほうが
流れを引き寄せるんじゃないかと思う。

ある機能を入れたい、と思うのは
(その機能の是非は一旦別として)
現状のデキに満足していない、もしくは不安がある
ということなので
きちんと受け止める必要がある。

だから、エンジニアは
面白い機能をみんなで考えて
プログラムとしての複雑性が高まらないようにして
バグが入らないようにして、
保守しやすいように、
すればいいんじゃないですかね。
やたらめったら実装するんじゃなくて
当てる為に必要な事は全部する

俺はそうありたいと思います。

このアプリがこけたら会社終わるって時に
複雑になるからとかって議論もないだろうし
その時には必要なこと全部やってやるって
気持ちにもきっとなるでしょう。

そういうことはほとんどないかもしれませんが
ぶち当たったとして、いきなり
そういうアクロバティックな動きが
できるとも思えません。

何事も広い視野をもって、訓練ですよね。


コメントを残す

メールアドレスが公開されることはありません。


*

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>