新着記事

仕事をスケジュールに沿って進捗させるために「完了」の条件をチームで共有する

開発者は、日々進行する業務を「タスク」や「課題」「イシュー」という単位にして、管理します。

ディレクションチームから、新たな機能開発の課題が生まれた時、それを課題トラッキングツールに作り、完了になるまでその業務をすすめていくことになりますが、この時ディレクションチームと開発チームで「完了」状態のイメージを揃えておかないと、この課題だけではなく、その次の課題の進捗にも遅延が発生します。お互いに、「完了」とは何かをより具体的にイメージしておくことが、開発をスムーズに進めることに繋がります。

「完了」とは何か

完了の定義は組織によって少しずつ変わってくるものだと思いますが、私が開発者に強くイメージしてほしい完了のイメージは、「もう作業をしなくていい状態」です。その課題に対して、もう何も考えなくてよくなったら、その課題は完了しています。

開発の進め方として

  1. 何か業務課題が見つかる
  2. 業務課題を解決させるために開発課題が生まれる
  3. コードを書いてテストする
  4. プルリクエストしてレビューする
  5. レビュー指摘箇所を直してマージする
  6. 検証環境に反映する
  7. 検証環境で動作検証し、不具合箇所の修正や調整をする
  8. 本番環境にリリースする
  9. 本番環境で動作検証する
  10. ディレクションチームに説明する

チーム編成や動作環境・開発手法の違いにより細かい所で違いはあると思いますが、おおよそこのような流れになります。

この中で、開発者は2-10まで担当することになると思います。動作検証に関しては、専用の検証チームや外注がいるかもしれませんが、検証中は開発者がのんびり待ってるわけでもなく、発見された不具合箇所の修正をしたり、サーバ側のデータを見て動作の確認をしています。

見積もりとタスク量

1. で業務課題が見つかり、2. で開発課題が生まれた時、ディレクションチームは業務課題の解決のために必要なコストの見積もりをします。コストの多くは開発時間で、開発には仕入れや材料が不要なため、単純な時間コストだけ聞く場合がほとんどです。「どれぐらいでできる?」と聞いてくるやつです。

その時、開発者は完了の状態をイメージしますが、そこでイメージするのは、多くは 3. が終了し、4. プルリクエストを出すタイミングでしょう。実際にそれで問題無い組織環境もあるかもしれませんが、TORICO や私がいままで所属していた企業では、「プルリクエスト出したら完了」とイメージするのは、関係者の考えている完了とは一致していないため、危険です。

ディレクションチームの完了条件

ディレクションチームが考える開発の完了した状態というのは、「開発成果が業務課題の改善に対して効果を発生し始める」時です。つまり、本番反映が終わりお客さんが使える状態になっている状態、ということです。

ディレクションをしている方は、開発者に「どれくらいでできる?」と聞いた時に「3日」と回答をもらったら、念の為に一度「開発着手してから3日で、お客さんが不具合なく完全に使える状態になっているか」を改めて聞いたほうが良いでしょう。開発者もそれを汲み取って、「本番環境で完全に動作する」と保証できる日程を答えなければなりません。必要以上に急いだり背伸びをする必要はな無く、大事なのは「本番環境で完璧に動作し、業務課題の改善に効果を発生している」状態を作ることです。そして、その状態にするためにどれだけの時間コストがかかるかの意識をなるべく正確に共有し、遠慮せずに伝える必要があります。

開発者の次の課題

コードを書いてプルリクエストを出した所で、開発担当者は一旦の区切りとなるため、そこまでを開発期間とイメージしがちです。わかります。実際はプルリクエストを出したら次の開発課題に着手することになると思うので、実際そうとも言えます。

ただし、次の開発課題を始めた後も、前の課題進捗は進むため、レビュー指摘箇所の直しだったり動作検証の不具合修正だったりで時間を使います。その対応を行っている時は、新しい開発課題は停止するので、新しい開発課題についても概ねのスケジュールを伝えているとしたら、遅延の原因になります。

別のタスクの開発時間を奪うような状態の課題は、「完了している」とは言えません。

そのため、「開発課題の完了」とは、その開発課題について何かを考慮することが無くなり、新しい開発課題に全力で集中できる状態をイメージすると良いでしょう。

本番環境て完全に動作する

さきほど、本番環境で完全に動作すること、ということを完了条件とする、と書きましたが、「完全に動作する」という文言に嫌悪感かある開発者もいるかもしれません。Windowsにも脆弱性があり修正パッチが月に何度も出ている、だから完全なんて保証できるものではない、という実例を話したくなるかもしれませんが、そういうことではないんです。本番リリースしたコードに不具合などのリスクがあることは、チーム全員もう知っています

そうではなく、本番リリースにあたり自分の責任範囲でやることを全部かったか?ということを考えてほしいのです。もし、そこで「本番環境特有のある条件下でのある動作が検証できておらず、不安がある」と感じているのなら、検証するかチームに共有してください。リスクと時間を考慮して、チーム全体で対応策を考えられます。それらの細かい残件の対応を行い、もう確認すべき所は無い状態になり、「残課題はありません」と胸を張って言える状態が、もう作業をしなくていい状態であり、完全に動作する(かもしれない)状態です。機能リリースにはリスクがあり、不安があるかもしれませんが、検証を十分にやっているなら、具体的な理由のない不安は考えるだけ時間の無駄です。ダメな所がなければOKです。気にせず早くリリースしましょう。

実際のタイム感

おおよそですが、ウェブサービスの開発の場合は、プルリクエストを行うまでが、実際の開発進捗の半分ぐらいのイメージで良いと思います。コードを書きはじめて、プルリクエストまで3日だったら、検証と調整と本番リリースであと3日ぐらいかかる感覚です。

逆に、リリースしたい日がすでに決まっているのであれば、開発着手からリリース日までの半分のあたりで、一通りコードが書き終わってないといけません。リリース直前にコードが書き終わるイメージをしているのであれば、その開発課題のリリースは遅延します。

予定通りに完了できなさそうな時どうするか

完了タイミングを関係者に伝えているにもかかわらず、予定通りに計画が進まずに、進捗が遅延しそうな時はよくあります。

特にアプリケーション開発は、予期しない計算(計画)の連続であり、現代のアプリケーション開発で開発終了時刻を正確に見積もることは、正直に言うなら困難です。

現代のアプリケーション開発は、業務が十分に抽象化(自動化)されている現場であれば、作業時間を見積もれるような定形作業はまずありません。

もし、開発作業内に定形作業があるとすれば、それはロボット(スクリプト)にやらせることだからです。

アプリケーション開発というのは、誰もやっていない新しい課題への挑戦です。具体的には、他の開発者が開発したコードを目的のために計算して組み合わせ、求める計算結果を出させ、それを出力し記録する。というのがおおまかな流れです。他の開発者が開発したコードが、今求めているビジネス領域にどれぐらいマッチするかは誰もやったことが無く誰にもわからないため、未来に発生するトラブルを事前に知ることは不可能です。それどころか、ビジネス課題を解決するプロダクトの完成イメージさえ、開発着手時には十分決まっているわけではありません。コードを書いて、動作をチーム全員で試してから、ブラッシュアップしていくのが現代のアプリケーション開発です。

アプリケーション開発が実際にどのようなものか、未経験者に伝えることは難しいですが、例えば問題集のようなものだと考えています。達成するには全問正解する必要がありますが、問題集を開くまでは中にどのような問題が書かれているかはわからず、設問自体が自分の理解できる言語で書かれていない可能性もあります。ただし、問題集の厚みだけは見えます。その問題集を全問正解するまでの時間を、開発者は毎回見積もります。なので、見積もりはけっこうテキトーですし、楽観的に答えがちな人、悲観的に答えがちな人など、答え方に個性も出ます。(もし、それと似た問題集を解いたことがあるようであれば、似た問題集を全問正解するための見積もりはしやすでしょう。)

アプリケーション開発は、実際に書き始めてみないと難易度を理解するのは難しいため、開発途中で未知のトラブルに遭遇したり、方針の変更により、予定通り完了できない時もよくあります。

長期の開発案件でプロジェクトが予定通り進んでおらず、途中から助っ人を追加するとしたら、追加する人をよく考えて選ばないといけません。作業者より上位の人(部署リーダー等)であれば、大抵はうまくいきます。同僚の場合、(通常は別の課題を担当しているなどで) 現在の具体的な課題まで把握できていないとしたら、情報共有だけで1-2週間かかりそうです。実状をまったく知らない部外の開発者であれば、現状把握に1-2ヶ月程度かかることも考えられます。新規参加メンバーに情報共有をする場合、教えられる側はもちろん、教える側も大きな作業工数がかかりますので、新しい人を参加させ、開発のスタート地点に立たせるだけで大きな時間を使いますし、もし新規参加の方であれば、実状を把握してコードを書けるようになってから、支払った時間を回収できるだけの成果を出すことは非常に難しいです。

そのため実際にスケジュールの遅延がありそうな時は、スケジュールの計画を関係者で共有し、現行のメンバーで問題無い品質を達成するまで開発し続けるのが、おそらく最も合理的です。

予定通りに完了できなかった時にどうするか

次回の見積もり時に今回の反省点を活かした見積もりをするのは当然として、開発者はどうすれば早く開発できるかを常に考えていかなければなりません。自分の実力が 100 として、今回の開発は 99 しか出せてなかったのではないか? を自問自答してみて、 99 だったかも…ではだめです。 100 出せなかった原因を取り除き、次回は 100 を出してください。

最後に

開発課題の「完了」とは、「もう作業をしなくていい状態」であり「開発成果が業務課題の改善に対して効果を発生できる状態」です。

実務経験で出会った便利なあれこれ

新卒エンジニアとして半年間働いてきて、現場でさまざまなことを勉強させていただきました。その中でも、もっと早く知っておきたかった便利なツール、Python の書き方など、幅広いあれこれを記事にしたいなと思います。

あれこれ、というざっくりとした括りになってしまっているのでまずは紹介したいものを示しておきたいと思います。

  • git submodule
  • Fabric3
  • Flake8
  • Python
    • 型ヒント
    • 整形文字列 f-string

git submodule

git submodule とは、git のレポジトリをサブモジュール化して複数のプロジェクトで共有することができる機能のことです。これを使うことで一度開発したコードを別のプロジェクトで簡単に再利用できます。例えばTORICOでは、 TORICO-ID のソーシャルログイン機能や決済機能だけでなく、ユーティリティ関数などを Django, Vue, Flutter それぞれのフレームワークでまとめたレポジトリが用意されてあります。

導入も至ってシンプルです。プロジェクト内で

git submodule add <リポジトリURL> <インストールパス>

たったこれだけで、今まで開発してきたコードを再利用することができます。わざわざプロジェクト間でコピペをしてくる必要はありません。さらに、git submodule はバージョン管理もしてくれます。サブモジュールを更新しても影響があるのはそのプロジェクト内だなので安心してサブモジュールの改良をすることができます。

1点注意として、submodule はメインのプロジェクト内で git clone や git pull を行っても自動で更新されることはありません。そのため、

git submodule update (初回のみ -i オプションで初期化)

コマンドを忘れずに実行する必要があります。

Fabric3

こちらは Python のモジュールの一つで、所定のアクションをコマンド一つで呼び出すことができます。例えば、デプロイするときの一連の流れを Python コードにしておくことで、ターミナルに fab deploy と入力するだけでその流れを自動で行ってくれるようになります。流れは以下のように記述します。

env.hosts = ['app1.sample.com', 'app2.sample.com']
def deploy():
    #  通知などを行う
    slack_announce('deploy')
    with cd ('/var/src'):
        run('git checkout master')
        run('git pull origin master')
        run('git submodule update')

このように一連の流れをコードとして残しておくことで、それをコマンド一つで呼び出すことができるようになります。さらに、新規に加入したメンバーでも簡単にデプロイができるというメリットがあります。その環境に慣れていない人が、例えば git submodule などのコマンドを忘れる心配もありません。また、私のような実務経験の無い人でもコードを確認することで流れを理解することができます。

TORICO では上記の git submodule を使ってほぼ全てのプロジェククトに deploy, ssh, flake8(後述), dsh (docker 環境にSSH)のコマンドが用意されています。

Flake8

こちらも Python のモジュールで、自動でコードレビューをしてくれます。導入は pip でインストールするだけです。実行は flake8 コマンドとオプションをターミナルにします。

flake8 --exclude="*migrations/*,venv/*,.venv/*,~* .

flake8 result

すると、このようにコードレビューをして規約に反する部分を教えてくれます。規約コードも教えてくれるため、わからない部分は検索できるようになっています。また、どうしても諸事情で変更できない場合は

from django.contrib import admin  # NOQA: F401

とコメントをつけることで、指定した規約コードの違反を行単位で無視させることもできます。

TORICO では毎回オプションを入力するのは面倒なため、上の Fabric3 を使って実行を簡単にしています。

Python 型ヒント

Python3.5 から導入された機能で型ヒントというものがあります。これは引数や帰り値の型をコードに書くことで可読性を向上させることができる機能です。

def hello(name: str) -> str:
    return f'hello, {name}.'

型ヒントはあくまでも補助的な役割のため、宣言とは異なる型を渡したところでエラーになることはありません。ただ、PyCharmでは型ヒントとは違う型を渡すと警告をしてくれます。可読性が飛躍的にあがるので、ぜひとも書くことを癖にしたいなと思っています。

Python F文字列

上の例でもしれっと使っていましたが、F文字列を使用することで .format 部分を短縮することができます。さらに、f文字列では変数だけでなく式なども使用できます。

print({a} + {b} = {a + b})  # format では a + b はエラーになる

format で記述するとコードが長くなる傾向があるので、スッキリと書けるf文字列は積極的に使用しています。

最後に

今回は現場で知った便利なあれこれを記事にしました。個人で勉強をしているとフレームワークや言語の知識は増やせますが、運用に関わる部分はなかなか知ることができないと思います。便利だなと思ったら、ぜひ積極的に使用してみてください。

新卒エンジニアが今になって就職前にやっておけば良かったと思うこと3選



就社してからは初めてのブログ投稿となります。
お久しぶりです。開発部の鈴木海人です。

株式会社TORICOにエンジニアとして入社して、半年が経ちました。
今回のブログでは、過去の内定をいただいてから入社までの間に対して何もしなかった自分に対して
入社までにやっておいたほうがいいことについてまとめました。
過去の自分のような過ちを他の人が犯さないようにまとめましたのでエンジニア内定をもらって何をすればいいかわからない人はぜひ参考にしてみてください。



私の簡単な経歴はこちら↓
都内私立文系大学卒業
大学3年時の夏に某大手プログラミングスクールに通い、プログラミングの基礎について学ぶ
スクール卒業後、都内のスタートアップの会社で2ヶ月ほどインターン(作業内容は主にLPの作成を行っていました)
大学4年時は就活を行い、株式会社TORICOに内定をいただき、今に至ります。



注意事項
簡単なコーディング知識があることを前提にお話しします。もしプログラミングが全くわからないという人はprogateなどのプログラミングを簡単に学べるサイトでまずは学びましょう。



それでは本題に戻ります。
まず結論からお話しします。以下の3つになります。
  1. タイピング強化

  2. 会社で使用する言語の参考書を1冊読んでおく

  3. ドキュメントで調べる癖をつける





それでは1つずつ説明していきます。

1.タイピング


これはどんな人でも絶対にやっておきましょう。
目安としましてはe-typingで安定してA以上や寿司打で1万円コースクリアでしょうか。
上記のサイトですと日本語入力ですので英単語を打つようなサイトを探してみてもいいかもしれません。
僕は入社してから、過去タイピング練習をしてこなかったことを最も後悔しています。

タイピングを強化しておくメリットには下記が挙げられます。
  1. 仕事スピードが上がる
  2. 成長スピードが上がる
  3. 教えていただいている時の時間を少なくできる


考えてみれば当たり前なのですが、タイピングスピードが2倍になればかけるコードも2倍になり、そのため成長スピードも2倍になります。
逆にタイピングスピードが1/2倍になればかけるコードも1/2倍になり、そのため成長スピードも1/2倍になります。
もはやエンジニアにとって一番重要なのではと思っています。
もちろん最初はコードを書くことよりも調べたり読んだりする時間の方が長いので、タイピングスピードの恩恵をあまり受けられないかもしれません
しかし後々大きく影響してくるので鍛えておきましょう。
後、単純にタイピングで遅くてミスりまくると恥ずかしいです。
1日10分とかでもいいので毎日タイピングの練習をするのがおすすめです。私も練習中です
タイピングに慣れてきたら数字や記号などもしっかりと打ち込めつように練習しましょう。

