「あの、これって表示項目をひとつ増やすだけなんですけど」。名古屋市内で製造業向けの受発注システムを使っている田中さん(仮名)は、営業担当者から「取引先の一覧画面に、担当者の内線番号も出してほしい」という要望を受け取った。データベースにはすでにその情報がある。画面のどこかに一行足すだけの、ごく簡単な話だと田中さんは思っていた。ところが開発会社に連絡すると、返ってきたのは「サーバー側の改修が必要なので、テストも含めて2週間ほどかかります」という回答だった。表示項目をひとつ増やすだけで2週間。田中さんは「なぜそんなに時間がかかるのか」と困惑しながらも、開発の世界にはそういうものかと納得するしかなかった。
なぜ小さな画面変更に時間がかかってしまうのか
第一の理由は、従来型のAPIが画面ごとに決まった形式のデータしか返せない仕組みになっていることにある。多くのシステムでは、ひとつの画面に対してひとつの決まったAPIが用意されており、そのAPIは「あらかじめ決められた項目」しか返さない。内線番号のような新しい項目を表示したい場合、サーバー側のプログラムを書き換えて、その項目を返せるように改修する必要が出てくる。
第二の理由は、ひとつの画面を表示するために複数のAPIを何度も呼び出さなければならない構造にある。取引先情報、担当者情報、内線番号の情報がそれぞれ別々の場所で管理されていると、画面を表示するたびに複数回サーバーへ問い合わせを行い、その結果を組み合わせる処理が必要になる。この呼び出しの回数が増えるほど、画面表示は遅くなり、改修すべき箇所も増えていく。
第三の理由は、フロント側(画面を作る担当者)とサーバー側(データを扱う担当者)の間で、「どの項目をどういう形式で返すか」を調整するのに時間がかかることだ。ちょっとした表示項目の追加であっても、双方の担当者が仕様を確認し、影響範囲を洗い出し、テストを行うという工程を経る必要がある。これが積み重なると、簡単な要望であっても着手から完了まで数週間かかるという事態が生まれる。
放置するとどうなるか
この構造をそのままにしておくと、画面改修のたびに開発コストと納期がじわじわと膨らんでいく。ひとつひとつは小さな要望でも、都度サーバー側の改修が発生するため、積み重なれば無視できない金額とスケジュールの遅延になる。また、フロント担当とサーバー担当の間で調整に時間を取られる状態が続けば、両者のコミュニケーションコストそのものが増え続け、開発チーム全体の生産性を静かに蝕んでいく。
もっとも深刻なのは、こうした摩擦が積み重なることで、現場からの改善要望が後回しにされ続けるようになることだ。「どうせ時間がかかるから」という理由で、現場の担当者が改善提案を出すこと自体をあきらめてしまう。小さな声が届かなくなったシステムは、少しずつ現実の業務から取り残されていく。
GraphQL APIとは何か、何を解決するのか
従来型のAPIは、あらかじめ決まったコース料理しか注文できないレストランに似ている。メニューにない一品を追加したければ、シェフに新しいレシピを考えてもらい、仕込みからやり直してもらう必要がある。これに対してGraphQL(グラフキューエル)は、ビュッフェ形式の食事に近い。並んでいる料理の中から、自分が欲しいものだけを、欲しい分だけ選んで自分の皿に盛ることができる。厨房側は素材をあらかじめ用意しておくだけで、客が何をどう組み合わせて取るかは、客自身が決められる。
画面側が欲しいデータを自分で指定できる
GraphQLでは、画面を作る担当者が「取引先名と担当者名と内線番号がほしい」というリクエストを送ると、サーバー側はその通りの形でデータを返す。あらかじめ決められた形式に縛られないため、新しい項目を表示したいだけであれば、サーバー側の大がかりな改修なしに、画面側の指定を変えるだけで実現できる場合が多い。
何度もAPIを呼ばずに一度で必要な情報がそろう
複数の情報源にまたがるデータであっても、GraphQLではひとつのリクエストでまとめて取得できるように設計できる。取引先情報も担当者情報も内線番号も、一度の問い合わせで手に入る。これにより、画面の表示速度が改善し、開発時に管理しなければならない呼び出しの数も減っていく。
項目を追加してもサーバー側への影響が小さい
GraphQLでは、あらかじめ用意しておいたデータの中から画面側が必要な項目を選び取る形になるため、新しい項目を表示したいという要望があっても、その項目がすでにデータとして存在していれば、サーバー側を大きく作り変えずに対応できることが多い。これが、田中さんが直面したような「表示項目をひとつ増やすだけで2週間」という事態を防ぐ土台になる。
導入時の注意点
ここで大事なのは、既存のシステムをすべてGraphQLに置き換える必要はまったくないということだ。GraphQLは万能薬ではなく、ひとつの選択肢に過ぎない。特に小規模なシステムや、画面と機能の数がそれほど多くないシステムでは、従来型のAPIのほうがシンプルで、開発も保守もしやすい場合が少なくない。導入すること自体を目的にしてしまうと、かえって開発会社との認識のズレや、余計な学習コストを生んでしまう。
発注者として確認すべきポイントは、いま抱えている「画面改修のたびに時間がかかる」という課題が、本当にAPIの設計に起因するものなのかということだ。開発会社に「表示項目を追加するたびにサーバー側の改修が必要になっているか」「複数の画面で同じような調整の手間が繰り返し発生しているか」を率直に尋ね、その答えによってGraphQLが有効な選択肢かどうかを判断するとよい。
現実的な進め方
既存のシステム全体を一気に作り変える必要はない。現実的なのは、これから新規に開発する部分や、今後も改修が頻繁に発生しそうな画面から、段階的に取り入れていくやり方だ。すでに安定して動いている部分にまで無理に手を入れる必要はなく、変化の多いところ、要望が今後も出続けそうなところから優先して見直していけばよい。そうすることで、リスクを抑えながら、現場の「もっとこうしたい」という声に、以前よりずっと早く応えられる体制に近づいていける。
壁を越えて働く人たちへ
「表示項目をひとつ増やしたいだけなのに」。そう感じたことがある人は、田中さんだけではないはずだ。小さな要望が届くまでに時間がかかりすぎる仕組みは、現場で日々工夫を重ねている人たちの熱意を、少しずつ削っていく。オルアナが向き合いたいのは、技術の難しさそのものではなく、その技術の裏側にある「もっと良くしたい」という気持ちを持つ人たちだ。表示項目ひとつのために現場の声をあきらめさせない仕組みづくりは、壁を越えて働こうとする人たちを後押しする、小さくても確かな一歩になる。オルアナは、その一歩を共に歩む存在でありたいと考えている。