昨年までは自分でプログラムを書くことは少なかったのですが、今年に入ってその時間が増えました。といっても、AIにコードを生成させているので、増えたのはAIに指示を出す時間と生成されたコードを確認する時間です。

この数か月、自社製品のポイントシステム「Cardfeel」やPOSレジ「コアレジ」で、機能追加やカスタマイズを生成AIを使って進めています。要件や仕様の整理にはChatGPTを使い、ソースコードの調査や実装にはCodex、Cursor、Claudeを使っています。

AIに任せる範囲は、プログラムの作成だけではありません。既存のソースコードの調査、影響範囲の洗い出し、実装方針の作成、テストコードやテスト項目の作成、ドキュメントの更新まで含みます。

ほんの1、2年前なら、かなりの時間が必要だった作業です。時代は変わったなと思います。

AIの使い方より大事なのはその前後

これからのエンジニアにとって、AIを使うことは前提になると思います。一方で、AIツールの操作方法そのものは、エンジニアの専門性としてはそれほど重要ではないとも思っています。

良い指示の出し方や、各ツールの特徴を理解する必要はありますが、基本的な使い方はAIに聞きながら短期間で身につけられます。プロンプトのちょっとしたテクニックも、モデルが進化するにつれて重要性が下がっていくと思います。

AIを操作できることと、AIを使って仕事を完了できることは別です。重要なのは、

・何を作るべきかを整理する
・AIに必要な情報を与える
・AIが作ったものが正しいか判断する
・問題があれば修正方法を決める
・最終的な品質に責任を持つ

といった、AIを使う前後の仕事です。これは、これまでプロジェクトリーダーや上級エンジニアに求められてきた仕事と重なります。

整っているのに間違っている

AIが生成する成果物には、少し厄介な特徴があります。文章もコードも見た目が整っているのです。

人が作った設計書やプログラムは、細部を見るとその人が全体像や重要なポイントをどの程度理解しているかが何となく分かります。説明に甘さがあったり、例外処理が雑だったり、似た処理が整理されずに並んでいたりすると、他の部分も慎重に確認した方がよいと判断できます。プロジェクトを長くやっていると、このような「成果物の品質感」からどこまで確認すべきかをある程度判断します。

ところが、AIの成果物は内容に問題があっても整って見えます。それらしい構造があり、クラスやメソッドの名前も自然でコメントも入っています。それでも前提を大きく誤解していたり、依頼していない処理や機能が含まれていたりすることがあります。この点は人が作る成果物とは違った意味でレビューが難しいです。

そこで複数の方法を組み合わせて確認します。

最初に行うのは、別のAIによるレビューです。例えばCodexで調査や実装を行った場合は、生成されたソースコードや仕様をClaudeで再確認します。実装を行ったAIの説明だけに頼らず、別のAIでも元の仕様やソースコードから確認するのです。

次に、可能な範囲でAIを使ってテストコードを作成し、自動テストを実行して結果を確認します。そのうえで従来どおり人が実際の動作、設計、影響範囲を確認します。AIがレビューし、テストが通ったことだけを、正しさの根拠にはできないのです。

ソフトウェア開発は複雑さとの戦い

ソフトウェア開発は、システムの複雑さと人が理解できる限界との戦いだと思っています。オブジェクト指向やレイヤー分割などの設計手法も、現実の複雑な問題を、人が理解できる単位や構造に整理するためのものと認識しています。

AIは大量のコードやドキュメントを短時間で作れますが、指示された内容を漏れなく盛り込もうとする結果、必要以上に複雑な成果物を作ることがあります。あらゆるケースを説明した長い文書、将来使うか分からない拡張機能、細かく分割しすぎたクラスなどです。一見するとよくできた成果物に見えますが、人が理解しにくくなれば、内容を十分に確認できず、品質に責任を持てません。つまり、そのままでは実務上の価値が低いのです。

だから、AI開発では以前より単純化する努力が重要になります。当たり前の説明は省く。補足事項は備考にまとめる。共通点を抽象化して整理する。現在の仕様と検討中の案を混在させない。採用しなかった案が重要なら、現行仕様とは別の決定記録として残す。AI開発では、この努力が欠かせません。

AIが仕事をしやすい開発環境

