タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
「とにかく日本の住所のヤバさをもっと知るべきだと思います」に、住所正規化コンバータはどこまで応えられるのか、やってみた - ジャスミンソフト日記
note.com を読みました。私自身も日本の住所の扱いを何とかしないと業務アプリケーションの運用に支障が出ると感じ、2003年に「住所正規化コンバータ」というソフトウェアをリリースし、20年が経過しました。現在は国際航業株式会社様に取り扱っていただいています。 www.kkc.co.jp このブログにあるような指摘にどこまで応えられただろうかということで、社内で試してみました。利用したバージョンは最新の R7.2.0 で、住所マスタは2022年秋版と組み合わせました。その結果を公開します。 住居表示 丁目表記と地番表記の混在に対応しています。 浦安市舞浜2-1-1 郵便番号 都道府県 市区町村 町域 小字・丁目 番地・号 マッチレベル 2790031 千葉県 浦安市 舞浜 2 1-1 号レベル 浦安市舞浜2-11 郵便番号 都道府県 市区町村 町域 小字・丁目 番地・号 マッチレベル 2
SPRING FEST 2019 - ローコード開発プラットフォームと、 ドメイン駆動設計と、Springの関係 - ジャスミンソフト日記
2019年12月18日のイベントで、ランチセッション枠として登壇しました。全体では700名を超える参加者で、私のランチセッション枠も満員御礼でした。ご参加いただいたみなさま、ありがとうございました！ springfest2019.springframework.jp 当日の発表内容を報告します。今回の対象は「社内業務システムの開発」です。また、タイトルは「ローコード開発」となっていますが、具体的にはWagbyに限定しています。そこはメーカーの発表として、お察しください。では、はじめます。 ドメイン駆動設計は自由度の高さが魅力だが... もし私が30歳で、Wagbyをつくっていなければ、DDDは大好物なネタとして飛びついたでしょう。私からみたDDDの特徴は次のとおりです。 業務設計者（現場）がコードを書くのではなく、プログラマが業務を理解するアプローチ。 内製開発、アジャイルと相性がいい。
ノーコード／ローコード開発ツールのジャンル分けと、Wagbyの立ち位置について - ジャスミンソフト日記
今年は間違いなく「ノーコード／ローコード開発ツールがブレイクした」年、になるでしょう。マイクロソフト社による PowerApps のアピールが本格化したことと、アマゾン社の HoneyCode の登場が決定打です。グーグル社もすでに AppSheet を出しており、これで海外大手企業の製品が出揃いました。 奇しくも日経コンピュータの次回号ではローコード開発の特集記事が予告されていました。メディアの取り扱いも増えていると感じています。 ガートナージャパン片山さんのインタビュー記事は、現在の状況をよく整理しています。ユーザ企業は「パッケージか、手組み開発か」の二択ではなく、「ローコード開発ツールで開発」の選択肢が増えた、と感じているはずです。 www.atmarkit.co.jp さてブレイクするのは嬉しいのですが、あまりにも選択肢が多いと開発者も混乱してしまいます。そこで大雑把なジャンル分け
2013年8月の超高速開発コミュニティ発足から関わって足掛け6年、当初は予想していなかった名称変更というイベントにも立ち会うことになりました。 www.atpress.ne.jp 上のプレスリリースにもあるように、"世界市場との歩調を合わせ…” というのが主な理由です。実際のところ、国内で業務アプリケーション開発に携わっている関係者の方々には "超高速開発” という言葉は知られてきたと実感しています。しかしこの考え方は日本でしか通用しないというものではなく、海外製品は "ローコード開発プラットフォーム” として認知されているという事実がありました。一般の方に "超高速開発とローコード開発って、何が違うの？” と混乱させないために、ここは名前を変えてでも市場への普及・啓蒙活動を優先させるという判断になりました。 会員の方からは「せっかく知られてきた言葉を捨てるのは、もったいない」という惜別の
2022年のジャスミンソフト運営方針、ローコードノーコード市場への逆風への備え - ジャスミンソフト日記
2022年になりました。読者の皆様、あけましておめでとうございます。 昨年はローコード開発、ノーコード開発というキーワードが一気に浸透した一年でした。私も運営に関わっている「ローコード開発コミュニティ」への参加希望者が増えていることからも、その勢いを感じています。 ところで、このようなブーム到来のあとは決まって「逆風」がやってきます。おそらく2022年は揺り戻しがくることでしょう。私が想定するツッコミは次のとおりです。 簡単なアプリは確かに素早く作れそうだ。しかし基幹系への適用は無理だろう。なぜならまともな方法論がないから。 市民開発者、というと聞こえはいいが、昔の EUC ブーム（End User Computing) の末路はどうなった？ 野良Excelの氾濫は好ましくない。 実は私たちは2006年のWagby市場投入から、ずっと似たような指摘を受けてきました。つまり、すでに耐性があり
予想はしていましたが、いまやDXというキーワードはなんでもあり、のバズワードです。最先端のAIやIoTといった技術を使いこなすのもDX、老朽化した基幹系刷新もDX（そういえば、このテーマについては「2025年の崖」でも語られました）、そしてノーコードやローコード開発ツールを学んで現場主導で内製化するのもDXです。ここまで対象が広いと、なんのためのDXだったのか、私も見失いそうになります。そこで今回、ITの専門用語を使わず、経営層に的を絞ってDXの意義を伝える文章を書いてみることにしました。 労働生産性の議論 これも経営層にとっては一度ならずも見聞したことがあるネタですが、いわゆる日本の労働生産性の問題です。 公益財団法人 日本生産性本部の「労働生産性の国際比較2021」によると、日本の時間当たり労働生産性は49.5ドル（5,086円）で、OECD加盟38カ国中23位とあります。 www.j
SAP2025年問題が投げかけたのは、システムではなく経営哲学そのもの - ジャスミンソフト日記
今、ネットで “SAP 2025年問題” で検索すると多くの意見を読むことができます。いい時代になりました。簡単にいうと「自社向けにカスタマイズしていたERPを、次のバージョンアップのタイミングでどう扱うか？」という問題について、対応期限が2025年までと設定された、ということです。現実問題としてユーザ企業の選択肢は限られています。 カスタマイズをやめ、次のバージョンアップではSAPの標準機能に自社業務を合わせる。 次の SAP でも、同じようなカスタマイズを再度、行う。 別の ERP に切り替える。（自社開発という選択もここに含まれる。） 私のこれまでの経験から、多くのユーザー企業の情報システム部で、上のパターンそれぞれの予算ならびに費用対効果の資料を作成しつつ、水面下で複数のSIerと接触し、落とし所を探るというフェーズに入っているのだろうと思います。しかし根本的には、この問題は経営陣
生成AIはローコード／ノーコードエンジニアにどのような影響を与えるのか - ジャスミンソフト日記
2023年上半期は、私の周辺でも生成AIの話題でもちきりでした。遅くなりましたが、このテーマについて私の現時点の見解を文章化します。 生成AIはローコード／ノーコードエンジニアにどのような影響を与えるのか 生成AIが、業務アプリケーション開発についての設計知識を十分に蓄積した状態 = 理想的な状態、にあると仮定します。（このブログを書いている2023年6月時点よりも、さらに賢くなった状態を想定しています。） ある目的を実現する業務アプリケーションを構築しようとしているエンジニアは、AIと対話を重ねることで、どういう機能やデータが必要かを早い段階で整理できることが容易になると期待できます。いわゆる要件洗い出しと分析、そして定義といった上流工程の分野を支援するという活用です。 これまでは既存システムまたは類似システムを調査しつつ、専門書を読んだり、現場担当者に尋ねるなどを重ねて、仕様を整理して
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
超高速開発コミュニティがローコード開発コミュニティに変わった背景 - ジャスミンソフト日記
専門用語をいっさい使わずに、経営層にDXの意義を伝えたい - ジャスミンソフト日記
www.aomori-life.com
hartwell.co.jp
blog.itokoichi.com
sumai.panasonic.jp
iixxx.hatenablog.com
mainichi.jp