カスタム対応外の特殊なシステムは、業務知識の宝庫：SEの未来を開く、フルスクラッチ開発術（4）（2/2 ページ）
プログラムレス開発が全盛の中、フルスクラッチ開発こそ、顧客のためになり、SEにとっても強みとなると主張する企業がある。彼らはなぜあえて今、このような主張をするのだろうか？
OSツールでは実現できなかった特殊な業務フローを作りこむ面白さ
島田氏 ただ、私たちは採用するに当たって、人柄も重視しています。
――例えば？ 人柄といっても、いろいろあります。
島田氏 挨拶ができるとか、やる気があるとか、そういうところも見ますが、一番重要なのは「お客さんの問題を解決することが自分の喜びでもある」といえるかどうかですね。
――そういう人を採用したい気持ちはよく分かります。ただ、実務においてはどうなのでしょう。人柄って役に立ちますか？
島田氏 プラムザの場合、OSツールやパッケージソフト（注1）では難しい、あるいは失敗した、という案件が持ち込まれることが多いのです。というか、ほとんどがそんな案件です。これらの案件は標準的なものではないので、自分たちで業務フローを作成しなければなりません。業務フローの作成は、ただのプログラミング・マニアでは難しいです。能力も必要ですが、それ以前にお客さんに対して親身になる気持ちがないとできないからです。
――確かに、業務フローは、通りいっぺんのヒアリングでは作成できませんね。お客さん自体も、業務を客観的に見る機会がなかったので、彼らの言うとおりに作成しても、実用に耐えないものになってしまう。お客さんに寄り添って、忍耐強くヒアリングしないと作れません。
島田氏 そのとおりです。まずは取りあえず、業務フローを起こしてみる。それで再度、ヒアリングする。私たちが無駄だと思った機能が、中にはある。突っ込んで聞くと、実は重要な機能だと分かってくる。私たちが無駄だと思った理由をぶつけていくと、現状のシステムの欠陥や不具合も見えてくる。こうしたやりとりが重要なのです。しかし、ここまでやるには、「絶対に問題を解決して、お客さんに喜ばれるぞ」という強い気持ちが必要です。
――そのような強い気持ちは、性格だけでは保てないように思います。
内藤氏 パッケージやOSツールでは解決できなかった案件なので、お客さんも切実なんです。だから、お話していると、何とかお応えしたいという気持ちになるんですよ。また、このような案件は、一般的な業務知識ではなく、お客さん独自の業務の開発になるので、懇切丁寧に教えてくれます。中にはかなり特殊なものもあるので、「世の中にはいろんな業務があるんだなあ」と、新しい発見にわくわくすることもあります。これはフルスクラッチ開発でしか味わえない、わくわく感だと思っています。
現行業務そのものの改善提案ができることもある
島田氏 ヒアリングを重ねるうちに、お客さんよりも私たちの方が業務に対する理解が深まることもあります。
――それは面白い現象ですね。
島田氏 システム化されていない部分をシステム化するので、どうやってシステムに落とし込もうとするかを一生懸命、考える。そうすると、業務の本質が見えてきます。
――現行業務そのものの改善ができる、ということですか？
島田氏 そうです。例えば、お客さんが画面案を持ってくることがあります。しかし、業務の本質を考えると必ずしもベストとは言えないことも多い。お客さんの画面案よりも良い提案ができることもしばしばあります。
――それは、提案の本質だと思います。先方の期待を超えないのであれば、私たちが提案する価値はありませんからね。それこそ、お客さんの言うとおりに作るしかない。
島田氏 以前、プラムザのスタンスを話しました（参考）。覚えていますか？
――社名の由来ですね。たしか「実際にビジネスを作っているのはお客さん。私たちはそれを手助けする道具、つまり裏方に徹したい」ということでした。
島田氏 ビジネスと業務はほぼ同じ意味です。やりたいことはお客さんが決めてくれればいい。私たちはシステム開発のプロとして、最適な提案をしたい。そうなるとやはり業務の流れを理解せざるを得ない。
――結果として業務が分かってくる、と。
関連システムの周辺も相談される
内藤氏 前回のインタビューで、「お客さんのちょっとした相談に対応できる」という話がありました。実は、それだけではありません。
――ほう。
内藤氏 私たちは「仕様変更」と言いません。基本的に「そこは対象外」という言い方をしないのです。すると、お客さんは安心して、周辺業務の悩みも相談してくるようになります。
島田氏 勘違いされると困るので、はっきりと区別させてください。私たちはまず、機能的な要望を伺います（図2）。これに基づいて見積もりをするわけで、大きな機能追加に関しては「見積もり範囲外」という言い方はしています。ここで言う「仕様変更」とは、それ以外の「実装上の変更」のことを指します。
――では、これ以降「仕様変更」という言葉を、その意味で使うことにしましょう。
島田氏 システム開発会社の多くは仕様変更に敏感ですが、実はお客さんの方が、仕様変更に対してびくびくしているケースが多いんですよ。
――分かります。ユーザー企業のITコンサルタントをしていたときに、「これは仕様変更になるんだろうか」という相談をよく受けました。
島田氏 私たちはそれに即応できます。一から作れるエンジニアを自社で抱えているからです。実際お客さんからの要望はそれほど大変でないものが多いんです。交渉に時間を費やしていないですぐにやれば、とても喜んでもらえます。
――その前提としては、第2回でお話ししていた「開発ドキュメントの徹底的な合理化」などがあるわけですね。
島田氏 はい。それは欠かせません。
――仕様変更に柔軟に対応することで、顧客満足度が高まると。
内藤氏 はい。すると実際に今開発しているシステムの周辺の開発もお願いしようか、という話になります。それにより、エンジニアの業務知識がまた広くなっていきます。つまり仕事の幅が広がることになるわけです。
――なるほど。フルスクラッチ開発がエンジニアにもたらす積極的なメリットがよく分かりました。まとめると、要点は大きく2つありました（図3）。
1つは、長く使える技術を深く身に付けられる。つまり、つぶしが利くということ。
もう1つは、フルスクラッチでないと開発できない案件が持ち込まれるので、業務理解が深くなるということ。
以上の2つが達成されることで、提案力が高まり、周辺業務の開発案件も持ち込まれるようになる。その結果エンジニアとしての世界が広がっていく、ということでした。よろしいでしょうか？
島田氏 そのとおりです。そして、それはまさにエンジニアの市場価値が高まるということだと、私は思っています。
次回予告
前回と今回で、フルスクラッチ開発がエンジニアにとってメリットがあることを検証してきた。
次回もエンジニアのメリットという観点で、マネジメント力や広い意味での営業力が身に付くかを議論する。
筆者紹介
森川 滋之
1963年生まれ。1987年、東洋情報システム（現TIS）に入社。TISに17年半勤務した後、システム営業 を経験。2005年独立し、ユーザー企業側のITコンサルタントを歴任。現在はIT企業を中心にプロモー ションのための文章を執筆。
著書は『SEのための価値ある「仕事の設計」学』、『奇跡の営業所』など。日経SYSTEMSなどIT系雑誌への寄稿多数。誠Biz.IDに「奇跡の無名人」シリーズを連載中。
Copyright © ITmedia, Inc. All Rights Reserved.