APIは、未来のために選ぶ

今だけ動けばいい、では終わらない。

システムを作るとき、まず考えるのは、

「今、必要なことをどう実現するか」

です。

SMSを送りたい。

電話をかけたい。

本人認証をしたい。

決済を受け付けたい。

必要な機能を実現できるAPIを選び、システムに組み込む。

もちろん、それは大切なことです。

でも、システムは完成した瞬間で終わるものではありません。

むしろ、そこから長い運用が始まります。

今日の「最適」が、ずっと最適とは限らない

サービスを運用していると、いろいろなことが変わります。

通信事業者のサービス内容が変わるかもしれません。

料金が改定されるかもしれません。

利用していた機能の仕様が変わることもあります。

新しい認証方式を追加したくなるかもしれません。

ユーザーが増えて、これまでとは違う使い方が必要になることもあります。

今日選んだ方法が、3年後も同じように使われているとは限りません。

では、3年後に必要になるものを、今すべて予測して作っておくべきでしょうか。

それも、少し違います。

未来を全部作っておく必要はない

まだ必要かどうかも分からない機能を、あらかじめ全部作っておく。

それでは、使われないもののために開発時間を使うことになります。

このシリーズの最初に、

「本当に、それを作る必要があるのか」

と考えました。

未来についても同じです。

必要になるかもしれないものを、すべて今作る必要はありません。

大切なのは、

未来のために、完成品を用意しておくことではなく、選択肢を残しておくこと。

です。

交換できるようにしておく

たとえば、あるシステムからSMSを送るとします。

アプリケーションのさまざまな場所から、特定のSMSサービスを直接呼び出す設計にすると、そのサービスに関する処理がシステム全体に広がっていきます。

もし将来、別のサービスを使う必要が出てきたら。

料金体系が変わったら。

別の通信経路を追加したくなったら。

変更しなければならない場所も増えてしまいます。

一方で、

「メッセージを送る」

という役割と、

「どのサービスを使って送るか」

を分けておけば、変更の影響を小さくできるかもしれません。

今は一つのAPIしか使わなくてもいい。

でも、あとから別の方法へ交換したり、追加したりできる余地を残しておく。

今は一つでも、未来まで一つに固定しない。

それも設計です。

認証方法だって、変わっていく

第7話では、

「最高の認証は、一つじゃない」

と考えました。

今はSMS認証だけで十分かもしれません。

でも将来、

パスキーを追加したい。

音声による認証経路が必要になった。

別の本人確認方法を組み合わせたい。

そんな変化が起きるかもしれません。

そのとき、

「最初から全部作っておけばよかった」

という話ではありません。

必要になったときに、新しい選択肢を加えられること。

一つの方法が使えなくなったときに、別の方法を検討できること。

変化できる余地そのものを、最初の設計に残しておく。

それが、未来への備えになります。

APIを選ぶとき、機能だけを見ない

APIを選ぶときには、つい、

「この機能があるか」

「料金はいくらか」

「すぐ使えるか」

に目が向きます。

もちろん、どれも重要です。

でも、長く使うシステムなら、もう少し先も考えてみます。

必要な機能を追加できるか。

既存のシステムと組み合わせやすいか。

変更するときの影響を小さくできるか。

運用や保守を続けやすいか。

そして、

そのAPIを使うことで、未来の選択肢が狭くならないか。

APIは、今の機能を実現するためだけのものではありません。

システムと外の世界をつなぐ境界でもあります。

だからこそ、その境界をどう作るかによって、未来の変化への向き合い方も変わります。

変化を「吸収できる」設計へ

料金改定。

通信事業者の変更。

新しい認証方式。

新しいユーザーのニーズ。

運用方法の変更。

変化そのものを、なくすことはできません。

そして、未来に何が変わるのかを、すべて予測することもできません。

だから設計で目指したいのは、

変化しないシステムではなく、変化を受け止められるシステム。

なのかもしれません。

何かが変わるたびに、システム全体を作り直すのではなく。

変わったところを、交換する。

必要なものを、追加する。

必要なくなったものを、外す。

そうできる余地を残しておく。

未来を当てるのではなく、未来に選択肢を残す

良い設計とは、未来を正確に予測することではありません。

3年後に何が必要になるのか。

どんな技術が使われているのか。

どのサービスが選ばれているのか。

それを今、全部知ることはできません。

だからこそ、

未来を決めてしまわない。

今必要なものを作りながら、未来の人が別の選択をできるようにしておく。

その「未来の人」は、別のエンジニアかもしれません。

運用を担当する人かもしれません。

サービスを使うユーザーかもしれません。

あるいは、数年後の自分自身かもしれません。

設計によって残された選択肢は、その人たちが使える自由になります。

エンジニアリングの時間は、今日の機能を作るためだけにあるのではありません。

未来の誰かが、よりよい選択をできるようにするためにも使えます。

次回、Engineering Time 最終回。

「良い設計は、人を自由にする」

ここまで考えてきた「作ること」「自動化すること」「失敗に備えること」「選択肢を残すこと」。

最後に、それらが誰のためにあるのかを考えます。