注目のストーリー
すべてのストーリー
豆寄席第12回『DX時代の新しいスキル「グラフィック・レコーディング(グラレコ)」を身に着けよう』参加レポート
中山 尚子2021年11月26日に、豆寄席 第12回『DX時代の新しいスキル「グラフィック・レコーディング(グラレコ)」を身に着けよう』を開催いたしました。富士通株式会社 グラフィックカタリスト 成田富男氏にご講演いただきました。本稿では、豆寄席の内容をセミナーレポートとしてご紹介します。セミナー＋ワークショップの形式で、講師 成田様に解説いただいた内容を受けて、受講者は紙とペンを用意して実際にグラレコをやってみました。 講演で考え方・やり方を習う → 演習で体験する → また講演に戻ってTipsで消化不良を解消する、という流れで、短時間でグラレコが自分もできそう！？やってみたい！と思わ...
オンラインイベント『～人が組織を強くする～ 実ビジネスを成功に導くためのDX組織・人材戦略セミナー』のレポート
デジタル戦略支援事業部 第5(人材開発)グループ2021年10月27日に「～人が組織を強くする～」をコアとしてDX人材育成に課題を持つ皆様を対象としたセミナーを開催いたしました。本稿では、そのセミナーの講演内容をセミナーレポートの形でご案内させていただきます。当日は、DXを掛け声に終わらせるのではなく、実ビジネスを成功に導くために必要な知見をお持ちの外部講演者をお招きした講演と当社の人材育成の事例が紹介されました。はじめに、一橋大学経営管理研究科でDX人材を活かすための組織についての研究を重ねておられる神岡太郎教授より「データ×スキル×ストーリー DXに向けた企業姿勢の醸成」と題した講演...
第3回：ドメインシフトと機械学習の性能低下
AI技術チームの藤堂です。今回は、機械学習システムの本番運用において課題として生じるドメインシフトに関し、その概要と原因、対策についてご紹介します。ドメインシフトは学習データとテストデータの分布が一致しない状況を指し、それにより機械学習の性能低下に繋がることがあります。また機械学習システムの実験・開発から運用における特有の課題を解決するための取り組みであるMLOpsが注目される中で、ドメインシフトは取り組むべきテーマの一つとされています。さらにドメインシフトに関連する考え方や技術は、機械学習システムの本番運用時のみならず、「少数のラベル付けされたデータしか利用できない状況」において対策と...
第2回：画像でないデータを画像として処理する
AI技術チームの石川です。今回は、我々が発表した論文で使ったアイディアの一つである、「画像でないデータを画像として扱う」ことで画像分析用の手法を活用するという考え方について紹介したいと思います。画像認識や画像処理のために開発された手法やツールを活用することで、画像でないデータの分析を簡単に、高精度に行うことができる場合があります。ビジネスにおいては、以下のような場面で活用できる可能性があります。製造業、商業、公共交通機関等での音声による異常検知時系列の金融データ分析画像データとCNN画像認識はAI・機械学習の代表的なタスクのひとつであり、幅広く研究されています。ディープラーニングが注目さ...
第1回：豆寄席「衛星データ利用の最前線！」のレポート
2021年6月1日に社内で若手メンバーを中心にしたAI技術チームが発足しました。このチームは、豆蔵がこれまで培ってきた人工知能（機械学習）分野における先端技術を活用した質の高いデータ分析・基盤構築サービスに関する知見を、広く社会へ実装できるように情報提供することを目的として設立され、先端技術活用のデモンストレーションとなるようなシステムもしくはソフトウェアの構築も行っていく予定です。今後、AIに関連したテーマで、技術情報を定期的（月1回程度）に発信していく予定で、今回はその第1回目になります。今回は一般財団法人リモート・センシング技術センター(RESTEC)の向井田明様と亀井雅敏様をお招...
「現在携わっているプロジェクト」若手社員３名によるクロストーク
Kazunari私が所属している「デジタル戦略支援事業部 第1グループ」は、主に機械学習やデータサイエンスの技術を活用したプロジェクトを、クライアントとともに推進するグループです。私自身は、入社して1年半になりますが、ある金融機関のプロジェクトを推進しています。テーマは、預金の「使用予測モデル」の開発です。その金融機関の利用者が、どれくらいのお金を引き出すのか、もしくは預けるのか、その量を予測することで、社内の保有金額を最適化できます。今は、マイナス金利が設定されているので、社内で保有している現金が多ければ多いほど、利子を取られてしまう。逆に、少なすぎると、巨額な融資に対応することが難し...
「将来の目標」若手社員３名によるクロストーク
Kazunari技術面では、AIをもっと勉強したいですね。まずは、ディープラーニングのアルゴリズムを自分で組めるようになることが目標です。あらゆる最新技術に精通した上で、自分でプロジェクトを提案して、自分で形にしていきたいですね。プロジェクトマネージャーになるだけではなく、プレイヤーとして技術に磨きを掛けていく。上流〜下流まで全てを担えるコンサルタントになりたいです。Shunsuke全ての業務用PCに、『MZbot™️』がインストールされている世界をつくりたいですね。そのためには、もっともっとユーザーの声を聞かなくてはなりません。今は、ユーザーとの接点が少ないので、技術スキルを磨くことで...
【UMLでプリキュア】変身のモデル見直し
前回からの反省前回の記事【UMLでプリキュア】分析モデル の続きを書こうとしたのですが、なんと、ドメインの分析が足りなかったようです。モデルを見直します。変身のセリフを調べていたら、そもそも、変身の概念って、プリキュア個々人ではなく、複数人での変身がそもそも基本なんですね。確かに、、、！！！参考サイト：歴代プリキュア、変身シーンのセリフまとめ！最新作『HUGっと！プリキュア』までの決め台詞変身をモデルで理解する今回は、変身のドメインの再理解からです。変身はそもそもチームでするもの前回モデル化したときは、プリキュア個々人が変身するだけと思っていたけれど、上述の参考サイトを見て調べたら、変身...
【備忘録】WPFのDataGridのCanUserDeleteRowsとCanUserAddRowsの初期値を疑問に思った件
この記事は、簡単な情報共有です。WPFのDataGridで、行の削除を禁止していたつもりが、キーボードでDeleteキーを押したら削除できてしまった時の備忘録。開発環境Visual Studio Community 2017WPFアプリ(.NET Framework) のプロジェクトWindows10 Home 64bitはじめの状況DataGridのプロパティでは、[CanUserAddRows]と[CanUserDeleteRows]のチェックボックスは入っていません。xamlをみると、CanUserAddRowsとCanUserDeleteRowsを指定していません。当然、デフォル...
プロセスって大事です - 工程は課題を解決する単位 -
若手エンジニアKさんの作業報告先日、若手のエンジニアの作業報告を聞いていると、ざっくりですが、次のような話がありました。上司の指導に基づいてた作業手順で行った作業を進めづらい点があった進めづらい点は考えるのをやめて、後工程での対応が妥当と考えたその工程では、できるところまで進めて完了とした「あぁ、これだと、この後、手戻りで混乱してゆく可能性があるな」と感じました。作業上の障害があり、別のタイミングで解決する方が論理的に正しいと判断することは、良いことだと思います。進め方の変更が必ず駄目な訳ではありません。でも、駄目だと言えるケースもあります。なぜ、こんな指摘をするのか、掘り下げていってみ...
「仕事のやりがい」若手社員３名によるクロストーク
Kazunari博士課程時代からデータを扱うのが好きでしたので、金融機関の大規模データに直接触れられるのは楽しいですね。扱っているデータが、学生時代と同じ「時系列データ」ということもあり、すんなり業務に入っていけました。時系列データとは、時間の推移とともに連続的に取得されるデータのこと。火星の大気の状況も、金融機関のデータも、時間とともに変化するので、根本的な構造は同じなのです。「いつ雨が降ったか」「その影響で何が起こったのか」「曜日によって異なる傾向は何か」といったものが該当します。これらのデータを可視化して傾向を見出し、その結果を元にクライアントとフラットに議論を行うのは、やりがいの...
モデリング・DDD＃１４ 「モデルの意味的な誤り(Ⅱ)」
はじめに今回も前回の記事に引き続いて、「表記法としては間違っていないけれども、表現している内容(モデルの意味)に{おかしな|あやしい}ところがある」というケースをいくつか見ていきたいと思います。ここではモデルの意味的な部分/解釈に関わってくることになるので、「明らかに間違っている」とは言えない(見方によっては十分に正しい)ケースも出てきます。そのため、この記事の内容が「どんなときも絶対的に正しい」などとは思わず、あくまでも参考程度に読んでみてください。今回の記事では、以下のようなヘルスメーター(体重・体脂肪率計)の概念モデルを考えてみます。「株式会社 豆蔵ヘルスケア」では、新型ヘルスメー...
モデリング・DDD＃１３ 「モデルの意味的な誤り(Ⅰ)」
はじめに本連載のここまでの記事では、おもにUMLの表記法上の{誤解|誤り}について触れてきました。今回の記事では少し趣向を変えて、「表記法としては間違っていないけれども、表現している内容(モデルの意味)に{おかしな|あやしい}ところがある」というケースをいくつか見ていきたいと思います。今回の記事ではモデルの意味的な部分/解釈に関わってくることになるので、「明らかに間違っている」とは言えない(見方によっては十分に正しい)ケースも出てきます。そのため、この記事の内容が「どんなときも絶対的に正しい」などとは思わず、あくまでも参考程度に読んでみてください。その1:エンティティとアクターの混同図書...
モデリング・DDD＃１２ 「初心者にありがちな間違い」
はじめに今回のテーマは「初級者にありがちな間違い」ということで、ここまでとは少し趣向を変えて、オブジェクト指向とUMLを習得しつつある人がしばらくの期間描きがちになる間違った例をいくつか紹介していきたいと思います。その1:汎化関係に多重度まずは、汎化(継承)の概念をいまひとつ理解しきれていない人が描くクラス図にたまに出てくる間違った例です(図1)。図1：汎化関係に多重度が付けられている間違った例この図はある図書館の貸出/返却処理や蔵書管理を行うシステムの分析モデルの一部と考えてください。UMLのクラス図を見慣れている人は、これを見てすぐに表記法上の間違いを指摘することができるでしょう。そ...
