もう半年ほど前になるのですが、ランチタイムを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%伝わるものではないので、非言語のニュアンスも含めてコミュニケーションの質を大事にしたいのです。

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

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

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

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

最近は朝のスキマ時間を趣味に割り当てています。趣味といっても少しやって飽きると次の趣味に移る感じなのでユルめです。

今のマイブームは朝食のオムレツづくり。

ホテルの朝食等でコックさんがフライパンをトントンと叩くとオムレツがクルっと回る職人芸がカッコイイなと。

YouTubeでコツを紹介する動画を見ながら練習しました。

作ったときは上出来と思ったのですが、写真にするとアラに気が付きますね。。一応中身のトロっとした具合は好みどおり（笑）

朝食はトーストと牛乳程度で十分と思うタイプだったのですが、最近はオムレツにほうれん草やソーセージを炒めたのを中に入れて具沢山にするのが気に入っています。

ちなみに、オムレツの前のマイブームはぬか漬け。気に入っていた具材はきゅうり、茄子、オクラ、ゆで卵、アボカド。これは美味しかったのですが、数日サボるとぬか床がダメになるのがどうにも厳しくやめてしまいました。また気が向いたら始めようかとも思うのですが、ぬか漬けは美味しくなるまでに一苦労なのですよね。

3年かけたプロダクト、ほぼ実装が完了し、まもなく完成へ向けた最終段階へ入ります。リリースはこの秋冬の予定。長かったです。

開発中に削った機能もいくつかあるのですが、満足できる内容に仕上がってきています。

3年ほど前のブログに掲載したDBのダイアグラムは、設計を進めた結果、倍くらいの規模になりました。(前回と同様にテーブル名を隠しています)

リリース後はPMF（プロダクト・マーケット・フィット）を目指した改善を続けます。

コロナ禍、一時的に一部の売り上げが下がったものの、現在は受注状況も開発実行も問題はなく、無事に事業を運営できています。ただ、3月末に導入したテレワークは現在も継続中でオフィスはガランとしています。

技術の会社だから当然なのですが、テレワーク移行のテクニカル面は容易でした。ソース管理はもともとクラウド上に設置したGitを利用していたので何もすることがなく、社内のファイルサーバーは、適切にセキュリティ設定を行ったクラウドストレージに移行。社員間で共有・更新するタイプのファイルはGoogleスプレッドシートを使っています。

逆に危惧したのはコミュニケーション面。いまのところは社員の協力で良好な状態を保っています。選択したテレワークのコミュニケーション方法はWeb会議とメールのみ。コミュニケーションが偏らないように、メールは本文に宛先を書いてプロジェクトチーム全員宛に送るルール。

少々変わっていると思うのですが、社内連絡の電話は原則禁止にしました。Web会議を使って情報の共有を図っています。

さて、このタイミングで求人をやります。数ヵ月後に展開する新しいプロダクトには、新たな力が必要なのです。社会全体の景気を考えると時期尚早なのでしょうが、雇用は微力ながらも当社ができる社会貢献。コロナ禍で求人数は減少し、求職者数は増加しているので、普段は出会えない方と出会えるのではないかと、実は少し期待しています。

面接はオンラインを基本にしますが、最終面接は直接お会いしようと思います。できることはやっておこうと会議室の会議テーブルに飛沫感染対策用の透明アクリルパーティションを設置しました。サイズは少し大きめの横600mm、縦700mm。写真のとおり2枚並べました。TV番組で知ったのですが、飛沫感染対策のアクリルパーティションは、高さが大事なのだそうです。