Upgrade to Pro — share decks privately, control downloads, hide ads and more …

製造業向け新事業の基盤をエンジニア1人のチームでローコード&マネージドで半年で立ち上げた話_220810

 製造業向け新事業の基盤をエンジニア1人のチームでローコード&マネージドで半年で立ち上げた話_220810

[email protected]

August 16, 2022
Tweet

Other Decks in Technology

Transcript

  1. 4 Backend Engineer Hiroaki Yamashita 前職ではDevOpsエンジニアとして、CI/CD, IaC, 自動テスト の導入を通して開発生産性向上のために活動。その後、自動 テストを生成・実行するプロダクトの企画・開発から導入ま

    でを経験。 現職では、DevOpsエンジニアとして活動後、SCMシステム、図 面管理システム、パートナー連携システムの開発に従事。 主にバックエンド開発をメインにしつつ、フロントエンド開 発も必要に応じて取り組んでいた。 2022年度から新事業部のシステム基盤構築に従事 Product Manager Norihisa Niwase LINE株式会社にてライブ配信サービスの新規開発から運用ま で従事。その後、建築系ベンチャーにてメディアサービスの 刷新やSaaS事業の立ち上げを行い独立。AI開発やNFTメディア 運用、D2Cなど様々な事業を展開。現在はキャディ株式会社に てオペレーション企画に関わっている。
  2. 8 MARKET 調達 イノベーション 特になし 製造 販売 設計 CAD /

    CAE などの活用 自動化・ ロボット化 AI・ビッグデータ の活用 日本国内での総生産額 180兆円規模 120兆円 100年以上イノベーションのない巨大な製造業調達市場 製造業の中で120兆円を占める調達市場においてのみ、大きな革新が未だない状況。
  3. 9 MARKET DETAILS (1) 調達コスト 120 兆円 多品種少量 40兆円 金属加工

    4兆円 ※ 多品種少量のみ 電車1車輌の部品点数30,000点のうち、 12,000点(40%) 程の多量の金属加工品が使われています 電機品 内装の裏・ 窓枠 扉 シート ライト 衛生設備の 骨組 台車 空調設備 筐体 流通総額 金属加工品の例(車輌業界)
  4. 10 MARKET DETAILS (2) 半導体製造 装置 FPD 製造装置 食品機械 包装機械

    医薬品 製造装置 身近な製品を製造する装置に 携わっています コンビニおにぎ り製造装置 ペットボトル ラベル貼付装置 自動車車載電池 製造装置 スマホ液晶 製造装置 どら焼き製造装置 製本機械 印刷機械 化学装置 射出成形機 工作機械 自社内検査 装置 鉄道関連 装置 自動車製造 ライン 分析機器 試験機械
  5. 12 SERVICE FEATURE 産業・市場構造の中でキャディが目指すものは個々の加工会社が強みを 最大限活かすことができるフラットな市場構造です マッチング(のみ行う) マッチングだけでは 探索コストが減るだけで 交渉・監督コストはそのまま ファブレスメーカー

    (的立ち位置) 商流に入ることで発注者・ 受注者の取引コスト・ 製造コストを下げる 図面データ アップロード・ 送付 2 ・調達工数削減 ・コスト削減 ・安定価格、納期 発注者 ・見積レス ・論理的原価計算 ・売上安定化 最適 加工会社に 確定発注 自動製造原価計算・ 見積提示 1 検査・品質保証 製品納入 3 CADDi 加工会社 MERIT MERIT
  6. 15 SERVICE HISTORY 板金 材料調 達 機械 加工 製罐 配電盤

    組立品/ 配線品 配管 プレス 加工品 鋳造 射出 成型 購入品 2017年 2021年~ 装置 一式 プラント 一式 創業当初は板金加工のみだったキャディは、 今では、装置一式やプラント一式を手掛けるようになり、売上・組織ともに急成長しています。
  7. 事業概況)立上げをカスタマイズで対応 18 新たな事業領域でFMTやデータ構造を把握しきれておらず、対応しやすいGoogle Sheetsで管理。結 果、日次新たなFMTやデータ構造、図面更新が発生。計数百回の変更を入社直後の数十人で対応 購買・製作 納品・現地施工 顧客 キャディ マスタデータ

    ( EDI ) 図面のやり取り (email) 材料管理 (Sheets) マスタデータ ( EDI ) 進捗管理 (Sheets) 顧客承認 (email) 図面管理 (G-Drive) 検査記録 (G-Drive) 輸送管理 (Sheets) 検収記録 (G-Drive)
  8. 事業概況)立上げをカスタマイズで対応 19 新たな事業領域でFMTやデータ構造を把握しきれておらず、対応しやすいGoogle Sheetsで管理。結 果、日次新たなFMTやデータ構造、図面更新が発生。計数百回の変更を入社直後の数十人で対応 購買・製作 納品・現地施工 顧客 キャディ マスタデータ

    ( EDI ) 図面のやり取り (email) 材料管理 (Sheets) マスタデータ ( EDI ) 進捗管理 (Sheets) 顧客承認 (email) 図面管理 (G-Drive) 検査記録 (G-Drive) 輸送管理 (Sheets) 検収記録 (G-Drive) 一貫した情報流通に向けた開発が必要に
  9. 21 あらすじ • 既存事業部からは新事業部は 完全なブラックボックス • 既存の社内システムの導入出来ておらず、 とにかく現場が大変 なことしか分からず •

    入ってみると、確かに 既存事業部とペインや取り扱うデータや Opsが違い導入できない • 結果、1から、ほぼ全ての業務システムを作る ことに • ただ、エンジニアは1人しかいないため、ローコードツールや既存サービスを軸に構築 • ツール特性を活かしながら、 Opsや現場と同期しながらシステムを作って運用に
  10. 22 新部署は外からは焼け野原、入ると開墾された大地 - キャディとして、新規事業であるプラント事業 - そんな事業部で、会社全体で過去最高の売上を大幅に更新する大型案件を受注 - ノウハウ不足で仕組み化も間に合わない中、案件規模の拡大に合わせて随時人員が投入 - 業界や顧客特有の要件や事情が加わることで

    混乱が混乱を呼び ギリギリまで追い込まれるが、最後まで案件をやり切る - そんな過酷な現場で、まさに焼け野原になったかと思われていたが・・・ - そこには、日本有数の大型案件をこなす上で培った 知見や やりきったことによる 顧客からの信頼があった
  11. 23 システム導入を阻んだのは、スコープだった 最終製品 中間製品 中間製品 中間製品 部品 部品 部品 支給品

    部品 購入品 装置事業部 の対象 プラント 事業部 の対象 - 製作自体がとりわけ難易度が高いわけ ではない - 組立まで含めた製作 - 顧客支給品や購入品、材料調達までカ バーが必要 - 長期間かつ多くのステークホルダーと のコミュニケーションと PJ管理 - 多種多様な素材・加工が必要な材料を QCDフィットした状態で調達
  12. 24 システムでカバーしなければいけない範囲 要はこれ全てやらないといけない 購買・製作 納品・現地施工 顧客 キャディ マスタデータ ( EDI

    ) 図面のやり取り (email) 材料管理 (Sheets) マスタデータ ( EDI ) 進捗管理 (Sheets) 顧客承認 (email) 図面管理 (G-Drive) 検査記録 (G-Drive) 輸送管理 (Sheets) 検収記録 (G-Drive)
  13. 26 使用したサービス・技術達 • 基盤となるデータ管理 : Airtable • 社外とAirtableのデータを制限付きで双方向にやり取り : miniExtensions

    • アプリ提供: AppSheet • BOM管理: OpenBOM • 材料・出荷管理: Logiless • 各種サービス連携: Make(Integromat) • 上記でどれも解決できないものは ◦ CloudRun上でNestJSを作ったAPIサーバーで処理 ◦ データは、Make(旧Integromat) => Cloud Pub/Sub => CloudRun で流す
  14. 27 どんな風にシステム化していったか - 最初に事業を進める上で必要なタスクの洗い出し & それに必要なシステムの 洗い出しとゴール設定を業務設計チームと一緒に進める - もっとも業務的にもデータ的にも依存性が低く、かつ、業務負荷が一定高い領域から 着手

    - 製作仕様の問い合わせを集約するところから - Quick Winで現場の信頼感を獲得 => 協力をより得やすい状態に - その後軸となるマスターデータの整備へ - 案件に紐付く情報群を正規化し管理 - その上で、生産管理などマスタデータを用いたり、一緒に使うことで価値あるものに広げいった - その際に、まずは作り込まず軽く使えるところから薄く広く展開していった - 必要に応じて作り込んでいく
  15. 28 現在、システム化が実現している範囲 - 案件管理 - 製品別工程管理 - 中間完成品別工程管理 - 生産状況の可視化Dashboard

    - 今、どの部材がどこにあって、どこまで製作が進んでおり何が組立に不足しているかを可視化 - BOMデータ管理 - 材料調達、在庫管理 - キッティング(製作に必要なものを必要な部材を揃えて発注) - 製作仕様など各種問い合わせ管理 - 検査・是正事項管理 - 車両手配 - 資格保有状況の管理 - 検査資料などドキュメント作成自動化 - 各種マスターデータ管理(関連会社情報、拠点、装備 etc) 以上、テーブル数だけで40を超える
  16. 30 ノーコード・ローコッドって結局どうなの? 想定したよりも、ずっと多くのものがローコードで実装することが出来た • ただ、それは対象が SoR領域で正しくデータを管理・活用するというものが対象だったから • 加えて、全てをシステムで補わず、 Opsでカバーできたから 設計から実装、導入までの

    リードタイムを大幅に短縮できたことで Be Agile を体現できる ただ、下記は実装は必要 • ロジックを多く含むもの( SoRでも必要) • SoRではなくSoEの色が強いユーザー視点のインターフェースや UXが必要なもの
  17. 31 結果 工数が70%削減 ① データの確認・変更・共有工数が削減 - データマネジメント構築により、業務改善が進行 ② オペレーションが標準化 - ツールの有用性を実感すると、チーム全体でデータ管理を重視するように -

    ツールやオペレーションに影響がないかを念頭に業務遂行する文化が定着 ③ 社外企業の業務工数も削減 - 社外企業にもツール導入を進め、外部企業の業務工数も削減
  18. 32 今後について • 情報を適切に管理・活用する、というのは、かなり実現出来てきている • その上で、より踏み込んだ自動化や、ユーザーのより複雑な要望を叶えるためのアプリケーションの提供など が必要になってきている • 加えて、キャディ社内向けに作ってきたシステム基盤でしたが、顧客に説明したところ刺さり SaaSとしての提

    供のためプロジェクトが発足(結果的に新サービスにとっても PoCになっていた) • 以上を実現するためには、エンジニアが必要になってくる • 現在に至る • 使用想定技術(完全未定) ◦ 言語: TypeScript ◦ FE: NextJS, React Native, Expo ◦ BE: Hasura, NextJS, Prisma ◦ インフラ: GCP(CloudRun, Cloud Pub/Sub, CloudSQL, Cloud Memorystore), Auth0 ◦ その他: Nx, Appolo Client, Prisma, CircleCI, Sequin, Retool, zx ◦ etc
  19. 33 AirtableのPros • CRUD操作可能で、ユースケースや個人ごとに編集可能な UIや共有UIを作成することが出来る ◦ それによって、UIではなくデータ構成に集中することが出来る => 実装・機能実現が早くなる •

    実装が早い、わけだが、それはどういうことか ◦ 設計 = 実装、ぐらいの感覚になる ◦ 考えながら、議論しながら、その場でサンプルを作りながら進められる ◦ 認識齟齬が大幅に減少し、手戻りが減る ◦ デリバリーもあがるため、最初の高揚した雰囲気から停滞した雰囲気になりがちな DXプロジェクトに とって対象を選べば勢いをつけられる ◦ 修正も即座に反映できることで、まずは作った上で、反応を確かめながら実戦に投入出来るし、設 計に悩んだら、まずは使ってみてもらおう、と言える ▪ Be Agile を体現できる • 細かな権限管理 ◦ 勝手にカラムは追加させない、変更させない、データ入力だけ・閲覧だけなど ◦ エンジニア側の完全な管理化に • 自動で生成されるドキュメント付きの API • 多数のIntegrationがあったり、コミュニティがあるなどエコシステムが充実 ◦ Airtable連携が前提だったり、連携機能を押しているサービスも多い • 旺盛な機能開発で以前出来なかったことが、いつの間にか出来るように
  20. 34 AirtableのCons • 行数制限。これより苦しめられるものはない ◦ Enterpriseで1データベースあたり 25万行、1テーブルあたり 10万行 ◦ Baseを分解したりArchiveしたりなどの工夫が必要に

    • APIのリクエスト制限: 5req/1sec ◦ この問題はまだ試してないですが、 sequinというAirtableとPostgres連携を行うサービスによって解決の 余地がありそう • Dev環境が存在しない ◦ ただ、簡単にテーブルはコピーは出来るので、そちらで確かめて変更などは可能 ◦ 加えて、Backupがしっかりしているので、失敗した場合は戻すことも可能 • Migrationが機械的には出来ない ◦ ただ、Airtableは賢く、Keyが一致していたらリレーションをバシッと紐付けなおしてくれる ◦ こいつのおかげで、データを正規化した後、リンクし直すのが一瞬 ◦ 実際に何度も大規模なりファクタリングを行っているが問題は起きてない ◦ こちらも最悪、Backupで戻せる • RDBと名乗っているが、案外分析には向いてない ◦ 細かな分析したいなら Power BIなど、BIツールを使うと良い • 編集者ごとに課金する、というモデルを採用しているせいか、外部のユーザーと編集可能な共有 Viewなど双 方向なやりとりに制約がある ◦ これはminiExtensionsのPortalによってカバー可能
  21. 39 RECRUITING POSITION バックエンドエンジニア フロントエンドエンジニア プラットフォームエンジニア エンジニアリングマネージャー PoCエンジニア アルゴリズムエンジニア 機械学習エンジニア

    MLOpsエンジニア QAエンジニア SaaSエンジニア 詳しくは右記よりご覧ください PoC SaaSエンジニア データエンジニア プロダクトデザイナー