別のプラットフォームを提供しているアプリ作成時注意点
別のプラットフォームでのアプリを作成したのですが、自分の属するプロダクトでは初の試みだったので、そこでの注意点を残しておきます。
今回の記事では当該プラットフォーマーを他社と表記します。
今回は他社の担当の方(アプリケーションの設計等に関する事柄に対応していただける方)に協力をしていただいています。
他社用語がわからない
発生する問題
当然のことですが、他社での用語を学習する必要があります。
MTGや資料では、他社製品導入後の話のレベルでのやり取りが多く、略語で語られるケースも多くありました。
HPでは正式名称で表示されていますが、資料上は略名で表記されているケースが散見されます。
そうなるとよくある 「わからない用語でわからない用語を説明される」 状態に陥ります。
対処方法
基本的に用語集があれば提供してもらえればいいですが、用意していることはあまりないと思います。
なので、都度用語集を作り忘れないようにする(MTG時も用語集を見ながら話す) が良いのかなと思います。
製品の名称などの表記やロゴの扱いを粗末にする
発生する問題
著作権法や商標法に違反する可能性があり、大きな問題になる可能性があります。
対処方法
他社のHPに商標に関するページがあればそれを確認しましょう。
無ければ必ず他社の担当の方に伺いましょう。
また、他社に対しても、自社の製品やロゴを提供する際には社内の権利の担当者に確認をしましょう。
商用環境と開発環境の差異の考慮ができていない
発生する問題
商用環境ではお客様がそれを気にすることがなく、コンサル側ですでにセットアップの一環として設定されているものが開発環境では存在しないことがあります。
例えば、海外の会社の製品で標準が英語であるが、日本企業が導入する場合には日本語の言語パックが提供されていて、それをコンサル側で適用している。この時に開発環境にはそのパックが当たっていないなどして、手動で入れる必要があったりします。
対処方法
こちらも 他社の担当者と他社コンサルの方に確認しましょう。
事前に構想が練られている場合はそのアプリケーションの開発に必要なコンポーネントに必要なプラグインやセットアップがないか確認できると尚よいでしょう。
自社と他社での同一用語で別の意味を持つ単語のケア
発生する問題
e.g. コードを管理する項目があった場合に以下の違いがあったとします。
・自社ではコードというものは一意性が担保されているもの
・他社ではコードというものは一意性が担保されていないもの
この時にバイアスがかかったままでアプリケーションの設計を進めると、
一意性が担保されておらず不整合なデータを生み出してしまったり、開発がおおよそ完了したタイミングのレビューで実装がひっくりかえる可能性があります。
自社では重要とされない情報が、他社では重要とされる情報である可能性もあります。
対処方法
こちらについては実際に知らないと回避ができない側面もあると思います。
すべての項目に対して精査するのは非常に難しいし時間もかかるので、 アプリケーションの構想において重要な項目だけでも事前に確認しましょう。
キャッチアップの範囲を考える
発生する問題
他社のプラットフォームで開発する場合当然ですが、キャッチアップが必要になります。
この時に キャッチアップマニュアルのすべてを実施しようとすると、かなりの時間がかかることになります。
(マニュアルがそのプラットフォームでできることすべてについての説明になっていることが非常に多いです)
対処方法
アプリケーションの構成上 最低限必要だと思われるところを他社の担当者方とすり合わせをしましょう。
追加で必要になったものがあれば、そのタイミングでキャッチアップしましょう。
文字コードやタイムゾーンや規格の違いに注意する
発生する問題
自社と他社では扱いが違うものがあることに留意しましょう。
・自社と他社でタイムゾーンが違っていた
e.g. 自社ではAsia/Tokyo、他社ではAmerica/New_Yorkを利用している
・文字コードがUTF-8だった
e.g. 自社ではSJIS、他社ではUTF8を利用している
・ISO規格を利用していた
e.g. 自社ではJIS規格、他社ではISO規格を利用している
対処方法
事前に上で記載した範囲に関しては確認しておくのが良いかもしれません。
(バイアスにかかりやす、且つ、食い違いが発生しやすい箇所だと思われるため)
出荷プロセスの違いに注意する
発生する問題
自社での出荷プロセスもあると思いますが、他社のアプリケーションを出荷するので他社でのアプリケーション出荷プロセスにも則る必要があります。
自社では存在しないプロセスが存在している可能性も往々にしてあると思います。
対処方法
事前にどういったレビューがあるのか、それに対してどれくらいの工数がかかるのかを確認しておく。
これにより少なくとも工数の見積もりでレビュー自体の工数が漏れている、という事態は防ぐことができると思います。
ちなみに、提示される工数は「担当者から出される工数は慣れている人がやった場合に」の場合があるのでバッファを積んでおくと良いと思います。
開発環境を整える
発生する問題
基本的にデフォルトのセットアップ環境を借りれる可能性が高いがゆえに、開発をしにくい環境の設定 になっていることもあります。
e.g. セッションタイムアウトの時間が標準10分になっている
セッションタイムアウトが短いと、何か調べものをしたりしていて、その間にセッションが切れてログインしなおしになるなど問題が発生します
対処方法
開発がしやすい環境になるように設定をしましょう。
担当の方から、開発環境用の設定などについて確認しておきましょう。
ただし、テストの際には実際の商用環境の設定に合わせた状態でテストができるように変更箇所をどこかに残しておきましょう。
アプリケーションの出荷範囲を協議する
発生する問題
やりたいことを自社のシステムで対応するのか他社のアプリケーションで対応するのかを決めましょう。
プラットフォームの場合できないとなるとプラットフォーム側(なので他社システム側)を改修する必要があります。
対処方法
プラットフォームの機能を確認しましょう。
相手側プラットフォームであるだろうのバイアスをぬぐって、あると思っていてもそういった機能があることを逐次確認することが大事です。
ユーザーの利用者数
発生する問題
自社のシステムの利用者の想定と、そのアプリの利用者の想定が違うことはあります。
そういった場合にアプリの利用者が想定より少なかったり多かったりすると、本来不要なコストがかかってしまったり、
多い場合はシステムが運用に耐えられなかったりしてしまいます。
対処方法
ユーザーの規模から想定して考えましょう。
例えば上場企業が利用する場合、MAXは約7万人ほどになります。
ターゲットユーザーがこの規模の場合には対応する必要があります。
しかし、上場企業の平均の社員数は約4600人なので切り上げて5000人をサポートする形でスモールスタートを切るなどしてもいいでしょう。
もちろんですが、全従業員が利用するものなのかどうかで利用者数は変化しますし、ピークタイムでの利用者はまた別になってくると思います。
初期リリースとバージョンアップリリースの差異
発生する問題
初期リリースでかかった期間や工数がそのままバージョンアップリリースでもかかるわけではありません。
当然ですが、担当者のノウハウもたまりますし、出荷に対するフローも異なるケースがあります。
対処方法
ドキュメント類に関しては 「何が必要なのか」 を確認しましょう
実装範囲に関しては 「次のバージョンで何をリリースしようと思っているのか」 を確認しましょう
その実装に関しては 「追加でどのようなキャッチアップが必要なのか」 を確認しましょう
ログや通知の受け取りについて
発生する問題
アプリに関しては、当然完全ではありません。
エラーが発生して処理が終了することもありますし、アプリとしてわざとエラーにする場合もあります。
対処方法
「ユーザーにどのように見せるか、通知するのか」 考える必要があります。
ログがどこにでるのか・どう見えるのか、通知はどのように実施するのか、誰に届けるのが適切なのかを考えましょう。
料金について
発生する問題
自社の利益の源泉となりますので、アプリへの課金については深く考える必要があります。
課金の種類についても、従量課金制をとるのか逓減課金制をとるのか、買い切りとするのか考える必要はあります。
また、その場合にどういった料金設定にするのかを考えなければなりません。
対処方法
「どの課金の方式がプラットフォーム側に存在しているのか」 確認が必要です。
また、「課金のキーとなる動作等」 を確認する必要があります。
例えば、ユーザー数課金で特定のフィールド(アクティブ/非アクティブ管理されている等)がアクティブの場合に料金として加算されるなど。
自社システムの他の機能に関する知識
発生する問題
自社のシステムが巨大な場合、自分の通常の担当の範囲外のことであっても、他社から確認されれば、返答や対応が必要になります。
実際、自分がわからないことを聞かれることも多くありました。
対処方法
他社の担当者の方から聞かれたことなどを、細かくまとめましょう。
自分で調べたうえで、わからなければ担当のチームの方に連携して確認しましょう。
まとめ
個人的に思ったこと
私個人として感じたことは以下です。
・バイアスを捨てて確認をすること
全体を通していえることですが、「〇〇だろう」のバイアスを捨てること、そして確認をすることが大切だと思いました。
実際に確認をしたところ、思っていたものとは違う回答が返ってくることは往々にしてありました。
細かく確認することによって、実は違ったという場合の手戻りを少なくすることができました。
・すぐに聞くこと
わからないことはチーム内外を問わず、確認をしました。
それによって他社との定例の会議で詰まることがなく、議論を進めることができました。
・問題を切り分けて細かくすること
かなり深刻だったのがモチベーション問題でした。
なぜかというと知っていればできるであろうことが知識がないがゆえにできないからです。
モチベーションを保つためにTODOとして通常時よりも細分化しました。
ある程度大きい問題にしてしまうと、それが解決しないがゆえにモチベーションも落ちてきます。
細かく切り分けることで、プチプチを潰すように楽しみながら進めることができました。
細分化することで