オルタナティブ・ブログ > そろそろ脳内ビジネスの話をしようか >

「脳内ビジネス」の話はまたにします!

42歳で転職したシステムエンジニアの堅井さん

»

若山つばさ(仮名28歳 女性SE)「堅井さんっ。夜遅くまでお疲れさまです。」

堅井建造(仮名42歳 男性SE)「ああ、若山さん...。ははは、、、40オーバーで連日の終電帰りは応えますね...。」

若山「堅井さんも転職してきて3ヶ月ですからね!そろそろ本稼働って感じですかっ?」

堅井「そうですね。今回初めてゼロからの案件を任されちゃったので気合いは入ってるんですけどね。、、、ただ、勝手が違ってちょっと苦労してます。」

若山「今回、ラボですよね?」

堅井「はい、国内ラボ開発です。しかしお客さんの要望がぼやっとしていて、要件のまとめようがないんですよ。」

若山「どんな感じなんですか?」

堅井「ああー、これです。こういうスマホアプリのサービスを作りたいっておっしゃってるんですが、内容が詰まってないですし、ネイティブアプリでやるのかガワアプリでやるのか、それすら決まってないんですよね。WEBの管理画面だけはざっくり決まってる感じです。」

若山「ラボですよね?」

堅井「?ラボですよ。困ったなぁ。これじゃ要件定義ができないよ。要件定義がなければ、実装に入っていけないし、、、」

若山ラボなら進めちゃっていいんですよ。要件定義じゃなくて、とりあえず今話題に出ている機能を一覧にして書き出して行くんです。やるかやらないかは置いておいて。」

堅井「え?要件を固めて工数を算出したりしないんですか?」

若山「工数は機能ごとに出して、お客さまに共有しておきますけど、『これがゴール』みたいに固めはしないですね。それがラボですよ。」

堅井「な、なるほど。どうも受託のクセが抜けきれなくてダメですね。頑張ってみます。」

・・・・・・(翌日)・・・・・・

堅井「若山さん。昨夜はありがとうございました。」

若山「いえいえ、昨日も終電だったんですか?」

堅井「そうですね。でも、大丈夫です。慣れるまでは見習いのつもりで頑張ります。それであの後、機能を一通り書き出してみたので見てもらえますか?」

若山「さすが早いですねっ。」

堅井「それはそうですよ。この道20年以上やってますから。我々の時代はクラサバ全盛で、NetBIOSが○○でNTが××で...」

若山「どれどれ、、、ああー、でもこれちょっと工数取りすぎじゃないですか?」

堅井Borlandが□□でDelphiが△△で・・・あぁ、そこですか。私もそう思ったんですが、プログラマーさんに確認したらそれってうちで経験のない部分らしいので、ちょっと多めに取っておかないと危ういかと。」

若山「危ういって、何が危ういんですか?」

堅井「えっ?だって例えば5人日でできるって言ってしまって、もし8人日かかってしまったら信用を失ってしまうじゃないですか」

若山「だから多めに10人日って書いてあるんですか?」

堅井「まぁSEとして基本の姿勢ですね。工数が余ったらその分を他の機能の実装に回せますので、プログラマーさんからも社長からも喜ばれます。」

若山「堅井さん...。これ、ラボですよね?」

堅井「?ラボですよ」

若山そういう怪しいやりくりこそ、お客さまの信用を失うんですよー!

堅井「え!?」

若山「5人日で出来そうだと思ったらここは5って書くんです。もしそれで終わらなければ理由を報告して『来月に持ち越します』って言うんですよ。それが一枚岩のチームです。」

堅井「うっ」

若山「ラボはお客さまとうちの開発陣が一体になったチームなので、予想外の工数が発生すればそう報告すべきですし、不測のトラブルが発生すればそれもその内容を正直に報告するんです。極力、ブラックボックスを作らないようにしてください。」

堅井「でも『やってみたら工数が予想以上にかかっちゃいました』って、そんなことを言って、プロとして許されるんでしょうか?お客さんが怒り出しませんか?」

若山「ベテランのSEさんほどそのへんを恐れるみたいですが意外と大丈夫ですよ。もちろんお客さまの方にも、なかなか「私たちは仲間だ」っていう意識を持てない方がいらっしゃいますが、こちらが終始その姿勢を貫き通すと次第に理解していただけます。ただ予想より早く終わってしまった場合も正直に報告することも大事ですよ。」

堅井「早く終わっても言うんですか...。それは地動説から天動説に変わったくらい斬新な発想です...。」

・・・・・・(3ヶ月後)・・・・・・

堅井「若山さん!」

