Kamada.S
その他

社内勉強会 26/2 〜セロトニン編〜

この記事は約9分で読めます。

さて、3月に入りましたね。

執筆時点で既に10日が経過していてとても怖いです。

すっかり雪も溶け…溶け始めています。

だってもうすぐ新卒が入ってくるんでしょ？

私だってついこの間まで新卒だったんですよ。

さて皆さん、日光、採ってますか？

気が滅入っちゃうのでね、定期的に接種しましょう。

私は日中日光を浴びることができず、若干気が滅入っています。

滅！

今回の発表内容

要件定義フェーズでのAI活用と失敗事例

発表者：A.Tさん

設計にもAIを使うきっかけになればと思い、参加しました。

あらかじめ結論

要件定義でAIを活用してみて…

  • 便利で使えるが、使いどころや使い方を見極めたほうがいい
  • AIはあくまでツールでサポート役
  • とはいえ要件定義でもAIを活用することはおすすめ

ちなみに、私自身はAIアンチではないです。

AIを活用した案件の概要と活用理由

  • アプリのリニューアル
  • 前ベンダーから弊社へ開発が引き継がれた
  • フロントエンドを起点に要件定義済み

私の役割はバックエンドのPGでした。
バックエンドは別途要件定義をやり直す必要がありました。
やることは多いが時間は足りないということで案件全体で積極的にAIを活用することになり、要件定義でも活用していきました。

どう使ったのか

要件定義ではGeminiを利用しました。
主にアプリのロジックや外部システム連携などの整理を行わせ、それを元に業務ロジックの作成を行わせました。

人間の役割としては、統一されたドキュメントを作成できるようプロンプトを作成することでした。

このようにして出力された内容を元にして、不明点や未確定事項のすり合わせを行いました。

失敗事例

前述の通りに活用してどのように失敗したかを紹介します。

主に要件漏れが発生してしまいました。
要件定義を行うためのベース資料を出力させる時点で情報が抜け落ちてしまったり、既存のフロントエンドの設計書と内容が乖離してしまったりしました。
私のチーム内でこのようなことが結構な頻度で発生していました。

要件漏れに繋がった原因としてはAIの出力を信じすぎたことが大きいです。
要件漏れの他に誤った情報が出力されてしまったこともありました。
そのときは気づくことができたため影響は出ませんでしたが、さらなる要件漏れや認識齟齬が発生する恐れがありました。

要件定義でのAIの使い方

AIは相談役のツールとして使うのがよいと感じました。
自分が作った資料をお客様に出す前に抜けている箇所や懸念点のチェックするために壁打ち相手に使うなどがよさそうです。
また、実際に行った使い方では、システムが大きいと膨大な情報の中から欲しい情報を見つけるための窓口として使うのが好感触でした。

これはGeminiの利点となるのですが、プロンプトさえうまく作れば膨大な情報の中から一定のクオリティの資料を作成させることができます。

最終的に使うものをAIに出力させるという使い方では失敗してしまいましたが、作業効率を上げるためのツールとしてはとても強力なので「あくまでサポート役」から逸れなければ利点だけをうまく享受できると思います。

最近のAIモデル(claudeとGemini)たちと業務

発表者：iwasaki_tさん

業務の中で感じたAIのモデルの使い分けについて話してみようと思います。

モデルの得意・不得意

個人的にはこのように感じました。

  • Gemini：画像解析や生成、アートが得意な印象
  • Claude：コード生成、文章読解などが得意な印象
  • ChatGPT：平均的な印象

最近Gemini 3.1がリリースされましたが、それでもコード生成はClaudeが強いと感じました。
ですが、Geminiは新たにSVGを使ったアニメーションなどが作れるようになったので、より特長が強化されたように感じました。
(Gemini 3.1 Proについてはiwasaki_tさんが記事にしているのでぜひ読んでみてください)

【Gemini】Gemini 3.1 Proが来た！
...
ramble.impl.co.jp
2026.02.26

業務で使うAIたち

では、業務でどのようにAIを使っているかを紹介します。

  • Claude：コーディングの補助がほとんどです。たまに雑談もしますが、それ以外の用途ではあまり使いません。
  • Gemini：
    最近抱えている案件の管理が難しくなってきたので工数管理をやらせてみています。画像解析が得意な点を活かして工数管理システムのスクリーンショットを読み込ませて稼働時間の管理に活用しました。
    モックアップやプロトタイプの作成にも使っています。Figmaで作成したUIをスマートフォンの画像にはめ込ませたり、簡単なUIを作らせたりしています。
    Geminiでも雑談をしています。個人的にはGeminiの方が気が合うなと思っています。

ツールで使うAIたち

プロダクトにAIを組み込むときにはどう使うとよいのか、個人的な意見を紹介します。

  • Gemini：画像の解析が得意なので、レシート解析、工数管理、モックアップ作成のような役割がよいでしょう。
  • Claude：文章などの文字情報の解析が得意なので、ソースコードを読ませてコンポーネントを抽出したりコードのチェックを行わせたりするのがよいでしょう。

応用情報午後試験〜僕はこのように学んだ・解いた〜組み込みシステム、経営戦略編

発表者：N.Aさん

前回に引き続き応用情報技術者試験の話をします。
試験に合格する方法はインターネット上にたくさん情報があるので、今回は問題を解く「コツ」みたいなところを話してみようと思います。