また少し話はタイピングから話がずれてしまうのですが、
よく使用するショートカットキーの暗記やカーソルの移動スピードmaxなどの使いやすいPC設定も行っておきましょう
こちらもPCを使う上での基礎スキルとなり、使っているか使っていいないかで作業効率が大幅に変わるので意識してみてください。






2.会社で使用する言語の参考書を1冊読んでおく


参考書を読むというのに抵抗感がある人は多いのではないでしょうか?
実際僕もそうでした。ネットなどで調べてみると「ネットに全部載っているのに本を買う必要はない」、「わからないことはその都度ググって調べればいい」など
本に対しては比較的、良い情報が流れていないようなイメージが僕にはあります。
これは私の上司から教えていただいて、確かにとなったのですが、本は体系的(一つ一つのものがある系統に従ってまとまっているさまのことという意味みたい)になっているため正確な情報をしっかりとインプットできるのです。
今までとりあえずわからなくなったらググってを繰り返していたのですが1通り本を読むことにより、もちろん完全暗記はできませんがコードを書いているとき、あれが使えるかなとか、それが出てこなくても
調べて出てきたメソッドなど、そういえばこんなのあったなと思い出せます。
また、おすすめの参考書なのですが
私の上司のおすすめの参考書はとりあえず分厚い本みたいです。。。
残念ながら優しくて短い本では情報量が少なすぎたりであまりお勧めをしていないようです。
参考書を買うときは分厚くて情報量の多い参考書を選びましょう。
こちらもタイピングと同様少ない時間でもいいので移動時間などを活用して少しずつ読み進めましょう。






3.ドキュメントで調べる癖をつける


皆さんはドキュメントで調べ物をしていますか?
僕は基本的にQiitaだったり個人ブログなどを参考にすることが多いです。。。
わかりやすいですよね。。。
なるべく意識はしていますが今でもあまりできていないのが現状です。
ドキュメントで調べる癖をつけた方がいい理由は、正確な情報が手に入れられるからです。
調べ物をしているとき正確な情報じゃないことや、記事が古く参考にならなかったり、バージョン違いで動作しなかったりと
結構クソみたいな記事が上に表示されることはあるあるではないでしょうか
ドキュメントで調べる癖をつけておくと正確な情報を手に入れることができるのはもちろんなのですが
英語で文を読む癖がついたり、英語で調べたりする癖がつくのでためになると思います。
日本語検索とは比べ物にならないほど英語の情報は出てくるので、英語めっちゃできるぜ!って感じを目指さなくてもいいですが
グーグル翻訳を使いながらでも少しずつ調べ物ができるようになると良いです。
プログラミングをしている人にとって英語は切っても切り離せない関係なので
早い段階で慣れておきましょう。





以上3つが私が入社前にやっておけば良かったことになります。
最後にもう1度
  1. タイピング強化

  2. 会社で使用する言語の参考書を1冊読んでおく

  3. ドキュメントで調べる癖をつける



重要順は上から1.2.3となります。
ぜひエンジニアに、これからなる人なりたい人は参考にしてみてください。




ビジネスサイドに知ってほしいエンジニア用語

今回の記事は新型コロナウイルスの影響で普段リモート開発をしていて浮き彫りになった問題点の1つとして「開発側と運用側でコミュニケーションが難しい時がある」といったものがありましたので、その原因として考えられる「IT専門用語が難しくしている」に焦点を当てて、業務中に発生した知ってもらえたら嬉しい用語を(個人的頻出度で)紹介していきます。(かなり噛み砕いていますので厳密で完璧にあっているものではないものもあります)




  1. デプロイ
    頻出度第一位は「デプロイ」です。ほぼ毎日slack上で打ち込んでいる気さえしてくる単語です。開発側が作った制作物を他人にも見てもらえるように反映することです。英和辞書などで調べると「配置する」といった意味がでてきますが、このままだと日常会話で出てくることもないでしょうし、直感的に理解することが難しいですね。もし自分がエンジニアをしていなく、デプロイと聞いたらどこかの国がミサイルでも配置しているのかと思ってしまうでしょう。


  2. 本番環境 & 検証環境
    1位のデプロイと関連しまして、よく使う定番フレーズが「本番環境にデプロイしました。」とか「検証環境にデプロイしました。」です。環境の単語がイメージしにくいのではないでしょうか。
    環境は目に見えるものではないので、得体の知れないところにデプロイしましたと言われたところで「どこか知らないけど、反映したことはわかったで。」のような感覚かと思います。この文脈でいう「環境」はサービスが動いているサーバーのことです。本番環境は実際にユーザーが見るサーバーで、検証環境はつくったサービスをいきなり公開にするのは怖いので、社内向けへの確認や動作の確認をするためのサーバーです。
    別名で本番環境はプロダクション( Production )環境、検証環境はデベロップメント( Development )環境やステージング( Staging )環境と呼ばれることもあります。

    ここまでで、もし「プロダクション環境にデプロイしました」というフレーズを聞いたらそれは「ユーザーが使えるように反映した」のような意味です。


  3. サーバー & サーバーサイド
    こちらは「サーバーが落ちた。」などで聞くと思われます。「サービスが動いている場所」のような感覚でなんとなくわかるけど、具体的にはよくわからない言葉ではないでしょうか。

    サービスが動いている場所というのは間違っていないですが、サーバーは英語の[ Server ]から来ており、給仕する人という意味で何かを給仕しているのですが、特定のものに限定されません。アプリケーションを動かす役割をサーブ( serve )していればアプリケーションサーバーで、データベースの役割をしていればそれはDB( データベースサーバー )です。そしてこの例のようにアプリケーションとデーターベースのサーバーが分けられていることもあれば1つのサーバーが両方を兼ねていることもあります。

    「サーバーが落ちた。」というのは何かしらの役割を給仕できなくなった状態です。

    そしてよくサーバーサイドとクライアントサイドのようなフレーズも見かけるかもしれません。ネットサーフィンしている私たちはクライアント(客)としてサービスを給仕されているのでサービス使用者はサーバーサイドに触れることができません。

    サーバーサイドエンジニアはユーザーが触れることができない箇所を開発しているエンジニアです。代表的なサーバーサイドを開発するプログラミング言語ではPHP、Ruby、Python( 当社で使用しているメイン言語 )があります。


  4. クライアント
    クライアントはつまりユーザーのことです。ですがユーザーは人間なので上記のサーバーから来たものを受け取ることもできません。なのでここでいうクライアントはブラウザやスマートフォンのことです。ブラウザとはSafari、Chrome、Firefox、Microsoft Edgeなどで、スマートフォンでは主に知られているのがiOSで動くiPhoneとAndroid OSを載せたものです。それぞれ動作は同じではなく、違いがあります。

    ブラウザではサーバーから受け取ったものを解釈してそれを表示するようにしますが開発に主に使用されるプログラミング言語はJavaScriptです。またスマートフォンではiOSならSwift、AndroidならKotlinなどがあります。当社ではブラウザ側ではJavaScriptのフレームワークNuxt.jsとスマートフォンではiOSとAndroid両方同時に開発できるFlutterを採用しています。


  5. Cookie (クッキー)
    業務でなくとも、プライベートでネットサーフィンをしていれば、途中で見かけた人も多いのではないでしょうか。もちろん、甘くて美味しいお菓子のクッキーではありません。そもそもこのCookieは何のためにあるかといえばユーザーの情報を覚えておくためにあります。そしてその保管場所です。

    本来はネットサーフィンをしていてもあなたのことをサービスは判断できません。ユーザーAさんがまた同じサイトに訪れてもAさんということはわかりません。データベースに情報を保存してあっても誰かわからないので何を返してよいかはわかりません。つまりCookieがないとあなたが大好きなAmazonでショッピングカートに商品を入れても、カートの商品はそのまま入ったままではいてくれません。それでは困るので、初回のサイトへのアクセス時に使っているブラウザ( SafariやChromeなど )にCookieをサイトは仕込み、今後はCookieが送信されサービスはそれを頼りにあなたを認識してくれます。

    他にもあなたが気になる商品の広告が出てくるのもこのCookieが原因です。


  6. セッション
    上のCookieでユーザーを認識してくれると書きましたが、Cookieはサーバーにアクセスした時に持っていれば自動的に送られるデータです。
    先ほどの例につづき、ショッピングだったら、何の商品をカートに入れたかを認識するためにあるのがセッションIDです。これがあなたのブラウザのCookieの中に一部として入っており、サービスを利用しているとセッションIDがCookieごとサービスに密かに送られ、サービスはセッションIDを元にしてカートに入れる、外す、購入するなどの利用状態( セッションデータ )を判断しています。

    そして例えばログイン済みのユーザーがログアウトすると、以後、利用状態を追いかける必要はないのでセッションIDは捨てられます。この一連の流れをセッションという単位で表します。個人を認識するための値なのでこれはセキュリティの観点からもれては他人に知られてはいけません。

    開発中に当社のサービスの1つでイベント申し込みをしたのに申し込み済みになっていない。というケースがあったのですが、こちらのセッションが切れているので申し込みをしたユーザーだと認識できていないことが原因でした。


  7. Cache (キャッシュ)
    こちらも普段、ネットサーフィンをしていれば、見かけたことがある言葉かもしれません。
    業務ではよくある問い合わせで開発側が「デプロイしました。」と反映したが運用側では「確認したのですが、変わっていません」です。これはキャッシュが悪さをしているかもしれません。( キャッシュは悪いやつではありません )。

    インターネットを利用する上で、同じサイトにまた行くというのはかなりよくあることだと思います。例えば写真が多いサイトは読み込む写真が多いので当然、完全にページを表示するのは文字だけのページと比べれば遅いです。そこで自動的にページの一部のデータを保存しておき、また来た時に、それを利用し早く表示するということをやっています。それのデータの保存場所がキャッシュです。

    なのでページの表示が変わっていないというのはこのキャッシュにためられた古い情報を使うとしていることが原因になっていることがあります。なのでブラウザの設定各種からこちらを消せば解決することがあります。

    本質的には一度した処理を保存しておき、効率的に再度利用するためのものなので、今回のテーマはビジネスサイドなのでブラウザのキャッシュを取り上げましたが、他にもコンテンツキャッシュサーバーやクエリキャッシュがあります( 興味があれば調べてみてください )


  8. AWS
    AWSはAmazon Web Serviceの略称です。Amazonと聞くとどうしても買い物のAmazonや電子書籍のKindle、映画のAmazon Premiumを想像すると思いますが、実はWebサービスのインフラ( 基盤 )をネット上( クラウド )で提供しています。

    AWSはサーバーをネット上使えるEC2というサービスや、データベースのRDS、世界各地に置かれたコンテンツキャッシュサーバーの集合のCDN( Content Delivery Network )であるCloud Frontというサービスなどを提供しています。それを利用することで場所にとらわれずにサービスのインフラを構築することができます。

    逆にオフィスにコンピューターを冷却するスペースを用意し、実際に現物のサーバーを購入したりして、設置する方式はオンプレミスと呼ばれたりします。




番外編

  1. hoge
    たまにエンジニアがデプロイしました。と言い確認してみると次の言葉を見かけることがあるかもしれません。こちらはエンジニア達の中では有名なダミーテキストです。実際に使用できる形を想定したデータを用意しお見せするのがいいのですが、もし見かけてもこれはふざけてやっているわけではない可能性が高いです。

  2.  lorem ipsum
    こちらもよく使われるダミーテキストです。ダミーテキストなので意味は特になく、仮置きに使われます。少し長めのダミーテキストであり、一般的には

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

    として使用されることが多いです。


今回はビジネスサイドに知って欲しい用語を技術的な部分には触れない範囲で紹介してみました。これでみなさんのプロジェクトでのコミュニケーションがより円滑になる助けになれば嬉しいです。また需要があれば更新もしくは続編を出すかもしれません。それでは良い開発ライフを。

10年に一度巡る雑誌コードの話

ISBNコード(書籍JANコード)とともに本に付番されている雑誌コードについて解説します。
雑誌コードからJANコードを作成しなければならない時に役に立つ知識です。

雑誌コードとは

雑誌扱いの本に付番されている5桁+4桁、または5桁+2桁のコードです。
この5桁に意味がずっしりと詰まっています。
また、バーコードはISBNコード(書籍JANコード)と一般商品JANコードのものがあります。
雑誌コードの始まる1桁目で雑誌コードの種類がきまります。

1. 1桁目が01は月刊誌(隔月刊や季刊の雑誌も含む)

基本、末尾は奇数。別冊や増刊号は末尾の数に+1して偶数になる。
本に印刷されるバーコードは一般商品JANコード

例)雑誌コード5桁+「-」+月2桁+年の下2桁

月刊TORICO 8月号
01234-0821、または省略して01234-08
月刊TORICO 8月増刊号
01235-0821、または省略して01235-08

2. 1桁目が23は週刊誌(隔週刊や月2回発売の雑誌も含む)

末尾は発売した週で1〜5。
別冊や増刊号は末尾に6以上の数が振られる。
本に印刷されるバーコードは一般商品JANコード

例)雑誌コード5桁+「-」+月2桁+年の下2桁

週刊TORICO 8/6号(8月1週目)
21231-0821、または21231-8/6
週刊TORICO 8/13号(8月2週目)
21232-0821、または21232-8/13
週刊TORICO 8/20号(8月3週目)
21233-0821、または21233-8/20
週刊TORICO 8/20増刊号
21236-0821、または21236-8/20

3. 1桁目が45は漫画のコミックス

雑誌コード5桁は固定。
だいたいレーベルごとになっている(〇〇コミック)
月年はなく雑誌コードに対して発売された巻数の通巻数2桁。
本に印刷されるバーコードは書籍JANコード

例)雑誌コード5桁+「-」+通巻数2桁

TORICOコミックス 1巻
41234-01
TORICOコミックス 2巻
41234-02

4. 1桁目が6はムック

雑誌コード5桁は固定。
だいたいレーベルごとになっている(〇〇ムック)
月年はなく雑誌コードに対して発売された巻数の通巻数2桁。
本に印刷されるバーコードは書籍JANコード

例)雑誌コード5桁+「-」+通巻数2桁

TORICOムック よくわかるTORICO
61234-01
TORICOムック TORICO大全
61234-02

5. 珍しいコード

1桁目が7で始まる、オーディオ・ビジュアル商品
1桁目が8で始まる、直販誌
1桁目が9で始まる、PB商品

雑誌コードから一般商品JANコードの作成方法

月刊誌、週刊誌にはISBNコード(書籍JANコード)がありません。
雑誌コードのみ付番されています。
ではバーコードは何でできているか?というと雑誌コードから一般商品JANコードを作成することができます。

例)01234-0821の場合
一般商品JANコードは4910012340819となります。
内訳としては
491=>定期刊行物コードのプレフィックス。固定
0=>予備。雑誌コードが満数になった場合使うかもしれない
01234=>雑誌コード5桁
08=>月号2桁
1=>年の下1桁
9=>JANのチェックデジット。形式はモジュラス10、ウエイト1、3
これをphpで書くと下記の様になります

/**
 * 雑誌コードをJANコードに変換する
 * @param string $code 雑誌コード、5桁-4桁
 * @return string JANコード
 */
function magazineCode2Jan($code)
{
    // 雑誌コードと月号で分ける
    $exp_code = explode('-', $code);
    $magazine_code = $exp_code[0];
    // 年の下1桁
    $year = substr($exp_code[1], 3, 1);
    $month = substr($exp_code[1], 0, 2);
    $prefix = 491;
    $spare = 0;
    $jan12 = $prefix . $spare . $magazine_code . $month . $year;
    // チェックデジット計算
    $chkdgt = getCheckDigit13($jan12);
    $jan13 = $jan12 . $chkdgt;
    return $jan13;
}

※チェックデジットの計算はエンジニアの知らないISBNの話のコード例にある「ISBN13桁のチェックディジット」を使用しています。
ここでタイトル回収になるのですが、年の下1桁を使用するため雑誌コードは10年に一度同じコードになります。
データベースにカラムを作る際はユニーク制約をしない、あるいは絶版になった雑誌を定期的に削除するような仕組みが必要になります。

新卒エンジニアが最初の半年に任された業務

今年の春に入社しました、情報システム部の清瀬です。

私がTORICOに入社からそろそろ半年が経過しようとしています。このタイミングで、この半年どういった業務を担当してきたのかを記事にしようと思います。TORICOに興味をもっている方にTORICOのエンジニア業務がどんなものなのか、知ってもらえればと思います。

社内アプリへの権限付与の自動化

torico-id のホームページ