AI開発で成果を上げられるかどうかは、開発環境の整備に大きく左右されます。当社のプロダクト開発では、次の整備を進めています。
・ソースコードと主要なドキュメントを同じGitリポジトリで管理する
・ドキュメントはAIが扱いやすいMarkdown形式で作成・維持する
・案件やタスクごとに、目的、前提、決定事項、対象外を記録する
・ドキュメントの冒頭に状態（作成中、確認済み、廃止など）を記載し、位置づけを明確にする

もっとも、既存システムに関する過去の文書を一気にMarkdownへ移行するのは合理的でも現実的でもありません。そこで、機能追加や修正を行う箇所から作業に合わせて整理しています。

ドキュメントはAIが扱いやすいように整えているのですが、結果として人にとっても現在の仕様や判断理由を探しやすい状態になります。AIが仕事をしやすい開発環境は、人にとっても仕事をしやすい開発環境なのだと思います。

実装は人が見切れる単位で進める

AIに大きな機能の実装をまとめて指示すると、かなり広い範囲まで一度に変更できます。それでも実際の開発では、調査、方針決定、実装、テストを小さな単位に分けて進めるようにしています。

これはAIの能力が足りないからではなく、人が変更内容を理解し、問題があったときに原因を特定し、必要に応じて元に戻せる状態を維持するためです。

例えば、ある機能の変更を行う場合でも、最初から関連するすべての処理を一度に変更するのではなく、
・現在の仕様と処理を調査する
・変更内容と影響範囲を整理する
・中心となる処理を変更する
・テストを追加して動作を確認する
といった形で段階を分けます。

AIは、一度に多くのファイルを変更することができます。しかし、変更量が人の理解できる範囲を超えると、レビューの精度は下がります。問題が発生した場合も、どの変更が原因なのか分かりにくくなります。さらに、途中の方針に誤りがあったときの後戻りも大きくなります。

そのため、AIが一度に実行できる範囲ではなく、人が見切れる範囲を基準に作業を分けます。

実装を段階的に進め、コミットも意味のある単位に分け、それぞれの段階で確認する。これは従来のソフトウェア開発でも大事なことでした。AIによって大きな変更を簡単に行えるようになったため、むしろ以前より重要になったと思います。

コードを書く量が減っても、技術は必要

これから、エンジニアが手でコードを書く量は減っていくと思います。一方で、AIが作ったコードを読み、処理の流れを理解し、変更の妥当性を判断する必要は、当面なくならないと思います。

そのため、オブジェクト指向、依存性注入、トランザクション、非同期処理など、既存のプログラムを理解するための知識は必要です。

さらに重要度が上がるのは、アーキテクチャ設計、データベースの論理設計、情報セキュリティ、テスト、障害対応などの知識です。どれも、これまでは上級エンジニアやプロジェクトリーダーに求められることが多かった能力です。

ここでいうリーダーは、人員管理だけを行う管理者ではありません。技術を理解し、何をどのように作るかを決め、プロジェクトを安全に進める人です。

私は会社設立以前から、プロジェクトマネージャの仕事は技術をベースにするものだと考えています。AI時代には、この考え方がさらに重要になると思います。

学ぶなら基本情報、次に応用情報

経験が浅いエンジニアから何を勉強すればよいかと聞かれることがありますが、まず基本情報技術者試験、次に応用情報技術者試験を勧めます。

資格を取得することだけが目的ではありません。コンピューター、データベース、ネットワーク、セキュリティ、システム設計、プロジェクト管理などを体系的に学ぶことに価値があります。

さらに深く学ぶなら、情報セキュリティの知識を深めることや、リレーショナルデータベースの論理設計をしっかり学ぶことを勧めます。

AIで作業速度が上がるほど、人は短時間に多くの判断を求められます。そのため、エンジニアの基礎知識は以前より重要になります。

しっかりした基礎知識があれば、それを基にAIへの指示や成果物の確認を効率よく的確に進められます。基礎知識の価値は下がるどころか、AI開発時代においては上がると思うのです。

経験数年のエンジニアにとってはチャンス

当社では現在、ソフトウェア開発の経験が数年程度あるエンジニアを募集しています。入社時点でアーキテクチャ設計や顧客対応まですべてできる必要はありません。

まずは既存のソースコードを読みながら、小規模な機能追加や不具合修正、テストから担当します。慣れてきた領域から、調査、設計、リリース、本番保守、見積り、顧客対応へと担当範囲を広げていきます。

