UMEZO

UMEZOコンサルティング合同会社代表。https://www.umezo.jp/ 従…

UMEZO

UMEZOコンサルティング合同会社代表。https://www.umezo.jp/ 従来手法とは違う視点でアプリ構築のお手伝いを行っています。 今までの経験を活かし皆様のお役に立てるような知識やアイデアをご提供しています。 ルールエンジン/ルール駆動開発/アーキテクチャ

最近の記事

福島銀行 ルールエンジンを使った勘定系システムを稼働

ルールエンジンを使った良い事例が発表されています。こちらは日経クロステックの記事です。 福島銀行さんもプレスリリースを出されておりました。 https://www.fukushimabank.co.jp/press/2024/img/20240716-001.pdf プロジェクトを推進したフューチャーアーキテクトさんも発表されています。 日経クロステックの記事にある通り、 間違いなくルールエンジンは強力なキーパーツです。プログラムの中のIf-Then を単に置き換え

    • 設計・開発に思いを伝える、要件定義書の重要性

      詳細設計書は要る?というblogを書きましたが、今度は要件定義書についてです。 いろいろな案件を見ていますが、企画書や要件定義書、要件仕様書等が不明確で、何を目的としているのか、どんな目標があるのかがわからないものをよく目にします。企画書・要件定義書、どちらでも良いのですが、書くべきものはちゃんと書いた方が良いです。 よくあるケースIT部門作成する要件定義書でよく見る「目的」は下記のようなものがあります。 システムの老朽化に伴いリニューアルをする 運用の負荷を軽減する

      • 今後10年を考えたデジタルトランスフォーメーションについて論 他

        オージス総研さんより、4つのコラムが掲載されております。 2つは経営者的視点より書かれており、10年後存続可能な企業であるためにITシステムがどうあるべきかを論じる前段の現状分析がしっかりとされております。 【ルールエンジン コラム】 日本企業のグローバルビジネスにむけた挑戦 ~ITテクノロジーとデジタルの活用~ 第1章 同時多発的に起きるグローバル経済の不確実性の増大 【ルールエンジン コラム】 日本企業のグローバルビジネスにむけた挑戦 ~ITテクノロジーとデジタルの活

        • 詳細設計書、やめませんか?

          アプリケーションを開発する時のドキュメント。色々ありますよね。要件定義書・概要設計書・詳細設計書・運用設計書・テスト計画書等、様々なドキュメントを作成します。作業の前に力をいれるあまり、プロジェクトが終了した時にあまり役に立たなくなっているドキュメントがあります。 詳細設計書です。 アプリ作成の潮流の変化ここ20年くらい、業務アプリはシステムインテグレータ(とそのパートナー会社)がドキュメントを作成し、下請けプログラマーや海外のプログラミング集団が実装を担当する というの

        福島銀行 ルールエンジンを使った勘定系システムを稼働

          Timefoldの配車ルート計画デモ

          Timefold の配車ルート計画 (Vehicle Routing) デモを使って、最適化とはどういうものかを御覧いただきたいと思います。(ちょっと長いです…すみません) このTimefoldの配車ルート計画 は、大型家電や家具のように、送達した先で時間を掛けて設置するような配送を想定しています。そのため、配達先での稼働時間が含まれます。 デモのデータまず、配達エリアを設定しています。エリアは左上(北東)と右下(南西)の緯度経度を指定し、そのスクエアな領域内に、配送拠点と

          Timefoldの配車ルート計画デモ

          流行りのAIではない方のAIは、今すぐ経営を改善!

          生成AIという言葉を見ない日はないくらいLLM(大規模言語モデル)によるAIが流行っていますが、一方、組合せ最適化というものをご存知でしょうか。人が気づかなかったより良い組み合わせを見つけ出す(探索する・計画する)という意味で、人工知能学会などではAIの一つと定義されています。 世の中は組み合わせでできている例えば、宅配業。 荷物の容積・重量と配送する車の積載量の組み合わせ、配送先と掛かる時間の組み合わせ、ドライバーとトラックの組み合わせ等が考えられます。 例えば、看護師

          流行りのAIではない方のAIは、今すぐ経営を改善!

          システムが経営をロックしている現状

          古い基幹システムをお持ちのお客様のシステムリニューアルにお付き合いしているのですが、なんとも無駄な行為ばかりが目立ってしまっています。経営に重大な影響を与えかねないのに、どうしてその道を選んでしまうのか… 現状の課題未だに30年前のメインフレームのアーキテクチャのまま、基幹システムを動かしていらっしゃるお客様がいらっしゃいます。基幹システムなので、もし動かなくなってしまった時の影響は計り知れません。全世界の物流・生産・会計が止まってしまうからです。 しかし、顧客との接点を持

          システムが経営をロックしている現状

          ルールエンジンが楽しい理由

          私がルールエンジンに出会ったのは、ILOG社に入社した時です。2007年かな? 入社した当時は、「ビジネスルールエンジン担当ね」と言われ、IF-THENに相当するロジックを、業務ユーザ向けの言語で書き直すものだと思っていました。なんでIF-THEN-ELSEで書けるものをわざわざIRL(ILog Rule Language) という特殊なものに書き直さないといけないのか?そりゃ「あたかも自然な日本語」で書くことで、わかりやすくなるけど、そんな手間を掛けるだけのものがあるのか?

          ルールエンジンが楽しい理由

          生成AIを活用した意思決定マネジメント開発ウェビナー (2024/7/4, 7/5 開催)

          イベントのお知らせです。(私は出ないですが…) 生成AIが流行っていますが、もともと人工知能やエキスパートシステムの研究から創出されたルールエンジンは、機械学習で導出されたロジックを実行する機構としても有用です。 こちらのイベントでは、ルールエンジンを稼働させるために必要なデータモデルやルールを生成AIで作成するようなアプローチと思われます。 私もルールエンジンDroolsのDRLをChatGPTに書かせてみたことがありますが、意外とできるものです!もちろんそのままdep

          生成AIを活用した意思決定マネジメント開発ウェビナー (2024/7/4, 7/5 開催)

          ルールエンジンのまとめサイト 公開!

          私が今まで企業に属していたということもあり、どうしても自社の製品を中心にBlog等を書くことが多くありました。担当していたルールエンジン製品が他社に移管されてしまったこともあり、独立をし中立性を持つことで、もっと広い視野で皆様のお力になるのではないかと考えていました。 「ルールエンジン」や「BRMS」 といったキーワードで検索してみると、結構な数の記事や動画が見当たりました。ベンダーの枠を取り払い、自力で検索しうる限りのデジタルコンテンツを集めました。 皆様、それなりに苦

          ルールエンジンのまとめサイト 公開!

          開発での無駄がコスト高に繋がる

          開発コストを下げ、リスクを下げ、稼働までの時間を短縮して業務に貢献する開発手法はあるのか? あります。単純な話です。無駄なものを開発しない。ソレにつきます。 ではどうすれば無駄な開発をしなくてよいのか? 通常の開発での無駄はここにあります。 実物で検証しない設計に基づく実装で、テスト段階に入ってから不具合が多発する開発 役割分担の不明確なアーキテクチャに基づく設計 既存基幹システムの入替えに伴う間違ったゴール設定 実物で検証しない設計に基づく実装で、テスト段階に入っ

          開発での無駄がコスト高に繋がる

          プロジェクト成功の鍵:意識と得意領域を最大限に活用

          プロジェクトが2つあるとします。 一つは、ビルのワンフロアを貸し切ってプロジェクトルームを設置し、厳格なコーディング規約を作って、担当毎に目標とゴールを設定した数年単位の大規模プロジェクト。 もう一つは、リリース後に不具合が発生し、顧客が激怒の中で修復するプロジェクト。 どちらがより高い満足度を得られるプロジェクトでしょうか? 業務コンサルタントを入れて戦略と戦術を完璧にし各部門毎にKPIを設定した企業が、引かれた線路の上を走っていると思いきや、在庫過多や納期遅れが多発して

          プロジェクト成功の鍵:意識と得意領域を最大限に活用

          クラウドネイティブとは

          IT界隈で使われている用語で、正しく使われているものもありますが、適切な解釈をせずに使われている言葉もあります。全てに共通するのですが、それらが誤用される一因として「概念」を示しているからだと思います。「概念」を「手法」や「ツール」と解釈することで違う意味を持ってしまって、結局「良くわからない」という状態になっていると思うんですよね。 今日はその中でもモヤモヤする「クラウドネイティブ」という言葉に注目してみたいと思います。 クラウドという環境が出てくる前は、オンプレミス(物

          クラウドネイティブとは

          人口減で迎えるこの先の経営に必要なモノ

          少子化による若手社員の減少は避けられない状態にあるのは皆さん御存知の通りです。現業を維持・発展させるために、社員が業務に専念できるようにしていく必要があります 業務には人へのサービス、ものづくり、巡回等があるわけですが、その他にも記録をつける・計算を行う・チェックを行う・記録を確認する・承認するといったことがあると思います。入力の分野はIoTやRPA等、データの発生源から自動的に取得する手法や、音声認識なども充実してきていますが、100%完全自動化までには至っていないと思い

          人口減で迎えるこの先の経営に必要なモノ

          プロジェクト成功の鍵:見積もりが最初の分かれ道

          皆さんは既存システムの更改時に、プロジェクトの見積をどのように見ていますでしょうか。今までお付き合いしている、いわゆる既存ベンダーに見積もってもらっているケース、ソースコードの量( Source Line Of Code、つまり行数。 以下 SLOCと略) や複雑度から見積もってもらっているケースなどがあるかと思います。 見積から完成までの注意点を見ていきたいと思います。 見積の根拠が「既存のSLOC」の場合 ハードウェアやソフトウェアの保守切れ、または運用費用のコスト高

          プロジェクト成功の鍵:見積もりが最初の分かれ道

          内部統制をホンキで考える

          皆様のところでは内部統制は十分にやっていますでしょうか。 「内部統制、ちゃんと業務フローを制定して、サインやハンコをやっているから、もし何か問題が発生しても、誰が犯人かすぐわかるようにしているよ」 こんな声が聞こえてくる日本社会ですが、そもそも間違っているように思えます。 はい、日本は昔からハンコ文化。ハンコを押すということの重みは解っているので、ハンコを押す=内部統制できていますという感じかもしれません。 そもそも内部統制は、6つの基本的要素から構成されます。 統制環

          内部統制をホンキで考える