組み込みシステム問題を解くコツ

  1. 仕様書の読解を楽しむ
    組み込みシステム問題は基本的に高い読解力が必要です。
    仕様書の中から設計者の意図を探り読み進めることが重要ですが、機能同士の関連性や機能の背景事情などに目を向けることで読み解きやすくなります。
  2. 物理的な制約に敏感になる
    物理的な制約、特に数値は重要なヒントになります。
    メモリや電力などのリソース、応答速度のようなパフォーマンスなどに目を向けると、不自然な条件に気づくことができます。
  3. 状態の変化を視覚化する
    問題文のシチュエーションの中で今何が起きているのか整理することで、状況を正確に把握できます。
    何が起こったときにどのような状態に遷移するのか時系列や条件を明確にすると、納得感のある予想を立てることができます。

経営戦略問題を解くコツ

  1. コンサルタントになりきる
    問題文の事例に感情移入することで自分事として捉えることができ、問題を解きやすくなります。
    問題文を頭の中でストーリーに仕立ててることで、解決策を想像しやすくなります。
  2. ニュースを因果関係で考える
    問題には出題年の5年以内に起きたケースが題材になることが多いです。
    (昨年はワークマンについて出題されたと思います)
    日頃からニュースの背景やITと経営の論理的な結びつきを深掘りしておくと役に立ちます。
  3. 論理の一貫性を守る
    午前試験(A試験)の知識がベースになります。
    問題文から事実(根拠)を見つけ、絶対的な出発点として定めます。
    ここで自身の経験則をもとにしてしまうと点が取れません。
    回答を作るときは、根拠と結論を最短距離で結ぶブレない論理構成を意識することが重要です。

午後試験のまとめ

知識自体は午前試験の勉強で十分備わります。
午後試験を解く鍵は「知識を文脈に合わせて加工する」ことです。
逆に言ってしまえば、午前試験の勉強をせずに午後試験は突破できません。

みんなで読もうSQLアンチパターン〜ナイーブツリー(素朴な木)編〜

発表者：H.Mさん

会社の補助で買った書籍の内容の紹介の続編です。

ナイーブツリー(素朴な木)とは

親のIDを持つ隣接リスト(Adjacency List)を指します。
隣接リストとは、コメントとリプライのような親子関係を表す設計手法です。
隣接リスト自体はよく見る設計手法です。
では、なぜアンチパターンとなるのか詳しく見ていきましょう。

なぜアンチパターンなのか

子に親のIDを持たせてしまうと、親子関係の階層が深くなるとSQL操作がつらくなります。
例えば、コメントに対して返信を追加できる仕様の場合、コメントに追加された返信にさらに返信を追加…できると以下のようなSQLが必要になります。

記事
├─────────┬──────┐
コメント コメント コメント
│         │
コメント コメント
│         │
コメント コメント
│
コメント
SELECT ... FROM articles a
LEFT JOIN comments c1 ON c1.article_id=a.id AND c1.parent_id IS NULL
LEFT JOIN comments c2 ON c2.parent_id=c1.id
LEFT JOIN comments c3 ON c3.parent_id=c2.id
LEFT JOIN comments c4 ON c4.parent_id=c3.id
WHERE a.id=1;

親子関係の層の分だけJOINする必要があります。
また、後々この層が増えてしまうとJOINも増やさなければなりません。

そもそもですが、隣接リスト自体はよく使われる手法でありアンチパターンではありません。
アンチパターンとなりうるのは、要件として親子関係の層が深い(深くなりうる、可変)場合です。

解決策

以下のいずれかを使うとよいです。

  1. 再帰クエリ(Recursive Common Table Expression)
    SQLの中でループ処理を書く方法です。
    forループをイメージすると分かりやすいです。
    便利ですが、DBによっては文法が異なったり使えなかったりするので確認が必要です。
  2. 経路列挙(Path Enumeration)
    親から自身までのパスを文字列で保持する方法です。
    例えばA→B→C→D→Eと繋がっているコメントの場合、DはA/B/C/Dというような形式で親から自分までの経路を記録します。
    ただし、前回紹介した「ジェイウォーク」に該当するので慎重に検討する必要があります。
  3. 入れ子集合(Nested Set)
    左右の数値で階層関係を表現する方法です。
    すべてのノードはLeftとRightの値を持ちます。
    あるノードの子は、そのノード自身が持つLeftとRightの値の範囲に収まります。
    例えばA→Bの親子関係において、AはLeft:1, Right:4を持ち、BはLeft:2, Right:3を持ちます。
    子をすべて取得する場合はLeftとRightの範囲内の値を持つノードを取得すればよく、Leftで簡単にソートできます。
    一方で、ノードの追加や削除をするときは関わるノードの値をすべて変更する必要があります。
  4. 閉包テーブル(Closure Table)
    すべての子孫関係を別テーブルに保存する方法です。
    先祖となるノードと子孫となるノードを2列で持ちます。
    例えばA→B→Cの親子関係において、A,A A,B A,C B,B B,C C,C というレコードが作られます。
    入れ子集合よりは理解しやすく処理がしやすいですが、必然的にレコード数が膨大になってしまうテーブルが1つ増えてしまうのでパフォーマンス要件の関係で採用できない場合があります。

まとめ

階層を表現しなければいけないデータを隣接リストで扱うとSQL操作がしづらくなってしまうためアンチパターンです。
ただし、隣接リスト自体はアンチパターンではないため注意してください。

階層を表現するデータを扱うときは、今回紹介した4つの手法の採用を検討してください。
それぞれにメリットとデメリットがあるので、要件に合わせて選んでください。

おわりに

最近は少し生活リズムが整ってきました。

今回は下旬に差し掛かる直前でリリースとなります。

このペースを維持していきたいものです。