1
/
5

<リレーブログ第8弾>リフカムのエンジニアと一般的なシステム開発者との違いとは

はじめに

開発部 エンジニアの一条と申します。

リレーブログ第8弾ということで、私からは「リフカムのエンジニアってどんなことしてるの?」という疑問を明らかにしていきたいと思います。

(この記事では「一般的」という言葉を多用していますが、私の主観です。「一般的な気がする」と読み替えてください。)

この内容で書こうと思った経緯ですが、弊社ではSlackというチャットツールを使っていて、ただただ日々の出来事を賞賛するだけのチャンネル(スレッド)が存在します。

そのチャンネルに

「会社規模感の違いもあるかもしれないのですが、私の知っている「ザ・開発さん」よりも、う-------んとオープンで能動的で素敵だな...としみじみ、ありがたいことだなぁと感じました。」

と賞賛してくださった方がいました。(すご-------く嬉しかったです!!)

その時に、確かに一般的なエンジニアのイメージって良くも悪くも「職人」というイメージがあり、弊社のエンジニアのイメージとは掛け離れているなぁと感じました。

その違いを探るにあたり、リフカムのエンジニアの業務を明らかにし、一般的なエンジニアの業務と比べることで何か見えるのではないかと思いました。

(そうすることでリフカムのエンジニアに必要なスキルが見えてきて、開発部が欲しい人物像も明らかになって、採用にも繋がるんじゃないかなぁ。。。なんて微塵も思ってないですよ。。。?)

というわけで、リフカムのエンジニアの業務内容を紹介していきたいと思います!

※私のプロフィールとかはこちらの記事をご覧ください。


SIerからHRベンチャーへ!〜エンジニアの「挑戦」〜 | 株式会社リフカム
こんにちは、リフカム採用担当です!リフカムインタビュー、7回目となる今回は、SIerから転職し、フルスタックエンジニアとして活躍している一条のインタビューです。ぜひご覧ください!まず初めに、これ...
https://www.wantedly.com/companies/refcome/post_articles/140919

そもそもエンジニアの仕事って?

エンジニアとは言っていますが、基本的にはシステムエンジニア、ITエンジニアという意味で使っています。

エンジニアの仕事を一言で言うと、コンピューターシステムの開発をするです。

もう一言追加すると「こんなことがしたいなぁ。。。」をシステムを使って実現するです。

開発ってどうやってるの?

一般的な開発フローとリフカムの開発フローを比べながら説明していきたいと思います。


リフカムの開発フローは一般的な開発フローと比べて工程が少なく、開発メンバーに地位や役職などの属性がありません。

工程が少ない要因としては、成果物の存在です。一般的な開発フローでは、各工程で設計書やテスト仕様書などの成果物を作成しますが、リフカムではほとんど作成していません。私が考える各種成果物とその存在意義については以下の通りです。

  • 要件定義書・基本設計書・詳細設計書
    • 責任者が実際の開発について全く分からないので、開発者以外の人間が見ても分かるようなものが欲しいから
  • 単体テスト仕様書・結合テスト仕様書・総合テスト仕様書
    • テストの数やバグの数で製品の品質を定量的に評価したいから

要件定義書・基本設計書・詳細設計書については、責任者がコードを読み書きできる人であれば作る必要がありません。単体テスト仕様書・結合テスト仕様書・総合テスト仕様書については、テストの数やバグの数では製品の品質は評価できないと考えており、その代わりにバグが出たらすぐに修正・リリースすることで品質を担保しているため、作る必要がありません。もちろんテストはしていますが、どれだけ入念にテストしてもバグは出るものと考えており、バグが出たらすぐ直せる方がよいという考えです。

属性がない要員としては、分業かどうかです。一般的な開発フローでは、開発メンバーと一括りにはしていますが、実際は要件定義担当、設計担当、開発担当、テスト担当、リリース担当と分かれていることが多く、そうなると開発リーダーという取りまとめる役職が必要となってきます。ですが、リフカムでは案件に対して主担当を必ず一人割り当てます。主担当が責任を持って要件定義からリリースまでを一貫して行っているので、認識の相違も少ないです。無駄な伝言ゲームが発生することもないです。

つまり、リフカムで開発をするためには、一人で要件定義からリリースまでできる、もしくはやろうとする意欲がないと務まらないということになります。

何を考えながら開発してるの?

先ほどは開発手順についてでしたが、今度はマインドについて考えてみました。

先ほど挙げた一般的な開発フローでは「責任者が求めるものを作る」と考えながら開発している方が多いと思います。

私自身、前職では一般的な開発フローで、開発メンバーとして仕事をしていました。

私がどんなに顧客や開発チームの事を思って作っても、責任者がNO!と言えばNO!になります。

次第に「開発リーダーが求めるもの」をベースに考えてしまい、それで私の評価が上がるのであればまぁいいか。。。という考えになっていきました。

また、コミュニケーションの範囲が開発チーム内で閉じていることも分かります。

一方、リフカムでは「プロダクトを使用するユーザにとって価値となるものを作る」ことを考えながら開発している方が多いと思います。

リフカムのValueには「心から価値あると思うものを届けよう」というものがあります。

リフカムを利用しているユーザの声をCSチームが連携してくれたり、直接聞きに行くことができたりもするため、このValueを意識する機会が非常に多いです。

また、コミュニケーションの範囲が開発チームだけではなく、CSチームやCEO、ユーザとかなり広いです。

それもあってか、リフカムに転職してからは、エンジニアとして本来当たり前であるべき事を考えながら開発ができるようになったと思っています。

その分、価値とは何かを考え抜かなければならないので非常に難しいですが、やりがいもあって楽しいです。

おわりに

リフカムのエンジニアの業務をまとめると以下の通りです。

  • 要件定義からリリースまで一貫して行う
  • プロダクトを使用するユーザにとって価値となるものを作るために日々考える

あらためて一般的なエンジニアの業務と比べてみると、リフカムのエンジニアの業務はとても「職人」とはかけ離れていると感じました。ただ、エンジニアに限らず、リフカムの社員に「職人」に該当する人がいないと思っています。全員が会社のVisionである「社員にとって紹介したい会社で溢れる世界。」を実現するための答えを、ただひたすらに探し続けています。



この記事を読んでリフカムのエンジニアに興味を持ちましたら、お気軽にご連絡ください!

また、リフカムでは全職種において積極的に募集しておりますので、お気軽にご応募ください!

株式会社リフカムでは一緒に働く仲間を募集しています
12 いいね!
12 いいね!
同じタグの記事
今週のランキング