「ITは初心者」の方向け解説 発注側が知っておきたい、kintone開発会社の評価基準
この記事は？
この記事は kintoneアドベントカレンダー2022 第2面 23日目の記事です。
誰が書いたの？
Polaris Infotech株式会社、情報親方こと東野誠です。
小学生時代にMSXでBASICをたしなみ、大学でFORTRANに触れ、社会人で旧GoogleApps導入スペシャリストの資格をとったけど資格自体が消滅したり、帳票系IT企業でマニュアル書いてたけど退職後にその会社が上場したり・・・、開発現場も知ってるけどエンジニアにはなってないテクニカルライティング/インフォメーションアーキテクト方面の人です。
法人として、製品やサービスの取扱説明書（最近は業務マニュアルやデザインも動画も）制作しています。取扱説明書の制作歴は今年で24年目になります。
2019年にkintone導入ガイドブックを弊社で制作させていただいた関係で、なぜかkintoneの問い合わせをいただくことがあります。
取扱説明書制作のプロがkintoneの導入ガイドブックをガチで作ってみた
ありがたや～。
「このガイドブック作った人だったらいろいろ知ってるだろう。」
「kintoneできる技術者知らない？」
「うちもkintone入れたいんだけど相談乗ってくれる？」
「どのサービスがいいの？」
そんな感じで、受注側としても発注側としても、kintoneの導入に関わることが多くなりました。
ただ・・・泥臭い、ダサい現場もみています。
今回は悪手kintone導入現場から、
ITは初心者の方でも、kintone開発発注時にリスクを少なくするポイントをじぶんなりにまとめて行きたいと思います。
kintoneと他のサービス開発と異なるところ
kintoneの裾野が広がると、ITに詳しくない人もkintoneに興味を持つようになります。（kintoneに限らずですが。）
kintoneは、スタンダードコースならAPIやJavaScriptなどを駆使していろいろ連携したり、細かなカスタマイズができてしまいます。
ただ、
いろいろできてしまうからといって自由にやってもいいわけではない
ですし、
スキルや技術的により「できる」ことと、ビジネスで実装してスムーズに運用できることは同列ではありません。
たとえば発注側の人、こんなことあったらどうしますか？
開発者に「できるか？」と聞くと、すぐに「できる」という。
「じゃあやってみて」と言うと、「それっぽいの」ができる。
「できたー！もちろん検証もしてるよね？」と聞くと、「してる」という。
納品すると、チョコ停の嵐。
なぜ！？
こんな残念なことですが、実際に起こりえる話です。
2023以降はそういう無毛なやりとりは繰り返したくないので、
いったい何が原因か、対策はどのようにすれば良いか
を自分なりに整理してみました。
ITは初心者の方向け解説。「開発」って？
ここで開発の大まかな手順を整理したいと思います。
晴れて受発注がまとまったあと、開発会社ではこんなことをしています。
要件定義：着手前に、必要な機能や要求をわかりやすく図や書類にまとめていく。★
外部設計：クライアントの意見をもとに詳細を決める。
内部設計：外部設計が実現できるように開発者がどこまで手を入れられるか決める。★
実装（プログラミング）：アプリ制作や、いわゆるコーディング。
検証：変更部分もそうでない部分も設計通り動くか、現場で停まるような事態にならないか確認する。★
納品（引き渡し）：現場での運用スタート。
運用保守：kintoneは納品時点で完成じゃないです。うまく組織になじむようにチューニングしていく。
（★印、特に重要です。）
発注側が知っておきたい、kintone開発会社の評価基準
ビジネスとしての発注評価基準は各社あると思うので割愛し、kintone導入に起こりやすい点をまとめてみます。
実績
あれば良いが、多くあるからと言って自社にいいものができるとは限らない。
「職種」が多い環境へのkintone導入や保守の経験があれば、「kintoneの変化球」をさまざま学んでいると思われるので良いかもしれない。
補助金獲得のためや、人柄やトークのうまさで導入が決まっているケースもある。
導入実績にあわせてパッケージを多く作っているところは、パッケージを出すことでリスクを下げてるので、ある程度信頼がおける。
思考
理系の脳みそを持ったロジカルな思考ができるエンジニアがいて欲しい。
ロジカルな思考ができるポイントは「JavaScriptコードの長さ」や「検証してるかどうか」に現れる。
専門性
更新情報や連携サービスの情報を知っていたからと言って、そのままビジネスに使えるわけではない。重要なのはクライアントのやりたいことを堅牢性をもって実現できるか。
なんでもアプリつなぎまっせ、というアプリのデパートのような人よりは特定のアプリに海よりも深い知識と経験（＝バグが起きない）があるほうがいい。
スピード感
早すぎることが重要とは限らない。
応対に堅牢性があり、着実にこなせるスピード感が重要。
連携する他サービス
サービスをつなぐ勘所でエンジニアのセンスが出る。
野良サーバ/サービスをできるだけ使わない。
エンジニアのアカウントで契約したサーバ/サービスは使わない。ほぼほぼ罠。
サーバ/サービスのリスクをきちんと伝えられるか。
信頼性とリカバリー
システム停止するようなバグを出す場合は、設計や検証に手薄な傾向がある。
仮にバグを出しても適切な手法で潰せるか、アフターフォローができるかも重要。
システムの信頼性と同じくらい、開発側の信頼性も大事。
トータルコスト
開発会社が提示する金額は希望する機能をどこまで含んでいるか、含んでいなければ何か？
システムがまともに動作しなくなった場合に開発費をどのくらい投入できるか？ （設計ミスによる費用を除く）
キーワード別！ ダサダサ開発をこうしてクリア！
連携する他サービス
無料の野良サーバ／サービスを利用しない。利用する場合でも十分な検証と、クライアントとの同意を得ましょう。もちろん何のリスクがあるかを説明できないエンジニアはNGです。
連携サービスで使うアカウントは自社に紐付いていますか？ 開発者のアカウントで契約したサービスであれば、その開発者がいなくなったときに、自社サービスが止まります。そのリスクを先に知っておく必要があります。
外部サービスを多く使うと、外部サービスへのコストが無視できなくなります。場合によりリスクになり得ます。JavaScriptを使用したkintoneのカスタマイズをする際は、利用に応じて課金される状況も生まれ、制限値を越えたために動かなかったり、無駄なRESTAPIでお金がかさんだり・・・いろいろ出てきます。
設計
疑問に思った業務フローは、臆せず質問しましょう。その回答で開発側のスタンスが明確になります。
まず手を動かしたあとで「さあどう全体を作ろうか」という泥縄式設計は、要件定義がまともにできてない可能性があります。存分に疑いましょう。
開発前にユースケースの洗い出しがされていない場合や、意思決定者と認識を合わせられていない場合など、将来のトラブルが予想されます。
開発（アプリ）
kintoneのアプリは「すぐ変更できる」のですが、生まれたばかりのアプリは単なるプロトタイプです。
作ったら終わりになってませんか？
実際に現場で運用と改善してみましたか？
要件（目的）をもって作られていますか？
開発（コーディング/スタンダードコース）
クライアントはITを知らないと想定して、JavaScriptの駄コードが放置されているかもしれません。すごく単純なことをしてるのに確認したらコードが長い長い長ーい場合、他のエンジニアにセカンドオピニオンを求めましょう。
コードを書いたら動いたから/自社の実績にしたいからと言う理由で、検証もなくフルスクラッチでJavaScriptをコーディングするのは悪手です。できるだけリスクヘッジするため、標準機能のままで使うか、パッケージ化されたサービスを使うことが良いです。パッケージ化されて販売までされているサービスは検証がすすみ、販売の課程でもある程度バグ出しはすんだ後であれば品質が担保され、将来バグが出るリスクも減らせます。
ライブラリ（多くの人が作成する事になる汎用的に使うプログラムだけ取り出してまとめた物）を複数使用するような機能があれば、ちゃんとプラグイン化しているか確認しましょう。保守性が下がります。
本番環境とは別にテスト環境が用意されていない場合、システムやアプリのアップデート時にシステムを停めざるを得ない事態がやってきます。
Githubなどを使ってソースやプラグインのバージョン管理がされていない。
検証
テストケース作成や検証をしていないか、スキル的にできない。
発生した障害に対して水平展開をしていない。（同じ事が二度三度～N度おこります。）
バグ修正後にリグレッションテスト（バグ箇所以外の動作検証）が行われていない。
開発者と検証者が同一人物。ひとりでチェックすると見つかりにくいんです。
請求
根拠に基づく費用算出をしているかどうか確認する。どんぶり感情で算出された費用をスルーしない。
開発者の設計ミスが改修費用に含まれている。時と場合によりますが、これが頻繁に繰り返される場合は開発者を変えた方がいいです。
モラル
作成したコードは、他社の権利を抵触するものでは？ 規約で転用禁止の制約をもうけたい。
規約で中抜き取引を禁止しているのに、こっそりと中抜き取引をもちかけてくる。
急ぎ案件がある晩に、ウイスキーを飲んでる写真をSNSにアップロードし、その後コーディングをミスる。
2023年も良いkintoneYearにしましょう！
～追記～
kintone界隈で、過去当社で動画マニュアルを一度だけ制作し、提供した開発業者が「kintoneの動画マニュアルつくれます」とLTなどで謳っているようですが、その制作以降、当社とは一切の関わりありませんことご注意ください。
いいなと思ったら応援しよう！
