SE(たぶん)の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。 でもテーマが定まってない感がすごい。

エンジニアがプロダクト開発だけやるのはもったいない

私は一応エンジニアですので、エンジニアの視点として思うことです。ポエム。まとまってないです。


社内で必要になるツールやプロセス改善の時にちょっとした自動化や開発が必要ってとき、プロダクトを作るエンジニアじゃなくて外部のエンジニア(SIとかのベンダー)を頼る風潮があるけど、それってもったいなくない?って思う。

プロダクトが上り調子で、人員が割けないことはあるけど、プロダクトを伸ばす以上に社内を整えたほうが良いことが明確なら、開発できる人を一時的に借りる(当然、意義や理由をエンジニア本人や上長と話し、納得した上で)ぐらいの柔軟性はあってよいのではと。

その間プロダクトの開発人員が減るから、開発速度が落ちる。それは当然。むしろプロダクト開発を止めてでも改善したほうが良い、という判断がどこかで行われることが、組織として正常な気がする。金額は仮だけど、プロダクト開発で10万円の収益を生む場合と、エンジニアによる社内プロセス改善で20万円の費用が減る場合を比較すると、後者が選ばれるのが組織としては正しい。それを「プロダクト開発担当なので」という理由でエンジニアを利用しないのはとてももったいない。

それに、プロダクト開発人員が増減することで、自動化などに力を注いで人手に頼らず品質確保したり、誰が見ても状況が分かるようにしたり、内部改善の動機にもなる。

営業メンバーの中で困りごとがあって、どうしても技術が分かる人に自動化してほしい、仕組化してほしいという需要があって。そこに入って課題解決するのってエンジニアにとってもすごく楽しいことだと思う。他部門で使っているツールを知れたり、もっとこうやって使ったらいいのにとか、そもそもこのぐらいだったら社内で作れるよ、とか、いろんな発見があるはず。普段使わない言語とか、見たこともないツールで自動化するとか、結構楽しいよ?新しい発見はワクワクする。それに、開発以外のメンバーが開発について考える機会にもなる。

エンジニアがなにかのきっかけで他部署の業務を見て、「これ改善できそう」って思った時、エンジニア本人が動くのはとっても難しい。だから、全社で組織として声を集めて、社内人員を動かせるようにするのは組織全体に責任がある経営者じゃないとできない。

エンジニア本人にとっては不本意な開発になることだってあるから、「手伝ってもらったで賞」みたいにちょっとしたボーナス(福利厚生でいいもの食べさせるとかでいいから)付与してさ。

何がいいって、すぐそばでエンジニアが動いてくれるから、社内の人にとって理想の状態を組み立てやすい。わざわざ外部に何か依頼するのとはスピード感が全然違う。

当然、こういう取り組みをやるのを担当者間でやってはいけなくて、必ず組織をまたいだやりとりが発生する。だから、社内制度からきちっと見直してさ。「エンジニア社内派遣制度」みたいなの作ればいいんだ。説明の責任は依頼者にあって、エンジニアはその枠の中でベストを尽くす。

プロダクトという枠に特化すると、その枠を取り払う社内政治に多大な労力を要する。だからその枠が無い制度として成立させてしまえばいい。

まあ、会社が大きくなって、社内SEが潤沢にいて、十分に回っているならこんなことしなくてもいいし、むしろプロダクト開発の不確実性が高まるから不要な制度になる。まだまだ社内を整えないといけない、というフェーズであれば一考の余地はあるかなと思う。


という、ポエムでした。結局は、プロダクト開発では使えないようなものを社内開発では使えるので、結構楽しいものです。プログラミングを利用した改善の芽はそこら中にあるんだなと、私自身思うので。