フルスクラッチ開発は、エンジニアのストレスを軽減する：SEの未来を開く、フルスクラッチ開発術（3）（2/2 ページ）

周辺開発が喜ばれる

――今までの話だと、お客さんに喜ばれるからストレスが少ない、ということのように思います。その観点で、ストレスレスだという話は他にないですか。

島田氏　フルスクラッチでやっていると、当たり前ですがコーディングができるようになります。ちょっとしたユーティリティを作ることで、お客さんの満足度が大きく変わることがあります。

――私も昔ユーティリティを作っていましたが、開発用でした。島田さんがおっしゃるのは、お客さん用のユーティリティということですか。

島田氏　そうです。例えば、従来はExcelでやっていた業務をECサイトに移行する開発がありました。そのシステムには数万件のマスタ・データがあり、それをWebシステムで使用するデータベースに移行しなければいけません。森川さんも経験があると思うのですが、Excel上のマスタをCSVに変換して、それをデータベースにインポートするのは思ったより大変な作業です。

――クリーンでないデータ、要するに型違いだとか、桁数が大きいとか、半角カタカナがあったりとか、そういうことで大量のエラーが出ます。

島田氏　はい。そこで私たちはデータの整形ツールを作成して、お客さんにお渡しします。コーディング能力のない会社だと、こういうことができないので、お客さんに多大な負荷のかかる手作業をお願いしないといけない。半日ぐらいのコーディングでできるようなユーティリティですが、お客さんの喜びは半日分の工数を補って余りあるほど大きいんです。

――私の会社員時代の経験を思い出しました。数億円規模の売り上げがあるシステム開発を受注する場合、審査会がありました。開発計画書と見積もりを役員などが参加してチェックするのです。かなり大きな金融系システムの審査会で、ある役員から次のような指摘がありました。「これ、マスタの移行は誰がやることになっているんだね」。開発リーダーの答えは「お客さんです」でした。すると、役員からつっこみが入りました。「それって、開発計画書と見積もりには明記されていないよね？ お客さんは、こちらがやるとたぶん思っているよ」と。

島田氏　ははは。

――その役員は、会社の歴史上でも有数の巨大システムの開発マネージャを経験していたので、即座に計算しました。「移行は手作業では無理、移行プログラムを作る必要がありそうだけど、その規模だと2?3000万円はかかるんじゃないかな。それを見積もりに入れた上で、どちらがそれを作るかお客さんともう一度相談してきなさい」と。

島田氏　これは笑いごとじゃなかったですね。私たちの開発はそれほどの規模ではありませんが、データの移行に関してはトラブルになりがちです。このことだけでも、ECサイトのようなバックオフィスが存在するシステムは、OSツールで開発するのはかなり厳しいのではないかと思います。仮に、主機能をWordPressとEC Cubeで作ることができたとしても、移行プログラムなどの周辺開発は、フルスクラッチでやる必要があります。その辺が本当に見積もりに含まれているのか、疑問はありますね。

内藤氏　他社のことは分かりませんが、このような周辺開発はかなりお客さんに喜んでいただけるのは事実です。開発者冥利につきる瞬間ですね。

ちょっとした相談に対応できる

島田氏　エンジニアは、ちょっとしたことを断ることにストレスを感じるのかもしれませんね。

――断るのにも労力が必要で、しかも後味が悪いのは確かです。これも以前いた会社での話ですが、「無償作業撲滅運動」というものがありました。この是非は措くとして、このような運動を全社的にやること自体、裏を返せば、「技術者がお客さんの要望を断るのがストレスである」ことを示していると思います。

島田氏　そこなんです。だから、私はちょっとした相談ごとには積極的に乗ることをエンジニアに奨励しています。

――例えば、どんな相談ごとですか。

島田氏　「どうも最近こんなメールがよく来るようになったんだけど、もしかしたらスパムかな」といったレベルの話です。あるいは、「営業で使いたいので某ショッピングサイトの出店社リストを集めたいんだけど」とか。

内藤氏　フルスクラッチだろうとOSツールでの開発だろうと、お客さんからみれば私たちはITの専門家なのです。「ITのことなら何でも相談したい」と思うのは、ごく自然なことです。

島田氏　大きな機能追加であれば、「見積もり範囲外です」と言うこともありますが、こうした相談には積極的に応えたいと思っています。それでお客さんが満足してくれるのなら。

――これは私の個人的な見解ですが、ちょっとした相談ごとに無償で応えていた間は、技術力や工夫力が高まっていたように思います。それを経営の論理で無償作業はいかんとなってから、技術力も下がったし、お客さんとのトラブルもかえって増えたように思います。

島田氏　実際にはある程度、見積もりにも含んではいますが、その分、全力で相談に乗っています。

――経営者がそういうことを言う会社は少ないように思います。やはり島田さんは変わっています。1998年当時にプラムザを知っていたら、私もエンジニアとして脂が乗り切っていた時期なので、転職していたかもしれません。ただ、年上で口うるさいので島田さんは使いづらかっただろうと思いますが（笑）。

島田氏　私は年上でも遠慮しないので、大丈夫です（笑）。

――以上でよろしければ、今回のお話をまとめます（図1）。フルスクラッチ開発がストレスレスな理由は4つあったと思います。

　1つは、納期とスケジュールの制約条件の中で精いっぱいの提案ができること。

　2つ目は、お客さんと一緒に、統一された世界観のシステムを作ることができること。

　3つ目は、周辺開発ができること。

　最後は、ちょっとした相談ごとに乗れること。

　これらはすべて顧客満足につながり、それゆえに技術者にも手応えがあるということなのだと思います。

図1　フルスクラッチ開発がストレスレスな理由

島田氏、内藤氏　そのとおりです。

――フルスクラッチならではという部分と会社の姿勢の部分とが混在していたとは思うのですが、たぶんプラムザでは切り離せないことなのでは、と思います。

次回予告

　今回は、フルスクラッチ開発がエンジニアにとってストレスレスだということを検証してきた。次回は、さらにポジティブな方向に目を向けて、フルスクラッチ開発がエンジニアの世界を広げていくかどうかを議論する。