インターフェースはローリスクハイリターン！

僕の経験上インターフェースは、業務アプリ開発で、トラブルが発生するベスト３にインターフェースはランクインぐらいハイリスクな領域です。インターフェースとは、システム間でやりとりするデータ連携のことで、トラブルの原因となるのが、項目の齟齬、文字化け（文字コードの考慮不足）、連携タイミングの認識があっていないなど色々あります。

このようなトラブルを招いてしまう要因は、大きく２つあると思ってます。

要因１：他者目線が欠けているため
他者目線とは、システムエンジニアの場合、相手のシステムのことを想像できる人のことです。システムエンジニアとして、この他者目線はめちゃくちゃ大切（また他者目線だけをテーマにして投稿したいと思います）なんですが、ことインターフェースに限っては、結構、ファイル定義書だけのやり取りだけで、相手のシステム構成（OSや文字コードなど）まで気にしていないイメージです。あと業務の力関係もありますね。経理に合わせるとか。

要因２：コミュニケーション不足
他システムの担当者と調整するため、お互い気を使って、あまり踏み込まなかったり、ちょっとした懸念事項があっても情報共有しなかったり、仕様変更（項目の増減など）があっても連絡が遅れたりする場合があります。とかく、インターフェースは、他システムの担当者との調整が大変だし、ドラブルが発生する可能性の高いので、泥臭いイメージを持たれている方がいるかもしれませんが、僕はどちらかというと積極的にインターフェースには関わっていきます。

理由は、ローリスク、ハイリターンだからです。なぜなら、業務知識が必要なく、アプリ開発のプログラミンの知識も必要なく、他者目線とコミュニケーション能力があれば適応できるのでローリスクです。また、インターフェースは上流フェーズのタスクとして扱われるケースが多く、PM、PLとも進捗の相談をしながら、しかも他システムの担当者とのやり取りの窓口になったりもするので、スキルの割には存在感が高いポジションです。そして、本番リリース後は、協業した他システムの担当者の方と顔見知りになり、今後の作業はスムーズになったり、PM、PLからも信頼され新たな案件受注につながる場合が多いためハイリターンです。

まとめ
みなさんお気付きかもしれませんが、実はインターフェースは、外部設計とスキルやその後の展開がかなり似ているんです。業務知識に頼らず、実行力、コミュニケーション能力、そして他者目線（お客さま、他システムへの優しさ）があれば適応でき、他システムの担当者とも顔見知りになりPM、PLからも信頼されるため、存在価値が高まるため、インターフェースのタスクは積極的に取りに行った方がいいでしょう。

何を隠そう、僕の主戦場も、外部設計とインターフェースの領域なんです。
業務知識は浅く広く持っているので要件定義の主役にはなれませんが（またどこかで要件定義の戦略についてはお話します）

直近3年で参画した案件を書き出してみると、ざっとこんなことやってました。
・2016/8 EDIシステム 外部設計（Linux/Java）
・2017/3 EDIシステム 要件定義（Linux/sh/Oracleのパッケージ）
・2017/6 イントラマート 外部設計（Linux/Java）
・2018/4 データベース構築 Postgre化対応 外部設計（AIX/sh）
・2018/7 工程管理システム 外部設計（AIX/java）
・2019/1 工程管理システム 外部設計（AIX/java）
・2019/4 インターフェース構築 OSS化対応 要件定義（Windows/Java）
・2020/3 工程管理システム 外部設計（Windows）