弊社が採用面接でよく聞かれることをまとめてみた～2/2【求人広告】
»
...... きこえますか... きこえますか... この記事は... またまた... ただの... 求人広告です... ベトナムの続きは... たぶん... 次回に... お届けします...
ということで、昨日に引き続き、弊社が採用面接でよく聞かれることをまとめてみました。
-----------------
前回は、軽いタッチで質問させていただいたのですが、今日は役員面接だと思ってください。
もうちょっと御社のことを深く聴取していきたいと思います。
-まずシステムエンジニアは営業もやるといいますが、飛び込みをやるということですか？
飛び込み営業はやりません。
-飛び込みじゃなくて、どうやってお客さんを捕まえるのですか？
やり方はいろいろなんですが、今回募集しているＳＥは基本的に「案件ありきのお客さんに対して提案する」ところから始めます。言ってみれば「提案営業」です。
-何か機能ごとに価格テーブルみたいのがあって、それで見積りを書くのですか？
そういうの、ありません。
-じゃあ、見積りはキャリアを積んだ先輩しか書けなくないですか？
半年もすれば書けるようになります。というか、ある機能をいくらでやるのかその場で言えないと提案にならないので。。
-その場で口頭で金額を言うのですか？
言います。まあ「円」で言うと生々しいので「工数(作業日数)」ですけど。それやると何人日です、みたいな感じです。
-怖いじゃないですか？後で辻褄合わなくなったりしませんか？
そこを頑張ります。ただ商品のスペックや価格テーブルを覚えるよりずっと楽です。自分なりの正義を作ってしまえば揺らぎません。
-営業は代行会社とか使ったり、専門の人を入れたらいいんじゃないですか？
それをやると、お客さんの「要求出し」から「見積り」までのスピードが落ちます。仕様の伝達漏れとか仕様変更の対応に遅れが出る危険があります。言った言わないの話にもなりますね。
-なるほど。営業はだいたい分かったので、設計の話に移ります。設計はどれくらいの精度でやるのですか？
主要画面のレイアウト設計とデータベース設計、複雑なバッチ処理のアルゴリズム設計くらいまでやります。
-仕様の確認は、主要画面だけということですか？
主要画面をベースにシステムのポリシーを確認して、あとは実際に画面で見てもらいながら確認していきます。それが一番早いですし大きな手戻りがないです。画面で確認できるようになってからは紙のレイアウト仕様書は更新しません。捨てちゃいます。
-データベース設計書もアルゴリズム設計書も途中から更新しないのですか？
それは永遠に更新します。それがないとシステムの運用が開始されたとき、何が正しい挙動なのか分からないので。
ネットワーク構成図とかもそうですが、要は忘れちゃうとソースやコンフィグファイルから情報を集めてくるのが大変で、後の打ち合わせ等でスピードが落ちるというものはきちんとドキュメントに残しておきます。
-データベース設計はプログラマがやった方が早くないですか？
データベース設計をプログラマがやると、お客さんが後から出してくる追加の要望の難しさが分からなくなってしまいます。それがまた遅さにつながります。
-プログラマがやれば、実装の速度は上がるんじゃないでしょうか？
着手時に全仕様が見渡せれば確かにそうかも知れませんが、仕様は開発の進捗に応じてずるずる変わっていくものです。そのずるずる変わる変わり方を予測して、先を見越したDB設計をするのがプラムザＳＥの仕事です。
ずるずる変わる仕様を織り込んでおくことで、顧客満足度を上げて、次の営業をしやすくするというグッドスパイラルに持っていきます。
-仕様がずるずる変わるのはＳＥの力量不足ではないのですか？
仕様がずるずる変わるのは、自然の摂理なので一介のＳＥ如きでは変えることができません。かつて主流だったウォーターフォール型開発でプロジェクトが8割以上トラブっていたのは、あれが仕様の変化を許容しない手法だったからです。
-それにしてもどこまでも仕様変更を認めていたら終わらなくないですか？
「当初まったく聞いていなかった」「それ、今思いついたんじゃないですか？」ということは、さすがに別見積りにさせていただくと言えば、大抵の場合は納得していただけます。
-そんなものですか。ところで、じゃあＳＥとプログラマが同一人物だとさらにスピードアップできそうですが？
それはダメです。設計ポリシーがお客さんの要求に飲み込まれてしまいます。
-意味がよく分からないのですが？
たとえば、開発も中盤に入ってきたところで、お客さんが訳の分からない難しい要求を出してきたとします。そのとき、それを断念していただく交渉をするコストと、言われたとおりに開発してしまうコストを天秤にかけて、後者が安ければその通りにやってしまう、というようなことが起きますが、これは自分で実装していると頻繁に起きます。そうすると設計ポリシーがグダグダになります。
-なるほど、面倒でもちゃんと筋を通せと言うことですか。
そうです。
もう一つ、逆に仕様を、より実装が簡単な方に、あるいは自分がやってみたい技術を使う方に誘導してしまうこともありがちで、これも健全な方向ではないです。
-実装担当なら今回やってみたい要素技術を入れてみたい、というのはあるかも知れませんね。でも実装が楽という方向なら価格も安くなってお客さんにとってメリットがあるのではないですか？
「実装が楽だからこうした」という仕様でのちのち禍根を残さなかったことは10に1つもないです。こないだもやってしまいました。。
-やってるんじゃないですか...！
予算が無いとおっしゃられるお客さんにはついやってしまって、それが開発側にもお客さんにもダメージを与えてしまいます。毎回、ちゃんと「できない」と言えば良かったと後悔します。こういうことがＳＥとプログラマが一緒だとより頻繁に起きるのです。
-プロマネの話に移ります。プロマネは開発メンバーのリーダー、すなわち上司なのですか？
プロマネは役職の一つであって、上司ではありません。その意味では、ＳＥもプログラマの上役ではありません。単なる役割の違いです。
-「プロマネ」の仕事をどう捉えていますか？
「プロマネ」はプロジェクトの進捗管理、工数管理をするお仕事です。
まずチームをキックオフミーティングに招集してシステムの概要を説明し、開発のスケジュールを告知し、プログラマが何か技術的な障害など抱えているようならＳＥに相談してその障害を取り除いてあげるようにしたり、おおよその工数管理をしたり、遅れていたら営業に報告してお客さんに謝ってもらったり、です。
-そのＳＥも営業も自分ですね？
はい。
-「はい」って、大変じゃないですか！
大変です。ただ、「この案件何待ちで止まってるのよ」っていうのが無くて、気持ちいいです。
-全体を見通せるわけですね？
はい。大変ではありますが、これができるようになれば、将来独立したり、自らサービスを立ち上げるとかっていうのも比較的簡単だと思います。プログラマは外部にアウトソースしたりして。
-前回は、社員が独立するのはいいこと、みたいに言っていましたが、それは冗談ではなく？
はい。社員はどんどんプラムザで腕を磨いて独立していけばいいと思います。
-それはともすると社内に残る社員より独立する社員の方が望まれていると聞こえますが？
いや、社内に残る社員はそれはそれで絶対的に素晴らしいです。スーパープレーヤーも素晴らしいですが、淡々と裏方に徹せられるプレーヤーというのも負けず劣らず素晴らしいです。むしろそっちの方が職人的で食いっぱぐれのない生き方だと思いますね。
-なるほど。ただ、独立する人をなんとか防がないと会社が痩せてしまうと思うのですが。
同じように別の人をまた育てていけばいいと思います。どうせ血気盛んで出て行く人は止められません。
社員が独立して出て行っても、弊社と末永く付き合っていただけるように、普段からインチキなこと阿漕(あこぎ)なことをしないということが大事だと思ってます。
-最後に私に一言アピールしてみてください。
ご興味のある方は、こちらの募集要項をご一読の上、是非ご応募お願いします。
株式会社plumsa(プラムザ)では、AWSの運用保守サービスも提供しています↓