TOIRCOには TORICO-ID というログインを共通化できるアプリがあります。マンガ全巻ドットコム や マンガ展 と連携させることでログインやアカウント作成の簡略化ができます。このアプリは10近くある社内アプリにも使われています。社員全員がボタン一つで簡単にログインできるのですが、問題点が一つありました。それは、Admin サイトへの権限の問題です。

TORICO の社員と一般のユーザーを分けるフラグはあります。そのため、社員にのみ権限を与えることは今までもできていました。しかし、全社員に全ての社内アプリのAdmin権限を付与するわけにはいきません。そのため今までは情報システム部が手動で権限の付与をしていました。

そこで部署ごとに権限を付与するサイトを事前に決めておき、権限の付与の自動化を行えるようにしました。作成したモデルは具体的には

  • Website
    • 権限を与えるアプリのモデル
    • 部署とM2Mの関係
    • django-allauth の Application と 1:N の関係
  • ClientGroup
    • ログイン成功時にユーザーに与える、クライアント側の Django の Group のモデ
    • django-allauth の Application と 1:N の関係
  • Department
    • 部署・部門のモデル
    • Website と M2M の関係
    • ClientGroup と M2M の関係
    • User と M2M の関係

の3つです。TORICO では Mezzanin という Django の CMS を使用しているため、Mezzanine の権限も付与できるように Website を Application と 1:N の関係にしています。

あとは Department に Application と ClientGroup を結びつけておくことで、どの部署にどの権限を付与するのかを自動で判別できるようになりました。TORICO は現在拡大期であり毎月のように新しく入社される方がいるため、この機能は非常に役立っていると個人的には思います。また、エンジニアとしても予想外のメリットがありました。それは新しいプロジェクトのローカル環境を作成した際に、いちいち SQLクライアントツールで自分のアカウントにスタッフ権限を付与しなくて済むことです。特に情報システム部は担当するアプリが多いため、その一手間を省けるのは非常に便利です。

古いシステムの Django 化

長年TORICOを支えてきてくれたシステムですが、その中の幾つかを Django に移行するお手伝いもしました。元のコードを読みながら、その機能を Django で再現するという業務でした。元のコードは PHP で書かれているため、PHP と Python を比較するような作業で、個人的にはとても楽しかったです。なにより、古いシステムを新しいシステムに置き換えることで、一つ一つの処理が非常に効率が良くなり、格段にレスポンスを早くすることができました。あらためてフレームワークの凄さを目の当たりできてよかったです。TORICO にはまだ古いシステムが残っているので、来期も移行の業務を積極的にやっていきたいと思っています。

MySQL 5.6 を 5.7 にバージョンアップする

RDS の MySQL5.6 のサポート期限が8月末(延長されて22/3/1まで)までであるということで、MySQL のパージョンアップもさせていただきました。手順としては、

  1. dev 環境のバージョンアップを行い、全ての機能が使えるかテストする
  2. 1 で問題あった機能を修正する
  3. スナップショットでバックアップをとる
  4. 修正したコードをデプロイして、本番のバージョンアップを行う

今回のバージョンアップでは1の部分で問題がありました。対象のアプリでは、ログイン時に MySQL の OLD_PASSWORD というハッシュ関数を使っていたのですが、それがサポートされなくなりました。そのため、代替となる関数をアプリ側で作成しなければなりませんでした。幸い、既に再現をしてくれているコードがあったため、それを拝借するだけで問題はありませんでした。ただ、ログインというアプリの基幹機能の修正だったため、本番へのデプロイは非常に緊張しました。

また、本番のバージョンアップ時にオプションの設定を忘れるというミスをしてしまいました。古いものが引き継がれると勘違いしていたことが原因です。その結果タイムゾーンの設定が狂ってしまい、表示されるべきコンテンツが表示されないという状況になってしまいました。普段からお世話になっている先輩に手助けしていただいたため無事に解決できましたが、もう少しで大惨事となるところでした。今後はもっと慎重に、情報集めからテストまでを行わなければいけないなと反省しています。

最後に

今回は、私がこの半年で任せていただいた主要な業務をいくつか紹介させていただきました。以上に取り上げたもの以外にも、

  • 新機能の追加
    • 5件
  • Django 化
    • 2件
  • DB・ネットワーク
    • 2件
  • セキュリティ(別ブログに記載)
    • 10件
  • コードの軽微な修正
    • 16件

と、様々な業務を体験できました。今回はシステムに関係する業務だけを取り上げましたが、他にも壁にドリルで穴を開けたり社内サーバーを移動させたりと、普段はできない業務も経験させていただきました。TORICO ではフルスタックであることが求められるため、業務も多岐にわたります。そこに魅力を感じた方は、ぜひ TORICO に応募してみてください。

実務経験0 入社一年目のエンジニアが任されたセキュリティの話

2021年春に入社しました、情報システム部の清瀬です。

TORICOの情報システム部では、セキュリティの向上を上半期の目標に掲げておりました。上半期も終わりに近づいてきたということで、新卒で入社した私がどんなセキュリティ向上のために携わってきた業務を記事にしようとおもいます。多くのシステムでは Django を使用しているためコード部分は Django 前提の話になります。

1. インフラレベルでの対応

AWS WAF の導入

  • SQLインジェクション対策
  • クロスサイトスクリプティング
  • その他、包括的な対策

TORICOでは一部の社内用アプリを除き、全てのサービスをAWSでデプロイしています。それら全てのサーバを悪意のあるリクエストから守るために、AWS WAF を導入しました。

AWS WAF は2019年に大幅アップデートされ、今までのものは WAF Classic と名称を変更しました。新しいWAFの最大のメリットは、るAWSによって作られたルールを簡単に導入できる点です。例えば AWSManagedRlesCommonRuleSet では、OWASPに記載された主要な脆弱性・リスク10個をカバーしてくれています。クロスサイトスクリプティングや悪意のあるボットを排除してくれるルールをボタン一つで導入できるため、包括的なセキュリティ対策をすることができます。もちろん、今までのようにオリジナルのルールを作ることができます。そのため、社内からのアクセスには一部のルールを緩和させたりなどもできるようになっています。

余談ですが、WAFの導入の検証を担当したのは、まだ私がインターン1週間くらいの時でした。検証のために簡易的な Django アプリを Ec2 にデプロイしてWAFの導入でクロスサイトスクリプティングやSQLインジェクションがきちんとブロックされるのかを検証しました。インターンなのにこんな重要そうな仕事をさせていただけるのかと驚いたのを今でも覚えています。

過去に使用していた IP アドレスのルーティングを解除

これはセキュリティとは少し違う話かもしれませんが、ドメインの整理などもしました。一部の未使用のドメインが、既に手放してある IP アドレスと結びついたまま放置されていました。もし IP アドレスが悪意のあるサイトに使われていた場合、最悪ユーザーを悪意のあるサイトに誘導してしまうということも起こり得ます。そうならないためにも、不要なドメインを整理しました。

2. アプリレベルでの対応

サービスのAdmin ・社内アプリ を社内からのみ許可する

  • 不正なアクセス対策
  • 個人情報の保護

こちらは Django の Middleware を使って対応しました。サブネットマスクの表現方法などが複数あるため IP を取り扱うのは面倒くさそうだなと思っていましたが、python には ipaddress という便利なモジュールが標準で搭載されています。このモジュールを使うことで簡単に実装することができました。このタスクは上記の WAF でも実装できますが、1つのALBで複数の社内アプリを制御していたためアプリレベルで対応することにしました。アプリレベルのため、各アプリに適した制限を導入することも簡単にできます。

ログインセッションキーを適切な設定にする

  • セッションハイジャック対策
  • CSRF対策

大事なセッションを管理してくれるクッキーにはセキュリティ対策は欠かせません。TORICOの全てのサイトで、その大切なCookieの設定が適切になるように対策をしました。具体的には HttpOnly Secure SameSite=Lax  の3つの設定です。これらの設定を簡単に説明すると、

HttpOnly: JavaScript からセッションにアクセスできないようにする。設定されていなかった場合、JS 経由で セッション情報が漏洩する危険がある。

Secure: https 通信でのみ セッションを送るようにする。設定されていなかった場合、暗号化されない Http 通信でセッションが送られてしまう危険がある。

SameSite: Strict, Lax, None の3つの設定がある。Lax の場合、別オリジンからの POST の時はセッションを送らない。None の場合、例えばECサイトの届け先を変更するフォームのある偽サイトからユーザーのセッションを使ってデータが送信されてしまう。

Django では 2系以上であれば settings で設定することができます。1系の場合は SameSite を設定することができません。クッキーセッションの注意点として、あまりにも厳しい設定にした場合、サービスがうまく動かなくなる可能性があります。特に SameSite は決済部分でエラーがでることがあるそうです。

ファイル出力時に追跡IDとログを残す

  • 情報漏洩元の究明

TORICOではできるだけ業務を自動化するために、いろいろな情報をCSVなどに出力します。万が一そういったデータが社外に流出した時、どのデータが、どこから流出したのかを特定しやすいように追跡IDをそれぞれのファイルに追記するようにしました。ログにはリクエストの情報を全てを保存しているため、いつ・誰が・どの検索ワードで CSV を出力したのかを追うことができます。 Django には DB へのログ出力機能はないため、DBに出力する場合には自作する必要があります。

3. データベースの対応

重要なフィールドの暗号化

  • 個人情報の保護
  • データ漏洩時の影響を最小限にする

重要なフィールドを可逆暗号化することで、万が一情報漏洩した時でもその影響を最小限に留められるようにしました。可逆暗号は Django のオリジナルのフィールドを作ることで簡単に対応することができました。具体的な実装方法についてはこちらの記事で書きました。また、一部の古い社内アプリではアカウントのパスワードがハッシュ化されていなかったため、 bcrypt という方法で不可逆暗号化もしました。

ソルトとペッパーの役割の違いなどが曖昧だったため、とても勉強になったタスクだったなと思っています。

最後に

上半期に行った主要なセキュリティ対策を紹介していきました。セキュリティは深刻な障害の原因になるため、普段のコーディングから気をつけていきたいと思います。

PMS&ISMS後編 Pマーク認定、ISO27001規格認証でのコンサルを選ぶポイントは、これだ・・・。


株式会社TORICO情報システム部の四斗邊です。

PMS、ISMS関連の後編です。
今回はP
マーク認証、ISO27001認証を取得する際のコンサルを選ぶポイントについて話したいと思います。

まずTORICOのブログをご覧になられている人ならご存知だと思いますが、TORICOは漫画のECサイトをメインに、デジタルコンテンツ配信、イベント事業行っている会社です。

従業員は150(20216月現在) を超え、事業規模の拡大に伴いPマーク認証、ISO27001認証を取得する流れになりました。

そんな私は入社早々にして取得するためのPJに参加したわけですが、今まで経験した会社に存在した規定などは、実はPマーク認証、ISO27001認証に基づいて行われていたんだなということがわかり、今まで関わった仕事を振り返り立ち返り興味深く関わることができたと実感しています。

ちなみにPMS
Pマーク認証とISMSISO27001認証の違いや説明については、前編をご覧ください。

作業内容は、今まで無法地帯だった箇所にメスを入れ、規律やルールを作成することが多かったと思います。具体的には、管理ルールの定まっていなかったPCの扱いについて、退勤時に施錠を徹底することなどです。

作成時は、これで良いのかと自問する不安の中での取得となっていました。

最終的には、「あ、これで良かったんだ」とある程度の経験と知識は蓄えることができたかなと思います。

さて前置きが長くなりました。

実はPマーク認証、ISO27001認証取得を経験した人が会社内に数名いると独力で取れるぐらいの取得しやすい認証なのですが、これを未経験者のみだけで挑戦すると、「何から手をつけていいのか」、「どうやったらいいのかわからない」ということが多すぎます。そんなときは、コンサルに頼んだほうが近道です。

弊社はもちろんコンサルに依頼することになりました。

ただコンサルを選ぶ際には以下の注意点を考慮されることを強くおすすめします。



1 Google Driveをつかってくれ!


弊社が担当していただいたコンサルは、情報保護の観点からかコンサル独自のアプリケーション、クラウドサービスを提供する会社でした。

その結果、保存する形式としてはofficeフォーマットでやり取りすることがほとんどでした。弊社はどちらかというとofficeなどを使わず共同で同時に編集作業できる点からGoogleのグループウェアを業務に多く取り入れている会社でしたので心底やりづらいです。

一旦編集したファイルをofficeファイルに変換しなければいけないことや、最新版であることが分かりづらいこと、共同編集できないなどGoogleのグループウェアの恩恵を受けられず効率が悪いと何度思ったか。

またクラウドストレージもコンサル独自のものがあったりと、Google Driveで共有しても対応してくれなかったというのがあるので、できれば事前にGoogle Driveなどグループウェアを共同で作業できるなどの事前確認は必要です。



2 リスクマネジメントは、一回マクロなしでやりませんか?


ISMS構築で一番大事なポイントといってもいいリスクマネジメント。

この作業を抜いではないといっても過言ではありません。

この作業を簡単に噛み砕くと「情報資産を特定して、リスクを把握して、驚異を数値化する」業務である。

この「作業の流れ」については、コンサルから説明を受けたので言葉では理解できるのですが、コンサルを交えて実践となった際に、事前に弊社の情報資産を予めピックアップした情報を渡していたので、書式に基づいて処理の流れを見せてくれるのかと思いきや、その部分は割愛されマクロでの処理の流れを説明されるという。

その場では、特に不明な点はないと思われたのですが、後々実際リスクマネジメントを回す際に見返すと「何やってんだ、この作業」となってしまいました。

そのため、できる限りマクロを交えず、実際の業務として落とし込めるまでコンサル立会のもと行うことを強くおすすめします。

特に書式やルールについては、コンサル提供の書式でもいいですが、コンサルと相談して独自の物を作って作業や管理のしやすいように改良することを強くおすすめします。

その場で頑なに拒んでくるコンサルは、実際のISMS構築やPMS構築の実務よりも審査を通ることのみを考えているコンサルではないかなと思われますので、注意が必要です。

 


3 審査期間の情報を豊富に持っているか?


弊社のコンサルでよかった点として、審査期間の情報を豊富に持っていた点があげられます。

実はPマーク認証、ISO27001認証の審査機関は1つではありません。

その審査機関の特徴といった情報を持っていることもコンサルの選ぶポイントと言えます。

大まかに以下の点があげられる。
① 審査の難易度
② 審査において指摘される傾向のあるポイントや過去や例
③ 審査にかかる費用

これらのデータや経験を持っているコンサルはなかなか頼りになるのではないかなと思います。

以上3つのポイントをご説明しました。

これらを踏まえてPマーク認証、ISO27001認証関連のコンサルを選ぶ際の参考にしてください。

前編と後編とかなり文字数多めで書きました。なかなかのボリュームとなっておりますのでお時間あるときにみていただけると大変嬉しく思います。
また、ネタがあればブログを書きたいと思います!

PMS&ISMS前編 PMSとISMSの違いについて


はじめまして株式会社TORICO情報システム部の四斗邊です。

いきなりですが、PMSとISMSについてお話したいと思います。

なぜこの話をしようと思ったかといいますと、株式会社TORICOでは、2021年1月にPマーク認証を取得、2021年2月にISMS認証(別名ISO/IEC 27001)を取得したからです!

この機会に、TORICOを知っていただこうと思い技術ブログとして若干逸れる内容ですが情報系のブログ記事としてPMS及びPマークとISMSに関する内容を前編と後編2回に分けてお話ししたいと思います。

まず、前編としてPMSおよびPマークとISMSの違いについて、後編はこれら認証取得時のコンサルの選ぶポイントをお伝えできればと思います。

それでは、前編スタート


1 PMS
Pマークについて


さっそくですがPMSとは「Personal information protection Management Systems」の略で個人情報保護マネジメントとも呼ばれています。

PMSは、個人情報保護を目的とした継続的な組織の設立や運営管理方法の制定と言った仕組みのことを指し「システム」と書かれていますが機械やプログラミングで構築したソフトウェアなのではありません。

具体的な仕組みとして継続的な個人情報管理台帳の作成と更新、漏洩リスクへの対策、漏洩時の対応など、実際に運用したPMSを評価する会議体を実施するなどがあげられます。

PMSによる個人情報の適切な取り扱いができるか審査を経て、JIS Q 15001規格に定義された個人情報保護マネジメントを実施する適合事業者と認められるとPマーク認証を取得できます。

ただ、Pマーク認証を取得していないからと言って企業には個人情報保護マネジメントが無いということでなく、審査を得ていない場合や、JIS Q 15001規格に沿っていない独自の個人情報保護マネジメントの構築している場合が企業には考えられます。


