システムを開発する際，任された範囲に集中して仕様通りに仕上げればエンジニアの任務としては十分です。さらにシステムが導入されたサービスが成果を出すところまで力を貸すのもありです。
例えば，システムだけではなくコンテンツもエンジニアが提供できるようになれば，顧客にとってこんな心強いことはありません。エンジニアだからこそ準備できるシステムにフィットしたコンテンツは，自身が開発したシステムを完全に活かし，サービスの成果を上げることになります。
本稿では，そのことをFAQサイト（よくある質問サイト）をモチーフに，順を追って解説します。小学生のころから始め今でもメールやSNSで書く「文」にすこし磨きをかけるだけでエンジニアの可能性が広がることに気づいていただければ幸いです。
責任範囲の線引きをしないことのすすめ
システムを仕上げるのと，そのシステムが導入されたサービスが成果を上げるのとでは話が違います。もしサービスの成果が上がらないことで，システムへの評価も下がればエンジニアは心中穏やかではありません。完璧に仕上げたはずのシステムがサービスで成果を上げていない。とするとサービスに関わる要素のうち，システム以外に何か原因があるはずです。その原因は本来はエンジニアの責任範囲外です。しかし，サービスは成果を上げていないためにシステムが活きていない。システムがダメに見える……の堂々めぐりです。
開発したモジュールが要件通り動作し，呼び出しやレスポンスで他のロジックに迷惑をかけていない。そしてメモリへの悪影響がなく，システム全体としてのパフォーマンスを良くしている。このようにミクロからマクロにだんだんと視野を広げていくのはエンジニアとしては基本的な姿勢です。
できれば，さらに視野を広げて，システムが組み込まれた顧客のサービスまで気にしてみましょう。「自分の仕事は完璧だし，あとは客の努力次第じゃね？」ではなく，「システムが活かされてないぞ！サービスにも首を突っ込んでみるか」のように考えるのです。エンジニアが責任範囲を気にせずひと肌脱ぐときです。
サービスが成果を上げるのには，いろんな要素が複雑に絡んできます。その時，責任範囲の線引きをせず，サービスの成果までを思いやる発想が，エンジニアには有利となります。
成果を上げるサービスのシステム以外の要素
FAQサイトというユーザーサポート用Webサービスを例にすると，具体的で分かりやすいです。
FAQサイトの成果とは，ユーザーでは自己解決できない問題が，サイトに訪れることで解決できるようになることです。もし大きな成果を上げるFAQサイトになれば，企業もユーザーもハッピーです。従って企業は，FAQシステムやチャットボット，そしてAIと銘打ったものに投資し導入しています。うまくいけば利益も残るはずです。
ところが現実的にはFAQサイトの「役に立っている率」は某所の統計では30%程度です。ネットショップに例えると「3回に1回ぐらいしか商品が買えない」ようなものなのです。FAQサイトにシステムを導入しても，企業は利益どころか投資も回収できていないかもしれません。
成果が上げられていない原因は，そのサービスに関わる次要素のどれかにあります。
- サイト導線
- ヴィジュアルデザイン，UIデザイン
- システムの機能・スピード
- コンテンツ（FAQそのもの）
原因がわかればその改善にエンジニアがサポートをすることでサービスは大きく成果を上げ始めます。
乗っかってはいけない顧客のシステム依存
ところで，顧客はFAQサイトで成果を出せない場合，しばしばシステムに対して追加の機能要求をします。「自動学習するようなAIはないのか」「賢いチャットボットを入れたい」「音声認識はいけるんじゃないか」などと。トレンドな技術に対する情報を都合よく解釈し，これこそは救世主であると考えてるようです。
向上心のあるエンジニアほど，顧客からのそういったリクエストに魅力を感じ，トライしたいはずです。ただし，いかに顧客のリクエストであってもすぐに「御意」と請け負うのは危険です。
サービスが「FAQサイトではなく回転寿司屋なら」……と考えてみましょう。寿司のネタも味も顧みず，オーナーが最新の回転ベルトシステムや音声認識の注文AIロボットなどの導入にこだわったら。そして店に客が来ないことを「なんとかしろ！」とシステム屋に文句を言ってきたら。いまさら，「寿司が不味いからなんです」とも言い出しにくいですよね。
しかしこういったシステム依存は，手遅れにならないうちに顧客に気づかせましょう。気づきが早いほど顧客もエンジニアも無意味な仕事が減ります。システム依存の顧客ほどサービスの成果が出ないのを，システムの性能や不具合だと決めつけることも多いものです。コンテンツがいかに重要で，システムを活かし，故にサービスの成果を出せるかということを顧客に気づかせるのはエンジニアの役割です。
サービス成功のために見極めるべき要素
サービスで成果をあげるための最優先事項は何か，FAQサイトから学んでみましょう。言わんとしていることはもうおわかりかと思いますが，「コンテンツとしてのFAQの質」を上げないと，FAQサイトは永遠にお役立ち度30%のままです。なぜならFAQサイトにユーザーが訪れる目的は，FAQそのものだからです。
FAQの質が低いと，導入しているシステムがどんなに美しく高機能で，素晴らしく高速で，鬼のようにセキュアでも，不味い寿司屋よろしくユーザーは見向きもしなくなります。
次は質の低いFAQの一例です（しかもよく目にします）。
- ①ログインするにはどうすればいいの
- ②機種変したい
- ③高速にできますか
これでは，システムはユーザーをFAQに導けません。たとえ導けたとしてもユーザーは解決に至らないでしょう。
システムの機能も，本来はユーザーを最適なFAQと解決に導くことです。システムの機能を高度化したいのなら，コンテンツ（FAQ）側もそれに応えられなければいけないのです。
エンジニアがコンテンツを準備できれば鬼に金棒
エンジニアが作ったシステムと顧客の準備したコンテンツで成り立つサービスは無数にあります。そのなかでもFAQサイトは特にコンテンツの質が成果に影響します。しかも上記したように，サービスの成果が出ていない代表的なものなのです。
前述のFAQ例は，このように書けば非常に良くなります。
- ①'ログインしたいので，Webでの会員登録手続きを教えて
- ②'ガラケーからスマホに機種変する際の必要書類を教えて
- ③'通信速度のアップグレード手続きをするサイトを教えて
FAQは文章ですが，このような書き方が良く，システムに適合しているということをエンジニアのほうがたやすく理解でき実践できます。なぜならエンジニアはシステムがFAQを検索するロジックに詳しく，FAQを納めるデータベースの構造も分かるからです。
『良いFAQの書き方』は少し学べばプログラミングよりやさしいことが分かります。また良いコードを書くことにも似ていて，ユーザーにもシステムにも読みやすく，メンテナンスや分析がしやすい特徴があります。
『良いFAQの書き方』をお読みいただければ，エンジニアだからこそ上のFAQ例がシステムにもユーザーにも良いFAQであることが素直に理解できます。エンジニアがコンテンツの領域に踏み込んでサービスとシステム自身の役立ち度を限りなく完璧に仕上げる。その入門としてFAQの世界をのぞいてみてください。