いきなり一人で全部を任せるわけではありませんが、指示された箇所のコードだけを書いて仕事を終えるのではなく、変更の目的や影響範囲を理解し、一つの機能やシステムに責任を持てるエンジニアを目指してほしいと思っています。

AIによって、指示どおりにコードを書く仕事は減っていくと思います。一方で、経験が浅いうちから、調査、設計、テスト、ドキュメント作成まで、幅広い仕事に取り組みやすくなりました。

使い方次第では、これまでより早い段階で、上級エンジニアが担ってきた仕事の一部を経験できます。これは、経験数年のエンジニアにとって大きなチャンスだと思います。

責任は人。作業はAI。

来年や再来年のソフトウェア開発がどうなっているかは、正直なところ分かりません。

人がコードをほとんど書かなくなるかもしれませんし、AIが作ったコードを一行ずつ読む仕事も減っていくかもしれません。

それでも、人の仕事は残ります。定型的な作業が減る一方で、一つ一つの判断の重要度は上がっていくと思います。

・何を作るかを決める
・具体化する過程で方向性を示し、承認する
・アーキテクチャを決める
・実装状況を把握する
・テスト結果を確認し、リリースの可否を判断する

そして、一番大事な「お客様に対して品質に責任を持つ」という仕事が残ります。AIがどれだけ進化しても、AI自身がお客様に対して責任を負うことはありません。

私は、これを「責任は人。作業はAI。」と捉えています。AIに仕事を丸投げするのではなく、人が目的と責任を持ち、そのための作業をAIに任せる。

こうした開発を面白いと思うエンジニアと一緒に仕事をしたいです。

東京ビックサイトで開催されているリテールテックJAPAN 2026(3/3～3/6)に出展中です。
今回は自社社開発のPOSレジ「コアレジ」を展示しています。

コアレジはStera Terminalで動作するPOSレジです。今回は釣銭機（グローリー社 N300シリーズ）と連携して動作するセミセルフレジのデモも用意しました。

この釣銭機連携は、チェーン店を想定して設計しました。特徴は「本部で現金を統括できるPOSレジ」です。もちろん単独店舗でも使えます。

一般的な釣銭機連携の機能は通常の会計のみPOSと釣銭機が連携し、それ以外の「つり銭の補充」や「現金の回収」等は釣銭機本体の操作で行うことが多いのですが、便利な反面、POSが関与しない現金の操作が発生してしまうと運用は店舗次第になってしまい、本部は現金の管理が難しくなります。

ですので、今回の設計では釣銭機本体の操作は禁止設定を入れて、「つり銭の補充」や「現金の回収」はPOS主導で動作するようにしました。投入金額や回収金額はPOSを通じてサーバーで管理され、本部が管理画面で掌握できます。

釣銭機連携は「付け足し機能」ではなく、現金運用の中心に刺さる機能です。
だからこそ、機能を増やすより先に、運用と設計の前提を合わせるのが近道だと思うのです。

営業時間外でもお問い合わせに対応できるように、自社POSプロダクト「コアレジ」のAIチャットボットを作成しました。コアレジはヘルプページが充実しているため、そこに掲載されている情報をナレッジとして活用しています。

大規模言語モデル（LLM）は OpenAI API を利用しています。

【仕組み（RAG）】

このAIチャットボットは、生成AIの RAG（Retrieval-Augmented Generation） という仕組みで動いています。簡単に説明すると、次の流れです。

1) ナレッジの準備（クロール → テキスト抽出 → embedding化）
あらかじめコアレジのWebサイトをクロールし、リンクをたどって関連ページを収集します。
収集したページからテキスト部分を抽出し、文章を embedding（数千次元のベクトル表現） に変換します。
テキストとベクトルはデータベースに格納しておきます。

2) 質問の検索（質問文をembedding化 → 類似検索）
利用者が質問を入力すると、同じようにその質問文をembeddingに変換します。
そのベクトルと近いベクトルをデータベースから検索し、質問に関連性の高いナレッジ（該当ページの本文）を抽出します。

3) 回答生成（質問＋根拠をLLMへ）
質問文と、関連性の高いナレッジをまとめてLLMに渡し、回答を生成します。
また、回答の根拠として 参考URL（出典） も表示できるようにしています。 

【誤情報対策（チューニング）】