2 ISMSISO27001について


ISMSとは「information security management system」の略で情報セキュリティマネジメントシステムとも呼ばれています。

ISMSは企業が保有する情報資産を保護する目的のため継続的な組織の設立や運営、管理方法の制定など仕組みを意味します。PMS同様、「システム」と書かれていますが機械やプログラミングで構築したソフトウェアなのではありません。

具体的な仕組みとして、継続的な情報資産の作成と更新、情報を「機密性」「完全性」「可用性」ごとにリスクを特定(リスクアセスメント)し、リスクに合わせて適切に管理改善していくことです。

ちなみにISO27001は、ISMSの国際規格を指します。

別名ISO/IEC 27001、JISQ27001とも呼ばれています。

Pマーク同様、ISMS構築後、審査を得て適合事業者と認められるとISO27001認証を取得できます。

ちなみに、PMSとISMSは個人情報の部分において重複します。

ISMSは全ての企業情報を保護対象としているため上位互換のように表現されますが、あくまで企業の情報資産の一部として個人情報を扱うISMSに対して、個人情報保護を重要視している点で差があります。具体的としては、PMS(JIS Q 15001)では個人情報の目的や取得方法の特定や個人情報の開示、個人情報を第三者へ提供する場合のルールなど規格内に盛り込まれています(問い合わせページとかでやたら同意を求めてくるこれです。)

また、Pマーク認証は法人単位、ISO27001認証は部門やセクション単位で取得できるようです。


3 メリットについて


TORICOではPマーク認証とISO27001認証を取得する過程で既にメリットはありました。

取得に伴い実施したリスクアセスメントや個人情報の洗い出しによって日常の業務において到底意識しない部分に目を向ける機会になったからです。また、それまで関わりのなかった部署に対しても協力していただく機会もあったので全社的に危機意識を培うチャンスとなったと思います。

またリスクを未然に防ぐためにPMSとISMS構築が一役買いました。

これまで個人情報や企業の情報など保管期間を明確に決めずに保存していたり、バックアップを取らなかった部分については改めるきっかけになったと思います。

本来のメリットとしては、公的機関への入札時などPマーク認証とISO27001認証を取得が条件になっているようで、入札時のメリットがあるようです。

またPマークやISO27001認証を取得している企業から取引の際、信用の目安になり、比較的に取引しやすいなどもメリットに挙げられます。

デメリットは、業務フローが増えたことと、書式などのフォーマットが増える点でしょうか。

以上、PMSとISMSの違いについてお話ししました。

後編に続きます。

参考文献


システム管理者の会 

第4回 プライバシーマーク(Pマーク)と他の認証制度の統合


帝国データバンクネットコミュニケーション

ismsとiso27001は何が違うのですか?

WORKーPJ

ISMSとプライバシーマーク(PMS)とは?概要と相違点、どちらを取得するべきか

エンジニアの知らないISBNの話

本には商品判別のためのバーコードがついています。
いわゆるISBNコード(JANコード)です。
ECショップでは本を取り扱うために本の書誌を記録するテーブルを作成しますが、その際にint型でいいだろう? ユニーク制約でいいか?とおもってはいけないません。

先に結論を書いてしまうと

  • 文字が含まれる可能性がある
  • 先頭に0が来る可能性がある
  • ユニークではない

char型にして、ユニーク制約をつけないほうがよい理由

1. 文字「X」が含まれる可能性がある

ISBNコードには10桁と13桁があります。
10桁ISBNコードは9桁+チェックデジット1桁で構成されます。
古い体系ですが、一部で使うことがあり、チェックデジットに文字「X」がはいる可能性があります。
これはチェックデジットがモジュラス11、ウェイト10-2という方法で算出されるためです。
計算方法をphpで書くと

/**
 * ISBN10桁のチェックディジットを返す
 */
function getCheckDigit10($jan9)
{
    $sum = 0;
    $cnt = 0;
    for ($i = 10; ; $i--) {
        if ($cnt > 10) {
            break;
        }
        $sum += substr($jan9, $cnt, 1) * $i;
        $cnt++;
    }
    $remainder = $sum % 11;
    if ($remainder == 0) {
        return 0;
    }
    $check_digit = 11 - $remainder;
    if ($check_digit == 10) {
        $check_digit = 'X';
    }
    return $check_digit;
}

2. 先頭に0がつく可能性がある

ISBNコードと書きましたが、実際にバーコードになっているのはJANコードです。
そしてJANコードは先頭が「0」になる可能性があります。
本を売るショップとして取り扱いそうなJANコードは3種類。

  1. 一般商品JANコード
    45,または49で始まる12桁+チェックデジット1桁の13桁JANコード。
    45と49は日本に割り振られた国コードなので固定。
    雑誌やグッズなどに使われています。
  2. 書籍JANコード
    9784で始まる12桁+チェックデジット1桁の13桁JANコード。
    978は世界共通の書籍コード
    4は日本に割り振られた国コードなので固定。
    いわゆる13桁ISBNコード。
    コミックや書籍などに使われています。
    バーコードは2段になっており、上段は書籍JANコード、分類・価格のコード。
  3. インストアコード
    02、04、20〜29で始まる12桁+チェックデジット1桁の13桁JANコード。
    ポイントカード、会員証やレジ袋などの管理・販売用に使われる、小売店が独自につくって使用してよいJANコード。
    20〜29始まりのJANコードを使用すればいい話だが、02、04も準備しておくに越したことはない。

JANコードのチェックデジットはモジュラス10、ウエイト3-1という方法で算出されるため0〜9の数字になります。

/**
 * ISBN13桁のチェックディジットを返す
 */
function getCheckDigit13($jan12)
{
    $sum_odd = 0;
    $sum_even = 0;
    for ($i = 11; $i >= 0; $i--) {
        if ($i % 2) {
            $sum_odd += substr($jan12, $i, 1);
        } else {
            $sum_even += substr($jan12, $i, 1);
        }
    }
    $sum = $sum_odd * 3 + $sum_even;
    $division = $sum % 10;
    return (10 - $division) % 10;
}

3. 同じJANコードが使われる

JANコードは同じコードが存在するのでユニークではありません。

  1. 書籍JANコードの場合
    「今現在販売中の本」と限定すれば書籍JANコードはユニークになります。
    ただし、本が絶版になったあと、そのJANコードは別の本に付番されます。
    そのため、今までに発売したすべての本のJANコードだと同じJANコードをもつ本が複数存在します。
  2. 雑誌の一般商品JANコードの場合
    雑誌に付番されている雑誌コードから一般商品JANコードが作成されます。
    その際に西暦の下1桁を使用しているため、10年ごとに同じコードになります。

以上がISBNコード(JANコード)をint型、ユニーク制約にしては行けない理由でした。
10桁と13桁のどちらも記録できるようにしてあると便利かもしれません。

海外回線からのブラウザリクエストを日本のオフィスから SOCK5プロキシを使って行う

海外回線からリクエストされた時に応答を変えるようなサービスで、実際の海外からアクセスした時のレスポンスを日本国内のPCから試したい場合は、SOCKS プロキシを使うと便利です。

実際に起動した、自分のコントロールしているサーバを使います。怪しげな VPN サービスを使わなくていいため安全です。

 SSHログインできる海外のサーバを用意する

海外リージョンで起動している AWS の EC2 などを使います。SSHでログインできるようになっており、HTTP関係のアウトバウンド通信がブロックされていなければOKです。

使っているPCで、 -D オプションをつけて SSHログインする

$ ssh -D 10080 user@example.com

これを行うと、普通にSSHのセッションが開始されますが、そのPCの 10080 ポートで SOCKS v5 プロキシが使えるようになってます。

SOCKS プロキシの接続先を、localhost:10080 にする

システム環境設定 から、プロキシの設定を行います。

Firefox はブラウザ内に固有のプロキシ設定を持っており、そこで特別な設定を行うこともできますが、デフォルトでは OS のプロキシ設定を使うようになっています。

接続を確認する

確認くんhttps://httpbin.org/ip を見て、接続元IPアドレスが変わっていることを確認できます。

Selenium でプロキシ設定済みのブラウザを起動する

システム環境設定を開いてプロキシの設定を変更するのは面倒ですが、Selenium を使えばプロキシ設定済みのブラウザインスタンスを起動できます。
( 127.0.0.1 となっている箇所は localhost でも同じです。)

Pythonスクリプトの例

Chrome

from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("--proxy-server=socks5://127.0.0.1:10080")
options.add_argument('--proxy-bypass-list=""')
driver = webdriver.Chrome(options=options)
driver.get('about:blank')

Firefox

from selenium import webdriver
profile = webdriver.FirefoxProfile()
profile.set_preference('network.proxy.type', 1)
profile.set_preference('network.proxy.socks', '127.0.0.1')
profile.set_preference('network.proxy.socks_port', 10080)
profile.set_preference('network.proxy.no_proxies_on', '')
driver = webdriver.Firefox(firefox_profile=profile)
driver.get('about:blank')

ターミナル(シェル)でプロキシ設定済みの Chrome を起動する

open -a "Google Chrome" --args --proxy-server="socks5://127.0.0.1:10080" --proxy-bypass-list=""

Google Chrome や Chromium の場合、コマンドラインオプションでプロキシの設定を行うこともできます。ただし、一度起動してしまうと、プロセスを完全終了しないと設定がクリアされないので戻す時が若干面倒です。

Amazon Pay Checkout v2 API の署名 (RSA-SHA256 (RS256) + RSA PSS Padding) を Python で行う

Amazon Pay の API クライアントを書く際、Amazon のAPIサーバに送信するリクエストに、RSA-SHA256, RSA PSS パディングを使って署名を作り、リクエストに含めて送信する必要があります。

Java や Node はクライアントライブラリがあったので、それを使って簡単に署名できたのですが、弊社 TORICO ではサーバサイドは主に Python を使っており、既存のクライアントライブラリは無かったため、Node のライブラリを参考に署名コードを書きました。

Amazon Pay のAPI

今回は、Amazon Pay の Checkout v2 API を使う必要がありました。

https://developer.amazon.com/ja/docs/amazon-pay/intro.html

リクエストヘッダに含める署名については、
この CV2 (Checkout V2) の 署名リクエストのページに解説があります。

このページを見ていくと、「署名を計算します」の箇所に

署名を計算するには、ステップ2で作成した署名する文字列に秘密鍵を使用して署名します。 SHA256ハッシュとソルト長20のRSASSA-PSSアルゴリズムを使用します。結果をBase64エンコードして、この手順を完了します。 RSASSA-PSSを使用して計算されたすべての署名は、入力が同じであっても一意であることに注意してください。

とありますので、この「 SHA256ハッシュとソルト長20のRSASSA-PSSアルゴリズム」を Pythonでコーディングする必要があります。

ところで、この最後の「 入力が同じであっても一意であることに注意してください」は、「〜一意でない」の間違いじゃないですかね。英語版ページは調べてませんが。

Amazon Pay Scratchpad

https://pay-api.amazon.jp/tools/scratchpad/index.html

検証リクエストを発行できるサイトが用意されていますので、署名ロジックの確認に使うと良さそうです。
私は、今回の開発中は存在を知らなかったので、使っていません。

Node.js の場合

node.js の場合は、クライアントライブラリは
@amazonpay/amazon-pay-api-sdk-nodejs があり、これを使うと署名を含めたAPIリクエストが一発で行えます。

ヘッダの署名を行っているコードは

https://github.com/amzn/amazon-pay-api-sdk-nodejs/blob/master/src/clientHelper.js#L142 このあたりで、
「 SHA256ハッシュとソルト長20のRSASSA-PSSアルゴリズム」のコードは
https://github.com/amzn/amazon-pay-api-sdk-nodejs/blob/master/src/clientHelper.js#L84 ここです。

Python の場合

上記 node.js 相当のコードを書くわけですが、hmac ライブラリには相当のコードはありません。

RSA や パディングの基礎的なロジックは cryptography に入っており、実際の使い方は PyJWT がいい感じになっているので、PyJWT を参考にします。

https://github.com/jpadilla/pyjwt/blob/master/jwt/algorithms.py#L232

PSS パディングはここです。

https://github.com/pyca/cryptography/blob/main/src/cryptography/hazmat/primitives/asymmetric/padding.py#L19

この PSS の第一引数の _mgf ってなんだ、と思いましたが、同モジュール中にある
MGF1(RSAAlgorithm.SHA256())
を入れたら動きました。

署名部分のコード

署名部分のコードはこのようになります。

import base64
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives.serialization import load_pem_private_key

private_key = b'''-----BEGIN PRIVATE KEY-----
MIIEvQIB....
....N/Qn4=
-----END PRIVATE KEY-----'''

string_to_sign = 'AMZN-PAY-RSASSA-PSS\nxxxxxxxxxxxxxxxxxxxxxxxx'

key = load_pem_private_key(private_key, password=None)

signature = key.sign(
string_to_sign.encode('utf-8'),
padding.PSS(padding.MGF1(hashes.SHA256()), 20),
hashes.SHA256())

signature = base64.b64encode(signature).decode('utf-8')

後になって気づきましたが、PyJWT に RSAPSSAlgorithm という、今回の用途にぴったりなクラスがあったので、これを使うともうちょっとシンプルなコードになるかもしれません。

署名元の文字列の生成も含めたコード

checkoutSessions を行うコードはこのような感じです。

node.js のコードを参考にした箇所がいくつかあり、それらは実際には使われない、不要なコードになってます。

import base64
import datetime
from hashlib import sha256

import requests
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives.serialization import load_pem_private_key

private_key = b'''-----BEGIN PRIVATE KEY-----
MIIEv....
....N/Qn4=
-----END PRIVATE KEY-----'''

config = {
'publicKeyId': 'SANDBOX-AEXXXXXXXXXXXX',
'privateKey': private_key,
'region': 'jp',
'sandbox': True,
}

constants = {
'SDK_VERSION': '2.1.4', 'API_VERSION': 'v2', 'RETRIES': 3,
'API_ENDPOINTS': {'na': 'pay-api.amazon.com', 'eu': 'pay-api.amazon.eu', 'jp': 'pay-api.amazon.jp'},
'REGION_MAP': {'na': 'na', 'us': 'na', 'de': 'eu', 'uk': 'eu', 'eu': 'eu', 'jp': 'jp'},
'AMAZON_SIGNATURE_ALGORITHM': 'AMZN-PAY-RSASSA-PSS',
}

checkoutSessionId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

options = {
'method': "GET",
'urlFragment': f"/v2/checkoutSessions/{checkoutSessionId}",
'headers': {},
'payload': ''
}

pay_date = datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')

headers = {
'x-amz-pay-region': config['region'],
'x-amz-pay-host': 'pay-api.amazon.jp',
'x-amz-pay-date': pay_date,
'content-type': 'application/json',
'accept': 'application/json',
'user-agent': 'amazon-pay-api-sdk-nodejs/2.1.4 (JS/14.15.1; darwin)',
}

lowercase_sorted_header_keys = list(sorted(headers.keys(), key=lambda x: x.lower()))
signed_headers = ';'.join(lowercase_sorted_header_keys)

canonical_request = [
options['method'],
options['urlFragment'],
'', # GETパラメータだが一旦無し
] + [
f'{h}:{headers[h]}' for h in lowercase_sorted_header_keys
] + [
'', # 空行入れる
signed_headers,
sha256(options['payload'].encode('utf-8')).hexdigest()
]

canonical_request_bytes = ('\n'.join(canonical_request)).encode('utf-8')

string_to_sign = constants['AMAZON_SIGNATURE_ALGORITHM'] + '\n' + sha256(canonical_request_bytes).hexdigest()

key = load_pem_private_key(config['privateKey'], password=None)

signature = key.sign(
string_to_sign.encode('utf-8'),
padding.PSS(padding.MGF1(hashes.SHA256()), 20),
hashes.SHA256())

signature = base64.b64encode(signature).decode('utf-8')

headers['authorization'] = \
f"{constants['AMAZON_SIGNATURE_ALGORITHM']} " \
f"PublicKeyId={config['publicKeyId']}, " \
f"SignedHeaders={signed_headers}, " \
f"Signature={signature}"

response = requests.get(
f"https://pay-api.amazon.jp{options['urlFragment']}",
headers=headers
)
print(response)
print(response.json())

ファンのうるさい MacBookPro を静かにする

メインの開発機として MacBookPro 2019 16インチ Intel CPU を使っています。

ちょっとでも負荷のかかる処理をさせると、すぐファンが最高速で回ってしまいます。会社での使用時は問題ありませんが、在宅で静かな部屋の中で使っている場合、なかなか不快です。