若山「わっ、びっくりした。堅井さん、どうしたんですか?青い顔して。」

堅井「やっぱりあの案件、トラブルになりましたよっ」

若山「えー?予算を大幅にオーバーとか?」

堅井「いえ、、、予算的にはまだ先方希望の4割くらいで、進捗率も4割くらいですので、ほぼ予定通りですね。」

若山「優秀じゃないですかー。やるぅ、堅井さんっ

堅井「それがそうじゃないんですよ。ここへ来て、大幅な仕様変更です!来ました!当初聞いてなかった大きな機能を入れたいと言ってきてます!」

若山「ふんふん。」

堅井「工数的に6割アップです。」

若山「またまた。そんなにアップしないでしょ。」

堅井「うぐっ、ああ、またやってしまいました。ついつい工数を大きく言ってしまう癖が出てしまいますね。そうです、でも4割はアップします。要件定義をいい加減にしてスタートしてるからこういうことになるんですよ。これは揉めますよ!

若山「堅井さん。」

堅井「訴訟になるかもしれません。」

若山「ラボですよね?」

堅井「社長にめっちゃ怒られます...」

若山「ラボ?」

堅井「10年振りの大失態だ...」

若山「ラボ?」

堅井「え?あ、はい、ラボ...」

若山「ラボなので、『その仕様変更で4割工数が増えます』って言えばいいだけですよ。今のメンバーのまま行くなら納期も3~4ヶ月後ろに倒れる、人を増やすと工期は多少短縮できますがコストは増え、結合作業やテストなどもありますので入れた分だけ短くなるというものではありません。どうしましょう?って」

堅井「!?」

若山「ラボのメリットは状況の変化に応じて柔軟に体制を変えられるところにありますから、お客さまが仕様変更をされたいって言うときは『ガッテン承知!!』と笑顔でお応えすればいいんです。」

堅井「ガッテン承知...」

若山「その上で大事なことは、コストの増加と工期の延長、クオリティの維持の3つをどうバランスとって着地させるかです。そこを堅井さんがプロとして、お客さまともよく話し合って、コントロールしていかなきゃいけないんです。」

堅井「そ、その発想はまったくなかったです。」

若山「ここでうちだけ守りに入ったようなことを言うと、一気に信頼関係を失いますよ!同じチームの仲間だということを忘れないように、気を付けてください。」

堅井「わ、わかりました。なるほどですね。頑張ってみます。」


・・・・・・(3ヶ月後)・・・・・・

若山「堅井さんっ。なんだか生き生きしてますねっ」

堅井「あ、若山さん。そうですか?でも、そうかも知れませんね。なんだか、最近楽しいんです。」

若山「そうなんですか?」

堅井「実は私、前に居た会社が大手のシステムインテグレータの会社で、正直この会社の1000倍くらい大きかったですけど...」

若山(社長に聞こえますよ...)

堅井「あ、すみません、、、でも考えてみると、本当にお客さんと同じ視点でシステムを作った記憶ってなかったなーと思って」

若山「そうなんですか?」

堅井「基本的には情報は常に開発側で抱える。その圧倒的な情報を使ってお客さんを枠にはめてコントロールする。それを「顧客啓蒙」なんて言ってみたりして。」

若山「こきゃくけいもう、、、。なんかずいぶん上からな響きですね。」

堅井「ふふふ。でもどこでも普通に使ってる言葉ですよ。あと、考えられるリスクはすべて見積りに載せて、リスクが現実にならなければこちらの利益になるようにする。開発はそれ自体がリスクなので社外に完全に委託しますので、社内には実装のノウハウはほとんどありません。そして作るものと言えば、使い勝手や先進性よりも安全で過去に経験のあるシステム...。そんなことばかりを考えていました。」

若山「へぇー、そんなものですか」

堅井「そういうことをするのがベテランSEの仕事と信じて疑わなかったですね。それがどうでしょう?入社する前からラボ型開発の記事はよく読んでいましたが、実際やってみるとやはり違いますね!ラボ開発のSEは、、、本当にものづくりをしている実感が感じられて、面白いです!!」

若山「堅井さん、、、あの、よかったら、今度飲みながらデルファイ?の話とか、いろいろ聞かせて下さいっ///」


と、このように、大手システムインテグレーターからの転職組でプラムザのSE業務にはまる人というのは多いです!

こちらのページ(https://www.plumsa.co.jp/)は完全にプログラミング経験者向きな感じで書かれていますが、堅井さんのようにSEオンリーでコーディングをしたことがないという人でも大丈夫です。ご興味のある方は是非ご応募を。お待ちしております。

東京のソフトウェア開発会社「株式会社プラムザ」
Comment(0)