生成AIは誤情報を出すことがあるため、精度改善に手間をかけています。まず約50件の代表的な質問を用意し、できる限り多くのケースで適切な回答になるようにテストと調整を繰り返しました。特に誤案内が問題になりやすい領域は、安全側に倒しています。具体的な例としては次のとおりです。

・契約・価格に関する内容は、推測で案内せず、公式情報を参照する形（定型の案内）にする
・カスタマイズで実現できる可能性がある要望は、「標準機能として"できる"」と断定せず、カスタマイズのご相談（個別見積）が必要であることを自然に案内する
・端末連携など誤解が起きやすい質問も、前提を置いて断定しないようにガードする

このAIチャットボットは社内での評価が完了次第、公開予定です。

もう半年ほど前になるのですが、ランチタイムを10分増やして70分にしました。

その分帰りが遅くなるという状況を避けるために、追加する10分間は仕事時間扱いにしました。一応、仕事したければ仕事しても良いルールです。（緊急時以外でこの時間に仕事する人はいないです。念のため）

なお、当社で働くSESのメンバーも同じルールです。

増えた時間の過ごし方はいろいろ。昼寝する人、ゲームする人、動画を見る人もいます。

この制度のランチタイムのスタートは11:50です。たかが10分ですけど、この10分で徒歩圏の人気飲食店に空席が残っていることがポイントです。このあたりはもともとランチ天国。安くておいしいお店が多いのです。それに70分あれば少し足を延ばすことができて選択肢が広がります。

（飯テロ写真ですね。すいません）

写真はオフィス徒歩圏の飲食店の料理。どれも美味しいです。最近のお気に入りは右下のランチで頂ける「本日のビザ」です。

さて、ブログをさぼって、はや１年。（すいません。変な出だしで・・）久しぶりのブログですので、近況をお伝えしようと思います。

もちろん会社の事業は順調です。黒字かつ実質無借金経営を継続しています。昨年はオフィスを引っ越したことが大ニュースだったのですが、今年のニュースは新プロダクトです。

新たにリリースしたのは、stera terminal(ステラターミナル)用のPOSレジ「コアレジ」。※stera terminalは三井住友カード株式会社の登録商標で、Panasonic製の決済端末です。

コアレジは、もちろん全て自社開発・自社運営。ポイントシステムCardfeelと共通の基盤で動作します。

コアレジは、ポイントシステムCardfeelと同様に小規模向けに見せていますが、エンタープライズ(大規模)を前提に設計。クラウド基盤はAWSを利用してフロントのAPIサーバー2台、一括処理のサーバー2台、データベースは3つのデータセンターを使ったモデルで、耐障害性に優れる構成を採用しています。

この手のプロダクトは、他社だと「高額な資金を投下してマーケットの独占を狙い、独占に失敗したら利益が出ないので撤退」というスタートアップならではの荒い運用が多いようなのですが、当社は大手企業からカスタマイズを受託しSIビジネスとしても成立させることで全体で利益を確保するモデル。

なので、撤退は視野に入れません。プロダクト本体の機能改善も短期勝負ではなく、時間をかけて丁寧に積み上げていきます。

ちなみにポイントシステムCardfeelは初回リリースから11周年を迎えました。超長期継続を前提に丁寧に運用しています。

長年に居着いたお気に入りのオフィスが手狭になったので、神田須田町から岩本町にオフィスを移転しました。最寄り駅は移転前と同じで、都営新宿線の岩本町駅からすぐ。JRだと神田駅と秋葉原駅のちょうど中間くらい。神田駅周辺は安価なランチが選びたい放題のランチ天国です。

せっかくなので新オフィスを紹介します。

【受付】

壁紙、会社ロゴ、照明で飾りました。照明のせいで少しレトロな感じになっているところが気に入っています。写真には写っていませんが、近くに高さ2m以上の大きなレトロ調ミラーを立てかけてあります。

【執務スペース】

数カ所に壁紙を張りました。デスクは創業時から使っている木製のデスクを追加購入。広さが確保できて快適になりました。

【会議室】

木目調のスチールパーティションで会議室を作りました。Web会議が多いのでエンジニアのデスクと同様、40インチ超のモニタを置いています。

【ネットワーク】

インターネット接続は10Gbpsの光回線「光クロス」を引きました。プロバイダーは固定IPが使えるぷららビジネス。接続方式はもちろんIPoEでOCNバーチャルコネクト 固定IP1です。