今回、そのファンの音をなんとか静かにしようと試行錯誤したのでその記録を書きます。

M1 Mac はとても静か

おすすめ度: ★★★

主題から逸れますが、Apple Silicon M1 Mac は、Intel の MacBookPro と比較してとっても静かです。

そもそも M1 Mac の MacBookPro ではない MacBook Air は、ファンレスなので無音です。

しかし、MacBook Air は、CPU に高負荷をかけ温度が上がると、CPUの処理能力に制限を設けて温度を下げるため、開発業務には不向きです。開発業務に使うのであれば、 MacBook Pro が良いでしょう。

M1 Mac の大きな欠点として、同時に1つの外部ディスプレイしか標準で使えないことがあります。

この制限があるため、機種変更をためらっている方もいると思います。私もそうでした。

ただし、DisplayLink のチップを搭載したディスプレイアダプタをつければ、複数ディスプレイ出力に対応できます。DisplayLink チップを使うにあたり、今度は CPUリソースの消費や描画遅延が気になりますが、気にするほどの負荷はまったくありません。私の使っている機種は Plugable というブランドのものですが、全く問題なく、非常に快適です。

https://www.amazon.co.jp/dp/B08F2TSR43/

M1 Mac は、開発環境も Intel Mac 同等のものが現在は使えます。特に Docker が早いと感じます。よっぽど古いミドルウェアを扱ってない限り、問題なく開発できますので、今後開発をされる方は M1 Mac がおすすめです。

ファン付きPCスタンドを使ってみる

おすすめ度: ★☆☆

Intel の MacBook Pro の話に戻します。まず、ファンの回転数を下げるために本体を冷却させようと、ファンつきのノートPCスタンドを買ってみました。

使ってみましたが、キーボードが打ちにくくなる割りに、大した効果は見込めませんでした。5℃くらい下がったかも…と感じなくもないですが、高負荷の処理をすると結局最高速にファンが回るため、たいして変わりがありません。買わなきゃよかったと思います。

ゴム足で傾けてみる

おすすめ度: ★★☆

エアフローが少し改善されるかと思い、Mac の奥側のデスクにゴム足を貼り付け、本体を傾けて隙間を作ってみました。

結果、冷却効果は変わりませんでしたが、本体角度の影響か騒音がまろやかになり、不快感が減りました。コストも低いので、おすすめです。

後ほど、100円ショップでも同様の意図のゴム足が売ってたので、比較的一般的な方法のようです。

コストが安い割に、心理的メリットが大きいので試されることをおすすめします。冷却効果はほとんどなさそうです。

TG Pro を使ってソフトウェアでファンコントロールをする

おすすめ度: ★★☆

TG Pro というアプリが販売されており、インストールすると、温度センサーの温度とファン回転数の関係を制御できます。

(2021-08-23 現在、半額セールで JPY 1155)

冷却されるわけではないのですが、CPU温度70℃近辺のファン回転数を抑えることで、少しの消音化ができます。

それと、各種温度センサーやファン回転数を把握したり、メニューバーにファン回転数が出るのは使っててなかなか楽しいです。買って良かったと思いますし、常用しています。

↑MacBook Pro は多くの温度センサーが搭載されており、それぞれの温度を確認できる。

↑メニューバーに温度とファン回転数が出せる。

ファン制御は、最悪ハードウェア故障などにつながるため、扱いは自己責任となります。アプリ内でも、制御機能を有効にする際に警告が出ますので、よく理解して使ってください。

試用で15日間使えますので、興味があれば使ってみると良いでしょう。

Intel Power Gadget で CPU 周波数と温度を監視する

おすすめ度: ★★☆

こちらも直接冷却につながりませんが、温度を監視するのに Intel Power Gadget が便利です。
Intel のサイトからダウンロードでき、無料で使えます。

https://software.intel.com/content/www/us/en/develop/articles/intel-power-gadget.html

CPUの動作周波数と温度、電力、そしてシステムがCPUに要求している周波数などがモニタリングできるので、発熱する原因の調査に有効です。後述する、クロックアップ禁止の動作確認にも使えます。

Turbo Boost Switcher Pro でクロックアップを禁止する

おすすめ度: ★★★

Intel Mac の CPU は、Turbo Boost というテクノロジによって、処理量によって動作クロックが随時変更されるようになっています。私の Mac は 定格2.3GHz 動作ですが、負荷の高い処理を行おうとすると 4GHz ほどの動作クロックになるようです。

とはいえ、この Turbo Boost はバッテリーを多く消費し、発熱も高くなるため、安定動作を求めて OFF にする場合も多いようで、実施を記録したブログも多く見つかります。

高速化の処理を無効化するため、処理低下が感じられそうに思いますが、他のブログでは、多くが体感的な処理速度はそれほど感じかったと書いています。

実際、私も Turbo Boost を無効化したところ、遅くなったという感じはまったくしませんので、発熱を抑えたい方は Turbo Boost の無効化をおすすめします。

Turbo Boost を無効化するのは、Turbo Boost Switcher Pro というアプリを購入して実行する必要があります。起動時に自動的に無効化するには Pro 版が必要で、買い切り10ドル弱です。

http://tbswitcher.rugarciap.com/

(サイトの見た目はけっこう怪しい感じ)

他の紹介記事

Turbo Boost Switcherのご紹介: Macの爆音爆熱問題はTurbo Boostをオフにして解決しよう

Turbo Boost Switcher で Turbo Boost を無効化した後に、Intel Power Gadget で CPU のグラフを見ると、システムが CPUのオーバークロックを要求してるのをガン無視してるのがわかります。

↑矢印の箇所で開発環境を起動。CPUのオーバークロック要求が出ているが、オーバークロックされない。

Mac をデスクの下に置く

おすすめ度: ★★★

気になるファン音を直接耳に入れないようにするため、試しに机の天板の下(キャビネットの上)に Mac を隠すように置いてみたら、ファン音がほとんど気にならずかなり快適になりました非常におすすめです。もっと早く気づけばよかったです。

つまり、クラムシェルモードで使うということです。Mac のキーボード、トラックパッド、タッチバー、指紋認証などが使えなくなってしまうデメリットが大きいですが、ファンノイズがうるさいことに比べれば小さいデメリットです。机の上がすっきりする副次効果もあります。

クラムシェルモードといっても、完全に閉じてしまうとキーボードの隙間からの吸気ができなくなってしまうので、本体温度が上がってしまいます。

2016? 以前の MacBook は、磁石でディスプレイの開閉をセンシングしてたため、磁石をキーボード左側に置くことで、ディスプレイを閉めたと錯覚させることができました。

最近の MacBookは、開閉センサーが磁石ではなくディスプレイヒンジ部に入っている傾きセンサーになったので、磁石をmacの上に置くことでディスプレイをOFFにする擬似クラムシェルモードはできなくなりましたが、傾きセンサーには遊びがあるため、2cmぐらい開けても閉まってると認識されます。吸気のため、それぐらい開けておくと、温度上昇は普通に使っているのと同じぐらいに保てます。

Webクライアントはリッチに、モバイルアプリクライアントはシンに運用開発する

  • Django, Nest, Laravel, Rails などの サーバサイドアプリ(APIサーバ)
  • Vue, React などの Webクライアント
  • iOS, Android 用の モバイルアプリクライアン

これらを組み合わせてサービスを作ることはよくあり、TORICOでもそうです。

Webクライアントとモバイルアプリクライアントは役割として同じものになるので、同じような感覚で開発を始めることはよくあります。

しかし、アプリのファーストリリースが終了し、運用開発のフェイズとなった時、同じような感覚で機能追加を進めていこうとするとうまくいきません。モバイルアプリは、非常にリリース速度が遅いのです。

アップデート容易さの比較

サーバサイドアプリ、Webクライアント、モバイルアプリクライアントをそれぞれ並列で比較した時、それぞれの更新の容易さ、障害時のインパクトは以下のようになると考えます。

Webクライアント

サーバサイド

モバイルアプリ

更新の容易さ

()

()

障害時のインパクト

Webクライアントとモバイルアプリクライアントは、使用用途としては同じですが、アップデート時の性質はまったく逆です。

Webクライアントは、ブラウザでアクセスすれば常に最新版のプロダクトが使えます。これはほぼ必ず自動的に入手でき、古いバージョンがそのまま使われることはまずありません。

比較して、モバイルアプリクライアントは、アップデート作成時にプラットフォーマー( Apple, Google ) の審査をまず通さなければならず、審査を通すのに数日が必要です。アップデートを提供したとしても、利用者の設定によっては自動アップデートはされないため、古いバージョンを使い続けられることもありあす。

更新難度を下げるためのテクニック

モバイルアプリのコードを動的にアップデートする方法が存在します。ゲームで多く使われています。

他に、古いアプリバージョンでAPIアクセスした時にアップデートを促してサービスを受け付けないなどの対応も考えられます。ただしどちらも基本的にプラットフォームの規約違反なので、通常は選択できません。

更新難度が高い理由

例えば、APIのエンドポイントURLをリファクタリングにより更新したい場合、Webアプリの場合はクライアントも同時に更新してリリースすれば、大抵は問題ありません。

しかしモバイルアプリのクライアントを扱っている場合、旧バージョンのユーザーを考慮して、古い仕様のAPI エンドポイントもしばらく(年単位で)残しておく必要があります。この非生産的なサービス保守は、モバイルアプリ運用をする上での大きな負荷となります。

そのため、モバイルアプリクライアントでサービス運営をする場合、なるべくクライアントで計算(判断)をさせない設計とした方が素早いサービス改修が行えます。

アップデート頻度を下げる

例えば日付時刻をモバイルアプリクライアントで表示する場合。

DBに日時型で入っている情報を、どこかで文字列にフォーマットする必要がありますが、私は文字列へのフォーマットは大抵サーバサイドで行い、文字列でモバイルアプリに送るようにしています。また、何かのリスト表示時の並び替えなども、可能であればすべてサーバサイドで行い、なるべくモバイルアプリクライアントでの計算は減らします。

そうしないと、何かの調整時…例えば、日付時刻を表示する箇所に「未定」と表示したいケースとなった時、わざわざ新たなアプリをビルドしてプラットフォーマーの審査を通過させ、新旧両バージョンのクライアントが同時に存在することを考慮してAPIの改修も行わなくてはならないという、目指す成果に対して非常に時間と手間のかかる運用開発をしなければいけません。

さらに、そのアプリに問題があり、「未定」と表示しなければならない箇所でアプリがクラッシュしてしまうビルドをリリースしてしまうと最悪です。ある一定の利用者は、不具合のあるバージョンを更新することなく、使い続け、障害が発生し続けます。それがプラットフォーマーの目に止まった場合、最悪でアプリの配信停止までありえます。

この困難さは、Web畑の開発者からの理解は難しいかもしれません。私の感覚では、モバイルアプリをリリースし運用開発を行っていくのは、コード量が同じだとするとWebクライアントの5倍大変です。5倍時間がかかるとも言えます。目標が同じなのに、4倍の回り道が追加で強いられる感覚です。

Webクライアントの運用開発

逆に、Vue や React などの Web クライアントの場合、更新が簡単な上に何か不具合があっても致命的な問題には発展しづらいため、クライアントサイドでもサーバサイドでもできるような処理は、なるべくクライアントサイドに寄せていったほうが素早いリリースが行えます。

クライアントサイドの改修ミスが、不正な支払いにつながったりセキュリティホールになることはほとんどありません(これはモバイルアプリでも言えることですが)。逆に、サーバサイド改修では、ちょっとした修正ミスがセキュリティホールにつながったりコアサービスの停止になることは少なくありません。そのため、Webクライアントのほうがサーバサイド改修より気軽に新規リリースができます。

気軽に改修できる分、どちらでも行えるような処理はWebクライアント側になるべく寄せることで、リリース頻度を高め、早く顧客体験を上げることができ、サーバの負荷軽減にもつながります。

まとめ

Webクライアントとモバイルアプリクライアントは、行う仕事としては同じようなものですが、

  • Webクライアントは更新が容易で不具合発生時のインパクトも少ないため、よりリッチに設計していったほうが良い。
  • モバイルアプリクライアントは、更新に時間がかかり、更新も強制させることはできないため、よりシンに設計し、サーバ側で表示内容などをコントロールしたほうが良い。

と、逆の運用開発方針で進めていったほうが、プロジェクトをうまく進捗できると考えています。

Webの技術でレジ(POS) を開発・運用する

当社TORICOは、主にインターネット上での書籍の販売サービス、つまりECサイトを自社開発して展開しています。

その他に、自社でイベント会場(実店舗)を営業しており、そこではお客様に会場に来てもらうことでのサービスやグッズ販売を提供しています。

実店舗を営業するにあたり、レジ(POSシステム) が必要となります。TORICOでは、POSシステムもWeb技術で自社開発し運用しています。当社と同様に Web技術で POSを開発される方に向けて、私が対応したいくつかの経験を書き残します。

サーバサイドのシステム

当社の POS システムは、40万点以上の商品を扱う必要があり、そのDBとリアルタイムに連携する必要があるのでクラウド上でのサーバサイドアプリを開発運用しています。バーコードを元に商品DBからの商品検索を行ったり、売上をDBに記録するなどの機能を担っています。一般的にECサイト開発で書くようなコードとほぼ違いはありません。通常の開発と同様に、WebセキュリティとACIDを意識して書けば問題ありません。

当社では、Django + Django Rest Framework が鉄板構成のため、今回の POSシステムのサーバサイドも Django で開発しました。

クライアントサイドのシステム

クライアント側は、大きく分けてブラウザかモバイルアプリかを使うことになります。社内スタッフしか使わないという限定的なアプリであるため、SEOやアプリストアへのレギュレーション等は考える必要が無く、コンシューマ向けアプリを作るより開発は単純化できます。

Webブラウザかモバイルアプリか。どちらにも一長一短あり、展開したい構成によってどちらが適しているか変わってきます。展開規模が多ければ、両方を作ってみるのも良いですね。

結局、当社は最初は Webブラウザで作り実運用しています。現在はモバイルアプリでの研究開発も開始しています。
Webブラウザかモバイルアプリか、両者の長所や違いについては、この後のシステム構成案の個所で再度書きます。

レシート出力方法の選択

POSシステムである以上、会計レシートの出力が必須となります。

レシートプリンタは各社から市販されていますが、主に3通りの使い方が存在します。

1. Windows のプリンタドライバ・プリントキューで印刷する

通常のプリンタと同じように、Windows のプリンタドライバとプリントキュー経由でプリントする方法です。各社から市販されているレシートプリンタは、ほとんどに Windows 用のプリンタドライバも配布されており、これを使うことで OS やブラウザの印刷機能で幅広い表現のレシートをプリントできます。

特にブラウザを使う場合、HTMLでレシートがデザインできますので、高い表現力のレシートを素早く開発することができます。レシートカッターのついているプリンタにレシートカット指示を明示的に出すことはできませんが、大抵はプリント終了時に自動でカットされます。

通常の用紙設定と違い、設定には一工夫必要ですし、ソフトウェアによっては印刷の制限があったりします。例えば Chrome では最少文字サイズが決められていたり、マージンやヘッダーのレイアウトに限界があるため、ブラウザからのレシート出力をするのであれば Firefox がおすすめです。

パソコンの中でも Window と限定しているのは、Linux, Chromebook はプリンタドライバを提供しているメーカーが少ないため除外、Mac はレジに向いている端末が無いため POSレジの候補とならないためです。

2. プリントSDK を使う

主に iOS・Android 等のモバイルアプリOSでレシートを出力するには、プリントメーカーから公開されているSDK をアプリ内に組み込んで使うのが一般的で、これ以外の方法は難しいです。Windows用のSDKを公開しているメーカーも多いです。表現力は、HTMLより数段劣りますが、応答が早く、またレシートカッターやレジドロワーなどプリント以外の機能も柔軟に使えます。

3. シリアル通信で使う

プリンタメーカーによってはシリアル通信の仕様書が公開されていますので、SDKが無い場合やSDKを使いたく無い場合には、直接シリアル通信してプリントすることになります。例えば、スター精密のプリント仕様書はこのようになります: StarPRNT 仕様書 。通信仕様を把握しないといけないため大変ですが、Python, Ruby, NodeJS, PHP など比較的モダンな言語での開発はドライバは用意されていないと思いますので、実質シリアル通信コードを書くしか方法がありません。Bluetooth 対応のレシートプリンタは、Bluetoothでペアリングを確立した後、その TTYに向けてシリアル通信を行います。

