はじめに
AXLBIT株式会社 のAXLGEAR開発チームに所属しております、久恒（@dadada1000）です！
本記事は、「AXLLAB（旧: 社内勉強会）」にて、僕が新入社員向けに発表した内容をもとに構成しています。
個人的にはより良いサービスを作る上で、ユーザー目線の視点を持って開発するということが他の何(技術力向上 / ライブラリ知識の獲得 etc)よりも重要な事項だと感じているので、その点だけでもまずは押さえていただきたいな、という想いを抱いて発表に臨みました。
目次
発表内容
僕が発表した内容は、大きく分けて
の3つのセクションに分かれてます。
順に軽く紹介していきます！
1. クラウドって何？
まず初めに、[クラウド]とは何なのか、ということをNIST(米国国立標準技術研究所)による定義1に沿って概説をしました。
↓(一部抜粋)
どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセスすることを可能とするモデルであり、最小限の利用手続きまたはサービスプロバイダとのやりとりで速やかに割り当てられ提供されるものである。このクラウドモデルは5つの基本的特徴 と 3つのサービスモデル, 4つの実装モデル によって構成される。
また、そのうち3つのサービスモデル(IaaS/PaaS/SaaS)の違いについては、 共同責任モデル がとっかかりやすい概念だと思い、その部分に関しては以下の表を用いて詳解しました！
共同責任モデル（Shared Responsibility Model）
↓AXLLAB内で使用したスライド抜粋
2. AXLGEARを取り巻くビジネスモデル
次に、AXLGEAR2は「契約管理SaaS」をコンセプトにしており、顧客の主な利用ケースの一つとして以下のような形があることを図解しました。なお、本記事においては図は省略します。
主な登場人物（4社）
- ベンダー/メーカー
- ディストリビューター/プロバイダー (← ここに位置する法人がAXLGEARのメインユーザー！)
- リセラー (← この法人も対象です！)
- カスタマー/エンドユーザー
このケースでのビジネスモデル
- ベンダー/メーカー => ディストリビューター/プロバイダー： (ソフトウェア)製品 提供
- ディストリビューター/プロバイダー => リセラー： 再販/サポート/クレジット(信用) 提供
- リセラー => カスタマー/エンドユーザー ： 販売/サポート(導入支援) 提供
3. 押さえておきたい開発の心得2つ
最後に、3つ目のテーマとして、僕が普段意識している開発の心得的なものも2つほど共有いたしました。
あ、ちなみにどちらも僕の造語です笑
開発の心得① Fail than Poisoning: 汚染よりも失敗を
(※ 今更ですが、[Fail First] の方が適切かなとか思ってます)
この心得に関しては、まず、以下の2ケースでどちらがより回避しなければならない事象なのかどうかを質問形式で提示し、続けて僕が思う、より避けなければならないケースとその理由を解説しました。
また、続けてDjangoのORMであるQuerySet3を例に挙げて良し悪しそれぞれのコード例も紹介しました。
ケース比較（どちらを防ぐべき？）
- Case A：エラーを吐いて業務が止まってしまう (= Fail)
- Case B：エラーを握り潰して、裏でデータ破壊（= Poisoning）
より回避すべきはCase B！
Case B の方が回避をしなければならない理由 2選
- すぐには異常に気づけない
- 異常データが紛れ込んだ時、復旧コストも膨大に要してしまう
コード例
悪い例
例に挙げたのは、.filter(~).first() を使用すること。
このケースでは 条件に合致するデータがない場合は[None]が、複数合致した場合には一つ目が取得できてしまい、エラーが発生せず、そのまま後続の関数some_funcが呼び出されてしまいます。
model_obj = Model.objects.filter(~).first()
some_func(model_obj)
良い例
良い例として、.get(~) / .filter(~).get() を利用すること。
これは先述の.first()と異なり、データがない場合にはObjectDoesNotExistのエラーが、複数合致した場合には MultipleObjectsReturned のエラーがそれぞれ発生します。
その上で、下記のコード例のように try ~ except構文の中で適切なエラーハンドリングを施して、意図しない処理の実行をなるべく避けましょう、とお話ししました。
try:
model_obj = Model.objects.get(~)
some_func(model_obj)
except Model.DoesNotExist as e:
handle_not_exist(e)
except Model.MultipleObjectsReturned as e:
handle_multiple_exists(e)
開発の心得②：Self-Service Support: 顧客(ディストリビューター/リセラー)が自己解決できる仕組みを
本記事では、こちらに関しては僕が伝えたい心得として選んだ理由を簡潔に2つほど紹介します。この心得は一般的なFAQと同じ類のものですね。
1. 運用対応工数の削減につながる
顧客（ディストリビューター）が自力で問題を解決できるようになるため、AXLBITへの問い合わせ件数が減少する。
また、カスタマーサポートから開発部門への仕様の確認も減るので、開発者側も開発に集中しやすくなる。
2. 実運用を意識した実装が可能
「どんな使い方がされるのか？」「どんなエラーを出すべきか？」という観点で開発できるようになり、ユーザーに即した機能開発がしやすくなります。
おわりに
今回ご紹介した内容は、今年4月4日に開催した社内勉強会(AXLLAB)で発表したもので、新人時代の自分に教えたかったことを詰め込んだ内容になっています。
といいつつも、話したビジネスモデルに関しては、想定顧客のごく一側面を切り取ったにしか過ぎず、また、その切り取った部分の解像度もまだまだ荒い状態です。ですので、僕自身現状に甘んじず、今後も貪欲に知識を吸収していきたい所存です。
また、今回ご紹介した開発の2つの心得
- Fail than Poisoning：問題は早く・大きく・明示的に表面化させよう
- Self-Service Support：顧客に自走してもらう仕組みがAXLBIT開発者と運用者の両方を救う
は、どちらも僕の開発経験から導き出した、地に足のついた考え方だと思います。
新人向けという体裁をとってはいますが、経験を重ねたエンジニアの方にも「そうだよな」と共感していただける部分があれば嬉しい限りです。
現場で実践し、改善し、また次の誰かに伝えていく。
そんな循環の一助になれば幸いです。
ちなみに発表は「AXLGEAR 開発のすゝめ」というタイトルでお話ししました。