ルーター機器は3台。2重ルーターが2台なので冗長な気もしますが、50台超の端末を扱うので良好な選択かと思います。

インターネット接続に使うルーターはYAMAHA RTX1300。10ギガビット対応のコンボポートを2ポート備え、将来インターネット接続を複数回線に増やして冗長化できる優れたルーターです。定価は税別で20万円弱。今回のインターネット接続（OCNバーチャルコネクトで固定IP1）を高速に使うためには、これ一択でした。

（青い機器がヤマハのルーターです）

今回、このルーターが必要と分かったその日に近くのショップで購入し持ち帰ってすぐ接続を確認しました。いつもはネットで買い物をしますが、秋葉原から近いこの立地はやっぱりソフトウェア業にメリットありですね。RTX1300の内側にはBUFFALOのWi-Fi6E対応のフラグシップモデル(購入時)のWi-Fiルーター WXR-11000XE12を2機配置。片方は社内LAN用。片方はテスト機器用です。デスクの島に置くスイッチングハブは2.5Gまたは1Gのタイプ、LANケーブルはCAT.7を選択しました。CAT.6でもいいはずなのですが、機器によってはCAT.7のときだけ2.5Gの接続ができたという記事を複数見かけたのでCAT.7を奢りました。

そして、OA床下のLANケーブルは私1人で敷設しました。これはその時の写真。

つい「OA床のLANケーブルの敷設なんて簡単、あっと言う間」と言ってしまった手前、年甲斐もなく少々意地を張りました（笑）。ずっと屈んで作業するのでお尻のあたりが軽い筋肉痛になりましたが作業時間は2.5時間ほど。この作業のコツはタイルカーペットをはがし切らずに3割ほど残すこと。タイルカーペットはべったり糊が付いているので、完全にはがすと戻すときの位置合わせに苦労しますが、少し残せば簡単なのです。

さて、オフィスの移転はこれで4回目になります。移転するたび経営の節目を超えているような気がします。気を引き締めて今まで以上に良い会社にしていこうと思います。

セキュリティ強化の一環で、AWSのクラウドで運用している自社サービス（Cardfeel）と自社ホームページのサイトにWAFを導入しました。WAFはウェブアプリケーションファイアウォールの略で、Webサーバーに対する攻撃をWebサーバーの前面で防御する仕組みです。

今回のWAF設定はロードバランサ（負荷分散）に対して行いました。インターネットからのアクセスを複数のサーバーに負荷分散する前の入り口部分で防御を行うことになります。

WAFの役割は、脆弱性に対する攻撃からシステムを防御することです。代表的なSQLインジェクションや、クロスサイトスクリプティングの攻撃に対してはWebサイトのプログラミングを適切に行うことが基本なのですが、このWAFを使うことでサイトの入り口でブロックすることができるようになり、プログラムのセキュリティ対策に抜け漏れがあるケースに対してもセキュリティを強化できます。またWAFの効力は上記にとどまらず、アプリケーション層の DDoS 攻撃や不正なボットからのアクセスも含まれます。

【導入手順】
WAFは異常なアクセスを検出しブロックする仕組みです。例えばPOSTアクセスで一定以上のデータサイズがあると攻撃とみなしてブロックするルールがありますが、実際に大きなデータをPOSTする仕様の場合は、実際に使うサイズのPOSTはブロックしないようにルールを調整する必要があります。

具体的には次の手順になります。
①本番同様の試験環境を用意しWAFの設定を行います。設定はサイトの特性に応じて適用ルールを調整します。サーバー間の連携など相手が安全なことを分かっている場合は、アクセス元のIPアドレス単位でブロックしないルールを適用することができます。
②本番相当のアクセスを行い動作テストを行います。十分テストすべきは攻撃のブロックではなく本来の操作です。本来の操作がブロックされる場合はルールを見直します。外部連携を伴う業務システムがある場合は少なくとも全ての連携をテストします。
③テスト済みの動作を本番環境に適用します。
④一般に公開しているサイトなら少なくても1日に数件は攻撃（脆弱性のサーチ）に該当するアクセスがあると思います。AWSの管理画面から攻撃がブロックされていることを確認します。また、当然ながらサイトが本来の正常な動作を行っているかをウォッチします。問題がある場合はルールを調整します。

