Azure Functions従量課金プランのコールドスタート時間が実用レベルになっていた
最近、サーバーレスでガッツリ開発を行っている取引先（元上司と元同僚が、うちとは別系統で独立した社）から、「Azure Functionsのコールドスタートが速くなった」という情報を聞いたので、試してみた。
計測方法
- Google Chromeの開発者ツールで手動でアクセスし、レスポンスタイムを測定。
- 2018/09/29-30の不定期に実施。Cold Startになるように20分以上測定時間をあける。
- 測定環境
- 愛知県名古屋市内
- いわゆる集合住宅のインターネット回線であまり品質は高くない。たびたびスローダウンする。
- 計測誤差が大きい環境であることは留意が必要。
- Azure Functionsは下記の通りに設定。
- 西日本
- 従量課金
- v2
- JavaScript
- PHP無効化
- FTP無効化
検証時に使ったコード
module.exports = async function (context, req) { context.log('JavaScript HTTP trigger function processed a request.'); context.res = { body: "hello" } };
計測結果
体感的には5-8sec。たまに速かったり遅かったり。ちなみに、コールドスタート完了後は数10～100msec程度でレスポンスが返ってくる。
| Item | Time[sec] |
|---|---|
| Average | 6.80 |
| Median | 6.16 |
| Max | 15.86 |
| Min | 4.25 |
| 80th percentile | 7.324 |
| 85th percentile | 8.755 |
| 90th percentile | 10.852 |
N = 105
まとめ
現時点ではコールドスタートは10秒程度を考えて設計すればよさそう。決して速い訳ではないが「まれに10秒程度待たされることがある」という程度ならば、Web APIとして使うとしても許容範囲内になってきたと思う。今後（半年スパンぐらい？で）、さらに改善されてくるはずなので、今から使い始めてみるのは悪くないタイミングではないかと思う。
Azure Functionsはざっくり、
- Azure App Service（もっと厳密にはWebJobs）上で実行されている
- JavaScriptの場合は、.NET Coreで実装されたサービスプロセスからNode.jsが実行されれる
- ユーザープログラムはコールドスタート時にAzure Filesから読みこむ
という構造になっている。Azure Filesが遅いと言われているのだが、いわゆるBundleを行って1ファイルにまとめたJavaScriptコードであれば、多少ファイルサイズが大きくなってもコールドスタート時間への影響は大きくないはずである。
しかし、過去に何度かAzure Functionsのコールドスタートを計測してきているのだが、サービス開始直後ぐらいは90秒ぐらいかかっていて、2017年11月ぐらいで20秒ぐらいかかっていた事を考えると、本当にめでたい。
Azure Functions従量課金プランのcold startでも10秒以内に収まるぐらいに改善したんだったら、割と積極的に使ってもいいかなぁという感じになる。前は60秒以上待たされてたからな…
— てるろー (@terurou) 2017年11月22日
Azure Functionsのcold start timeを何度か計測していて、母数が少ないのだけど、 ほぼ20secかなあという雰囲気。これに実行対象モジュールのロード（これも遅い）とか入るので…。という感じ。まぁでも、数か月前に計測してた時は60-90secぐらいかかってたので大分改善した
— てるろー (@terurou) 2017年11月23日
あわせて読みたい
次にソフトウェアエンジニア採用した際に教材にしたい本（基礎教養部分）
受託の仕事がひと段落したので、現実逃避がてら内容が古い・良くない社内図書の整理を行っていた。整理しながら「そういえば基礎教養部分の社員教育カリキュラムがまったく準備できてないなぁ」と思い、社内図書をベースに教育用に課す本を考えてみた。
以前から「日本語作文能力が足りない～」と言ってきていたのだが、それに対しての現時点の暫定解がこれかなぁと思っている。
世界一やさしい課題解決の授業
世界一やさしい問題解決の授業―自分で考え、行動する力が身につく
posted with amazlet at 18.09.25
とりあえず最初に読む本。ごく当たり前の話がサクっと書いてあるが、意識がないと全く身についてない話でもある。
読むだけなら数時間（読むのが早い人であれば、30分もあれば読める）、演習もやるなら1日～1.5日程度。
デキる大人の文章力教室（暫定、省略可）
類書は多いので、別にこれでなくてもよい。軽く数時間～半日読んで、手元に置いて必要時に読み返せれば十分。
新卒採用の初っ端によく見る「学生っぽい幼稚な文章表現」を矯正する（認知させる）ために使う。切り口は違うのだが、後述の「数学文章作法」と被る内容も多いので、教育時間がなかったり、2年ぐらいの業務経験がある人なら省略してもいいかもしれない。
数学文章作法 基礎編・推敲編
THE 基礎教養。仕事で日本語文章を書く全ての人間は読むべき。
ページ数が少ない本ではあるが、1日～2日程度かけてじっくり読んだ方がいい。時間的に早く読み終わってしまった場合は、休憩を挟んで読み直しさせるのもいいぐらい。
類書に有名な「理科系の作文技術」があるが、今なら「数学文章作法」だけで十分だと思う。「理科系の作文技術」は名著であることは間違いないのだが、エピソードトークみたいなものが若干多いせいで内容が分かりづらくなっている面もあり、「数学文章作法」の登場によって役目は果たしたのかなと思う。
「聞く技術」が人を動かす（暫定、省略可）
「聞く技術」が人を動かす―ビジネス・人間関係を制す最終兵器 (知恵の森文庫)
posted with amazlet at 18.09.25
伊東 明
光文社
売り上げランキング: 172,217
光文社
売り上げランキング: 172,217
端的には「相手を怒らせない」「相手のモチベーションを下げない」受け答えの仕方が書かれた本。教育側が「他人との会話が得意ではないな」と感じた場合は読ませた方がよい。話すのが得意なタイプであれば省略しても構わない。
数時間～半日程度で読んだら、手元に置いておいて何度も見返すタイプの本。ただ、この本は若干読みづらいなとは思っているので、もっと良い類書が見つかれば差し替えると思う。
メール文章力の基本 大切だけど、だれも教えてくれない77のルール（暫定、省略可）
メール文章力の基本 大切だけど、だれも教えてくれない77のルール
posted with amazlet at 18.09.25
類書は多いので、これも別にこの本でなくても構わない。これも数時間～半日程度読んで、手元に置いて必要時に読み直すタイプの本。
新卒採用の場合は必読として、中途採用でもメール文章を書くのが苦手な人（もしくはあまり書いてきてない人）は割と見かけるので、念のため読んでもらった方がいい。仕事で出すメールなんてほとんどのケースが定型なのだけど、定型文をちゃんと学習できてないことで、メールの往復回数が無駄に多くなって時間を無駄にしたり、「お前それ喧嘩売ってるよね」みたいな文章を平気で出してトラブルになってしまったりする事故を未然に防ぐことができる。
顧客折衝をガンガンやってきましたみたいな人の場合は、当然読まなくてよい。
考える技術・書く技術
考える技術・書く技術―問題解決力を伸ばすピラミッド原則
posted with amazlet at 18.09.25
ロジカルシンキング・ロジカルライティングの名著。前述までの本とは違って、一気に難易度が上がるのだが、世の中のロジカルシンキング・ロジカルライティング本は大体これの派生みたいな感じがあるので、最初からこれを読んだ方がよい。
できれば1週間ぐらいかけて、要約しながら読むという感じで進めたい。
プログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと（省略可）
プログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと
posted with amazlet at 18.09.25
これは厳密には基礎教養というよりかは、おっさんが話す「やらかさないようにこうした方がええで」とか「業界で食ってくならこういう立ち振る舞いをしたほうがええで」的な経験則に沿った内容を体系立てて1冊にまとめた本というべきか。受託開発ありきな内容に若干偏っているところがあり、ここが会社によっては合わないかもしれない。
これは半日ぐらいかけて読んでもらって、半年後とか1年後とかにもう一回読んでもらうとよさそう。時間にあまり余裕がない場合は、教える側の判断で後述の「エンジニアの知的生産術」と排他選択でよいと思う。
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする（省略可）
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
posted with amazlet at 18.09.25
どのように勉強したり思考したりすると良いのかが、人間の認知構造をベースに解説されている。
正直、読む人を選ぶなという感触があって、ボトムアップで思考する傾向のある人（もしくは内向的・自閉傾向がある人）に向いているなと思う。一方で前述の「プログラムは技術だけでは動かない」のようなトップダウン・経験則な面から入った方からとっつきやすいタイプもいるので、教える側の判断で排他選択でいいかなという気がしている。もちろん、時間が許せば両方読むに越したことはない。
この本は理詰めで書かれてる分、流し読みでは内容を理解することが難しいため、1日ぐらいかけて読んだ方がよさそう。
HaxeのマクロでPromise専用構文を作った
専用構文というか、マクロでF#のコンピュテーション式のサブセットライブラリ（Bind, Return, Zeroのみ）を実装して、その上にPromiseを載せたという表現の方が正確な説明です。
Promiseを使った非同期処理がこんな感じで書けます。hxgndでは、hxgnd.Promiseという独自実装のPromise型が提供されていますが、これはjs.Promiseと混在させることが可能です。
import hxgnd.Promise; class Main { public static function main() { Promise.compute({ var a = @await Promise.resolve(1); var b = @await js.Promise.resolve(2); var c = @await getValue(); (a + b + c) * 10; }).then(function (x) { trace(x); // 60 }); } static function getValue() { return new Promise(function (fulfill, _) { haxe.Timer.delay(function () fulfill(3), 100); }); } }
とりあえずこれがあれば、他人に無理やりHaxeを書かせる際に「Haxeってasync/awaitとかScalaのforがないじゃないですか」って言われるケースは封殺できるようになってめでたいです。あとはHaxe 4でアロー構文とfinalが入ってくるのを待つ感じです。
Surface 3にUbuntu 18.04をインストール
デュアルブートにする訳でもなかったので、OSのインストール自体は特に引っかかるところはなかった。ただ、実際に使おうとすると多少問題が出た。
サウンドデバイスが認識されない
ディスプレイがHDMIデバイスとして認識されている（＝サウンドデバイスとして認識されている）ため、起動時に失敗しているような挙動をしていた。よって無効化する。
デバイスを確認する。
$ cat /proc/asound/modules 0 snd_hdmi_lpe_audio 1 snd_soc_sst_cht_bsw_rt5645
HDMIっぽい怪しいデバイスが見つかったのでブラックリストに登録する。
$ sudo vi /etc/modprobe.d/blacklist
以下を追加して再起動する。
blacklist snd_hdmi_lpe_audio
WiFiがすぐに切れる
いまいち原因が特定できてないのだが、以下を設定したら安定したようだ。
WiFiの周波数帯を日本に設定
$ sudo vi /etc/default/crda
REGDOMAIN=JP に設定する。
IPv6を無効化
$ sudo vi /etc/sysctl.conf
以下を追加する。
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1
設定を反映する。
$ sudo sysctl -p
設定されたか確認する。以下のコマンドを実行してIPv6がないことを確認する。
$ ip a
WiFiのパワーマネジメントを無効化
$ sudo vi /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
wifi.powersave を 2 に変更して、再起動する。
サスペンドの無効化
常時起動する場合は設定する。
$ sudo vi /etc/systemd/logind.conf
HandleLidSwitch=ignore に設定する。
ubuntuが入ったノートPCでサスペンドを無効にする - あるシステム管理者の日常
ついでにやっておく設定
デンキヤギの採用の考え方 2018-08-11版
このイベントに弊社も出てきた。いい機会なので、会社説明時に説明しているようなことを書いておく。
発表資料
他社がキレイなスライドで発表している中、弊社は私がTwitterをしながら3時間ぐらいで新規で書き起こしたスライドを持っていった。
デンキヤギの採用の考え方 from terurou
www.slideshare.net
発表資料の補足
フリータイム中に質問されたことを思い出しながら、補足していく。
想定する会社規模、求人自体の考え方
求人イベントに出ておいて言うのは何だが、現状は何が何でも人を採用したいという状況ではない。当然、社内ニーズや社風にマッチする人間が、会社の状況を理解したうえで入社してくれるというのであれば採用したいし、社員が10人ぐらいまでは増えてもいいかなという感じでも考えている。
受託開発が売上100％の状況のため、人員不足で案件受注を見送ってきた面もあるし、人員が増えればその分の営業・管理が大変になる面もあるので、人が増えれば単純に良いという考え方は持っていない。10人というのは、2-3チームぐらいが構成できる人数感で、もしこれ以上スケールさせるには管理職を増やさないといけないが、現状は社内に自分以外の適任が居ない。
とはいえ、自社開発が軌道に乗ったらと言うことが変わると思う。
キラキラを求める人はマッチしない
社員旅行やBBQなどの社内の一体感！みたいなイベントをする気は一切ない。社内行事としての飲み会は、人が増えたときの歓迎会をやる程度で、会社が全額費用を負担する。
技術者採用
現状の社内人員は技術好きな人で偏ってしまっている傾向があり、顧客と折衝できるタイプの人が限られてしまっている。理想を言えば、一人親方もしくは2-3人程度のチームで顧客と調整を行いながら技術もやる現場リーダー経験者、もしくはそれができそうな人が採用したい。
ただ、ある程度技術を抑えているうえで調整事ができる人間なんて存在自体が希少なことも理解しているので、最低限としてはチーム開発に興味がある、技術が好き、本意ではない技術選択をせざるを得ない状況でも仕事として淡々とこなせる人を求める事になる。いくら「この技術がやりたい！」と思っていようが、（ある程度は配慮はするが）その仕事が割り当たるとは限らないし、プロジェクト全体の最適解で技術選択を行ってそれに従ってもらうことになる。ここが割り切れない人は向いていないので他社をあたった方が良い。
また、会社サイトの取引実績にも書いてある取り、今回の求人イベントに出ていた来栖川電算さんなどと取引をしている。弊社に入って、いきなり来栖川電算さんの仕事をするというケースも普通に考えられる。もちろん、違う仕事も色々あるのだが、この辺りに違和感を感じてしまう人も、素直に他社をあたった方が良い。
総務採用
代表取締役の私が色々雑務をやりすぎなので、それをお任せするために雇いたい意思がある。電話応対、来客対応（宅配物受け取りと飛び込み営業への塩対応がほとんど）、売掛/買掛の管理、物理媒体を納品しなければならない場合の出荷作業、郵便物チェック、書類の郵送、社内の備品管理、福利厚生設備の導入計画（例えばコーヒーサーバーとか、どれを買ってどこに置くのとか）、日程調整、スポンサーイベントの運営準備、社内清掃（ルンバのメンテやゴミ出し程度）など、定型・非定型業務に関わらず多岐に渡る。
ただ、現状はフルタイムにするほどの仕事量がないのも事実なので、短時間正社員か、何か他の業務と兼務してくれると助かる。総務 兼 技術支援みたいな人が一番都合がよい。
給与水準
給与は、ベース給与＋業績連動賞与という構成になっている。
今期の計画では、役職なしフルタイムプログラマー職の場合、ベース給与が各種手当込みの額面で年350-450万円ぐらい、業績連動賞与が年100万円以上ぐらいで設定している。ベース給与は確定で支給するが、業績連動賞与は業績が極端に悪い時は0円もありうるし、業績が計画よりも良ければ増えることになる。
給与としては低い訳でもないが、特段高い訳でもない。あくまでも目安額なので、採用条件によってはこれ以上出すこともあるだろうし、その逆もある。
人事評価制度の設計は非常に難しいのだが、デンキヤギの売上が受託に完全依存している関係上、各個人の受託単価（に各種事情の補正をかけた推定の市場価値）を基準に給与額を設定している。これが絶対的に正しいとは思っていないのだが、現状はこれがシンプルだろうという判断をしている。
短時間正社員
短時間正社員の勤務時間は、特に週何時間と決まっている訳ではなく、採用都度の相談となる。
ストックオプション
今のところ発行予定がない。受託が売上100%の状況でストックオプションとか訳がわからないので、給与（というか賞与）で還元する方針になっている。
将来的に自社サービスが流れに乗って、VCから資本調達して出口戦略がどうとかを考える状況が来た場合は、その時に改めて考える。
受託案件
いわゆるSI業界における多重下請け構造の案件は原則請けていない。基本的には、エンドユーザーと直接取引するプライム案件と、プライムベンダーと直接契約する技術支援系の案件が大半になっている。ただ、過去に全く無かったかというと、残念ながらそういうこともなく、どうしても営業タイミングが合わず繋ぎで請けたケースも僅かにある。
案件では、技術検証・プロトタイピング・新規事業立ち上げみたいなことに関わることが多い。これはデンキヤギの営業スタイルによるところが大きいと思われる。
代表取締役の私が、おもしろそうな会社に"遊び"に行って、ついでに「仕事がない？」かと聞いてくると、3社だか5社だかに1社ぐらいの割合で実際に仕事を出してくれる。ただ、仕事を出してくれる側も、取引実績もない会社にいきなり事業コアを任せるようなことはしてこない。いつかやろうと思っていたものや、技術検証してほしいみたいなものを、技量を測るにお試しで投げてくる事が多い。幸いなことに「思いの外いいやつが出てきた」と評価されることが多く、「じゃあこれを使って新規事業をやってみようか」というような流れで食わせてもらっている。
また、私が10年以上勉強会に出入りし続けている関係から、他社の技術キーマンの人と仲が良かったりするので、ありがたいことにバイネームで呼ばれることもある。また、他社では人手が足りずに請けきれなかった案件を丸々紹介してもらうこともある。
会社の規模が小さいので、成り立っている営業スタイルかもしれない。
自社開発
スライド動画配信をコア技術にしたサービスを開発している。スライドに音声とページ送りを記録して、動画として配信させることを、Webブラウザ単体で行うことができ、安価に使う事ができる。厳密には異なるのだが「音声付きで自動再生されるSlideShareみたいなやつ」といえばイメージできる人もいるかと思う。
元々は勉強会を簡単にネット配信するために作った技術である。カメラを買って、セッティングして、撮影して、ライブ配信して、後から編集してアップロードして、みたいなことを個人でやるのコストが高すぎてできねーだろという考え方から来ている。最近でこそYouTubeなどで高画質ライブ配信ができるようにはなったが、UStreamというものが現役だったころは折角ライブ配信しても「画質が悪すぎてスライドが読めねーぞクソ」という反応が多く、これでは配信側のモチベーションが続くわけがない状況だった。TV会議システムベースで簡単にWebinarができるというシステムも存在はするのだが、同時配信100人とかで考えると、とても個人が手を出せる価格帯ではない。
技術を作ったのはいいが、勉強会相手だけでは市場規模が小さすぎてビジネスとしては難しいだろうという判断があり、販売先を色々探してきた。だが、「動画はコストが高い」から「使ったことがない」ので「使う場面が想像できない」ため、要は文化がないという事がわかってきた。
なので、ここ最近腹を括ったこととしては、文化を創りにいく方針で進めることにした。正直、VCやらからは「実際に売ってから持ってこい」と全く見向きもされてないのだが、幸いなことに受託でそれなりに企業体力がついてきたことと、役員定額働きたい放題に毛が生えた程度で開発はできそうなので、その範囲でやっていく。
ここが許容できない人は他社をあたった方がよい。
技術
広義のWeb開発：Webフロントエンドからバックエンドまで
Haxe/JS, Scala(Scala.js), Javaを使ったWebシステム開発やWebフロントエンド開発が実績の大半を占める。複雑度の高いUI・ハイパフォーマンスが求められる開発対象でも、構造を破綻させずに作り切れる会社自体がなかなかないので、このあたりは技術的な強みとして言ってもよいかと思う。
昨今のニーズでビジュアライゼーション関係の開発にも関わることがある。サーバーサイドの設計構築を含め、大規模データセットでも破綻しないようにすることは得意としているが、社内にデザイナーが居ないため視覚的なところは強くない。ここは強化できるなら強化したいポイントではある。
サーバーサイドのランタイムはJVMやNode.jsを使う開発が多い。サーバーレス環境の開発が増えてきているので、Node.jsの比率が高まってきている。AWSとAzureは普通に使っているが、GCPは今のところ実績はない。
その他、AkkaやRabbitMQなどを使った分散システムの開発実績がある。Kafkaはタイミングが合わずに今のところ実績はない。ZooKeeperのような分散協調システムや、Cassandra, AWS DynamoDB, Azure Cosmos DB, Elasticsearchあたりの開発実績・知見もある。ErlangはちょっとだけRabbitMQやVerneMQのプラグインを書いた程度。
モバイルアプリ
モバイルアプリ開発は何故か今まで案件がマッチングしてこなかったため、会社としての開発実績がない。開発経験がある技術者も在籍しているので対応は可能だが、会社としてもあまり優先はしていないので、最新情報がキャッチアップできているわけではない。
.NET系技術
MS/.NET系の技術は私個人としては大好きなのだが、まともな案件が流れてくることが少なく、あまり実績がない。
機械学習
機械学習は積極的には手を出していない。機械学習のプロジェクトでWebフロントエンド開発を担当することはまぁまぁある。
開発言語
特に強いこだわりがある訳ではなく、技術選定では適切なものがあればそれを選択する。
プログラミング言語については、静的型付き言語が選択できる状況であれば、必ず選択するという考え方をしている。また、余程の理由がない限り、静的型付き言語が使えないプロジェクトは避ける方針で考えている。今のところ社内における第一公用語はScalaで、Haxeは全員がガリガリ書けるという訳ではない。
名古屋の小さめな企業で集まって求人イベントを開催しました
こういうイベントを開催しました。
開催までの経緯
適当なことを言ってたら、意外と趣旨に賛同する会社が集まってきたので、一時のノリで開催が決まりました。
何社か集めて、なごやか求人カンファレンスでもやりますかね
— てるろー (@terurou) June 21, 2018
もう少し真面目に書くと、
- 各社、人員を増やしたいが募集してもなかなか集まらずに困っている
- 大きい会社はカネをかけて求人イベントをバンバンやってるが、そんなカネもないし知名度もない
- だったら小さい会社で集まってイベントをやれば、イベントのコストも分散するし、小さな会社でも興味のある人を集められそう
という算段は何となくあって、実際にやってみようということになりました。
イベント初回ということで正直どれだけ人が集まるかはわかっていなかったんですが、過去にNGKというイベントを開催してきた経験と使える集客媒体から、「おそらく20-30人ぐらい、うまく集客できると40-50人ぐらいになるかも」という仮説を提示して、「動員目標30人、20人来たら成功」という設定で開催準備を進めました。
正直、私は最初の声がけぐらいしかやってなくて、会場を提供してくださった Misocaさん とケータリングの手配を行ってくださった PREVENTさん が特に大変だったのではないかと思います。
また、どうなるんかよくわからないイベントに参加して頂いた以下の各社もありがとうございました。
開催結果
結果的に大して告知をしてないにも拘わらず、結果的に動員目標の30人を超えて、35人に定員を増員＋キャンセル待ちが発生するという、思っていた以上の集客がありました。申込・参加いただいた方ありがとうございました。
これだけ人が集まることがわかれば、今後も半年～1年の周期ぐらいで定期的に開催していくこともできそうです。もし次にやるとしたら、来年3月とかのインターンや新卒求人の募集時期になるんでしょうかね。
また、やはり複数の会社が集まると、事業内容が違うのは当然として、企業文化、資金調達の意思・状況、出口戦略、利用技術など、それぞれに特徴があり、参加者側にもなかなかメリットがあるイベントにできたのではないかと思います。
人月単価で80万円ぐらいの仕事
Twitterでこういうことを書いたら、そこそこ反応があった。
今のご時世、技術難易度が並ぐらい（一人でWebシステムが構築できる程度）で、2‐3人月ぐらいの小さなシステムを一人でヒアリング～実装～運用引き渡しができて、説明責任ちゃんと果たせれば、人月単価換算で80万円ぐらいは一杯転がってる（常にあるとは言ってない）し、その他要因で単価はもっと上がる
— てるろー (@terurou) 2018年4月17日
意図通りには伝わらないだろうなぁと思いつつ、所詮Twitterだしなーと思いぶん投げたんだけど、想定してた範疇の誤解が広まってきたので、一応補足する。
「人月単価で80万円ぐらいの仕事」の難易度
ちゃんと書いてないから伝わらなくて当然といえば当然なんだけど、行間をちゃんと補うと、
- エンドユーザー直案件
- 技術難易度的には、いわゆるマスタメンテナンス機能に毛の生えた程度のもの
- 実装技術とは別で、現状の業務分析であったり、システム化後の運用フローがどうなるかを考えたり、開発完了後の導入やユーザー教育（操作方法レクチャー）を行うことが必要
割と具体的な例を出すと、経費精算みたいな社内業務。
こんな感じの業務を、業務フローを見直しつつ、システム化していくみたいな話。この要件を80万円で1か月で作るという話ではないし、ヒアリングしたら印刷が必要だとか会計システムとはAPI連携が必要だとか、ミッションクリティカルなシステムだとか、セキュリティの事をちゃんと考えないとダメだとか、技術難易度が上がる要素があれば当然その部分は単価を80万円から割り増しする。
上記の業務例を、単価レンジ80万円で対応できる内容に落とすと、
- ユーザーロールは一般ユーザーと承認者の2つ
- 一般ユーザーはWebフォームに申請内容を入力し、入力ができたら申請ボタンを押す
- 承認者は一覧画面で未承認のデータが検索でき、個別に内容を確認して承認ボタンを押す
- 一覧画面で年月を指定して承認済みデータが検索でき、該当データの一覧がCSVファイルとして出力できる
- あわよくば会計・給与システムと連携できるCSVフォーマットになっているとよい
- インターネット非公開（社内からしかアクセスできない）サーバーに配置して、サーバーにアクセスできる人ならデータ自体は誰でも見えてOK
- サーバー構築は不要（今時だと何らかのSaaS上に構築するみたいのが多いと思う）
- 対応ブラウザはPC版Chromeのみ
という程度のシステム化具合。業務要件のヒアリング・設計・開発・システムテスト・ユーザーテスト兼ユーザー教育・導入初期の運用・不具合サポートみたいなところをもろもろやると、2-3人月かかるよねぇ、単価と期間を掛け算して最終的な請求額は200万円ぐらいかなぁ、という感じ。実装部分だけ抜き出すと1か月分相当ぐらいだろうし、使うフレームワークやSaaSや技術の練度によってはもっと期間短縮したりできるとは思う。あと、フル稼働が必要な部分は実装～システムテストの部分だけで、それ以外はお客さんからの回答待ちや待機のような拘束時間には変わりはないが実質何もしてないみたいな時間もある。
人月単価80万円ぐらいという相場感
前述の例のような紙やらExcelで日常業務を回してるところは大量に存在していて、当人たちも効率が悪いことは自覚していてシステム化も検討してはいる。しかし、SIerに相談するとクソ高い見積もりが出てくるとか、仕事のロットが小さすぎるから請けてくれないとか、過去発注したシステムが金をかけた割にクソだった経験があるとかで、結局放置されていることが本当に良くある。
そういった相手に話をする際に、基準となってくるのが80万円ぐらいかなぁというのが個人の肌感覚である。もちろん仕事でやっていく際は、相手の懐具合を見て多めに要求することもある（実際には相手が大きな会社だと、AD連携がどうとか、瑕疵の保証がどうとかの要素が増えてくるので、懐具合関係なしに割増が生じる）し、逆に予算がほぼないところもある。
ここまで書いて、会社によって営業費とか間接費のかけ方が違うので「人月単価80万円では安すぎる」という話はあるでしょう。ただ、繰り返しになるが、ある程度の規模のSIerだと単価レンジが80万円の2-3倍ぐらいになるはず（前述の例だと請求額で500万円を超えてきたりとか）で、これが高すぎるからシステム化出来てないみたいのは腐るほど存在している。
80万円という単価レンジは、クライアントから見ると割安な価格設定に見える。同時に営業費用をあまりかけていない会社であっても単価80万円を割ってくると、おちんぎんが少なくなるので、ここは守らないといけないラインかなと設定している。
人月単価80万円ぐらいの仕事を工夫して、割の良い仕事にする
ジョイゾーさん
直接話をしたことはないので私が勝手にそう思ってるだけですが、ジョイゾーさんのKintone SIがこんな費用感をベースにやっている認識です。
まともに開発すると2-3か月かかるような話をテンプレートを適用していくことで開発工数を減らすものと、テンプレートではどうにもならないものを1週間20万円で対応しますよというもの。
弊社の例
アジャイル開発契約というか、ソニックガーデンさんの「納品のない受託開発」もどきというか、みたいな定額制の契約モデルで請けているお客さんがいる（全てではない）。
「納品のない受託開発」もどきの定額制の契約モデルというのは、
- 納品自体はしている
- 月額費用は数十万円ぐらい（作業ボリュームに合わせて調整）
- 開発初期はどうしても労力が大きいので、ギリギリ赤字にならないレベルの額を初期費用として請求している
- 最低限の機能を実装した段階でお客さんに納め、運用しながら改善をしていく
- 毎月1回定期訪問して、改善点等のヒアリングを行う
- 月間に対応できる改善工数に上限値があり、それをどうしても超えたい場合は別途お見積りで対応
- 対応速度はベストエフォート（手が空いている場合は即日対応、契約上は10営業日以内に着手）
というように、費用・開発規模共にスモールスタートでやって長期的に改善をおこなっていき、売上的には初期導入費用＋月額サブスクリプションみたいな感じになっていて、トータルで見たときに単価80万円ぐらいに設定している。効率的に仕事を捌けば実際の作業に対する売上効率は良くなる。
これの良いところは、
- 初期費用を抑えていて、納品後も機能追加を継続的に行うことが前提になってるので、開発スコープの絞り込みで合意が取りやすい
- 「とりあえず優先順位の高いこれに絞りましょう」「実際に使い始めて足りなかったら機能追加しましょう」
- 安定稼働して、ユーザーもシステムに慣れてくると、やることがかなり減ってくる
- 継続的な収入があって、構造的に作りすぎが発生しにくいので、瑕疵対応がつらくない（お客さん側も機能改善の一環として見てくれることが多い
- 毎月1回定期訪問すると、納品したものとは別のシステム化の話が出てくるので、お金をもらいながら営業してる状況になる
といったところ。
悪いところ？としては、プログラミング言語の知識とかを生かすことがほぼなくて、本当にITコンサルタント的な動き方になるので、技術だけやりたいみたいな人だとやりたがらない。
追記：運用・改善フェーズに入ったら、 月々の実稼働が1日と想定して10万円みたいな価格設定 になっている（実際の想定日数とか、技術難易度とかで割り増しはある）。当然運用は長期になるので、大儲けはないが効率の良いお仕事。あと、運用してる間に「あれもシステム化したい」みたいな話は当然出てくるので、「それも初期開発は別料金になりますねー」みたいなサイクルが続く。
追記2：この話の文脈
