SaaS開発を通じて業界固有業務のデジタル化を支援しています
- 保管に膨大な紙とデータが必要となっている
- 沢山の現場チェック項目がある
- 写真付き報告書の作成に手間が掛かる
- データを時系列で比較検討できない
- 情報が紙なので過去の検索ができない
- 案件のデジタル管理ができていない
開発事例１ ビル管理・設備点検・不動産管理等に特化した写真付き報告書作成システム 「Raccoon」
ビル管理、ビル清掃などの現場報告書作成に
特化した
クラウドサービスです。
超高速開発・ラピッド
最新のテクノロジーを使い、超高速開発を実現いたします。
ラピッド開発とは
「ラピッド開発」をご存じでしょうか？これまでフル新規の業務用アプリケーションシステムを作るには最低でも半年、長くて１年もの時間が必要でした。
しかし社会の環境変化は速くなり、また、デジタル・ソフトウェアで解決すべき課題は年々増えています。
これからは新しいアプリケーションシステムは、素早く構築し、素早く運用を始め、素早く改善していくというサイクルが求められます。
そのためには、まず、動くものを作り、アプリケーションを使うメンバーからのフィードバックを得ながら高速で開発サイクルを回して行かなければないません。
このように短期間でフルスクラッチのアプリケーションシステムを創ることを、ラピッド開発といいます。
なぜジェイネクストは、ラピッド開発ができるのか
Point1
プログラマが、仕様を決めてすぐにコードを書きます。
無駄なやりとりが一切ありません。
Point2
フルスタックエンジニアが、構想、設計、コーディング、バグだし、サーバー実装、修正までを全て行います。
分業しないので、言語化したり文章化する時間が圧倒的に短いです。
Point3
全ての作業が驚くほど早く終わります。
●データベースの設計４時間
●基盤構築１時間
●１画面の構築に３０分ほどです。
●２０画面程度のモックアップであれば、実働３日ほどで作ることが出来ます。
仕事のプロセスの違い
既存のアプリケーション構築フロー
①クライアント側が社内の業務部門にヒアリングをして要望をとりまとめします。
②次に要求仕様書（ＲＦＰ）を作成して、委託するベンダーに見積検討依頼を出します
③ベンダー側は、ＲＦＰに基づき大まかな構想を決めて社内用の仕様書・設計概要書を作成します。
④社内のみならず、外注も使う場合には、ここで再度見積のための作業依頼書が作成されます。
⑤外注先ではコーディングするための詳細指示書が作成されます。
つまり一つのアプリケーションのプログラムを作り始める前に、何枚もの書類が再生産されます。この時間こそが無駄な工期の原因です。
また、図の末端にいるコーダーと呼ばれる「手を動かしてプログラムを作る人」は、顧客と会うことも無ければ、実利用者の意見を聞くこともありません。
そのため、プログラムの意図を知らずにコードを書くことがあるのです。
受託ベンダーと外注には利害関係もありますから、途中の仕様変更や、追加機能などについてはその都度このプロセスが繰り返されることとなります。
また、コーディングの現場で起きる、「意外と実装負荷の掛かる機能が見つかったので、機能の代替案に現場が妥協できるか」などについては、この真逆のルートで情報がクライアントに上がっていき判断を仰ぐことになってきます。途中に何層もの人物や関係者、はたまた企業間のやりとりが発生するため、とんでもない時間のロスが起きるのです。
かつてアプリケーション構築フローは処理する情報量が大きく、営業、設計、コーディングという分業をする必要がありました。しかし今では、各プロセスの設計は効率化され、少ない人数でプログラムを作成することも出来ます。分業による情報交換コストの方が大きくなってきたのです。
また、仕様書など文書が先にできると、画面構成や使い勝手はおざなりになります。なぜなら、「レスポンスは●秒以内」「使いやすいこと」などといった文言は、仕様書に書きにくいからです。
残念ながらこのようなプロセスで作られたシステムは、出来上がったときに「なんか思っていたのと違う」「新しいシステム、使いにくいよね」ということになるのです。
そして、それに気づいた時には後戻りできないくらいシステムの構築は進んでいるでしょう。
ジェイネクストの構築フロー
プログラマー（まぁ社長である私がプログラマーなわけですがw）が現場に赴き、現場で実際に新しいアプリケーションシステムを使う人に、何を求めているかをヒアリングします。
画面の具体的な動きを想定しながらプログラムの仕様を作っていきます。
あとは、プログラマー（私）の構想に基づいて、仮仕様を決めて「実際に動く画面」を提供します。
この間、仕様書は、メモ書き程度のものしか作りません。
近年要望されるアプリケーションシステムは、「製造現場」「建設現場」「店頭」など現場スタッフが働く場所で使われるものが多くなりました。
スマートフォン、iPadなどの安価で使えるモバイル端末が増えたためです。これらはデスクトップパソコン＋フルキーボードという環境では無く、小さい画面でタッチによる操作が基本です。
そのため、画面構成の使いやすさや、タッチでの目的へのたどり着きやすさ、また、オフィスワークとの親和性などが求められます。
このような使い勝手が優先される時代こそ、「実際に動く画面を見ながら開発する」ということが求められています。
ジェイネクストでは、フルスタックエンジニア（私）が、直接お客様の声を聞き、動く画面をみせながら設計を進めます。
出来上がったときには、自分達の要求する、使いやすいシステムが展開され導入もスムーズになります。
御社独自のクラウド型業務システム開発を請け負います
対象業種
製造業、建設業、医療・介護、サービス業
アウトプット
現在の業務における課題を解決するための業務アプリケーションの開発・納品・保守
活用シーン
できること
iPad / Android / スマホ対応
操作可能
保存・一元管理が可能
印刷・PDFにも対応
多彩な記録手段
利用テクノロジー
当社が対応しているプログラミング言語である「Python」は「Java」や「C言語」などと比べれば日本では耳慣れない言語ですが、世界では最新技術の開発に使われる高級言語です。
PythonはGoogleやFacebook、Instagramといった世界的WEBサービスで標準開発言語として使われており、最近ではクラウドストレージの「DropBox」、Softbankが開発した人間型ロボット「Pepper」、IoT用の小型コンピュータ「RaspberryPi」、そしてビッグデータ解析、AI開発、ディープラーニングプロジェクトなどでも使われる言語です。
Pythonは膨大なライブラリ（プログラムの部品セット）と秀逸なフレームワーク（アプリケーションの枠組み）を持っており、通常のプログラミング言語の30〜50%の時間とコーディング労力でプロジェクトを作ることができます。
制作事例
制作事例の一部をご紹介します。
ビル清掃報告書システム
- 画面数：約５５画面
- バックエンド Python + Flask + PostgresSQL
- フロントエンド HTML + CSS + JQuery +Jinja2テンプレート
- プラットフォーム Heroku
- データ取扱件数 現場数15000件/年、写真数450,000件/年
- 主な機能：ビル清掃の清掃状況や清掃結果をスマートフォンで記録し即時報告書を作成するシステム
- 主な機能：ビル内の清掃個所を事前登録し、清掃予定や清掃開始時に箇所を読み込む
- 主な機能：清掃報告書をオンラインで管理会社に公開するシステム
- 主な機能：スマートフォンで撮影した写真を４Ｇ環境でも３秒程度でサーバーに送る技術
- 制作期間4ヶ月
- 構築価格目安400万円
- 月額保守費用目安30,000円
食品衛生検査 情報管理システム
- 画面数：約３５画面
- バックエンド Python + Flask + PostgresSQL
- フロントエンド HTML + CSS + JQuery +Jinja2テンプレート
- プラットフォーム Heroku
- データ取扱件数 1000件/年
- 主な機能：データエクセルアップロード、データ検索、PDF送信機能など
- 制作期間4ヶ月
- 構築価格目安400万円
- 月額保守費用目安20,000円
契約書 タブレット電子署名システム
- 画面数：約20画面
- バックエンド Python + Flask + PostgresSQL
- フロントエンド HTML + CSS + JQuery +Jinja2テンプレート
- プラットフォーム Heroku
- データ件数 年間500件程度
- 主な機能：iPadでのスタイラスを使った署名システム、契約書PDFファイルの登録、ユーザーと契約データの紐付け、自動メール送信システム
- 制作期間：1.5ヶ月
- 構築価格目安150万円
- 月額保守費用目安10,000円
食品衛生検査 情報登録アプリケーション
- 画面数：１画面（シングルページアプリケーション）
- フロントエンド：HTML + CSS + JQuery
- バックエンド：PHP
- 主な機能：HTML上の食品衛生に関する条件において、テーブルデータの動的な組み替え、検査数値を判断した動的な判定可否システム、AJAXによる非同期でのサーバー保存
- 構築価格目安40万円
- 月額保守費用目安3,000円
訪問看護・訪問介護 スケジュール作成支援システム
- 画面数：約5画面
- バックエンド Python + Flask + PostgresSQL
- フロントエンド HTML + CSS + JQuery +Jinja2テンプレート
- プラットフォーム Heroku
- 主な機能：既存のクラウド型スケジュール管理システムに自動ログインし、スクレイピングで各従業員の稼働時間をチェックする。訪問業務でより効率的なスケジュール構築を支援するシステム
- 構築価格目安40万円
- 月額保守費用目安5,000円
タイヤ交換作業所 社内システム
- 画面数：60画面
- バックエンド Python + Flask + PostgreSQL + mongoDB
- フロントエンド HTML + CSS + JQuery +Jinja2テンプレート
- プラットフォーム Heroku
- 主な機能：価格比較サイトから特定条件にてスクレイピング技術を使いタイヤ価格を自動取得する。
- 主な機能：取得した価格情報は毎晩自動更新され、ドキュメントデータベースに格納される。
- 主な機能：ランティングページからはタイヤサイズに応じてAjaxにて検索出来注文できる。
- タイヤ交換ピットの予約をユーザーが行える時間管理
- タイヤ予約情報を管理側で確認しデータを更新するシステム
- タイヤ販売後のタイヤ調達・決済・ピット予約までを一貫管理するシステム
- 構築価格目安550万円
- 月額保守費用目安40,000円
- 製作期間６か月
コンサルティングソリューションのユーザー閲覧システム
- 画面数：30画面
- バックエンド Python + Flask + PostgreSQL + mongoDB + AWS S3
- フロントエンド HTML + CSS + JQuery + Jinja2テンプレート
- プラットフォーム Heroku
- 主な機能：コンサルティングのソリューション資料を有料閲覧会員に公開するシステム
- 主な機能：ＰＤＦをダウンロードできないよう内部レンダリングする仕組
- 主な機能：会員のステータスに応じて表示コンテンツを切り替える技術
- 構築価格目安350万円
- 月額保守費用目安50,000円
- 製作期間２か月
制作料金
制作料金は都度見積となります
主要技術
クラウド型WEBアプリケーションシステムの開発において主に以下の技術を利用します。
使用プログラミング言語（フロントエンド）
HTML / CSS / JavaScript / jQuery / Bootstrap / Bulma.io
使用プログラミング言語（バックエンド）
Python / Flask / PHP
データベース・ストレージ
PostgreSQL / MySQL / MongoDB / AWS-S3 / AWS-DynamoDB
サーバー環境
Heroku / AWS
対応デバイス
デスクトップPC / スマートフォン / タブレット / モバイルレスポンシブ対応
技術水準目安
対応レベルを 最大★５つで表現しています
| Python | ★★★★★ |
|---|---|
| Flask | ★★★★★ |
| HTML+CSS | ★★★★★ |
| Bootstrap / Bulma | ★★★ |
| JS/jQuery | ★★★★★ |
| PHP | ★★ |
| MySQL / PostgreSQL | ★★★★ |
| MongoDB | ★★★★ |
| Excel VBA Macro | ★★★★★ |
タイムカードに頼らない勤務時間管理をしませんか？
クラウドウォッチドッグはPCのログ管理、ITインベントリ管理を行います。
●労基署対応のエビデンスアップに
●ソフトウェアのライセンス数管理に
●私用ソフト、ウイルス対策ソフトのインストールの管理に
ＤＸ：デジタルトランスフォーメーションがうまくいかない理由
日本では「ＤＸがうまくいかない」と言われていますが、なぜだと思いますか？
いや、ＤＸ以前に「ＩＴ化」も遅れていると言われています。まず始めは「ＤＸ」と「ＩＴ化」をひとまず同じものとしてとらえて日本企業になじまない理由をご紹介しましょう。
ＩＴ化とは本質的に「時間と空間をゼロにすること」と言い換えると分かりやすいと思います。これまで人手でやっていた事がコンピューターに代われば一瞬で業務が終わります。
身近な例であればオンラインショップですね。オンラインショップは実店舗に比べて２４時間３６５日動きますし、店舗に行く必要も無ければ店舗の従業員も要りません。もちろん物理的な店舗も不要です。銀座に行かなくても、遠方から買うことも出来ますし、銀座に従業員が通勤することも、銀座に店舗を建てること（借りること）も不要です。このように時間と空間をゼロにすることがＩＴ化のイメージと思うとよいでしょう。
そうなると様々なＩＴ化で起きることは、「そのために働いていた人が不要」になり「そのための物理的スペースが不要」になります。
とはいえ、「ネットショップを運営する人が必要になるのだから、ＩＴ化後も従業員が必要なのは変わりない」「運営作業をするスペースは必要だ」という意見もあるかと思います。しかし店舗で販売員をやっていた人がネットショップの運営ができるでしょうか。お客様の好みを考えて企画を立案する人は必要かも知れませんが、それはごく僅かです。そして運営に必要なスタッフの数は激減するでしょう。運営スペースも確かに必要ですが、一等地にある必要はありません。ネットにつながるＰＣがあればどこからでも仕事ができます。
仕事はネットショップの在庫管理や、オペレーションとなり、求められるスキルが販売員とは全く異なります。また多くの場合、運営に関する仕事の多くを外注に委託するでしょう。
つまり本気でＩＴ化をするなら、従業員には大幅に辞めていただき、残った人（残りたい人）には大きなスキル転換が必須になる。さらに実店舗が不要になるということです。日本では正社員の従業員を簡単に解雇することはできませんし、既存の店舗の撤退なども考えにくいでしょう。なかなか既存の組織の抵抗に遭って実現できないのではないでしょうか。
そして、「ＤＸ」では、これまでのような一部の業務（例：販売業務→ネットショップ）だけをＩＴ化するのにとどまりません。一つの事業に携わるあらゆる工程・業務をもＩＴ化していき、事業のインプットからアウトプットを一気通貫してＩＴ化するというものです。例えば経理、給与計算、交通費精算などバックオフィスの業務はこの１０年で一貫してＩＴ化の道をたどってきました。同じく対顧客もオンラインショップ、キャッシュレス決済等、人手を介さないツールへの移行が進んできました。
しかし製造業でいえば、開発、調達、生産、といったコア業務がありますが、そのようなコア業務にも「ＩＴ化による時間と空間の削減」を持ち込むというものです。中核業務を担う従業員は多くの場合正社員を雇っています。これまでＩＴ化してきた分野（バックオフィスやフロント業務）では有期雇用社員（アルバイトや派遣社員等）を使っていたので長期的な人材の増減には対応できましたが、中核の正社員（無期雇用社員）を簡単に辞めさせたり配置転換できるわけではありません。
このようにＤＸするには会社をスリム化したり、大幅な従業員スキルの入れ替えが必要になります。部門毎不要になるということもあるでしょう。既存の会社における人間関係に縛られた経営者ではＤＸはできないのです。やったとしても既存の組織に影響のないオマケ的な位置づけでいつまで経っても会社全体のＤＸはできないのです。ましてや大企業の順送り人事で就任したサラリーマン経営者には決してできなことです。順当に任期を満了することが彼らのインセンティブですから。
さて、こうして書いていると否定的な側面ばかりに思われますが、これらは一般的に大企業に当てはまることです。大企業は既存の自社事業が大きく、社内制度や仕組みはすべて既存事業に合わせて作られています。つまり巨人が部分的にダイエットすることを目指しているにすぎないのです。しかし中小企業は違います。既存の自社事業は小さいですから、もっと大きい市場にＤＸされたビジネスモデルで挑めばいいのです。大企業が時間と空間を使って行っていることを横目に、時間と空間を一切省いたプロセスで勝負することができるのです。
もちろん新しくＤＸのための投資が必要でしょう。人材も必要でしょう。しかし大きな市場を取りに行くためにゼロベースで事業を創造できれば既存の大企業の市場を侵食することもできます。仮にそのＤＸされたビジネスモデルを大企業がまねしようにも既存の枠組みと雇用慣行に縛られた状態では手も足も出ないのです。
大切なのは、大企業が一見強みと見える、守って離さないものを、離せないように市場を創造することです。