【コスト】
アクセスコントロールの登録に対して月額5ドル、1ルールあたり月額1ドル、100万リクエストに対して0.6ドルといったところです。設定の数やアクセス規模に対して料金が変わるのですが、サーバー全体の費用に比べてとても安価です。

参考：サーバーに対するリクエストのグラフ

グラフの一番低いところに少し現れるのがブロックしたアクセスです。

AWSの管理画面では、ブロックしたアクセスの詳細も確認できます。目立つのは脆弱性のあるサイトをサーチするアクセスです。例えば次はWordPressを狙った脆弱性のサーチ。よく見かけます。これに限らずWordPressを狙った攻撃は非常に多いです。

次はPHPのフレームワークLaravelの環境設定ファイルを狙ったアクセスです。このアクセスも多いです。この脆弱性をサーチするWebツールが存在しているのでしょう。環境設定はDBの接続情報が記述されることもあり、絶対に公開しないファイルです。しかしながら何かのきっかけで外部からアクセス可能になると攻撃されてしまいます。WAFがあればこのようにWebサーバーの手前でブロックしてくれます。

このAWS WAFは価格が安価であり導入も比較的短期間で行えます。新規に構築するサイトはもちろんのこと、既存のサイトに対しても適用をお勧めします。

コンポーネントデザインでは新規サイトはもちろん、既存のAWSのサイトへのWAF導入を実施致します。どうぞお気軽にご相談下さい。

ポイントシステム Cardfeel のお客様訪問で広島に出張しました。泊りがけの出張は久しぶりです。

広島は高校生のときの修学旅行以来。出張ついでに観光地2箇所に寄り道しました。

1箇所目はずっと行ってみたかった厳島神社。一部修繕中だったのですが、歴史を感じる素晴らしいところでした。

時間の都合で満潮のタイミングを逃したので、いつか必ず満潮を狙って再来しようと思います。

2カ所目は呉市の御手洗（みたらい）。瀬戸内海の美しい自然と古い町並みが一度に味わえます。

やっぱり瀬戸内海はいつ来てもいいですね。

今一番力を入れているプロダクトCardfeelは全国対応なので、チャンスがあればまた出張ついでに地方を回ってみたいと思います。

5月17日にポイントシステムCardfeelのリニューアル版をリリースしました。

※画像はCardfeelエンタープライズプランのWebサイトです

私たちは「プロダクト（ソフトウェア製品）の開発・運営」と「受託システム開発・運用」の両方の事業を並行して行っているのですが、プロダクトと受託システムの両方とも1つ1つ「渾身の作」を目指して本気で開発しています。このCardfeelも「渾身の作」です。

Cardfeelは受託システム開発を含めて私たちにとって最大級のシステムです。たとえばデータベースのテーブルは適切に設計した状態（つまり無駄にテーブルを増やしていない設計）で72テーブル。項目数は合計で1,000を超えます。開発は3年超、旧バージョンからの移行やリリース準備を含めると丸4年の期間を掛けました。

私たちはCardfeelのリニューアルにあたり、過去数年にわたるCardfeelの前バージョンの開発・運営や、大手ポイント事業者様から受託したポイントシステムのエンジン部分の開発、多数の企業様から受託したアプリ開発などで学んだことを踏まえ、ポイントシステムのあるべき姿を追求し一から設計・実装しました。

Cardfeelがどのように「渾身の作」なのか、どこを頑張っているのかをいくつかご紹介します。

①厳格なポイント操作

ポイントシステムの扱うポイントはお金に近しい概念ですので、金融機関と同様の厳格な設計・実装を行いました。金融系のシステムでは当然ではありますが、『すべてのポイント操作は成功か失敗の何れかであり中間はない』（アトミック性と言います）という設計に基づいています。また、同時並行でポイント付与の一括処理や店舗アプリ、管理画面からのポイント操作が行われても、安全に残高を更新し確実に履歴を残す設計としています。

②複数のポイント種類に対応

大手のポイント事業者は複数のポイントを並行して運用していることをご存知でしょうか。例えばお買い物に対して通常ポイントが付与されるほかに、何かのイベントで期限付きのボーナスポイントが付与されたりします。また、ボーナスポイントは利用できる店舗が限定されることもあるかと思います。これはポイントを戦略的なマーケティングツールとして活用するためです。もらったポイントが特定の店で使えるなら、その店への送客効果があるのです。

