並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 27 件 / 27件

新着順 人気順

Terraformの検索結果1 - 27 件 / 27件

  • モバイルゲームのインフラアーキテクチャ特集 - 技術選定のポイントと今後の展望 - Findy Tools

    モバイルゲームの裏側には、最高のプレイ体験を支える高度なインフラ技術があります。 本特集では、「グリー株式会社」「株式会社gumi」「KLab株式会社」「株式会社コロプラ」「株式会社MIXI」の5社のエンジニアの方々にご協力頂き、インフラにおける技術選定のポイントや今後の展望を、アーキテクチャ図と共に解説頂きました。 ※ご紹介は企業名のアルファベット順となっております グリー株式会社 会員限定コンテンツ無料登録してアーキテクチャを見る アーキテクチャ選択の背景や意図 ゲームサービスのクラウドアーキテクチャとして重要な点は、急激な高負荷に対してスケールできることと、サービスのメンテナンス時間を不要にできることの2点でした。そのため、Google Kubernetes EngineとCloud Spannerを主軸に置いた構成となっています。特に、書き込み・読み込みの性能のスケールができ、クラ

      モバイルゲームのインフラアーキテクチャ特集 - 技術選定のポイントと今後の展望 - Findy Tools
    • AWS 構成図を S3 にアップするだけで Terraform のコードを git push / pull request から terraform plan まで自動で動作するシステム

      2024/10/25 社内 LT 会 ■GitHub ・Lambda https://github.com/hiyanger/diagram-to-terraform-cicd-lambda ・生成コード https://github.com/hiyanger/diagram-to-t…

        AWS 構成図を S3 にアップするだけで Terraform のコードを git push / pull request から terraform plan まで自動で動作するシステム
      • GitHubをコードで管理 ! Terraformを導入して安全な管理を実現しました - ROUTE06 Tech Blog

        ROUTE06 では GitHub の管理に Terraform を導入しました。今回はその導入の背景、実際に導入してどう変わったのか、導入方法について紹介したいと思います。 Terraform とは Terraform は、IaC(Infrastructure as Code)ツールの一種です。 インフラの設定をコードとして管理することで、設定の変更履歴が明確になり、誤った設定によるトラブルを防ぐことができます。 なぜ GitHub を Terraform で管理するのか ROUTE06 では、全社的に GitHub を使用しています。そのため、GitHub の管理は非常に重要です。 Terraform 導入前には、以下のような課題がありました。 手動での設定変更時にミスが発生する 設定変更の履歴が追いにくい 重要な変更(リポジトリの作成や Organization へのユーザー招待など

          GitHubをコードで管理 ! Terraformを導入して安全な管理を実現しました - ROUTE06 Tech Blog
        • Fargate Spot が Arm アーキテクチャに対応! シュッと移行してコスト削減を実現 - カミナシ エンジニアブログ

          こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 「円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します」にも書いたとおり、カミナシではほぼすべてのコンピューティングに Arm アーキテクチャを採用しています。また、運用コストを下げるために AWS Fargate を最大限活用しています。 Fargate には Fargate Spot という選択肢があります。 EC2 のスポットインスタンスと同様のコンセプトで、次のような特徴があります。 AWS クラウドの空きキャパシティを活用してタスクを実行 キャパシティが逼迫すると 2 分前の通知とともに停止させられる コストは Fargate と比べて 7 割引(東京リージョンの場合) 高い可用性を求められない環境では Fargate Spot を使ってコストを抑えたいところですが

            Fargate Spot が Arm アーキテクチャに対応! シュッと移行してコスト削減を実現 - カミナシ エンジニアブログ
          • AWS ECS Fargate Autoscaling の実戦的な基礎知識 | 外道父の匠

            Autoscaling については過去に何度か書いているのですが、今回は ECS Fargate について少し掘り下げつつ整理してみたいと思います。 仕組みとしては難しくはなく、わりと雑な理解度でも動くっちゃ動くとはいえ、リソースとしての重要度は高い箇所であり、正しく理解するとより関連箇所の最適化が見込めるところでもあります。 概要 ECS は on EC2 で動かすと、インスタンスとタスクの二段階での Autoscaling になるところが、Fargate だとタスクのみで考えられる簡素さが強みです。 ECS Service のタスク群に対して、特定の条件(主に平均CPU使用率)を満たした時にタスク数を自動的に増減することで、負荷対策とコスト削減という目的を達成しつつ、運用者が基本は放置できることになります。 ただ、それだけの理解では浅すぎるので、増減における詳細やリスクなどについて把握

              AWS ECS Fargate Autoscaling の実戦的な基礎知識 | 外道父の匠
            • モニタリング品質改善でMTTA(平均確認時間)を90%短縮した話 - ぐるなびをちょっと良くするエンジニアブログ

              こんにちは。ぐるなびでSREをしている江島です。 普段はコンテナ基盤の運用やサービスの品質向上に向けたSRE活動といった業務を行っています。 9月6日に開催された「Cloud Operator Days Tokyo 2024」で登壇し、「モニタリング品質向上」をテーマに発表を行いました。今回の記事では、その内容を掘り下げ、具体的な方法や実践的なアプローチについて解説していきます。 Cloud Operator Days Tokyo(CODT) とは 「Cloud Operator Days Tokyo (CODT)」は、クラウドシステムの運用者に焦点を当て、日本のオペレーターの底力を高めることを目的とする技術イベントです。 運用の自動化やパブリッククラウドの運用、オブザーバビリティなどクラウドにまつわる様々なテーマでのセッションが行われていました。 モニタリング品質向上の背景 今回は「モニ

                モニタリング品質改善でMTTA(平均確認時間)を90%短縮した話 - ぐるなびをちょっと良くするエンジニアブログ
              • 【Google Cloud】プロジェクト横断のロギング基盤を構築(データ収集から可視化まで) - Insight Edge Tech Blog

                目次 1. はじめに 2. ログデータの収集 GCP インフラ構成の説明 各サービスの設定 ディレクトリ構成 共通リソースの作成 個別プロジェクトリソースの作成 3. ログデータの可視化 4. まとめ 1. はじめに こんにちは。Insight Edge で Developer をしている熊田です。 普段システム開発を進める上で、システムの利用者数や頻繁に利用されている機能を調べたいと思うことはありませんか? 特にPoC検証やシステム運用フェーズにおいては、そのようなニーズが多くあるのではないでしょうか。 そのようなニーズに応えるためには、ログを収集する必要があります。また、上記のようなニーズはプロジェクト共通のものであることが多いかと思います。 これら要望に応えるために、GCP の複数プロジェクトにまたがるログ収集及び可視化をするためのロギング基盤を検証構築してみたので、その紹介をしたい

                  【Google Cloud】プロジェクト横断のロギング基盤を構築(データ収集から可視化まで) - Insight Edge Tech Blog
                • FourKeys風の指標で開発生産性が4.5倍になった話 | CyberAgent Developers Blog

                  こんにちは、FANTECH本部の山下(@takecy)です。 エンジニアリング活動の計測や可視化、難しいですよね。 そもそもそんな事が可能なのか?と思いつつも、自分たちはこんだけやっているぜ、1年前と比べてこんだけ改善したぜ、というのが見えるのは、ドラクエのレベルアップと同じような楽しさがあります。(ドラクエ3予約しました) 紆余曲折を経てエンジニアリング活動を計測/可視化した後、開発フローなどを見直したら、結果的に指標が思った以上に伸びたのが目に見えて、テンションが上がったお話をご紹介します。 計測と可視化方法 エンジニアリング活動の計測方法は色々ありますが、まずは王道のFourKeysを使ってやってみることにしました。 2022/03月ごろからこの試みを開始しました。 FourKeysとは 色々なところで言及されているので詳細な説明は省略しますが、ソフトウェア開発チームのパフォーマンス

                    FourKeys風の指標で開発生産性が4.5倍になった話 | CyberAgent Developers Blog
                  • go-graphviz が新しくなりました - Route54

                    TL;DR goccy/go-graphviz が新しくなり、cgo を使って Graphviz の機能をバインディングしていたところを WebAssembly ( 以降 WASM ) ベースに置き換えたため、晴れて Pure Go になりました。 一部 API のインターフェースが少し変わっていますが、以前できたDOT言語の読み書きやSVG、PNGとしての出力などは全て可能です。それに加え、図中の画像のレンダリングサポートやフォントまわりの改善、最新のGraphvizライブラリへの対応により以前よりもレンダリング処理が改善されています。 また、任意の出力フォーマットに対するレンダリング処理をプラグイン形式で外から追加できるようになったので、terraform graph の内容を読んで構成図を出力するとか、アスキーアート出力するみたいな特殊な処理が実装しやすくなりました。 Graphvi

                      go-graphviz が新しくなりました - Route54
                    • 現職での技術的活動の振り返りと反省(自戒) | ymtdzzz.dev

                      2024年6月30日に今の会社を退職し、翌7月1日から別の会社に入社することになった。 現職の在籍期間は大体3年弱ほどで、アーキテクチャを中心とした技術的な意思決定も色々してきた。新規構築から運用までやってきた中で感じたことや経験豊富なエンジニアからいただいたアドバイスなど、それらを含めて当時の意思決定の反省を自戒を込めてここで書いておく。 Table of Contents 留意事項 やったこと 想定効果 基盤チーム側の効果 サービス開発(基盤のクライアント)側の効果 意思決定 技術スタック コード管理 インフラ その他 所感と教訓 コンポーネントとリポジトリの粒度は別 複雑性を犠牲にする決断の重さ(マルチクラウド、マイクロサービス etc.) 共通基盤を初めから独立したサービスとしてデプロイしないのもあり サブシステムとしての共通基盤にどこまで粗結合を求めるべきか考える 結論:後から分

                        現職での技術的活動の振り返りと反省(自戒) | ymtdzzz.dev
                      • Terraform v1.10 からは S3 Backend の State Lock に DynamoDB が必要なくなる

                        terraform { backend "s3" { bucket = "tf-s3-state-lock-example-tfstate" key = "terraform.tfstate" + use_lockfile = true # これだけで State Lock が有効化される - dynamodb_table = "example-state-lock-table" # こっちは不要 } } この機能は v1.10 から実験的に導入されます。 そしてこの機能追加に伴い、従来の DynamoDB テーブルを使用した State Lock の機能は将来的に削除されます。 In a future minor version the DynamoDB locking mechanism will be removed. github.com/hashicorp/terraform/w

                          Terraform v1.10 からは S3 Backend の State Lock に DynamoDB が必要なくなる
                        • LLMアプリ開発プラットフォームOSS Difyのスケーラブル・高可用な運用 | BLOG - DeNA Engineering

                          はじめに はじめまして。24卒でデータ基盤部に配属されたMLエンジニアの大泉です。この記事では、DeNA の社内生成 AI サービス「SAI」のバックボーンとして用いられているオープンソースの LLM アプリ開発プラットフォームである Dify を DeNA でどのように運用しているかをお話しします。 Dify を本記事の構成で Google Cloud 上で立ち上げるためのコードを GitHub 上で OSS として公開しております。Google Cloud 環境をお持ちの方はぜひお試しください。 背景 4月の共通研修を終えた新卒エンジニアの中で、有志で集まった8名の新卒が、 「DeNA が日本で一番生成 AI を活用している企業になる!」という Vision を掲げ、社内プロダクトを作る新卒エンジニア研修のプロダクトのひとつとして社内生成 AI サービス SAI の開発に取り組みました

                            LLMアプリ開発プラットフォームOSS Difyのスケーラブル・高可用な運用 | BLOG - DeNA Engineering
                          • Octoverse: AI leads Python to top language as the number of global developers surges

                            Remember when people said AI would replace developers? Our data tells a different story. As AI rapidly expands, developers are increasingly building AI models into applications and engaging with AI projects on GitHub in large numbers. At the same time, we’re seeing an unprecedented number of developers join GitHub from across the globe, and many of these developers are contributing to open source

                              Octoverse: AI leads Python to top language as the number of global developers surges
                            • やったことが無い技術領域のチームマネジメントについて | フューチャー技術ブログ

                              秋のブログ週間2024の1本目です。 はじめにTechnology Innovation Group真野です。 社会人歴15年の中で、自分が業務で実施したことがない領域のマネジメントを求められる場面がありました。 私で言うと、普段はバックエンド(バッチ処理やWeb APIなど)を作ることが多いです。フロントエンド開発・モバイルアプリ開発・ML/データ分析系の領域について、フルコミットで直接開発を行ったことが無く不得手です。実際の開発はそれぞれリーディングできる人材がいるという前提ですが、やったことがない技術領域のチーム も 「見ておく必要がある」という時にどうすべきかの考えをまとめます。なお、ちゃんとした経験者をマネージャーにアサインすべきという話が間違いなく正論ですが、体制上そこまでリッチに組めなかったこととし、計画周りをどうこうする話はこの記事では割愛させてください。 エッセー的な話が

                                やったことが無い技術領域のチームマネジメントについて | フューチャー技術ブログ
                              • Terraformで学ぶAWS(1):サーバーレスから始める再利用可能なインフラストラクチャ:じゅ~しぃ~すくりぷと

                                IaCは怖くない! Terraformを使って再利用可能なインフラストラクチャを学んでいこう ■ 説明 本書はAWSの初心者~若干触ったことのある方向けの本です。Terraformとは、HashiCorp社により開発しているオープンソースのインフラ自動構成ツールです。AWSだけでなく、Google CloudやAzure、Discordなどのインフラを構築可能です。Terraformでは、インフラのデプロイ設定や手順をコードとして記載する「Infrastructure as Code(IaC)」の一種です。IaCを使うことで、デプロイの作業手順を再利用できるようになり、統一化や状態変更に対して頑強なシステムを作ることができます。 以前はTerraformといえば、「ブラウザから操作はできるけどIaCはちょっと…、せめてCDKにしてほしい」のように敷居が高いものでした。しかし、昨今の生成AI

                                  Terraformで学ぶAWS(1):サーバーレスから始める再利用可能なインフラストラクチャ:じゅ~しぃ~すくりぷと
                                • SpringBoot x MyBatis x TestContainersでSQLテストを行う

                                  自己紹介 佐々木興平 ( X: @earu) 所属: エキサイト(株) (4年6ヶ月)(ex.セレス,CA,ぐるなび) 職種: メディア事業部事業部長 兼 メディア事業部開発責任者 やっていること: - PdM - テックリード 最近チームでよくさわっている : - SpringBoot / Java / htmx / alpine.js / Tailwind CSS / MySQL PostgreSQL / Redis / AWS 色々/ AWS copilot CLI / Terraform ポリシー: - 設計は難しくても正しいものに寄せる - 設定は簡単なものに寄せる

                                    SpringBoot x MyBatis x TestContainersでSQLテストを行う
                                  • Terraform Stacksの構成要素を図解してみる | DevelopersIO

                                    HashiConf 2024でTerraform Stacksがパブリックベータになりました。 Terraform Stacksによって新しい構成要素がいくつか追加されたので、できるだけ図を使って説明していきます。 Terraform Stacksとは Stacks are a powerful configuration layer in HCP Terraform that simplifies managing your infrastructure modules and then repeating that infrastructure. スタックは、インフラストラクチャ モジュールの管理とそのインフラストラクチャの繰り返しを簡素化する、HCP Terraform の強力な構成レイヤーです。 Stacks Overview | Terraform | HashiCorp Dev

                                      Terraform Stacksの構成要素を図解してみる | DevelopersIO
                                    • 新BIツール「Superset」を導入した話

                                      こんにちは。Data Engineeringチームの河野(@matako1124) です! 今年のData Engineering業務としてデータマネジメントからデータ活用促進の仕組み化まで幅広く活動してきましたが、その中でも特に事業にインパクトの大きい変革のお話をしていこうと思います。 結論から言うと、Supersetの新規導入とRedashからの乗り換えを試みています。 注意 執筆に当たり細心の注意を払っておりますが、不十分な説明や誤りがある可能性もございます。 記事内で紹介しているコードは部分的なものです。参考程度にご参照ください。 目次 2024年時点でのLuupのデータ基盤のご紹介 現状の課題 Superset導入の目的と理由 構築事例 Superset推し機能 Superset改善したい機能 まとめ、今後の施策 終わりに 2024年時点でのLuupのデータ基盤のご紹介 本編に入

                                        新BIツール「Superset」を導入した話
                                      • YAMLで記述するGo製のビルドツールTaskをGitHub Actionsと連携してみた | DevelopersIO

                                        Goの開発現場では、ビルドやテストをビルドツールのMake(Makefile)で実行することがよくあります(例: $ make test)。たとえば、Mobyプロジェクト(Dockerの主要コンポーネント)やTerraformもそうです。 TerraformのMakefile MobyのMakefile Makefileは一度書いてしまえば変更の頻度は少ないとはいえ、最近では configure; make; make install といった手順でMakefileと触れる機会も減少しています。また、JSONやYAMLに慣れた人には、1970年代から存在するMakeの書式をとっつきにくく感じることもあり、保守性に課題が生じる場合もあります。 そこで登場するのがTaskです。Taskは、Makeの主要なユースケースをシンプルかつ簡単にYAML形式で記述できるツールです。 本記事では、Goプロ

                                          YAMLで記述するGo製のビルドツールTaskをGitHub Actionsと連携してみた | DevelopersIO
                                        • ECRはイミュータブルにしておくと安全

                                          レバテック開発部の松浪です。 現在、私はレバテックの認証基盤(レバテックID)の開発・保守を担当しているのですが、セキュリティ強化や一貫性の保証の観点からECRに置くコンテナイメージをイミュータブルとなるように設定を変更しました。 イミュータブルにすることでなぜセキュリティの強化に繋がるのか?一貫性が保証できるのか? 簡単にですが説明したいと思います。 そもそもECRって何? ECRはAWSが提供するコンテナイメージのレジストリサービスです。 ECRを利用するとコンテナイメージの保存や管理、デプロイに使用したりできます。 イミュータブルにすると、一度保存したコンテナイメージを後から変更(上書き)することができなくなります。 ※ Amazon Elastic Container Registry GitHubActionsを利用したECSのデプロイ 認証基盤の機能のデプロイにはGitHub

                                            ECRはイミュータブルにしておくと安全
                                          • Atlantisのマルチクラウドへの対応について - カンムテックブログ

                                            SREの菅原です。 カンムではAWSやGCP、Datadogなど様々をIaaS・SaaSをterraformで管理しているのですが、以前は「GitHub Actionsでplan」「管理者や開発者が手元でapply」というフローになっており、terraform applyの実行が管理者や一部の権限を持った開発者に集中してしまい、インフラの変更作業の速度が落ちてしまっている状態でした。 しかし、Atlantisという「Pull Request上でterraform plan・applyを実行する」ツールを導入したことで、うまくapply権限を各開発者に委譲することができるようになったので、Atlantisの運用について、特にマルチクラウドへの対応について書きます。 Atlantis www.runatlantis.io AtlantisはWebhookでGitHubのPull Request

                                              Atlantisのマルチクラウドへの対応について - カンムテックブログ
                                            • いまさら聞けない「サーバレスは安くて簡単」が誤解なのはなぜ?

                                              関連キーワード アプリケーション開発 | クラウド運用管理 | 運用管理 | サーバ 「サーバレスコンピューティング」で何ができるのかについて、正しく理解されていないことがよくある。「運用作業から解放される」「コストを抑えることができる」という認識を持ったままアプリケーションを運用すると、“思わぬトラブル”に見舞われることがある。誤解しないためには、以降で紹介するサーバレスコンピューティングの仕組みや要点を理解することが重要だ。 「サーバレスは安くて簡単」が誤解なのはなぜ? 併せて読みたいお薦め記事 連載:「サーバレス」の正しい理解とは いまさら聞けない「サーバレス」で何ができる? 3大クラウドで丸分かり サーバレスについてもっと詳しく サーバ管理不要だけじゃない「サーバレスの利点」とは? 3つの例で解説 クラウドでまさかの「高額請求」を招く意外な“設定ミス”の正体 サーバレスコンピューテ

                                                いまさら聞けない「サーバレスは安くて簡単」が誤解なのはなぜ?
                                              • 今週のはてなブログランキング〔2024年10月第3週〕 - 週刊はてなブログ

                                                はてなブログ独自の集計による人気記事のランキング。10月13日(日)から10月19日(土)〔2024年10月第3週〕のトップ30です*1。 # タイトル/著者とブックマーク 1 40歳になるので30代でやってよかったことをまとめた - そーだいなるらくがき帳 by id:Soudai 2 令和最新の起業はオンライン完結で簡単だし、スマホだけで会社のホームページが作れて最高だった - 941::blog by id:kushii 3 チャットコミュニケーションで使わないようにしている表現 - Konifar's ZATSU by id:konifar 4 国家を崩壊に向かわせる要因について、歴史を定量分析することで導き出す「歴史動力学」を扱った一冊──『エリート過剰生産が国家を滅ぼす』 - 基本読書 by id:huyukiitoichi 5 問題を"放置"さえしなければちょっとずつよくなっ

                                                  今週のはてなブログランキング〔2024年10月第3週〕 - 週刊はてなブログ
                                                • 自宅とGoogle Cloud VPCをVPNで繋いでみる - abekoh's tech note

                                                  はじめに 我が家には数年前に組んだ「GeForce RTX 3080搭載のゲーミングPC」があるわけですが、最近はPCゲームをそこまでやらず、それなりのGPUあるのにもったいないなという状態です。 最近はローカルLLMの性能も良くなり、せっかくなのでそれなりのGPU積んだゲーミングPCをAIマシンにして有効活用できないかな、と思い。それなら自宅以外、クラウドからも呼び出せると嬉しいだろうなーと妄想してました。 そのはじめの一歩として、IPSec VPNで自宅ネットワークとGoogle Cloud VPCを繋ぐ仕組みを整えてみました。そのログです。 Overview 全体イメージはこちら。Google Cloudのほうはとりあえず疎通確認のためにCompute Engineのみ。自宅のほうはYAMAHAルータを中心にネットワークを構築してみてます。 自宅ネットワークの刷新 自宅の回線はNur

                                                    自宅とGoogle Cloud VPCをVPNで繋いでみる - abekoh's tech note
                                                  • 技術がなければ作れない、必要がなければ存在している資格がない - Platform Engineering: A Guide for Technical, Product, and People Leaders の読書感想文 - じゃあ、おうちで学べる

                                                    我に似せる者は生き、我を象る者は死す(本質を理解して創造的に学ぶ者は発展し、表面的な模倣に留まる者は衰退する)。 はじめに 「Platform Engineering: A Guide for Technical, Product, and People Leaders」は、現場での実践知を出発点として、プラットフォームエンジニアリングの本質に迫る実践的なガイドとして、技術リーダーから上級管理職まで向けた幅広い読者層に向けて書かれています。個人的にはもう少しだけ広げて開発者やプラットフォームを実際に使う側も読んでも学びのある本だと思いました。著者のCamilleとIanの豊富な経験が凝縮された本書は、単なる表面的な手法の模倣ではなく、実際の現場での試行錯誤から導き出されたプラクティス、そしてその背後にある根本的な原理と思想を探求し、それが現代のソフトウェア開発組織においていかに革新的な価値

                                                      技術がなければ作れない、必要がなければ存在している資格がない - Platform Engineering: A Guide for Technical, Product, and People Leaders の読書感想文 - じゃあ、おうちで学べる
                                                    • lock 機構のための GitHub Action を作った

                                                      lock 機構を実現するための GitHub Action を作ったので紹介します。 背景 lock 機構によって複数のプロセスが同時に実行されるのを防ぐことが出来ます。 例えば GitHub Flow で Pull Request (以下 PR) をマージしたらデプロイを実行する場合に、デプロイ直前に lock を取り完了後に unlock することで、デプロイ中に他の PR がマージされてデプロイが複数同時に実行されるようなことを防ぐことが出来ます。 また、 Terraform で State の分割作業を行う際に、作業前に lock を取り完了後に unlock することで作業中に terraform plan, apply が実行されるのを防ぐことが出来ます。 今回は GitHub Actions で簡単に lock 機構を実現するための Action を開発しました。 特徴 今回

                                                        lock 機構のための GitHub Action を作った
                                                      • リーナープロダクトの現状と課題、採用情報 2024年10月版 - リーナー開発者ブログ

                                                        こんにちは、リーナーの小久保 id:yusuke-k です。 この記事は、リーナーという会社の名前は知ってるけど、どんな会社なのかもうちょっと知れるといいな、という人向けの簡潔な紹介記事です。内容についてより詳しく聞いてみたいことがあればお近くのリーナーメンバーに気軽にお声がけください。 プロダクトとチームの現状と課題 リーナーは調達購買領域で、BtoB SaaSを開発提供しているスタートアップです。 調達購買とはいわゆる「企業の買い物」です。複雑なプロセスが絡み合う領域ですが、現在はその中でも、見積や購買(発注)における業務を中心に扱っています。 二つのプロダクト、一つの新規プロダクト リーナー見積 https://leaner.jp/sourcing リーナー購買 https://leaner.jp/purchasing 新プロダクト(開発中) プロダクト横断の基盤 ID基盤(開発中)

                                                          リーナープロダクトの現状と課題、採用情報 2024年10月版 - リーナー開発者ブログ
                                                        1