新卒目線で感じたAIレビュー機能開発の学びと課題

Transcript

1. 新卒目線で感じた AIレビュー機能開発の学びと課題 くらっち 2025.11.15 1
2. 2 01 02 03 04 kintoneとは 新卒エンジニアとして学んだこと まとめ 今後の目標 P03 P10 P38 P40 目 次
3. kintoneとは 3
4. サイボウズが世界中にチームワークを広めるため開発している 「業務改善プラットフォーム」 のクラウドサービスです。 kintoneとは 4 kintoneとは
5. 業務データを柔軟に蓄積し、社内で共有・見える化 運用しながらの変更も容易 ドラッグ&ドロップで簡単に作成できるWebデータベース（＝”アプリ”） 5 kintoneとは
6. 顧客の業務に合わせて拡張可能なノーコード/ローコード開発プラットフォーム 6 kintoneとは 外部サービスとの連携などを可能にするAPIを開発・提供
7. 私が所属しているチームが担当しているアプリ設定機能について 7 kintoneとは
8. 世の中的に市民開発という考え方が広まっている。 kintoneとしても市民開発を推進していきたい。 kintoneを導入した会社でIT部門の管理者（kintoneシステム管理者）の立場から • IT部門の人以外にもアプリを作成、管理、運用してもらいたい • 社内ルールに反しているアプリや社内のニーズにあっていないアプリは避けたいので、全社で定 めた運用ルールには従ってほしい という要望があった 今回のAI機能を開発した背景 8 kintoneとは
9. 機能名：「アプリ設定レビューAI」 AIによるアプリ設定レビューを受けられる機能。 kintoneシステム管理者がアプリ設定に関するガイドラインを登録すると、 AIがその内容を踏まえてレビューを実施。 AI機能の概要 9 kintoneとは
10. アプリ設定レビューAIには、次のような特徴がある • アプリ設定に関するルールや観点だけでなく、AIによるレビュー結果のトーンや 伝えかたの形式も設定できるため、kintoneシステム管理者は、レビュー結果の表示を調整可能 アプリ設定レビューAIの特徴 10 kintoneとは
11. 新卒エンジニアとして学んだこと 11
12. 1. 認識のズレを防ぐ具体化 2. 設計で意識した責務分離と拡張性 3. 機能を使うユーザーのことを想像する 4. 意思決定とコミュニケーション 新卒エンジニアとして学んだこと 12 新卒エンジニアとして学んだこと
13. • 「わからない」を「わかる」に変えるプロセス • 具体化の問いかけ • 曖昧さを残さないコミュニケーション 学び①：認識のズレを防ぐ具体化 13 学び①：認識のズレを防ぐ具体化
14. • コードの理解やドメイン知識が少ない • チームにジョインして2ヶ月 • プロダクトコードの理解が浅い • 何がわからないのかを言語化する苦労 • 技術レベルが高かったり、ドメイン知識が必要な議論に着いていけない • 分からないから参加出来ないが、何が分からないかも上手く言語化ができない 課題：実装開始時はわからないことだらけ 14 学び①：認識のズレを防ぐ具体化
15. • PMとの間で起きた認識のズレ • なぜズレが起きたのか • 前提条件の共有不足 • AIレビューの出力結果の理想状態 課題：AI出力の理想状態についての認識ズレ 15 学び①：認識のズレを防ぐ具体化
16. • サーバーサイドの実装 • 〇〇package配下に△△Serviceの実装 • Publicメソッドはget()とset()を定義 • □□Controllerで△△Service.get()を呼び出す • クライアントサイドの実装 • 「アプリ設定をレビュー」ボタンを〇〇.jsに実装 • レビュー依頼のrequestメソッドを実装 • ボタンのUIを実装 壁打ちの効果： • 実装前に方向性を確認できた • 自分の理解の曖昧な部分が明確になった 解決策：実装方針をチームメンバーに壁打ちしてもらう 16 学び①：認識のズレを防ぐ具体化
17. • ヘルプサイトについての認識合わせ • アプリ設定のAI出力結果の理想形の相談 • AIレビューダイアログのデザインを共有 解決策：機能に関わるメンバーで定期的な確認 17 学び①：認識のズレを防ぐ具体化
18. • わからないことを言語化する力 • 認識のズレが起きる原因の理解 • 具体化することで得られる効果 何を学んだのか 18 学び①：認識のズレを防ぐ具体化
19. • 責務分離の考え方 • 可読性・メンテナンス性を考慮した設計 学び② ：設計で意識した責務分離と拡張性 19 学び②：設計で意識した責務分離と拡張性
20. 各設定のMarkdown生成をシンプルにするため、Markdown構築用のBuilderクラスを用意 前提：AIに渡すアプリ設定データを構築するためにMarkdownBuilderを実装 20 • 見出し作成 (header): 指定されたレベルの見出しを追加 • HeaderLevelでプレフィックス(#の数)を制御 • テキスト追加 (text): 通常のテキストを追加 • 箇条書き (uli): インデント付きの箇条書き項目を追加 • IndentLevelでインデント量を制御 • 改行 (newline): 明示的に改行を挿入 • ビルド (build): Markdownテキストを文字列として返す 学び②：設計で意識した責務分離と拡張性
21. • 変更前：AIに渡すアプリ設定データ（Markdown形式）を一つの関数の中で生成 • 問題点：設定情報が増えるにつれて関数が肥大化し、可読性やメンテナンス性が低い 課題：設定情報が増加するにつれて関数が肥大化しメンテナンス性が低くなる 21 学び②：設計で意識した責務分離と拡張性 通知の 設定情報からAI向けの Markdown情報を構築 カテゴリの 設定情報からAI向けの Markdown情報を構築
22. • 変更前：AIに渡すアプリ設定データ（Markdown形式）を一つの関数の中で生成 • 問題点：設定情報が増えるにつれて関数が肥大化し、可読性やメンテナンス性が低い 課題：設定情報が増加するにつれて関数が肥大化しメンテナンス性が低くなる 22 学び②：設計で意識した責務分離と拡張性
23. • 変更後：Markdownの構造を作る処理と、Markdownのデータに必要な設定の取得や加工する 処理を、責務に応じて分離 • 全体の構造を構築するロジックと設定値毎の実装詳細を分離 • 設定情報からAI向けのMarkdown情報を構築する専用のクラスを作成 解決策：AIに送るデータ構造とAIに送るデータ作成を行う処理を分離 23 学び②：設計で意識した責務分離と拡張性
24. • 全体のMarkdown構造をつくる（CreateQueryService） • 設定情報からAI向けのMarkdown情報を構築する（XXXCreator） • Markdown形式を構築する（MarkdownBuilder） AIに送る用のMarkdownを作成する際に必要な責務 24 学び②：設計で意識した責務分離と拡張性
25. 改善前のコード 25 学び②：設計で意識した責務分離と拡張性
26. 全体と各設定毎のMarkdownの構造を作成する責務を分離 26 学び②：設計で意識した責務分離と拡張性 通知の 設定情報からAI向けの Markdown情報を構築 カテゴリの 設定情報からAI向けの Markdown情報を構築 設定情報からAI向けの Markdown構築を privateメソッドに分離 設定情報からAI向けの Markdown情報を構築す るXXCreatorクラス
27. 設定情報からAI向けのMarkdown情報を構築するクラスを実装 27 学び②：設計で意識した責務分離と拡張性 設定情報全体の Markdownを構築 設定値をもとに Markdownを構築
28. 設定情報からAI向けのMarkdown情報を構築する責務を分離する前 28 学び②：設計で意識した責務分離と拡張性 設定情報からAI向けの Markdown情報を構築す るXXCreatorクラス
29. 設定情報からAI向けのMarkdown情報を構築する責務を分離 29 学び②：設計で意識した責務分離と拡張性
30. 改善前のコード 30 学び②：設計で意識した責務分離と拡張性
31. 改善後のコード 31 学び②：設計で意識した責務分離と拡張性
32. • 全体のMarkdown構造をつくる（CreateQueryService） • 設定情報からAI向けのMarkdown情報を構築する（XXXCreator） • Markdown形式を構築する（MarkdownBuilder） AIに送る用のMarkdownを作成する際に必要な責務毎に分離することが出来た 32 学び②：設計で意識した責務分離と拡張性
33. 責務分離の考え方とその効果 • 関心事に基づいて整理する • 単にコードを分割するのではなく、「何をする処理なのか」という関心毎で分ける • 抽象度のレベルを揃える • 全体構造では「何をしているか」を示し、詳細は別の場所に隠蔽する • 変更の影響範囲を限定する • 1つの責務が明確になると、変更時に外の部分への影響を最小限に抑えられる 何を学んだのか 33 学び②：設計で意識した責務分離と拡張性
34. 可読性・拡張性を考慮した設計の重要性 • コードは書いた時間のほうが長い • 読まれる、修正される、拡張される時間を考慮する • 可読性と拡張性は相互に関係する • 可読性が高いと「どこを変えればよいか」が分かりやすく、拡張しやすい • 将来の変更を予測しすぎない • 将来の拡張に備えた柔軟性を持たせつつ、過度な抽象化は避ける 何を学んだのか 34 学び②：設計で意識した責務分離と拡張性
35. • ユーザーのことを想像する • ユーザーが普段どのような状態で働いているのかを考える 学び③：機能を使うユーザーのことを想像する 35 学び③：機能を使うユーザーのことを想像する
36. • IT部門ではないアプリ開発者への配慮不足 • PMからの「指摘が優しくない」という感想 課題：AIレビュー内容の違和感 36 学び③：機能を使うユーザーのことを想像する
37. • PMと認識合わせの時間を設け、「機能のイメージ」「利用するユーザー」を改めて共有 • 「AIレビューのトーンや形式」という項目を置き、レビュー出力の表現を設定可能にした 解決策：レビューの理想状態の再定義 37 学び③：機能を使うユーザーのことを想像する
38. ユーザーの満足する仕様を考えるためにユーザーのことをたくさん想像する • ITに深い知見があるか • IT部門以外のアプリ作成・管理・運用を考えている • レビュー時にどのように感じるか • レビュー結果を受け取って改善する意識を持つことが出来るか 何を学んだのか 38 学び③：機能を使うユーザーのことを想像する ITに深い知見がなくても 理解出来る内容 トーンや形式の項目追加
39. • やらないことを決める勇気 • 優先順位付けとトレードオフの判断 学び④：チーム開発での意思決定とコミュニケーション 39 学び④：意思決定とコミュニケーション
40. • CybozuDaysでリリースすることになった背景 • 9月末までは、 CybozuDaysでデモをする方針であり、当日のリリースの話は挙がっていなかった • 10月頭にCybozuDays当日リリースしたいという要望が上がった • CybozuDaysリリースに向けての準備 • リリースに必要な機能を用意 • 当日リリースするための仕組みの対応 課題：CybozuDaysのリリースに向けた準備 40 学び④：意思決定とコミュニケーション
41. • タスクの優先順位調整 • 何を基準に判断したか • 限られた時間での判断 • チーム全体として納得した状態で取り組むためのコミュニケーション • 新卒でも意見を気軽に伝えられる機会がある • 何を基準に取捨選択したのかは常にチーム全体に共有 解決策：タスクの優先順位を調整し、取り組むことを絞る 41 学び④：意思決定とコミュニケーション
42. チームで認識を合わせながら機能の取捨選択をして開発を進めること • 意思決定プロセス • 新卒でも意見を言える環境 • 技術的な制約を踏まえた提案の仕方 • やらないことを決める判断 • 理想の実現と工数のトレードオフ • 限られた時間での現実的な判断 何を学んだのか 42 学び④：意思決定とコミュニケーション
43. まとめ 43
44. 1. 認識のズレを防ぐ具体化 2. 設計で意識した責務分離と拡張性 3. 機能を使うユーザーのことを想像する 4. 意思決定とコミュニケーション 新卒エンジニアとして学んだこと（再掲） 44 まとめ
45. 今後の目標 45
46. • ユーザー視点を持つ • ユーザーが普段どのような状態で働いているのかを深く想像する • 認識を統一できる • 曖昧さを残さず、具体例を使って早期に認識のズレを解消する • コミュニケーションを円滑にできる • チーム内外で情報を透明にし、信頼関係を築きながらプロジェクトを進める ユーザーが満足するプロダクトを作れるエンジニアを目指す 46 今後の目標
47. ご清聴ありがとうございました 47