Cardfeelは、同時並行で複数のポイント種類を運用できるようにしました。ポイントの有効期限は「獲得のX年後の年末まで有効」や「ポイント操作毎に自動延長」など複数のタイプを用意。ポイント種類毎の利用可能店舗は店舗をグルーピングしたうえでグループ毎に設定できます。企業のマーケ戦略の一環として、運用開始後にポイントの種類を増やし、その企業ならではのポイント施策を実行できるようにしています。

③過去の計上データを投入可能

前月までの過去日時を指定したポイント操作を可能としました。指定された過去日時から現在までに別のポイント操作が行われているとき、そのポイント操作は一度巻き戻して再計算する仕組みです。例えば過去データの追加投入で会員ランクに変動がある場合、投入後の正しいランクでポイントを再計算します。システム間連携を行う場合、障害対策を考慮する必要があるのですが、障害復旧が数日遅れてポイント操作が数日遅れた場合でも正しいポイント付与を行えます。

購買金額や獲得ポイント数により会員ランクが決定し、会員ランクによりポイント付与レートが異なるシステムの場合、障害対策を考慮するためにランク決定は判定期間が完了してからとするシステムが多いのですが、これでは顧客の気持ちが離れてしまいます。やはりランクアップは速やかに行って顧客の心を獲得すべきです。Cardfeelは前述の過去データ投入を可能にすることにより、理想的な運用ができるようにしました。

④大量のプッシュ通知に対応

Cardfeelには条件指定により（もちろん全員宛も可能です）ニュースやクーポンを発行でき、また発行時にプッシュ通知を送信できます。プッシュ通知は短時間に大量の送信が可能なように、送信ロジックを自作しています。（正確にはApple社、Google社のサーバーを経由します）

短時間に大量のプッシュ通知を送信し利用者がそれに反応してアプリを操作すると、会員アプリは表示すべき情報を取得するために、サーバーを呼び出します。Cardfeelでは、処理が遅延しアプリのレスポンスが悪化しないようにサーバー側の仕組みを最適化して、より負荷を低く保つようにサーバー処理を実装しています。これによりCardfeelは大量のアプリ会員に対して、より低いランニングコストでの運用を実現しています。（低コストについては当社比ではありますが、自信がある部分です）

以上、Cardfeelが「渾身の作」と言える理由をいくつか紹介しましたが、他にも沢山の特徴を備えています。それはまた別のブログ等で紹介致します。

システム開発では、特に提案・見積もりや要件定義などで開発するシステムの内容を決める際に繰り返し打合せを行います。

最近の打ち合わせはオンラインミーティング主体になっているのですが、コロナ感染症が下火になっている今だけは、受注前や要件定義段階のお打ち合わせはお客様にご希望頂ければ、対面を優先するようにしています。

受注前や要件定義段階の打ち合わせは、現状の業務やシステム化の目的、どのようなシステムを想定しているかなどをじっくりヒアリングしたり、それを受けて検討した提案内容を説明したりします。この打合せは複雑な内容が含まれることも多く、そうでなくても常に100%伝わるものではないので、非言語のニュアンスも含めてコミュニケーションの質を大事にしたいのです。

たとえば、私が技術的なことを説明するとき、ほぼ理解できたが少しだけ不明瞭なところがあるときは、お客様は少しだけ不明瞭だということを、表情や声のトーンで表現して頂けることが多いと思うのです。私はそれを受けて、説明し直したりその後の説明内容を調整したりすることができるわけです。

コロナ感染症については、次の波が来てしまったらやはり対面は難しくなってしまうので、オンラインでも打ち合わせ回数を増やすとか、打合せ資料を丁寧に作るとかの手法で頑張るしかないわけですが、やはり波が十分低い状態で収まることを願いたいと思います。そして波が低い間はお客様のご希望次第で対面を優先したいです。

ところで、オンラインの打ち合わせは往復の時間を節約できるので、気軽に声をかけて頂くことができるメリットもあるのかとは思います。特に自社製品の初回の概要説明は、作りこんだ資料もあるので、気軽に声をかけて頂いてオンラインで説明させて頂く方法がよさそうです。ある程度、お客様に適合することが分かってきたら、次は（お客様が希望頂ければ）対面で打ち合わせする手順になると思います。

対面とオンライン、うまく使い分けてコロナ禍であってもビジネスをより良いものにしたいです。