実際に書いてみると、レシートへの出力パターンはそれほど多く無く、軽量言語からシリアル通信をするのはそれほど複雑コードにはなりません。つまりどころとしては、1行の中に左寄せと右寄せの文字を同時に出したり、表を出力する時に困るぐらいでしょうか。

購入レシートなので表っぽい形式での出力は必須となるため、ここが技術的にクリアできれば問題無いといえます。

それ以外

プリンタによっては、HTTPサーバが内蔵されており、そのHTTPサーバに向かって印刷内容をリクエストすると印刷できる機能を持ったものがあります。システムを ブラウザだけで完結させるこができ、使い勝手は良いのですが、通信インフラの設置制限などを受けます。

スター精密の機種は、WebPRNT というブランド名でこの機能が搭載されています。使いたかったのですが、当社にある「mC-Print3」は無線Lanインターフェイスがなく有線LANのみ搭載で、設置環境は有線LANのケーブリングは無理だったため今回は採用できませんでした。

また、プリンタによってはクラウド経由のプリントをサポートしているものもあるようです。

バーコードリーダーとの接続方法の選択

バーコードリーダーの接続方法は、大きく分けて2つあります。

「キーボード」として認識させるもの

大抵は、バーコードリーダは「キーボード」として扱います。

バーコードを読み取ると、そのコードがキーボードの打鍵としてOSに入ってきます。これはソフトを選ばず使えるため、使い勝手は良く、大抵この方法で問題ありません。

シリアルポート接続

バーコードリーダーによっては、シリアルポートとして接続させることもできます。Bluetoothで接続でき、市販のモバイルのレジアプリとの対応を謳っている製品にはこの機能が入っていると思います。キー入力に影響が無いためアプリの自由度は高まりますが、入力を受け付けるサービスを別途用意しなければいけないので、開発が少し手間です。

クライアントシステム構成の例

当社で運用している(検討している)具体的なハードウェア構成パターンを2つ書きます。

構成1. Windows + Firefox + OSのプリントキューでレシート印刷

当社で実際の販売点で使っている構成です。

Webブラウザを使ったレジアプリの場合、ハードウェアを Windows にすると、WIndows 特有の恩寵も多く受けられる非常に低コストで素早い開発が行えます。

利点

利点としてはこのような点があげられます。

  • 機能リリース(アップデート)が簡単。ブラウザをリロードするだけで良い。
  • プリンタドライバが豊富。間違い無く用意されている。
  • レシートを HTMLでレイアウトができるため、表現力が豊富で開発も早い。

特に、アップデートが早くて簡単なのは非常に高い優位があります。

フレームワーク

Webサイトのフロントエンドフレームワークとして、Vue, React, Angular 等のモダンなフレームワークを使うことで、レスポンスの良く体験に優れた POS アプリが簡単に作れます。CSSフレームワークも、Tailwind や Bootstrap等を用いることで美しいものが手軽に作れます。

弊社の鉄板構成は、Nuxt + TypeScript + Bootstrap です。

タッチ前提のUIにすると良い

開発中は、トラックパッドやマウスなどのポインティングデバイスでの利用を考えてしまいますが、実際のレジ現場ではタッチパネルを使ったほうが断然使いやすいので、タッチを前提としたUIにした方が良いです。ハードウェアも、Windowsタブレットを採用するのが良いでしょう。

Firefoxに限定している理由

ブラウザを Firefox に限定しているのは、Chrome の場合は最少フォント制限がありレシート印刷が難しいのと、Firefox はプリント時の余白設定も柔軟に行えるためです。

Firefoxでのプリント設定例

レシートプリント時、以下の設定を行うことで、専用システムのレシート出力に比べて遜色ないプリントができます。

  1. 余白を「なし」に設定する
  2. 倍率を「100%」に固定する
  3. ヘッダー・フッターはプリントしない
  4. プリントプレビューを表示しなくする

1〜3は、メニュー内の「プリント」をクリックすることで設定できます。

倍率を100% とし、横幅の制限は HTML上で作ります。例えば80mmプリンタを使うのであれば、レシートの内容は width: 70mm 程度にしたdiv の中に組んでいき、それをプリントさせるということです。

Firefoxでプリントプレビューを表示しない

Firefoxで プリントプレビューを表示しないようにするには、

about:config を開いて、print.always_print_silent を検索し、false となっているのを true にします。

ちなみにこの設定は、プラグインで簡単に設定できないかと思ったのですが、プラグインから about:config を操作するのは無理みたいで、実現できるものは存在しませんでした。

USB電源管理を無効化する

プリンタは USBで接続することになると思いますが、Windowsは使用方法によっては USBの仮想プリンタポート番号がいつの間にか変わってしまう場合があります。それを防ぐため、下記の記事を参考に、USBでの電源管理を無効化しておくとトラブルを防げます。

Windows10 (1803) USBの仮想プリンターポートを固定化する

デバイスマネージャの「ユニバーサル シリアル バス コントローラー」の中のUSB Root HubもしくはUSB ルート ハブ(USB 3.0)のプロパティを開き 「電源の管理」タブの「電力の節約のために、コンピューターでこのデバイスの電源をオフにできるようにする(A)」のチェックを外します。 

バーコードリーダ対応ライブラリ

Vue.js でキーボードとして認識されたバーコードリーダーからのバーコード入力を読み取る用途に

vue-barcode-scanner というライブラリが開発されており、これを使うと何の問題も無くバーコードリーダーとの連携ができます。

お客様ディスプレイ

レジスタッフだけではなく、お客様にも金額を確認してもらうため、お客様用のディスプレイの用意が必要になります。

ディスプレイ自体は、1万円弱でラズパイ用のディスプレイが多く出回っているのでそれを購入し、ブラウザから window.open() 等でお客様ディスプレイ用のウインドウを出します。

レジで打っている内容を、お客様ディスプレイに反映させる方法としては、ローカルストレージを使うのが一番手軽で良いと思います。

レジでバーコードをスキャンした時、その商品名や金額、合計金額をブラウザのローカルストレージに入れる。

お客様用ディスプレイのブラウザウィンドウで稼働しているJSコードは、ローカルストレージを500msとかでポーリングして監視し、変更があったらブラウザウィンドウに描画する。

プッシュ通知や PubSub, ウェブソケット等使うより素朴ですが、ローカルストレージをポーリングする方法は構成要素も少なく、安定して稼働できると考えています。

構成2. Android + Flutter + 専用プリンタドライバ

現在、研究開発段階でまだ実用化はできていません。

Sunmi というメーカーの POS 用品が美しく、今後は使っていきたいと思っているため、Flutter でアプリ開発を初めています。

レシート出力については、flutter_sunmi_printer というライブラリが pub で公開されており、これを使うと sunmi の内蔵プリンタへの出力が容易に行えます。

テーブル出力についても、このライブラリは 「Bootstrap のように 1行を12カラムに分けてレイアウトする」という方式を取っており、比較的容易に表組みを作れました。

実は、Windows POSシステムを作ると、開発は楽なのですがセットアップの工程が多かったりトラブルも多く、あまり安定稼働に向かないと考えています。その点、Android 主体のシステムは、アプリさえしっかり書いておけば安定動作はさせやすい(機材トラブルが少ない) と考えています。

Django の ORマッパーで生成されたSQLを実行前に置換し、JOIN時のインデックスを強制する

Django には、便利な ORマッパーが搭載されており、SQLを一切書かずともRDBの操作が行えます。

今回、SQL実行時に思ったようにインデックスが使用されず、パフォーマンスが出ない問題がありました。

これは、生SQLを実行した場合も同様にインデックスが使われなかったため、Django の問題ではなく、実行計画が最適に作成されなかったというSQL上の問題(というか仕様?)です。

SQL内にインデックスヒントを強引に書き込むことでインデックスを強制した所、正常なパフォーマンスとすることができたので、その方法を書きます。

MySQLの強制インデックス

今回、SQLを発行したページは Django の Admin 内で、子モデルの Admin ページから、親モデルを select_related して、リスト表示するというコードとなっていました。

@admin.register(models.Child)
class ChildAdmin(admin.ModelAdmin):
    ...
list_select_related = (
    'parent',
)

DB の種類は MySQL です。発行される SQL は以下のようになります。

SELECT *
FROM child
INNER JOIN parent
ON child.title_id = parent.title_id
ORDER BY child.id
LIMIT 100

※ 実際には SELECT 句の中は各フィールドが明示的に書き出されます

実際にこのSQLをSQLコンソールから実行してみると、50秒ほどかかりました。

(child は約100万レコード、parent は約40万レコードほどの分量です。)

予想より多くの時間がかかっており、テーブルフルスキャンが発生している印象です。

EXPLAIN してみると、possible_keys に title_id というキーを認識しているものの、実際にはキーが使用されると判断されない状況でした。

EXPLAIN 結果

※ 実際のテーブル名は child, parent ではないため、画像を加工しています。

ためしに、認識して使用されていないキー title_id の使用を強制し、SQLを発行してみます。

SELECT *
FROM child
  INNER JOIN parent
  FORCE INDEX (title_id)
  ON child.title_id = parent.title_id
ORDER BY child.id
LIMIT 100

FORCE INDEX (title_id) を追加しています。

すると、50ミリ秒 ほどでSQLを完了することができました。今回はインデックスが活用されています。

EXPLAIN で見ても、key が使われています。

解決へのアプローチ

インデックスが使われない問題は MySQL のサーバ側にあります。インデックスの再構築などを行うことで改善する可能性はあります。

ただし、今回は MySQL サーバへの変更などは行わず、コード上の変更により、 インデックス強制の SQL をなんとか発行する方針としました。

Django の SQL 生成のフック

Django は、搭載されている OR マッパーで SQL を組み上げます。その中には、テーブルジョインする際にインデックスを指定するオプションはありません

そこで、生成されたSQL を発行前にフックし、何らかの処理(置換)を行うことで、インデックス強制をさせることを考えました。

Python は、変数のほかクラス・関数などあらゆるものがファーストクラスオブジェクトであり、使用時に上書きや代入することができます。

特に、コア機能のメソッドを外部から上書きすることで動作を変更させる手法はパッチ、もしくはモンキーパッチと言われ、フレームワークやライブラリの主要機能を一時的に書き換えることも容易に行えます。

今回は、Djangoで生成されるSQL部分をパッチすることで、SQLの置換が行えそうです。

動作の安定性を失ったり(特にスレッド安全性など)、セキュリティ上の問題も生みやすく、動作を追うことが困難になるため、安直に行うべきものではありませんが、課題の解決やビジネス成長につながるのであれば選択肢として考えることはできます。Pythonは、速度など多くの犠牲のもと、柔軟な拡張性を獲得していると言えます。

SQL生成の箇所

Django のORマッパーを追っていくと、

  1. まず Model.objectsQuerySet を生成する
  2. QuerySetQuery を作成する
  3. Query が、 SQLCompier (django.db.models.sql.compiler.SQLCompiler) を作り、 as_sql メソッドを使ってSQL を組み上げる

という動作をします。

Model > QuerySet > Query > SQLCompiler

的な感じです。(記号はイメージです。has a 関係のようなものを表しているつもりですが、厳密ではありません)

SQLCompiler.as_sql を読んでみると、200行ほどからなるそこそこ分量のあるメソッドで、その中には JOIN 時にインデックス強制をできそうなフックポイントなどは無いため、簡単に処理は追加できません。

今回は、この as_sql を一旦どこかに退避し、新しくSQL置換機能をもった as_sql を勝手に作って SQLCompler の as_sql として置き換え、その勝手に作った as_sql の中で、もともとの as_sql を呼ぶことで、機能の拡張を行うものとします。

パッチのコード

具体的なコードとしては

def patch_sql_transformer():
    """
    queryset.query に sql_transformer というメソッドを付与すると、
    生成済み SQL をその sql_transformer で処理(置換など)して返す
    """
    from django.db.models.sql.compiler import SQLCompiler
    o_as_sql = SQLCompiler.as_sql

    def _decorate_as_sql(self, *args, **kwargs):
        sql, params = o_as_sql(self, *args, **kwargs)
        transformer = getattr(self.query, 'sql_transformer', None)
        if transformer:
            sql = transformer(sql)
        return sql, params

    SQLCompiler.as_sql = _decorate_as_sql

このようなコードとしました。このコードを、アプリの起動時のどこかで1回だけ実行することで、as_sql の機能が書き換わります。

機能としては、クエリセット内の Query のインスタンスに、 sql_transformer という関数がついていれば(つけていれば)、生成された SQL をその関数を通してから実行します。

今回、sql_transformer として実行したい関数は下記のものです。

def _transform_sql(sql):
    return sql.replace(
    'INNER JOIN `parent` ON',
        'INNER JOIN `parent` FORCE INDEX (title_id) ON')

近距離パワー型のアプローチですが、INNER JOIN 句を文字列置換して、強制的にインデックスを使わせます。

今回は Admin ページ内だけでこれを適用したかったため、このメソッドを ModelAdmin の get_queryset 内で作り、Query に仕込みます。

@admin.register(models.Child)
class ChildAdmin(admin.ModelAdmin):
   ...
    def get_queryset(self, request):
        qs = super().get_queryset(request)

        def _transform_sql(sql):
            return sql.replace(
                'INNER JOIN `parent` ON',
                'INNER JOIN `parent` FORCE INDEX (title_id) ON')
        qs.query.sql_transformer = _transform_sql
        return qs
 
    list_select_related = (
        'parent',
    )
...

これにより、インデックスが強制指定で使われるようになり、速度を改善させることができました。

なぜ Query にメソッドを作るのか?

SQL の生成時は

Model > QuerySet > Query > SQLCompiler

とモデルが関係していますが、今回、なぜ半端な位置の Querysql_transformer を生やす、というデザインにしたかというと、それ以外に適した場所がなかったからです。

クエリセットを生成中の、QuerySet や、 SQLCompiler は、クエリセットをチェーンする時

例えば

qs = MyModel.objects.filter(active=True)
qs = qs.filter(item_type=xxx)
qs = qs.order_by('-id')
qs = qs.limit(100)

のようなコードの場合 (実際、Django の ModelAdmin の中では上記相当のコードが発行されています)、毎回 queryset インスタンスが作り直されます。

なので、queryset インスタンスになにかフック用の関数を付与したとしても、SQLCompiler の SQL 構築まではインスタンスが無くなり、メソッドも失われてしまいます。同様に、SQLCompiler になにか関数を作っても、クエリセットが作り直される時に消えます。

では、その中間にある Query はというと、QuerySet のコンストラクト引数として常に引き渡され、場合によっては deepcopy され、インスタンスのプロパティや変数などは大元の QuerySet がすべて消えるまで生存しており、かつ SQLCompiler の第一引数でもあるためアクセスが容易ですので、今回は Query のインスタンスを用いて関数の引き回しをすることにしました。

サーバレスアプリケーション (HTML/JSのみ) で、Google Analytics API を使ってアクティブユーザー数を表示するダッシュボードを作る

Google Analytics は、API経由で様々な数値を取得することができます。
今回は、API経由でサイトのアクティブユーザー数を取得して、Nuxtで作ったダッシュボード風JSアプリに表示してみます。

Google Analytics の APIから値を表示してウェブページに表示する場合、APIとの通信をサーバサイドで PHP や Python のプログラムで取得してウェブブラウザに表示時する方法と、ウェブブラウザ自体が直接 Google Analytics API にリクエストして表示する方法と、どちらの方法でも実現できます。

サーバサイドで行う場合、認証情報やシステムを隠蔽でき、またHTTPリクエストが無くともバックグラウンドで値を取得し続けることができるなど、大きな利点がありますが、常時起動するサーバを用意しておかないといけないため構築が若干手間です。

今回は、手間をかけずに実現したかったため、ブラウザと静的リソースのみで動作するものを作ります。
APIへの認証は、ブラウザにログインしている Google ユーザーが行います。

認証のしくみ

Googleの提供している APIは、OAuth2 の認証・認可が必要となります。

アプリのページを開くと、Google のログインページを表示して認証を求め、認証されるとダッシュボードアプリの指定したコールバックURL にリダイレクトされるようにします。

リダイレクトされると、コールバックURL末尾の # (ハッシュ, フラグメント) の後にアクセストークンが含まれた状態になりますので、それを nuxt 内の JSでパースし、ブラウザのメモリ(変数)に格納します。

注意点として、認証情報(アクセストークン)がブラウザの変数に格納されるため、XSSが発生した際にアクセストークンが漏洩するリスクがあります。これはJSで認証情報を扱う以上避けられません。

XSSによる認証情報漏洩を防ぐには、GoogleとのAPIリクエストをサーバサイドで行い、サーバとの認証は httpOnly属性のついたセッションクッキーで行うべきですが、今回は、静的リソースなのでXSSは通常発生しないという前提の元、リスクを受容した上でクライアントサイドJSで機能を提供するものとします。

コールバックURLから取得したアクセストークンを認証ヘッダに含めて、ブラウザから Google Analytics にAPIリクエストをすることで、アクティブユーザー数などを取得できます。

アクセストークンは、localStorage に保存すると、セッション終了後も保持されるため漏洩の危険性が上がります。そのため変数として保存するだけにとどめます。ただし、OAuth2の state パラメータは、ブラウザセッションが変更されても維持する必要があるため、localStorage に一時的に保存します。

アプリのページを開くたびに、OAuth2のアクセストークンをリクエストし続けるとすると、毎回 Google のアカウント選択ページが出て面倒なように感じられるかもしれませんが、実際に使ってみるとそんなことはなく、一度ブラウザと Google の認証セッションクッキーが作られればあとはリダイレクトしか発生せず、1秒程度で自動的に認証が終わりアクセストークンが取得済みの状態になりますので、使用感として悪くはありません。

 試しにAPIにリクエストする

https://developers.google.com/analytics/devguides/reporting/realtime/v3/reference/data/realtime/get?#try-it

こちらの Google アナリティクスのページを見ると、APIの説明と共に、中央もしくは右側にAPIのテストリクエストができるフォームが表示されます。

ids に、 ga: を先頭につけた GoogleAnalytics のID番号を書き、metrics は rt:activeUsers を入れ、

下部 「Google OAuth 2.0」と「API key」にチェックを入れ、「Execute」 ボタンを押します。

すると、さらに下部にレスポンスデータが表示されます。
この情報を、nuxt 等ウェブアプリケーションで取得できます。

作り方

Google Cloud Platform のプロジェクトを作る

まず、Google APIを使うため、GCPのプロジェクトを作ります。

GCPのダッシュボードの上部ヘッダから、プロジェクトを新しく作ります。
https://console.cloud.google.com/home/dashboard

ライブラリの追加

プロジェクトを作ったら、APIとサービスページを開きます。
https://console.cloud.google.com/apis/dashboard

左メニューの「ライブラリ」をクリックし、ライブラリの追加ページで、Google Analytics API と Google Analytics Reporting API を有効にします。

認証情報の追加

次は、認証情報ページを開きます。
https://console.cloud.google.com/apis/credentials

上部「認証情報を作成」リンクから、「API キー」を選択し、APIキーを一つ作ります。

続いて、「認証情報を作成」リンクから、「OAuthクライアント ID」を選択します。

アプリケーションの種類 は、今回は「ウェブアプリケーション」で、名前は、適当に「nuxt client」とかにします。

「承認済みの JavaScript 生成元」は、クロスオリジンリクエストを許可するオリジン名です。
平文 http でもOKなので、

http://localhost:3000

などを追加しておきます。

「承認済みのリダイレクト URI」は、OAuth2 の認証フローのリダイレクトURL(コールバックURL)です。
認証完了時、このURLに、アクセストークンが URLに含まれた形でリダイレクトされます。
今回は、

http://localhost:3000/code

としました。
本番用のURLが決まっていたら、その分も追加します。後からでも追加できます。

スクリーンショットの例は、ローカルPCで docker + Nginx でポート80 でサービスする場合を考慮し、
http://localhost も追加してあります。

ちなみに、クライアントID とクライアントシークレット が作成されますが、ブラウザからのリクエストの場合はクライアントシークレットは使いません。

OAuth 同意画面は、今回は社内用途のみ考慮しているので「内部」を選択し、作成します。

プロジェクトの状態によっては、この選択肢は無いかもしれません。

これで、GCP のプロジェクトの設定は終了です。

アプリを書く

今回は、nuxt + TypeScript で書きます。すべてを載せると冗長なので、要点のみ記載します。

流れとしては、

1.
まずブラウザで / ページ表示時。
最初はアクセストークンが無いため、
store/auth.ts の navigateTokenRequestUrl がコールされる。

2.
navigateTokenRequestUrl の中では、ステートパラメータを作ってローカルストレージに保存し、
Google の認証URLに遷移。

3.
認証が完了すると、リダイレクトURL である /code に着地します。

4.
/code では、URLのハッシュ(フラグメント) から、アクセストークンとステートを取得し、
ステートの一致を検証後、アクセストークンを保存し、/ に遷移します。

5.
/ では、今回はアクセストークンがあるため、
コンポーネント内でそのアクセストークンを使って Google API でリアルタイムユーザー数を取得して表示します。

6.
このアクセストークンの寿命は1時間のため、1時間するとGoogle API は http 401 を返すようになります。
その場合、もう一度アクセストークン取得URLに遷移することで、アクセストークンの取り直しをします。

この時、Google とのセッションクッキーが認証済みであれば、ユーザー操作は不要で、一瞬画面がちらつくだけでアクセストークンの更新が完了します。

設定ファイル settings.ts

export const GOOGLE_API = {
authAPIEndpoint: 'https://accounts.google.com/o/oauth2/v2/auth',
analyticsAPIEndpoint: 'https://www.googleapis.com/analytics/v3/data/realtime',
clientId: '<GoogleAPIの認証情報で作成されてたクライアントID>.apps.googleusercontent.com',
apyKey: 'AIz<GoogleAPIの認証情報で作成されてたAPIキー>o04',
scope: 'https://www.googleapis.com/auth/analytics.readonly'
}

export const GOOGLE_ANALYTICS_ACCOUNTS = [
{
id: '157xxxxx',
title: 'サイト1'
},
{
id: '872xxxxx',
title: 'サイト2'
},
]

型ファイル types/tasks.d.ts

interface TaskResult {
success: boolean;
message: string;
}

Vuex Store モジュール store/auth.ts

import { Action, Module, Mutation, VuexModule } from 'vuex-module-decorators'
import { GOOGLE_API } from '~/settings'

// OAuth2 state パラメータの localStorage一時保存用
const LOCAL_STORAGE_AUTH_STATE_KEY = 'authState'

@Module({
name: 'auth',
stateFactory: true,
namespaced: true
})
export default class extends VuexModule {
accessToken: string = ''

/**
* 認証済みか?
*/
get authorized () {
return this.accessToken !== ''
}

/**
* アクセストークンを保存
*/
@Mutation
setAccessToken (token: string) {
this.accessToken = token
}

/**
* OAuth2 認証URLに移動する
*/
@Action
navigateTokenRequestUrl () {
// 乱数で state パラメータを作成
const authState = [...Array(30)].map(
() => Math.random().toString(36)[2]).join('')
// state パラメータをローカルストレージに保存する
window.localStorage.setItem(LOCAL_STORAGE_AUTH_STATE_KEY, authState)
const params = [
['scope', GOOGLE_API.scope],
['include_granted_scopes', 'true'],
['response_type', 'token'],
['state', authState],
['redirect_uri', `${window.location.origin}/code`],
['client_id', GOOGLE_API.clientId]
]

window.location.href = `${GOOGLE_API.authAPIEndpoint}?` +
params.map(i => `${i[0]}=${encodeURIComponent(i[1])}`).join('&')
}

/**
* OAuth2認証完了後のURLのハッシュ(フラグメント)を解析して、アクセストークンを保存
*/
@Action
parseResponseParamsString (paramsString: string) : TaskResult {
// #key=value&key2=value2 形式の文字列を URLSearchParams にする
const usp = new URLSearchParams(
paramsString.replace(/^#/, '')) as any
// URLSearchParams を辞書型(マップ型)変数に変換
const paramsDict = [...usp.entries()].reduce(
(dict, e) => ({ ...dict, [e[0]]: e[1] }), {})
// localStorage に保存されている state と一致しているか検証
if (paramsDict.state !== window.localStorage.getItem(
LOCAL_STORAGE_AUTH_STATE_KEY)) {
return {
success: false,
message: 'stateが一致していません'
}
}
// state はもう使わないので消す
window.localStorage.removeItem(LOCAL_STORAGE_AUTH_STATE_KEY)
// アクセストークンがあるか検証
if (!paramsDict.access_token) {
return {
success: false,
message: 'アクセストークンが取得できません'
}
}
// アクセストークンがあったので変数に保存する。認証成功。
this.setAccessToken((paramsDict.access_token))
return {
success: true,
message: ''
}
}
}

pages/index.vue

ユーザーが最初に表示するページ

<template>
<div>
<header class="d-flex text-white p-2">
<div class="flex-grow-1 py-1">
Developer Dashboard
</div>
</header>
<div v-if="authorized">
<div class="container-fluid">
<div class="row">
<div
v-for="account in googleAnalyticsAccounts"
:key="account.id"
class="col-6 col-md-4 col-xl-3 my-3"
>
<RealtimePanel
:analytics-id="account.id"
:title="account.title"
/>
</div>
</div>
</div>
</div>
</div>
</template>

<script lang="ts">
import { Component, Vue } from 'nuxt-property-decorator'
import { authStore } from '~/store'
import RealtimePanel from '~/components/RealtimePanel.vue'
import { GOOGLE_ANALYTICS_ACCOUNTS } from '~/settings'
@Component({
components: {
RealtimePanel
}
})
export default class Index extends Vue {
get accessToken () {
return authStore.accessToken
}

get authorized () {
return authStore.authorized
}

get googleAnalyticsAccounts () {
return GOOGLE_ANALYTICS_ACCOUNTS
}

requestToken () {
authStore.navigateTokenRequestUrl()
}

mounted () {
// 認証済みでなければトークン取得URLへ遷移
if (!authStore.authorized) {
this.requestToken()
}
}
}
</script>

pages/code/index.vue

OAuth API 認証後のリダイレクトURL(コールバックURL)

<!--
OAuth2 認証後にリダイレクトされるURL
URLに含まれるハッシュ(フラグメント)から、アクセストークンを取得して変数に格納する。
-->
<template>
<div>
code received
</div>
</template>

<script lang="ts">
import { Component, Vue } from 'nuxt-property-decorator'
import { authStore } from '~/store'
@Component({
components: {
}
})
export default class Index extends Vue {
getRequestToken () {
authStore.navigateTokenRequestUrl()
}

async mounted () {
const taskResult = await authStore.parseResponseParamsString(
window.location.hash.replace(/^#/, ''))
if (!taskResult.success) {
throw new Error(taskResult.message)
}
this.$router.push('/')
}
}
</script>

components/RealtimePanel.vue

<!--
GAのアカウント1つに対応
一定時間ごとに、リアルタイムユーザー数を更新し続けるコンポーネント
-->
<template>
<div class="card">
<div class="card-header h2 py-3 text-truncate">
{{ title }}
</div>
<div class="card-body">
<div v-if="errorMessage" class="my-4">
{{ errorMessage }}
</div>
<div v-if="responseSuccess" class="text-center my-4">
<div class="display-1 fw-bold">
{{ activeUsers|addComma }}
</div>
<div class="text-muted small">
Active User
</div>
</div>
</div>
</div>
</template>
<script lang="ts">
import { Component, Vue, Prop } from 'nuxt-property-decorator'
import { authStore } from '~/store'
import { GOOGLE_API } from '~/settings'

@Component({
components: {
}
})
export default class extends Vue {
activeUsers: number | null = 0
responseSuccess: boolean = false
errorMessage: string = ''

@Prop({
type: String,
required: true
})
title!: string

@Prop({
type: String,
required: true
})
analyticsId!: string

mounted () {
this.reloadPolling()
}

reloadPolling () {
this.reload()
setTimeout(() => {
this.reloadPolling()
}, 20000)
}

async reload () {
const response = await this.$axios.get(
GOOGLE_API.analyticsAPIEndpoint, {
params: {
key: GOOGLE_API.apyKey,
ids: `ga:${this.analyticsId}`,
metrics: 'rt:activeUsers'
},
headers: {
Accept: 'application/json',
Authorization: `Bearer ${authStore.accessToken}`
},
validateStatus: _ => true
}
)
// トークン期限切れ
if (response.status === 401) {
authStore.navigateTokenRequestUrl()
return
}
// 403: アクセス過多など
if (response.status !== 200) {
this.responseSuccess = false
this.errorMessage = `ERROR: ${response.status}`
return
}
if (response.data) {
this.activeUsers = parseInt(response.data.totalsForAllResults['rt:activeUsers'])
this.responseSuccess = true
this.errorMessage = ''
}
}
}
</script>

Ubuntu server 20.04 に Rancher で Kubernetes (シングルノードk3s) + Ingress 環境を構築し、ウェブアプリをホストする

現在の最新版のRancher 2.5.2 を使った所、1年前のものと違った点で環境構築に躓いた所があったので書きます。

Rancher 添付の K3S のシングルノードクラスタで、Ingress で外部リクエストにレスポンスする所まで行います。

1. Docker エンジンのインストール

curl 'https://releases.rancher.com/install-docker/19.03.13.sh' | bash
sudo usermod -aG docker <yourname>

Ubuntu Server 20.04 のインストーラは、途中でチェックボックスでDocker をインストールできるうようになっていますが、このインストーラ途中での Docker のインストールはしないでください

Ubuntuのインストーラでインストールする Docker は、snap のものです。この snap版 Docker は、ストレージのマウントができないため、今回の Rancher の中で起動するシングルノードクラスタの中でホストのストレージをマウントさせることができません。(できそうな気がしますがわかりません)

なので、snap 版の Docker は使わず、Rancher が提供しているインストールスクリプトで Docker をインストールします。

github の https://github.com/rancher/install-docker を見ると、バージョンごとのdocker インストールスクリプトがありますので、それを使います。README にある通り、これらのスクリプトは releases.rancher.com でホストされてますので、bash で実行します。

curl 'https://releases.rancher.com/install-docker/19.03.13.sh' | bash

インストール完了時、ユーザーを docker グループに追加させるコマンドが表示されるので、実行しておきます。

sudo usermod -aG docker <yourname>

2. Rancher の実行

docker run -d --restart=unless-stopped -p 80:30080 -p 443:30443 -p 32080:80 -p 32443:443 -v /data/rancher:/var/lib/rancher -v /data:/data --privileged rancher/rancher

Rancher は、Docker コンテナとして実行するだけなので、明示的なインストールは不要です。

まず参考にするドキュメントは、Github の README が良いでしょう。 https://github.com/rancher/rancher

ここに書いてある起動スクリプト

sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher

これは、ただ起動する分には問題ありませんが、Pod の中でホストボリュームをマウントしたり、Ingress でホストリクエストを受けたりする場合に不足を感じます。

ポイントとして、k3s のシングルノードクラスタも、このコンテナ内で作られるため、Rancher起動時にホストボリュームのマウントやポート転送をしておく必要があります。

rancher イメージで指定しているポート 80 および 443 は、Rancherの Web UI および Kuberntes の API に使われるポートです。このポートを他のホストポートに逃し、80 と 443 は Ingress で受けれるようにします。

-p 32080:80 -p 32443:443 -p 80:30080 -p 443:30443

ホストの 32080と32443 を Rancherの 80, 443 へ、ホストの 80,443 を Ingress の NodePort 32080, 32443 へ転送する設定です。

また、上記のまま起動すると、コンテナ削除時に Rancher (Kubernetes) の設定が消えてしまいますので、永続化させるためにホストのボリュームをマウントします。

ホストの /data ディレクトリをすべて、Kubernetes 用とします。/data/rancher ディレクトリを作り、 -v /data/rancher:/var/lib/rancher でマウント。

さらに、ホストの /data/ をその他の Podでも使う想定のため、 -v /data:/data で Rancher コンテナにマウントしておきます。

コマンド全体としてはこのようになります。

docker run -d --restart=unless-stopped -p 80:30080 -p 443:30443 -p 32080:80 -p 32443:443 -v /data/rancher:/var/lib/rancher -v /data:/data --privileged rancher/rancher

3. kubeconfig の取得

起動できたら、ウェブブラウザで rancherのホストの 32443 ポートへリクエストします。

https://<your-rancher-host>:32443/

Adminパスワードを設定し、Webコンソールのデフォルトビューがどっちがいいか聞かれるのでどちらかを答えます。どっちでも良いですが、シングルノードの場合は Cluster Exproler のほうが見やすいと思うので右側を選択します。なお、どちらのビューでも、クリックするだけでもう一方のビューに切り替えができます。

起動したら、一旦 Cluster Manager に移動し、

Cluster を選択します。そうすると、右上に Kubeconfig file とありますので、そこをクリックします。

クリックすると Kubeconfig ファイルが表示されるので、それをコピペして、mac に .kube/config-my-cluster みたいな名前で 保存します。ファイル名の部分は適当に変更してください。

ちなみに、kubectl はすべて mac から操作すると思いますので、 Rancher 起動ホストにこの kubeconfig を保存する必要は無いと思います。

4. mac から kubectl を実行 (試しにネームスペースを作る)

kubectl が無い場合は、brew でインストールしておきます。

#!/usr/bin/env zsh
export KUBECONFIG=${HOME}/.kube/config-my-cluster
kubectl create namespace <my-namespace-name>

これを実行し、 created が表示されればOKです。 my-namespace-name は適当に決めてください。今後も出てきます。(自分の github や twitter のアカウント名で良いと思います。)

5. Ingress Controller の作成

イングレスコントローラを起動します。

普通に起動するだけなら https://github.com/kubernetes/ingress-nginx ここにあるマニフェスト

https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.41.2/deploy/static/provider/baremetal/deploy.yaml

これを、kubectl で実行するだけなのですが、これだと 80, 443 でリッスンするため Rancher コンテナ内のシングルノードクラスタでは応答できません。なので、NodePort を開けます。(もっと良い方法あるかも。ベストプラクティスがわかりませんでした)

上記 yaml マニフェストファイルをダウンロードして、270 行目あたりにある ingress-nginx-controller

サービスの項目の ports nodePort  に、30080 と 30443 を追加します。

---
# Source: ingress-nginx/templates/controller-service.yaml
apiVersion: v1
kind: Service
metadata:
annotations:
labels:
helm.sh/chart: ingress-nginx-3.10.1
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: 0.41.2
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
type: NodePort
ports:
- name: http
port: 80
protocol: TCP
targetPort: http
nodePort: 30080 # 追加
- name: https
port: 443
protocol: TCP
targetPort: https
nodePort: 30443 # 追加
selector:

そして、このマニフェストを mac から apply します。

#!/usr/bin/env zsh
export KUBECONFIG=${HOME}/.kube/config-my-cluster
kubectl apply -f ingress.yml

これで、80,443 ポートをレスポンスする準備ができました。

6. SSL(TLS)証明書があれば入れとく

#!/usr/bin/env zsh
export KUBECONFIG=${HOME}/.kube/config-my-cluster
kubectl -n <my-namespace-name> create secret tls cert-wildcard-mydomain \
  --key wildcard.mydomain.key \
  --cert wildcard.mydomain.crt

SSL 証明書の key ファイルと crt ファイルを、tls secret 「cert-wildcard-mydomain 」として 登録します。

この証明書を Ingress から使えるようになります。無ければ不要です。
(例では wildcard と書いてありますが特にワイルドカード証明書でなければいけないわけではありません)

7. 適当にサービスを作る

alpine nginx で、適当にサービスしてみます。

deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: <my-namespace-name>
name: test-alpine-deployment
spec:
selector:
matchLabels:
app: test-alpine

strategy:
type: Recreate
template:
metadata:
labels:
app: test-alpine
spec:
containers:
- image: nginx:stable-alpine
name: test-alpine
volumeMounts:
- name: test-volume
mountPath: /data/test
volumes:
- name: test-volume
hostPath:
path: /data/test  

検証用に /data/test ディレクトリをマウントしています。予め、ホスト上に /data/test ディレクトリを作っておいてください。

service.yaml
apiVersion: v1
kind: Service
metadata:
name: test-alpine-service
namespace: <my-namespace-name>
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
name: test-alpine-http
selector:
app: test-alpine
ingress.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: test-alpine-ingress
namespace: <my-namespace-name>
spec:
# 先程 SSL(TLS) 証明書をインポートした場合はここで指定
#tls:
# - hosts:
# - myhost.example.com
# secretName: cert-wildcard-mydomain
rules:
- host: myhost.example.com
http:
paths:
- path: /
backend:
serviceName: test-alpine-service
servicePort: 80

applyします

#!/usr/bin/env zsh
export KUBECONFIG=${HOME}/.kube/config-my-cluster
kubectl apply -f deployment.yaml
kubectl apply -f service.yml
kubectl apply -f ingress.yml

検証

httpサービスを検証

Rancherホストに対して、httpリクエストすると Nginxのデフォルトページが見れます。

ホストボリュームのマウントを検証

Pod にログインします。

#!/usr/bin/env zsh
export KUBECONFIG=${HOME}/.kube/config-my-cluster
podname=$(kubectl -n <my-namespace-name> get pod -l app=test-alpine -o jsonpath="{.items[0].metadata.name}")
kubectl -n <my-namespace-name> exec -it ${podname} -- /bin/ash

ログインしたら、/data/test に移動し、ファイルを作るなどしてホストの /data/test ボリュームがマウントされていることを確認します。

一定期間より昔のGmailを自動的に削除する方法 (Google Apps Script を使う)

Google Apps Script を使って、一定時間より古い Gmail を自動的に削除するスクリプトを定期動作させる方法を書きます。

ちなみに、Google Drive の容量が不足している場合、Drive にメール以外の容量の大きなファイルがあるかもしれません。Google Drive にある容量の大きなファイルは、 https://drive.google.com/drive/quota こちらから一覧で見れます。

1.

Google Apps Script のページを開く。

https://script.google.com/

もしログインしてなければ、「Start Scripting」のボタンを押してログインします。

2.

左上の「新しいプロジェクト」のボタンを押します。

3.

上の「無題のプロジェクト」をクリックし、「古いGmailを削除」にプロジェクト名を変更します。

下記のスクリプト入力欄(コード.gs)にこのスクリプトを貼り付けます。

function deleteOldGmails() {
// 1年以上前のメールを削除
var deleteThreads = GmailApp.search('older_than:1y -is:starred');
Logger.log('該当スレッド: ' + deleteThreads.length + '件');
for (var i = 0; i < deleteThreads.length; i++) {
deleteThreads[i].moveToTrash();
if (i > 1000) {
Logger.log('1000件削除しました');
break;
}
}
Logger.log('終了');
}

上記スクリプトは、1年以上前に受信したメールでスターのついていないものを、1回で1000件まで削除するスクリプトです。

一度に多くのメールを削除しようとすると、スクリプトの実行がタイムアウトすることがあります。もしスクリプトがタイムアウトするようであれば、この数(1000)は適宜減らす調整をしてください。(500とか)

すべてのメールを削除対象とせずに、特定のラベルのみ対象にする場合は、下記のようなスクリプトとします。

function deleteOldGmails() {
var queries = [
'label:削除したいラベル1',
'label:削除したいラベル2',
'category:updates',
'category:forums',
'category:promotions',
];

for(var i=0; i < queries.length; i++){
var query = queries[i];
Logger.log('削除開始:' + query);
var criteria = '' + query + ' older_than:100d -is:starred'
var deleteThreads = GmailApp.search(criteria);
Logger.log('該当スレッド: ' + deleteThreads.length + '件');
for (var j = 0; j < deleteThreads.length; j++) {
   deleteThreads[j].moveToTrash();
}
Logger.log('' + query + 'の処理を終了')
}
}

こちらの場合は、「削除したいラベル1」「削除したいラベル2」「新着」タブ、「プロモーション」タブ、「フォーラム」タブの、100日以上古い、スターのついていないメールを削除するスクリプトとなります。

4.

スクリプトを貼り付けたら、保存ボタンを押してから実行ボタンを押します。

5.

Authorization required と出たら、「許可を確認」ボタンを押します。

「アカウントを選択してください」と表示されたら、自分のアカウントを選択。

「Googleアカウントへのアクセスをリクエストしています」と出たら、「許可」をクリック。

※ ちなみに、Gsuiteではなくフリーの gmail の場合、ここですぐ「許可」ボタンは押せません。
「詳細」→「メッセージダイアログ(安全ではないページに移動)」→「許可」と押していきます。

6.

スクリプトの実行が始まります。数分で終わります。

7.

実行結果は、「表示」→「ログ」で見れます。

8.

自動実行するために、トリガーを設定します。トリガーボタンを押します。

9.

右下の「トリガーを追加」ボタンを押します。

10.

イベントのソースを選択: 時間主導型

時間ベースのトリガーのタイプを選択: 時間ベースのタイマー

時間の感覚を選択(時間): 1時間おき

のように設定して、「保存」をクリック。

これで、一定時間ごとに Gmail の削除が動作するはずです。

TORICO全社会イベント TORICO NIGHT 2019 でオペレータしました

Qiita の TORICO Advent Calendar 2019 の記事として書きました

TORICO NIGHT

TORICOでは、年2回のペースで全社員任意参加の食事会「TORICO NIGHT」を開催しています。

2017年から開始して、201911月の開催で5回を迎えました。

多くの会社は、12月に「忘年会」という形で食事会をされると思いますが、TORICO12月は商品が非常に多く売れる時期であり、物流チームも事務チームも気が抜けなくなるため、その時期を避けて秋口に食事会をします。

開催場所

TORICOでは、マンガの原画展やトークイベントを行うためのイベントスペースを自社運営しています。TORICO NIGHT を開催する際も自社イベントスペースを使うことが多くあります。

今回の TORICO NIGHT は、自社運営の池袋のイベントスペース「池袋虜」で行うこととしました。

運営スタッフ

TORICO NIGHT の運営スタッフ(幹事)は、毎回くじ引きなどで決めます。イベントの最後に、当会の幹事が決めた方法で次回幹事を決めることが多いです。2019年春のTORICO NIGHT での決め方は「役員によるくじ引き」で、私は自分自身を引き当ててしまったため2019 TORICO NIGHT の幹事となりました。

2019年秋の幹事は、部門がそれぞれ違う5名が選ばれました。その5名で、次のTORICO NIGHT の全てを決め、実施することになります。

実施6週間前

顔合わせ、役割分担決め

実施時期が近づいたので、幹事チームで集まっておおよその役割を決めます。

私は、製作物のデザインや製作、本番のPA、照明のオペレーションを担当することにしました。

その他のメンバーで、ケータリングの手配や参加者への案内、会場押さえなどをします。当日の進行は全員で作ります。

今後、週イチで一時間ほど使って幹事チームで集まることを合意し、Slackのプライベートチャンネルを作ってミーティングは終了しました。

実施5週間前

テーマ決め、ケータリング決め

会のテーマやおおよその進行を決めます。ケータリングは早めに業者を決めて、予約を取ります。

予算としては単価3000円強、ドリンク別 程度からあります。前回のケータリングの感想をメンバーで話し合いながら、良さそうな所を選定します。

今回の会のテーマとして、クイズ主体で行ってみようと決めたので、問題の提出を宿題としてMTGは終了しました。

実施4週間前

進行の詰め

全体のタイムテーブルを詰めます。

クイズ以外のゲームのテストプレイをしながら、全体の時間規模を見積もります。

この段階で必要な製作物が見えてきますし、会場設営の図面も見えてきます。

実施3週間前

必要なものの洗い出し。当日の司会進行の確認など。

私は音響と照明を担当するため、現地会場を観察しながら、機材設備の数や状態を確認します。

今回はクイズのコンテンツとして、社外の脱出イベントで見るような謎解きゲームを少し盛り込みたいと思っていたので、会場を観察してその題材も探します。

会場である池袋虜は、TORICOが運営する前はクラブとして使われていました。ワンマンオペレーションか出来るよう、ステージ上のDJ卓のまわりにPA・照明設備が配置されています。

池袋虜の図面

この形だと外音を作るのも大変ですし、画面や照明を見ながらのオペレーションができませんので、なんとか配置を直したいところです。

マルチケーブルを会場奥まで取り回して、メイン卓を移動させるのも考えましたか、1日の社内イベントのためだけにやるのは手間がかかりすぎるので低優先とし、他の方法を探します。

池袋虜のPA卓「PRESONUS StudioLive 16.0.2 USB」は、USBで接続したPCでリモートコントロールができます。調光卓も、すでにWindows PC の Surfaceでコントロールできるようになっています。そのため、15mUSBケーブルで、コントロール用のPCだけ客席に配置する方法で行くことにしました。

当日は客席の隅に私のオペレーションブースを作り、PC4台で演出をコントロールすることにします。4台の役割としては

Mac1 スライド (keynote)
Mac2 BGM (iTunes, vlc)
Mac3 PAミキサー
Win1 調光卓

となります。

1PCに複数のアプリを使って台数を減らせますが、オペレーターである私が混乱してミスをする可能性もあるため、1PCに1つのアプリでわかりやすくします。

ディスプレイは、今回は全部で3台使いました。HDMI分配器を使って全てのディスプレイに同じものを映します。

実施2週間前

クイズ問題の調整と確定

配点の計算、想定できるエラーのシミュレーション、集計と伝達方法など詰めます。

デザインクリエイティブもほぼ出来上がっているので、試し刷りをして使用感を確認します。

制作物

作ったものとしては、

  • ネームカード用紙
  • 謎解き用問題用紙
  • ドリンクメニュー
  • 会場地図
  • くじ引き用ネームカード

などを作りました。

ネームカード用紙

名刺カードにプリントしたのですが、フチなしプリントはA4に8面配置のクリアカット用紙がきれいに印刷できて使いやすく、よかったです。

四隅に色がついているのは、謎解きゲームで使うためです。

くじ引き用ネームカード

次回幹事決めのためのくじを作ります。これも名刺カードで作りました。くじ引きは電子化(アプリ化)もできますが、アプリにすると運営が操作しているように見える可能性もあるため、印刷物で作ります。

コストと使いやすさ、当選発表の時の見た目のバランスを考えて、名刺カードで刷ることにしました。自動印刷をしやすくするため、A4面付けの用紙ではなく既に名刺サイズになっている用紙を使います。

HTML + jQuery でページを作って印刷しました。

Github

HTML

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link href="business-card.css" rel="stylesheet">
    <script src="https://code.jquery.com/jquery-3.4.1.min.js"
            integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo="
            crossorigin="anonymous"></script>
</head>
<body>
<script>
const nameSource = `
漫画 全館子
スキマ ネ子
ホーリン ラブ子
まんが 王子
マンガ テンコ
`;
    const names = nameSource.split('\n').filter(i => i);
    $(function () {
        const $body = $('body');
        for (const name of names ){
            const $card = $('<section>').addClass('sheet');
            const $name = $('<div>').addClass('name');
            $name.text(name);
            const $signature = $('<div>').addClass('signature');
            $signature.text('TORICO NIGHT 2019.11');
            $card.append($name);
            $card.append($signature);
            $body.append($card);
        }
    });
</script>
</body>
</html>

SCSS

* {
  box-sizingborder-box;
}
htmlbody {
  margin0;
  padding0;
}
@page {
  size91mm 54.5mm;
  margin0;
}
@media print {
  body {
    width91mm/* needed for Chrome */
  }
}
.sheet {
  width91mm;
  height54.5mm/* 0.5mm余裕をもたせる */
  // page-break-after: always;
  page-break-beforealways;
  positionrelative;
  margin0;
  padding5mm;
  &:nth-of-type(1) {
    page-break-beforeauto;
  }
  .name {
    width100%;
    margin-top15mm;
    height10mm;
    line-height10mm;
    //border: 1px solid black;
    font-size13mm;
    text-aligncenter;
  }
  .signature {
    width100%;
    margin-top10mm;
    height10mm;
    line-height10mm;
    font-size3mm;
    color#777;
    text-aligncenter;
  }
}
/* プレビュー用のスタイル */
@media screen {
  body {
    background#eee;
  }
  .sheet {
    backgroundwhite/* 背景を白く */
    box-shadow0 .5mm 2mm rgba(000.3); /* ドロップシャドウ */
    margin5mm;
  }
}

ドリンクメニュー

てきとうに時間をかけずにささっと。

(ダサい枠線の黒丸はクイズ中の謎と関連させるためです)

実施1週間前

準備は終わっているため、大きな作業は特にありませんでした。
当日の進行やクイズ問題の出題方法の確認を行います。

また、購入物が揃っているかの確認も行っておきます。

ちなみに、Keynote のスライドは、150枚ほどになりました。スライドをしっかり組むほど、当日はリラックスしてオペレーションできます。

当日

準備通りにイベントを進行します。小さなトラブルはいくつかありましたが、リカバリしつつ無事にイベントを終えることができました。

次回運営担当者に向けて

仕事のついでに行うものなので、できる範囲で、リラックスして設計してください。ただし、自社運営会場を使う場合、ケータリングやドリンクの提供方法は、早めに決めたほうが良いでしょう。

スライドを使うのであれば、やっぱり Keynote が使いやすく美しいと思います。

一生懸命がんばっても、参加者に冷たい態度を取られることはあるかもしれません。そういった方を見つけてしまっても、心を動かされずに練習どおり最後まで通し切るのが良いでしょう。それが、他の楽しんでいる方のためになります。

Search