ネスケラボ

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です8月8日にChatGPT-5がリリースされ、では早速。。とCursor を開いてみたところ、Cursor CLIが公開されたという通知が来ていました。少し前にClaude Codeも触ったこともあり、比較するならば早い方がよいだろうということで早速試してみました。ちなみにCursor CLIはこの記事を書いている段階ではまだベータ版となります。更に後述しますがWindowsはWSLでの動作であり、また、筆者はCursorのProプランを購入しています。インストール・実行準備まずはcurlコマンドでインストール。特に問題無く完了しました。で、上の画面で指示されているようにパスを通して。。とあるのですが、ここでふと気づいたのが前述の実行環境について。以前のClaude Codeのように現時点（25/08/13）のCursor CLIはWindows上では動かないため、WSLを起動します。以下のようにbashでパスを通して、cursor-agentコマンドでバージョンを確認。無事実行できました。そこでcursor-agentで改めて実行しますと以下のようなタイトルが表示されます（画像だとよくわからないと思いますが、右側はCursorのアイコン画像がぐるぐるアニメーションしています）サインインを促されるのですが、WSL環境のためかうまくいかず、画面に「このURLアクセスしてログインしてね」的な文章が表示されますのでそのURLを叩いてブラウザを起動し、そこからサインインします。以下がCursor CLIのログイン画面。無事ログイン完了しました。そうしてコマンドプロンプトに戻るとClaude Codeと同じようにプロンプトの入力待ちとなります。Claude Codeであれば「/init」コマンドで設定ファイルの作成やプロジェクト解析をしてくれたのですが、パッと見そういったコマンドは無さそうでしたので「現在のプロジェクトを解析してください」とお願いしてみます。すると以下のように色々と詳しく解析してくれました。以下の画面はあくまで一部でして、実際は３ページ分ぐらい情報を出力してくれています。Cursor CLIによる改修では、Claude Codeの時と同じプロンプトで改修を依頼します。「現在のホームページをもっとモダンでレスポンシブなデザインに更新して、Bootstrap5を使って、カードレイアウトやグラデーション背景を追加してください」するとしばらく考えた後に処理が進み、ソースコードの改修差分が以下のように表示されます。コードの内容が省略されている場合は画面に表示されている通り「Ctrl+r」で全て表示されます。このあたりの差分の表示の仕方はClaude Codeと同じです。そして以下のように改修が終わった旨が表示されます。Claude CodeではToDoを最初に示し、都度ユーザーに対してこれで進めてよいかどうかを確認してきたのですが、今回は一気に実装終了まで進めてきました。これがCursor CLIの特性なのかどうかは一概に判断できないのですが、もしこの記事を見てCursor CLIを試そうと思った方はご注意ください。さらにもう１つ「ん？」と思ったところがありまして、Claude Codeであれば確認することなく一気にビルドまで進んでくれました。そこでビルドをお願いしたところ、それでもユーザー側で実施してほしいとのことで手順を示してくれます。もしかするとWSL環境ということも関係しているのかもしれません（Cursor CLI自身がWSLでの手順も提示してくれてますが。。）。とりあえずVisual Studioを立ち上げ、ビルド・実行したところ、以下のようにTOPページが変更されていることを確認できました。仕様書作成さて、Claude Codeの時と同様、改修内容を仕様書にまとめてもらいます。すると以下のようにコマンドプロンプト上に仕様書としての内容が表示されました。Markdownファイルに出力されることを想定していたのですが、言葉が足りなかったようなので改めてMarkdownファイルへの出力依頼を。。そうすると無事プロジェクト直下にMarkdownファイルを出力してくれました。所感１つの環境、ツールにおいてビルド、実行ができる強みというのはやはり非常に大きく、「現時点で」Windows＋C#で開発を行いたい方はまずはClaude Codeで開発した方が良いかもしれません。また、Claude Codeを試した際はファイルの修正に関して１つ１つインタラクティブにやり取りしてくれましたので、「現時点では」Claude Codeが良いのかなというのが個人的な感想になります。Claude Codeは事前にちゃんとToDoを明確にしてくれるところも個人的には高評価でした。ただ、X等でのコメントを眺めているとClaude Codeよりも良さげ、と書かれた内容も多く、言語や環境の違いで評価は大きく変わってきますし、何よりもベータ版ですのでまだまだこれから。。というところかと思います。日進月歩のAI界隈ですので、このCursor CLIも正式版がリリースされ、そしてWindowsに正式対応されたタイミングで改めて触ってみたらCursor  CLIの方が良かったとなる可能性は非常に高いです（上で「現時点で」と強調したのはその意味です）別の記事でも書いてますが、AIツールはプロンプトはもちろん、言語やその規模に応じて同じモデルであっても色々と反応が異なります。皆さんも是非色々試してみてください。ちなみに先ほど調べたところ、Claude Codeが正式リリースされたのは5月中旬頃、そしてWindows版に正式対応したのがその2カ月後の7月半ばですので、Cursor CLIのWindows版もきっとそのくらいのスピードで対応してくれるかもしれません（Cursor CLIは現時点ではベータ版ですのでそこの違いはありますが）。引き続きAIに関する情報をキャッチアップしていきたいと思います。当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。 nextscape.net（以下当社お問合せフォーム）Microsoft Forms

Windows環境でCursor CLIを試してみる

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です前回の私の記事から約1カ月半経ちました。AI界隈も１カ月半も経つとまた更に色々と動きがありまして、私個人としてはコードを書く時はCursor＋Claude、コードに関係無いこともClaude for Desktopで。。というですっかりClaudeばかり使う毎日でした。社内では私に限らずあらゆる部署でAIによる開発が行われており、Claude以外にも様々なAIツールが利用されておりまして、共有会等も開かれております（以下の記事、第２弾もありますので是非）。blog.nextscape.netClaudeが普段使いとなっていた私もClaude Codeはまだ触っていなかったため、キャッチアップしなくてはという思いもありまして、やや今更感はあるものの、Claude Codeのインストールから始まり、色々と試した結果を書いてみたいと思います。今まではLinux、Macでしか動かせなかったということも食指が動かない理由だったのですが、早くも先月7月半ばにはWindowsで動かせるようになったということも今回のきっかけの１つではあります。ちなみに私はClaudeのProプランを購入しておりますのでその前提で書かせていただきます。Claude CodeインストールまずはnpmでClaude Codeをインストールします。インストールは上記のスクショ通りあっさり終わりました。さて、次はClaude Codeの起動なのですが、その前に今回Claude Codeの対象とするのはVisual Studio2022で作成した.NETのWebサイトのプロジェクトになります。とりあえず何も手を入れず、サンプルとして作られた直後の状態から始めます。コマンドプロンプトでプロジェクトが存在するディレクトリに移動し、Claude Codeを起動します。すると以下の通り画面表示についての選択画面になります。今回は先頭のDark modeで。すると以下のようにWelcome画面が表示されて、１と２の選択肢、いずれかを選ぶように促されます。この選択肢ですが、１番目は「Claude account with subscription」、つまり、一般ユーザー向けのClaude.aiのアカウントでProプランなどの月額サブスクリプションを購入している方はこちらを選ぶ形になります。もう１つのAnthropic Console accountはAPI開発者向けのアカウントで、プログラムからClaudeにアクセスするためのAPI利用する人向けです。もう少し言い換えると自分でアプリケーションを開発してClaudeのAPIを組み込む開発者が使うものになりますので、今回は１を選びます。すると、以下のようにブラウザが開きますのでログインを行います。ログインが成功すると以下の表示が。。 そして、また選択肢が出てきます。これはClaude Codeのセキュリティに関する注意事項画面となりまして「Claudeは間違いを犯す可能性がある」「信頼できるコードでのみ使用すること」等の注意事項が表示されてます。Claude Codeは強力なツールですが、AIが生成するコードをそのまま実行するのは潜在的なリスクがあるため、このような警告が表示されています。Enterキーを押すと次に進めますが、まずはこれらの注意点を理解してからご利用ください。特に、Claudeが提案するコードは必ず内容を確認してから実行することが重要です。更にClaude Codeが特定のフォルダへのアクセス許可を求める確認画面が表示され、以下のいずれかを選びます。１．Yes, proceed - 許可して続行２．No, exit - 許可せずに終了今回のプロジェクトの中身のファイルが信頼できるものであれば「1」を選択して続行します。もし不明なファイルが含まれている可能性があるなら、先にフォルダの内容を確認してから判断することをお勧めします。その結果、以下のようにClaude Codeが正常に起動し、メイン画面（というのもちょっとおかしいですかね。メインの文章？）が表示されます。Claude Codeによるコード改修では、いよいよコード改修を試みてみましょう。現時点でのコマンドプロンプトの表示内容を見ると、現在のディレクトリ「C:\git\WebApplication1」が表示され、利用開始のヒントが表示されてます。日本語に訳すと以下の通り。１．/initを実行してCLAUDE.mdファイルを作成（Claude向けの説明書）２．ファイル分析、編集、bash/gitコマンドなどでClaudeを活用３．他のエンジニアと同じように具体的な指示を出すと良い結果が得られる下部のプロンプト（Try "refactor <filepath>"）で、Claudeに自然言語でプログラミングタスクを依頼できます。例えば「このファイルをリファクタリングして」「新しい機能を追加して」などと指示できるわけです。ここまで来ると他のAIツールと同じですね。まずは指示通りrun /initで初期化を行いましょう。すると、 ClaudeがWebApplication1フォルダの中身を調べ、ASP.NET Coreのウェブアプリケーションだと認識し、複数の設定ファイル（.csproj、appsettings.jsonなど）を発見します。次に初期化の提案、つまり、Claudeがdotnet restoreコマンドの実行を提案してくれます。.NETを使われている方には言わずもがなですが、このコマンドはNuGetパッケージを復元するコマンドであり、プロジェクトのビルドに必要な依存関係をダウンロードしてくれます。このサンプルプロジェクトを作った時点でビルドとデバッグ起動も行っていますので、このコマンドも正直不要ではあるのですが、今回はアドバイスに従ってみましょう。すると、dotnet restoreが実行し、更にビルド及び実行を促されますので、それにも従って進めていきます。サラッと書きましたが、これらの作業は本来Visual StudioやそのSDKで自分たちでやらなければならない作業でした。今回は全てClaude Codeがやってくれます。更に実行もしてくれて、https://localhost/xxxxにアクセスしてね。と言われたので、言われるがままにURLを叩くと以下の画面が表示されます。Claude for DesktopやClaudeのWeb版しか使っていない方ですとプロジェクト全体に対してコード実装・改修を行う経験が無いかもしれませんのでこれだけでも便利さを痛感するかもしれませんね。では、いよいよコードの改修を行っていきましょう。以下のように「現在のホームページをもっとモダンでレスポンシブなデザインに更新して、Bootstrap5を使って、カードレイアウトやグラデーション背景を追加してください」とざっくり指示を出してみます。すると以下のように自らTodoを挙げてくれて、その通りに作業を進めていってくれます。ソースコードを変更した場合は以下のように差分を表示し、更新して良いかどうか聞いてくれます。以下も同様で、改修に対して確認を取ってくれます。結果、以下のように完了した旨を連絡してくれました。エラーの文字が見受けられたので念のため聞いてみます。dotnet runコマンドのタイムアウトで問題無いとのこと。そこで表示されたURLにアクセスすると先ほどの殺風景な画面から以下のような画面へと変わっていることが確認できます。仕様書作成Claude Codeでできることがコード改修だけではないことを確認するため、ここまでの改修内容について仕様書の作成を依頼します。すると以下のようにMarkdown形式で仕様書を作成します。「ホームページ改修仕様書.md」というファイルを作ってくれたようなのですが、どこに作成したかわからないので作成場所を確認します。すると以下のような回答が。。実際にエクスプローラーで確認しますと確かに存在しますね。以下が上記のファイルをVS Codeで開いた結果です。CLAUDE.mdファイル設定最初のやり取りは英語で回答していましたが、今後は全て日本語でやり取りしてもらいたいと思います。その場合はCLAUDE.mdファイルを作成することで設定できるのですが、それも自分で作るのではなくお願いしてしまいましょう。すると、以下のようなお約束事を設定してCLAUDE.mdファイルを作ってくれます。プロジェクト概要も書いてくれてますね。すべての説明とコメントは日本語で記述してくださいユーザーとのやり取りは日本語で行ってくださいコード内のコメントも日本語で書いてくださいClaude Code for VS CodeコマンドプロンプトではUI・UX的に物足りないという方にはVS CodeでClaude Codeを使えるようにすることもできます。Claudeを提供しているAnthropic社が以下のように公式の拡張機能を用意してくれてますのでそれをインストールします。marketplace.visualstudio.comもしくはVS CodeのTERMINALでインストールすることもできますが、いずれにしても無事インストールが終わると最初に紹介したようなClaude Codeのメイン画面が表示され、VS CodeでClaude Codeが使えるようになるわけです。ファイル共有ここまで見てきて、ある程度色々とAIツールを触った方であれば画像等のファイル共有はできるだろうかと思った方もいらっしゃるかもしれません。実際、Claude for DesktopやCursorで入力エリアに画像を貼り付けて共有し、その画像に関して質問するといったことをしている方もいらっしゃるかと思います。試してみた結果としてはこれも可能でした。例えばWindowsにおいてコマンドプロンプト上でClaude Codeを利用している場合、テキストファイルや画像ファイルを共有したい場合にはそのコマンドプロンプトにドラッグ＆ドロップしてみてください。先ほど紹介したClaude Code for VS Codeのサイトのスクリーンショットをpngファイルで保存し、コマンドプロンプトにドラッグ＆ドロップしますと以下のように[Image #1]と表示されます。そこで更に以下のように質問します。すると以下のように説明してくれます。合ってますね。テキストファイルもドラッグ＆ドロップというよりはパス指定になりますが同じように読み取ってくれます。Excelファイルも試してみたところ、こちらは駄目でした。Claude for DesktopであればExcelファイルも読み取ってくれますので扱えるファイルに違いや制限があるようです。最後に最初に書いた通り、今まではCursor＋Claudeでも間に合ってはいたのですが、当社の共有会でも話題に出ているようにAIツールは同じモデルを使っていてもそれぞれに強みであったり、得手不得手があり、色々と使ってみることも非常に大事ではありますので、Claude Codeももう少し試してみたいと思います。社内でも非常に評判が良いのでもしかするとこちらがメインになるかも。。当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

WindowsでClaude Codeを触ってみた

「AIがコードを書く時代」と言われる昨今、本当に“人間は手を動かさなくてもいい”ところまで来ているのか？第2回となるAI活用共有会では、そんな問いに真正面から挑んだ実践例が共有されました。照山さんは、ノーコードAI開発環境「Cursor」を活用し、Webアプリケーションをほぼ“コードを書かずに”構築。AIとの対話を通じて、ゼロからサービスが生まれていく過程は、まるでエンジニアがAIとペアプロをしているような感覚。だがその裏には、AIならではの落とし穴や“壊されるリスク”も潜んでいました。本記事では、Cursor体験と参加メンバーとのリアルな議論から、「AIと協働する開発」の現実を掘り下げていきます。イントロダクション：AIとの「協働開発」はどこまで進んだ？「AIがコードを書く時代」——そんな言葉を聞いたことがある人も多いはず。でも実際のところ、AIは“どこまで”開発の役に立つのか？そして“どうやって”活用するのか？第2回AI活用共有会では、照山さんが自身の体験をもとに、AI開発環境「Cursor」を使ったノーコード開発のリアルを共有してくれました。彼が掲げたのは「AIと協働して、コードを書かずにWebアプリを開発できるか？」というチャレンジ。その実例を通じて、AI開発の可能性と落とし穴が浮かび上がりました。開発テーマ：ビジネス向けトラッキングソリューションの構想発表の冒頭で紹介されたのは、AlterLockデバイスを活用した「ビジネス向けトラッキングソリューション」。もともとコンシューマー向け製品として展開していた技術をベースに、より汎用的なアセット管理・位置情報管理システムを目指したものです。アセット（管理したいモノ）にデバイスを紐付け、ジオフェンスやバッテリー通知なども含めて一括管理する仕組み。マルチテナント構成、ユーザー管理、組織管理といった機能まで含まれた本格的なWebアプリを、Cursorを使って短期間で実装しました。Cursorでの開発体験：1行もコードを書かずにアプリができる？「私はこの開発で、一行もコードを書いていません」VS CodeベースのCursor上で、チャット形式で指示を出しながらプロジェクトを一から構築。まずはユーザー管理機能を、次に二段階認証、そして資産情報の管理やマップ表示まで。驚くべきは、それらを“ペアプロ”のようにAIとやり取りする中で完成させていったという点です。画面のスタイル修正やタイトル変更など、ほんのわずかな微調整を人の手で行ったのみだったそうです。便利さの裏側にある注意点：勝手に壊すAIの一面とはいえ、良いことばかりではありませんでした。Cursorに大量のコード生成を任せた結果、「知らないうちに他の画面に影響が出ていた」「スタイルが破壊された」「DBテーブルが重複してできていた」といったトラブルが頻発。「全体の構造を把握しているわけではなく、コンテクストが限定的」と照山さん。特定のファイルや機能だけを操作させるように明示的に制御しないと、意図しない修正が生じるケースも多かったと語ります。Claudeとの比較活用：やさしい？丁寧？それとも壊し屋？この日、参加者からも活用事例が共有されました。開發さんはCursorとClaudeを併用し、Cursor上でClaude Codeの出力も活用していたとのこと。「Claudeは丁寧だけど、文脈を見ずに壊すことも多い」とのコメントがあり、結局のところ“人間の目でレビューする必要がある”という点は一致した見解に。便利であるがゆえに、少しの油断でシステム全体が破綻しかねない。これはAI開発ツール共通の課題といえるでしょう。セキュリティとパフォーマンスは人間が守るセキュリティの観点でも注意が必要でした。管理者専用機能の制御が効いていなかったり、SQLがループで数百回実行されるような非効率な実装があったりと、放置できない問題も。そのたびに指示を変えて、修正を重ねていく必要がありました。「AIは実装してくれるけど、セキュリティやパフォーマンスの意図までは汲み取らない」ことが明確になったといいます。Cursor＋Codex＋ChatGPT：AI三刀流開発術照山さんはCursor以外にも、CodexやChatGPTと併用することで、AIを「分担」して使う工夫をしていました。外出先で機能追加をしたいときにはCodexで指示しておき、帰宅後にマージして検証、といったワークフローも可能になったといいます。また、実装方式から調査して、どの技術を採用するか検討する場面では普段から使い慣れているChatGPTを使っていました。まさに“AI三刀流”。それぞれの強みを活かして使い分けることで、より柔軟で効率的な開発が実現できるのです。対話形式が鍵：「一緒に作る感覚」が生む開発体験の変化今回の取り組みで印象的だったのは、「AIと一緒に作っている感覚」のリアリティでした。「要件を全部書いて渡すのではなく、チャットで段階的に指示を出しながら一緒に組み立てる」という手法は、従来の受託開発やウォーターフォール型開発とは全く異なる体験です。参加者からも「対話しながら進めると自分も理解が深まる」といった声がありました。まとめ：AIを開発パートナーにするために大切なことCursorは、確かに“コードを書かずに開発ができる”夢のようなツールかもしれません。しかし、それを実現するには「限定的なコンテクストでの指示」「レビューと修正」「目的意識のあるドキュメント整理」など、人間の戦略的な介入が不可欠です。AIは開発者の“補助”ではなく、いまや“協働者”になりつつあります。この共有会が示したのは、AIと人間が信頼関係を築きながら共にものづくりをする、新しい開発のかたちでした。次回の共有会では、どんな“協働”が生まれるのか。ますます楽しみです。第1回の記事はこちら。blog.nextscape.net

【AI活用共有会#2】Cursorで挑むノーコード開発！AIと“ペアプロ”してみたら分かったこと

「AI使ってる？」を聞ける場所、つくりました2025年、AIは「一部の先進ユーザーのもの」ではなく、「みんなが使って当たり前」な存在になりつつあります。でも、使っている人が多いからこそ、こんな疑問も生まれます。「他の人はどう使ってるの？」「あのツールって実際、現場で役に立ってるの？」ネクストスケープ社内の有志によるAI推進プロジェクト「DevscAIpeLab」では、そんな声に応える場として、ゆるく情報共有できる「AI活用共有会」を定期開催することにしました。第1回は「MCP（Model Context Protocol）と生成AIのリアル活用」がテーマ。実務で活用しているメンバーが次々と登壇し、熱のこもった活用ノウハウを共有しました。この記事ではその様子を、対話形式で臨場感たっぷりにお届けします。 Claude × Microsoft Docsで"即答力"を強化するYanai（司会）では、早速ですが「最近こんなAI活用してるよ」という方、いらっしゃいますか？Uchijima（登壇者）はい、自分からいきますね。プロジェクトでClaude Desktopを使っていて、特に「Microsoft Docs MCPサーバー」が便利です。YanaiAzure DevOpsの設定確認とか？Uchijimaそうです。ビルドアドミニストレーターやエンドポイントクリエイターといった権限が何を意味してるか、ぱっと見て思い出せないことがあるんですよね。そんなときにClaudeに質問すると、MCP経由で公式ドキュメントを参照して、適切な説明をしてくれる。地味だけど、すごく実務的な時短になります。Yasudaその使い方、すごく共感します。昔は公式ページ探してコピペしてましたよ…。Uchijima設定は簡単で、Claudeに「Microsoft Docs MCP Server」をコネクタとして追加しておくだけ。URIを指定するだけで、Claudeがその知識を元に応答してくれるようになります。 DevOpsのチケット作成も、AIに"お願い"でOKUchijimaさらに便利なのが、「Azure DevOps MCPサーバー」との連携です。チケット発行の自動化がめちゃくちゃ効きます。Yanaiそれ、秘書がついた感ありますね。Uchijima例えば、会議設定の依頼を出すと、AIがWikiを参照して、必要事項を埋めてチケットを自動作成してくれます。手作業でやっていたときの手間と抜け漏れを考えると、相当な改善です。Yasudaチケット作成から実行までAIがやってくれるのはすごい。Copilotともまた違った、実行型のアプローチですね。IwayaMCPって、AIと外部ツールをつなぐ"通訳"みたいな存在ですよね。中にはファイル操作など、シンプルな命令だけを受け付けるMCPもありますが、今はかなり多機能化していますね。 BacklogにもMCPで"つながるAI"を構築！YanaiちなみにBacklogをMCPでつなげてる方、いますか？Uchijimaはい、私もやってます。チケット参照だけでなく、作成やWiki編集まで、MCP経由で指示可能です。すでに社内では、AIがBacklogから過去チケットを参照して回答の素案まで作る活用も進んでいます。Sakamoto最初は「便利なチャットボット」って感じでAIを見てましたが、MCPがあると"指示したらやってくれるツール"になりますよね。例えば「この内容でチケット書いて」と言うだけで、Backlogに投稿される。Yanaiまさに"実行するAI"ですね。 Slack × GitHub連携AI「Devin」の破壊力SakamotoSlackに「Devin」というAIを組み込んで、GitHubのコード解析に使ってます。例えば「この処理は何をしてる？」と聞くと、該当コードとその意味を画像付きで返してくれます。Yanai画像付きは熱いですね。Claude CodeやCursorでも近いことはできますが、Slackとの統合は便利。Sakamoto「アプリのバージョンを変えるにはどこを直せばいい？」みたいな質問にも、具体的な場所と変更方法を示してくれる。ちょっとした変更でも効率が段違いです。 「AIがやってくれる」が当たり前になる未来Teruyama実は私も、最近AIコーディングを始めました。Copilotから始めて、Codex、今はCursorで試しています。徐々に"補助型"から"自律型"にシフトしているのを感じますね。Yanai次回はそのあたり、ぜひLTで聞かせてください！Teruyama初心者目線での学びやつまずきポイントなど、共有できると思います！ まとめ：MCPが切り拓く、AI実行型の世界「調べてくれるAI」から「動いてくれるAI」へ。その進化のカギを握るのがMCPです。Claudeで公式ドキュメントを参照DevOpsやBacklogのチケットを作成GitHubコードの解析と改善提案Slack上から直接AIに指示こうした"実務に入り込むAI"は、もはや一部のツールに限られた話ではありません。APIさえあれば、多くの業務ツールにMCP経由でつなぐことが可能です。AIはもはや「助言者」ではなく「アシスタント」——そう実感させられる共有会でした。 次回予告：自律型AIによる開発支援を深掘り！次回は、CopilotやCodex、Cursorといったツールを使った「AIによるコーディング支援」がテーマ。エンジニアがどのようにAIと"共同作業"しているのかを掘り下げていきます。 参考リンク：Claude DesktopMCP (Model Context Protocol)Microsoft Docs MCPサーバーAzure DevOps MCPサーバーBacklog MCPサーバー

【AI活用共有会#1】ClaudeもDevOpsもBacklogも！MCPで始まる"実行するAI"の時代

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です今回はDifyというAIツールを触ってみましたのでその紹介記事となります。DifyはLangGenius, Inc.（米国デラウェア州）という会社が開発した、正確にはオープンソースのAI開発プラットフォーム となります。調べてみると去年のこの頃、AIブームとともに爆発的に利用者も増えたようで、既に様々な会社で利用されているツールとなります。これに関する記事も既に色々と書かれてはおりますが、2025年6月の最新の状況かつ、初めて知る方に向けて。。ということで書いてみたいと思います。早速ですが、まずはTOPページから。海外のツールではありますが、既にこのように日本語で書かれたページがあります。ちなみに前回のGammaと異なりサイトの言語としては日本語、中国、英語の３言語から選べます。作成開始～事前準備早速ですが、TOP画面右上の「始める」をクリックして試してみましょう。ログイン画面が表示されますのでそこからサインイン・ログインを行うと以下の画面になりまして、ここでアプリを作成していきます。先に価格についてお知らせしておきますと、Difyには以下の３つのプランがあります(2025年6月15日時点の情報です)。これはあくまで「Dify」の利用だけの料金となりますのでご注意ください。実際には使用したいAIのAPIキーを設定・利用することになりますので上記の料金プラン＋使用したいAIの料金が必要になります。が、APIキーが用意されている方は無料で利用が可能になりますので興味のある方は是非お試しください。改めてDifyについてですが、今までのプログラミングやデザイン開発、そしてプレゼン資料の作成サポートといったものとはまた別ものとなりまして、最初に「AI開発プラットフォーム」と書いた通り、AIアプリを作るためのツールになります。更にはノーコード・ローコードツールであるため、エンジニアだけでなく、ビジネスユーザーまでを対象とした、誰でもAIアプリが作れるというのが特徴になります。今回は、仮想の会社・製品についての資料、会社案内・製品仕様書・FAQの3つの資料をナレッジベースとしたRAGシステムをDifyで構築してみましょう。まずはログイン後の画面において以下の「アプリを作成する」から「最初から作成」を選びます。すると以下のような画面に遷移します。画面左側の「アプリタイプを選択」において「チャットフロー」を選び、更にアプリの名前、説明を入力して「作成する」を押下します。「チャットフロー」は今回作成するアプリのような会話専用のワークフローでして、「ワークフロー」は汎用的な処理フロー、例えば文書の自動処理としてPDFをアップして、テキスト抽出、要約、翻訳してメールを送信するといった一連の流れを行うためのものになります。チャットフローを選択し、その他の必要事項を入力すると以下の画面に遷移します。ノーコード・ローコードツールであるため、GUIベースで「ノード」と呼ばれる各機能単位・処理単位を組み合わせてアプリを構築していきます。AIモデル設定では、まずは「LLM」ノードをクリックすると右側に以下のようなウィンドウが表示されます。「AIモデル」に「！」マークがあるのでパッと見で気付いた方もいらっしゃるかもしれませんが、事前準備としてAIモデルの設定が必要となります。ですので、ちょっと順番が前後しますが、先にAIモデルの設定を行い、その後再度この画面に戻って構築を進めていきましょう。Difyの設定画面から「モデルプロバイダー」を選ぶと以下のような画面になります。ここでそのAIモデルを使用するか、そしてのそのAIモデルのAPIキー等を設定します。様々なモデルが利用できることがわかるかと思います。当然ながらこの設定前には各AIモデルのAPIキーを利用できるようにしてください。今回はGeminiを使いたいと思います。「プラグイン」という表現になっていますが、ここでモデルを選び（インストール）、APIキーを設定します。正しく設定できると以下のようになりまして、「API-KEY」右側のランプがオレンジから緑色になります（注意書きも出てますがそこは気になさらず。。）。では、先ほどのアプリ構築の画面に戻って、「開始」と「LLM」の線にマウスを移動すると以下のように「＋」のアイコンが表示されますのでこれをクリックします。すると以下のようなウィンドウが表示されるので実行したい言処理を選びます。今回はRAGを実現したいので「知識検索」を選びます。すると以下のように「知識検索」のノードが追加されます。ナレッジベース作成次に画面上部の「ナレッジ」をクリックします。以下のように「ナレッジベースを作成」の画面へと遷移しますので、「ナレッジベースを作成」の「＋」をクリックします。するとデータソースの選択を促されますので今回は「テキストファイルから。。」を選択します。少々文字が小さくて見づらいかもですが、「TXT」ファイル以外にWork、Excel、PDF等、テキストファイルといっても様々なファイルに対応しています。次にアップロードしたファイルに対して「チャンク設定」、つまり長い文書を、AIが理解しやすい小さな単位に分割する設定を行います。見切れていますが、画面下部の「保存して処理」ボタンをクリックすると「CloudSync Pro」という仮想のソフトウェア製品のナレッジベースが作成されますので、同様にこの製品のFAQの資料やこの製品を扱う会社の案内資料もアップしていきます。各種ノード設定次に再度アプリ構築の画面に戻り、「知識検索」で先ほど作成したナレッジベースを設定します。更に最初に選択した「LLM」をもう一度クリックし、AIモデルや「SYSTEM」「USER」等を設定します。「SYSTEM」と「USER」ですが、いわゆる「AIとの会話における役割設定」でして、具体的にはSYSTEM: 「AIの性格・役割・ルールを決める指示書」例：「あなたは親切なカスタマーサポート担当者です」USER: 「ユーザーが実際に入力する質問や内容」例：「商品の返品方法を教えて」といったものになります。つまり、SYSTEMでAIの「キャラクター設定」、つまりはAI行動指針を決め、USERで「実際の質問」を入力する仕組みです。上の画面が実際に設定した内容になりますが、ここをちゃんと設定しておかないと望んだ回答が得られませんでしたので（会社情報なのに製品情報のような回答をされてしまったり。。等）、今回のようなアプリ、構成で作成する場合には一番注意が必要になる部分ではないかと思いました。単に私のプロンプト等がよろしくなかったのかもしれませんが、できる限りAIが正しい方向に進めるようにしておくことにこしたことはないかと。「プレビュー」機能そして、画面右上の「プレビュー」ボタンを押下すると以下のようなウィンドウが開きますので、ここでテストが行えます。以下が製品についての問合せ結果。以下が会社に関する問合せ結果となります。終わりにこうして作成したアプリについてはAPI経由で利用できるようになりますが、今回は割愛いたします。このように非常に簡単な例ではありますが、このようにGUIベースで簡単にAIアプリを作成することができます。実際には精度を上げるために更に調整、設定が必要になりますが、それでもこのようにエンジニアでない方々でもプログラミングの知識を必要とせず、アプリを作成できるのは非常に魅力的だと思います。実はこのDify以外に似たようなノーコード・ローコードのAIアプリ作成ツールとしてFlowiseというツールも試していたのですが、GUIのわかりやすさ、扱いやすさという点においてはこちらのDifyの方が個人的には良さげでした。ただ、Flowiseも「エンジニア寄りの」ノーコード・ローコードツールと呼ばれ、Difyよりも高い自由度を持っており、人によってはDifyよりも高い評価を得ているようなので改めて本ブログに書ければと思います。当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

AI開発プラットフォーム Difyを触ってみた

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です最近はエンジニアよりのツール紹介が続いていたため、そうでない方々向け、例えばということでプレゼン資料作成のツールを探してみたところ、Gammaというツールが良さげでしたのでこれを使ってプレゼン資料を作成してみたいと思います。こちらはアメリカ、サンフランシスコのGamma Tech.Inc.という会社が提供しているツール、サービスとなります。https://gamma.app/ja上がHOME画面となりまして、海外のサービスということなので英語での表示を予想していたのですが、既に日本語のページもありました。ちなみに約40か国語に対応しているようでして、これだけでも急速に普及していることが伺えます。まずはサインアップしてみます。以下のようなアンケートがありますが、「まだ決めてない」という項目もあるので、その後の操作には影響しないようです。生成依頼サインアップが終了すると以下の画面になります。何を元に作成するかの選択画面になります。以前、PowerPointでCopilotを試したときも簡単な文章から作成してもらいましたので比較の意味も含め「生成」を選択します。「生成」選択時の画面が以下になります。「作りたいものを説明してください」と書かれた入力欄に以下の内容を入力してみたいと思いますが、「AzureとAWS、それぞれの特徴や、メリット・デメリットを説明してください。必要に応じて表形式での説明もお願いします。」その前に画面上の設定で皆さんも気になっているであろう部分があると思うのでそちらを説明しておきますと、「日本語(です/ます体)」をクリックすると言語が選べます。日本語も「だ/である体」と先ほどの「です/ます体」を選べるのは非常に配慮が細かくてよいなと思いました。自分で書くと統一し忘れていることもありますので。あとは「8枚のカード」と表示されている箇所、こちらは以下の画面の通り「カード」＝「スライドもしくはページ」でして、今回の依頼内容を「何枚で」表現するかもここで指定できます。「PLUS」「PRO」とありますが、これは料金プランとなります。今回は無料プランで試しているため最大10ページ作成可能です。では、改めて本題に戻って先ほどのAWSとAzureの違いで依頼すると以下のようなアウトラインが出力されます。ここでは各項目の内容を直接書き換えることもできますし、並び替えや項目自体の削除も可能です。このあたりはPowerPointのCopilotと似ていますね。更に下にスクロールすると「テーマ」の設定やテキストの量、画像の使用有無を指定できます。最初は以下の内容のまま、全てデフォルトで行きたいと思います。生成結果直前の画面の「生成」をクリックしてしばらくするとプレゼン資料が出力されます。以下のように表も出力されています。何故「表」について確認したかといいますと、以前同様のプロンプトでPowerPointのCopilotで出力してもらったことがありました。その時は表までは出力してもらえず、今回のGammaを試した後にもう一度PowerPoint上のCopilotで「表も使用して」という指示も含めて試してみたのですが、残念ながら出力してくれませんでした。もっと正しいプロンプトがあるのかもしれませんが。。さて、メニューからエクスポートを選択すると以下の画面が表示されまして、パワーポイントはもちろん、PDFやGoogleスライド、PNGへのエクスポートが可能です。このようにパワーポイントでも出力でき、編集も可能になります。ただ、例えば以下のような箇条書きの羅列の場合のように、人間であればまとめてテキストボックスとして記述するであろう箇所も1行ずつ個別のテキストボックス内に書かれていますので、改めて手作業で追記・編集・修正を行う場合はやや手間がかかるかもしれません。まあ、所詮プレゼン資料なのでそれほどの手間ではないと思いますが。。その他の機能別の機能を試すにあたって、もう１枚別ページ、性能比較のページを見せておきます。ちょっと情報量、文字数の少なさが気になったので最初のプロンプト入力画面においてテキストの量を「詳しく」にした結果が以下です。なかなか良い感じではないでしょうか？ちなみにレイアウトが全く違っていますが、これはテキストの量の設定に限らず、出力されるたびにランダムで変わります。プロンプトの指定によってある程度制御できるかもしれません。あとは画像について。恐らく仕事で、特に社外の他のお客さまに向けて作成する際は自社のテンプレートや、あるいはお客様の会社のイメージカラーに合わせてテーマを別途設定すると思います。そうなると先に上のような形で色々と画像が設定されてしまっていると逆に扱いにくくなってしまいます。そこで画像を無しにして再出力してみました。その結果が以下になります。いかがでしょうか。最小限のアイコンのみとなりまして個人的にはこの方が良さげに思えます。あとはこれに自社のデザインテンプレート（デザインテーマ）を適用する等、必要なデザイン設定をしていただければいいのではないかと思います。色々機能はありますが、あともう１つだけ。グラフや図表の挿入も当然ながら可能です。例えば以下のように「縦棒グラフ」を選択するとこのようにグラフが表示され、更にグラフを選択して表示されたメニューから「グラフデータを編集」を選択すると以下のようにグラフの編集画面へ遷移します。ここで細かいデータの追加・編集、見た目の変更が可能です。パワーポイントでも同様のことは可能なのですが、以下のように見た目と値の設定が別ウィンドウとなりますのでそういう意味では上のように一画面で収まる形が使いやすいかもしれません。単純に「プロンプトを指定して、出力」だけに留まらず、色々と設定が可能で、かなり使える、便利なツールでした。NoteやQiita、X等で頻繁に目にしていましたが、納得の使い勝手です。ただ、AIツール全てに言えることとしまして、出力結果には誤りを含む場合があります。重要な情報は必ず確認・検証を行ってください。また、機密情報や個人情報など、外部に共有すべきでないデータの入力については注意・確認の上ご利用いただければと思います。当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

プレゼンテーション作成ツール Gammaを触ってみた

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です。ここ最近の記事ではAIツールについて色々とご紹介してきました。特に最近についてはNotebookLM、Firebase Studio、Julesと、Googleのサービスについてフォーカスを当ててきた形となります。今回は同じくGoogleのGemini、正確にはGemini in BigQueryについてご紹介させていただきたいと思います。サンプルデータ選択ということで早速試してみましょう。まずは以下がBigQueryのTOP画面になります。そもそもBigQueryはDWHですのでデータが無いと使えません。BigQueryではサンプルデータが用意されているのでまずはそれで試してみたいと思います。上記のTOP画面の赤枠部分、「Add data」をクリックすると右側から以下のような画面が表示されます（各スクリーンショットについては文字が小さく見えづらい部分もあると思いますのでブラウザの拡大機能等ご利用ください）。そして赤枠の「Star a project by name」をクリックし、以下のダイアログが表示されるので「bigquery-public-data」と入力して「Star」をクリックします。すると以下のように左側の「Explorer」のツリー部分に上記で追加したデータ（データセット）が追加されます。このデータセットの中には以下のような名前のデータがありまして、Eコマース（ECサイト）におけるGoogleAnalyticsのGA4のデータ、ECサイトの各ページにおけるPV数等が入っています。・bigquery-public-data.ga4_obfuscated_sample_ecommerceこれを元にBigQueryにおけるGemini絡みの機能を見てみたいと思います。Cloud Assistの利用まずは画面右側のCloud AssistでGeminiとのチャットを開始します。すると以下のようにプロンプトの入力が可能になります。このCloud Assistはエンジニア向けのSQLを書くための支援ツールとなりますので、以下のようなプロンプトを投げてみます。「【要件】・ページビュー数が多いページを上位10件表示したい・ページのURLまたはタイトルでランキングを作りたい・初心者にもわかるように、クエリの各部分を説明してくださいGA4のデータ構造についても簡単に教えてもらえると助かります。」すると、以下の画面右側にクエリが表示されます。左側赤枠部分でクエリを実行できますのでそこで今回の出力されたクエリを試してみると、要望通りPV数をTOP10を抽出できました。正しく出力されない場合もあるのですが、そこもこのCloud Assistに問い合わせることで修正してくれます。Cloud Assistは基本的にSQLの記述支援になりますので基本的にはSQLの提示のみになるのですが、プロンプトの書き方を工夫することでクエリ自体の説明はもちろん、以下のように今回対象としているGA4のデータ構造についても教えてくれます。ちなみに画面右側のスペースが狭くて見づらい場合は以下のように３点リーダーから「Full page」をクリックすると。。以下のように別タブでチャット部分が広く表示されるようになります。もう少しだけ横道にそれますと、クエリ結果のところの「Chart」。ここをクリックすると。。以下のようにその結果のグラフ表示ができます。BIツールであるLooker Studioでもいいのですが、簡易的でよければこのようにBigQueryだけで完結出来ます。独自データ及びデータキャンバスの利用さて、次は別のGeminiを使った機能を試してみたいと思います。上記のECサイトのデータですと自分の作ったサイトではないこともあり、あまり馴染みのないデータであるため、もう少しわかりやすいデータにしてみたいと思います。そこで、仮想の（カレーに特化した）食品メーカーとレトルトカレーの製品に関するアンケート結果のデータを作ってみます。辛さとレビュー、値段（今回は定価とします）も加えます。このデータ（currysurverという名前にしています）をBigQueryに追加し、「データキャンバス」という機能で取り込みます。では、「最も人気の商品を教えて」と聞いてみます。すると自動的にその結果を求めるためのクエリを作成・実行し。。。グラフも含め結果を出してくれます（人気＝アンケートの結果が多いという判断です）。ちなみに結果についての説明が英語で書かれてますが、「日本語で」とお願いすると日本語で出力してくれます。では別の質問で日本語での回答を求めてみましょう。「結果を日本語で説明してください。どの辛さレベルが最も人気ですか？」と聞いてみます。するとちゃんとアンケート結果を元に回答してくれます。一番人気だけでなく、その辛さが何件あって。。ということもちゃんと教えてくれます。素晴らしい。そもそも取り込んだデータについて実はよくわかってなくて。。という場合でも以下のように質問すると説明してくれました。カラム名や製品名からの推測だと思いますが、教えたことが無いにも関わらず適格に説明してくれます。ちなみにデータキャンバスは最初は何もない状態ですが、Geminiとやり取りをしていくと、以下のように複数のパネルが紐づけられていきます。これはデータや解析作業の関連状況を表していまして、従来のBIツールでは結果のみ出力されているため、どうやって作ったかは作った人間にしかわからないのですが、BigQueryではこのデータキャンバスによってどのようにデータが処理されているか、なぜこの結果になったのかを追跡することができます。最後にこのようにデータキャンバスは簡単なプロンプトにもかかわらず、色々と配慮した形で情報を出力してくれます。今回データについても急ぎ準備・出力したものなので、データ量はもちろんのこと製品に関する情報としては欠けている部分が多々ありました。例えば購入日時等もデータの一項目として追加すれば（存在していれば）、月毎もしくは季節に応じた売り上げの違い、傾向等も出てくるはずなのでそういったものもGeminiが自動的に解析を行い、アドバイスをしてくれるのではと思います。つまり実際のデータで、かつその量や質がしっかりしたものであればあるほど、それに応じた情報・解析結果を出力してくれます。今までCursor等コーディング支援のツールを中心に触ってきまして、ある程度AIを使うことに対する「慣れ」も多少ながら出てきたのですが、今回DWHにおけるビッグデータを対象にしたAIツールということで、改めて「おっ」と思わされる内容でした。今までのどれともまた違った魅力を持ったツールです。是非使ってみてはいかがでしょうか。当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

Gemini in BigQueryを触ってみた

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です。先日5月20日にGoogleからコーディングエージェント「Jules」が発表されました。もともとは昨年12月にGemini2.0と共に発表され、この5月20日にパブリックベータという形で公開されました。今回はこのJulesを触ってみた感想となります。現在このJulesはベータ版で、無料で利用可能です。また、モデルについては当初のGemini2.0から進化し、2.5 Proを搭載しており、公式サイトに書かれている機能としては以下になります。・テスト作成・バグの修正・新機能の構築・音声による変更ログの提供・ライブラリのバージョンを上げる今回はバグの修正というところでJulesを使ってみたいと思います。ログイン及び設定Julesにログインしてみましょう。https://jules.google.com/以下がログイン画面になります。昔懐かしい感じの画面になりまして、タコのような宇宙人？＝エージェントがコードを修正しているといったところでしょうか。Googleのサービスなので当然ながらGoogleアカウントが必要になります。右上の「Try Jules」をクリックします。プライバシーに関するお知らせのダイアログが表示されますので確認の上、次へ進んでください。次にGitHubに接続します。なので、GitHubアカウント及びリポジトリも必要となりますので併せてご注意ください。JulesはGitHubリポジトリがベースになります。Firebase StudioやCursorは何もないレベルからソースコードを書いたりできるのですが、JulesはGitHubリポジトリが必要であり、それを元にやり取りを行い、変更・修正を行います。次にJulesに対する権限設定、そして参照するリポジトリを設定します。全てのリポジトリでもよいですし、特定のリポジトリのみでもよいです。リポジトリはPublic、Private、両方ともに対応可能のようでして今回はPrivateにしました。無事、設定及びGitHubへの接続が終わると以下のようにチャット欄のところに接続したGitHubのリポジトリとブランチが表示・変更できます。余談なのですが、筆者はテスト用にGitHub上で何もリポジトリが無い状態から先にJulesでGitHubに接続し、「その後に」リポジトリを作成したのですが、何故かJulesでリポジトリやブランチが表示されず、一旦接続情報を削除したりと少々てこずりました。結果、時間の経過で自然に直ったようなのですが、もしかするとベータ版というところも影響しているのかもしれません。事前準備（対象リポジトリの準備）更に事前準備を進めます。JulesはGitHubベースで動きますのでGitHubリポジトリが必要となります。そこでリポジトリにはNode.jsでWebベースの簡単なToDoアプリを作ってPushしておきました。更に意図的に構文エラー、論理エラーを仕込んでおきます。まずは以下の赤枠部分、セミコロンを削除しておきます。Node.jsではエラーにはならないのですが、今回行末には全てセミコロンを設定してありますので、見た目の統一のために追加するのでは。。と思った次第です。次に以下のコードの34行目の記述を丸々消します。つまり、必要な括弧閉じが書かれていない状態であり、明らかな構文エラーです。次に以下の新しいToDoを追加する処理においてToDoの数をインクリメントするところを削除します。そして試しに実行し、エラーが出て起動しないことも確認しておき、これをPushします。Julesへの依頼～プルリクエストまでではいよいよここからが本番です。元々の画面では全て英語だったのですが、試しに日本語で指示してみます。しかも相変わらずざっくりレベルで。するとJulesがリポジトリをチェックし、以下のようなメッセージが表示されます。このメッセージはJulesが立てた実行プランとなりまして、直訳しますと「public/script.jsでファイルの切り捨てによる構文エラーと、routes/api.jsで新しいTodo IDが生成される方法に潜在的なバグがあることを確認しました。これらの問題を修正する計画を立てました：public/script.jsの構文エラーを修正する： 標準的なTodoリストの機能を想定して、ファイルを完成させる。routes/api.jsのTodo ID生成の改善：より安全なID生成ストラテジーを実装する。APIの基本テストを追加： Todoの追加に関する修正を検証する。変更を確定する。フィードバックがあれば教えてください。そうでなければ、承認してください。」というものになります。どうやら仕込んだバグをちゃんと見つけられたようです。そこでJulesが立てたこの計画を承認しますとJulesが次々と作業を進めていきます。まずはscript.jsの修正。。修正が終わるとウィンドウが2分割され、右側にその内容が表示されます。括弧を削除したところも修正されています。インクリメントの部分も元々初期化がなされていなかったようで、初期化処理と、インクリメントも修正されています。プランの中にテストの追加も書かれてましたが、ちゃんと「test」フォルダを作成し、テストコードも書いてくれています。ただ、セミコロンを削除した部分だけはそのままとなっていました。プロンプトが雑すぎたことも影響しているかもしれず、記述の統一等も依頼すれば修正されたかもしれません。Julesは仮想マシンを内部に持っているそうで、そこでテストコードも実行してくれます。そしてFixブランチに対してのプルリクエストを提案します。上記の表示内容において「Publish branch」をクリックするとFixブランチに対してPushを行ってくれます。。。と、このように自律型エージェントとしてプルリクエストまで実行してくれました。スクリプトをもっと丁寧な内容にすれば更に期待以上の結果をもたらしてくれるのではと思います。この後も色々触ってみたのですが、恐らくはベータ版ということもあり、Jules側で次のアクションまでにかなり時間がかかったり、途中でリポジトリを見失ったりもしていまして、少なくても私の環境においては若干の不安定さもありました。ただ、ここ最近のAI界隈の進化を考えるとこのあたりもすぐに改善してくれると思いますし、日本語での回答も近々に対応してくれるかもしれません。同じタイミングに発表されたGitHub Copilot Coding Agent、そしてOpenAIのCodex等、コーディングエージェントが次々と出てきており、AIツールの覇権争いはますます激化しそうですね。。当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

自律型エージェント Google Julesを触ってみる

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です。今回はGoogleのノートアプリ、NotebookLMについて触ってみた感想を書いてみたいと思います。https://notebooklm.google.com/このNotebookLM、2023年の夏ごろからベータ版としてアメリカ限定で公開されており、そこから生成AIの普及に伴い各国への展開、そして対象とするデータの範囲も広がり、日本語にも対応して今に至ります。早速アクセスしてみると以下のようなダイアログが表示されまして、個人データがトレーニングに使用されないということが明記されています（文字が小さくて見づらい方はブラウザの機能で拡大してください）。ただ、他のAIサービスにも言えることですが、NotebookLMは外部のクラウドサービスですのでデータに関しても慎重な扱いが求められます。その点ご注意ください。さて、上記ダイアログを確認した後は以下の画面へ遷移します。ちょっと見づらいかもですが、「サンプルのノートブックを試す」と「ノートブックを新規作成」の２つの選択肢があります。準備・ソースの追加普通であれば「サンプルの～」が良さそうな気がするのですが、実際に触ってみた感想としては正直なところNotebookLMのサンプルだけですとソースが英語であるためNotebookLMがどういったものなのかというのがちょっとわかりづらかったです。そこで今回は「ノートブックを新規作成」で進めていくことにします。「ノートブックを新規作成」をクリックしますと、以下のような「ソースを追加」ダイアログが表示されます。NotebookLMはソースを元にチャットでやり取りを行い、ユーザーに情報・データを提供していきますのでまずはソースが必要となります。以下のダイアログはそのソースを指定（追加）するためのものになります。対象となるソースは以下になります（2025年5月19日時点）。PDFテキストファイル音声ファイル（*.avi、*.mp3等）GoogleドライブGoogleドキュメントGoogleスライドリンク（URL）ウェブサイトYoutube テキスト本記事ではまずはリンク→Youtubeを試してみましょう。上記ダイアログで「Youtube」を選択するとURLを貼り付けるダイアログが表示されるのでそこに対象としたいYoutubeのURLを貼り付けて「挿入」ボタンを押します。今回はNotebookLM繋がりということでGoogleの提供している動画、Lookerに関する動画のアドレスを設定してみます。URLの入力ダイアログで「挿入」ボタンを押してしばらくすると以下のような画面に切り替わります。これがNotebookLMのメイン画面で、ここにソースに対してGeminiとやり取りを行い、得られた情報をメモ・整理していく形になります。大きく3つのペインに分かれ、左側がソース一覧となります。現在ソースは先ほど追加したYoutubeのURLのみですが、１つに限らず更に追加することも可能です。後でこの部分についてもう一度触れますので一旦次に行きます。次に真ん中の「チャット」画面がありまして、ここでGeminiとのやり取りを行います。初期段階ではソースに対する概要、つまり指定したYoutubeの概要が書かれています。これだけでも結構役立つのではないでしょうか。概要をざっと眺めてみまして動画の内容について理解はできたのですが、おもむろに「OpenX」という筆者の知らない単語が出てきたので「OpenX」って何？と聞いてみると以下のような回答が返ってきました。あくまで「ソースによると～」ということなので、別途検索してみるとそれらしきサイトがあったので更に聞いてみます。これも「ソースによると。。」という言葉から始まります。（NotebookLMを知っている方には今更だと思いますが）つまりNotebookLMは提供したソースに基づき回答を行っており、それ以外のところから自主的にデータを取りに行くということをしません。そのため、Geminiから得られる内容をより充実させていくためにはソースを増やしていく必要があるのですが、それについては後述するということで一旦他の機能について言及させてください。音声概要次にチャットの下に「音声概要」というのがあるのでこれをクリックします。すると少々時間がかかった後（動画によると思いますが、私が試した1時間程度の動画であれば４～５分でしょうか）、右側のペインに以下のような内容が表示されます。実は個人的にこれが一番面白かったです。以下の画面を見ると何か音声を再生できるような雰囲気なのですが、実際の動画よりも短い再生時間となっていまして、いったい何が聞けるのか恐る恐る聞いてみたところ、おもむろに男性と女性の2人が「ラジオ番組のように」今回ソースに設定した動画の説明をしていました。「ラジオ番組のように」とはどういうことかと言いますと、機械的に概要を読み上げるわけではなく本当に会話形式で、かつ、時々「えーと」とか、「そうですね」といったあいづちも含まれていまして、本当にリアルタイムでその２人がそこにいて、その動画について語っているかのようでした。少々不真面目な感想になってしまいますが、まさかこういった情報が出力されるとは思わず、少し笑ってしまいました。。ただ、単に面白いというだけなく、2人より会話の掛け合いによって動画の内容が非常にうまく説明されていると思いました。皆さんも是非これだけでも試してみてもらえればと思います。マインドマップ次に同じくチャットの部分に表示されている「マインドマップ」をクリックすると右側に以下の内容が表示されますので、それをクリックします。※同じ文章が並んでますが、間違えて２回押してしまったためですするとマインドマップという名前通りではありますが、今回のソースである動画の内容をマインドマップで整理した結果が表示されます。これも非常に興味深い機能なのですが、動画が外国語の場合は日本語での出力が行われないようです。チャットで色々と試してみたのですが（私の場合は）駄目でした。音声概要含め様々な機能が日本語対応されていますので、このマインドマップの部分も是非近いうちに日本語に対応してくれることを期待します。より実践的な使い方さて、ここまで幾つか機能を紹介したところでもう少し「どう使えば？」レベルに踏み込んでみたいと思います。今度はウェブサイトのURLを設定してみます。当社のサイトURLを設定してみましょう。メイン画面は以下。チャット部分にサイトに基づく企業概要がまとめられています。マインドマップは以下の通り。サイト（だけ）をソースにするとサイトマップとほぼイコールになるように思われますので、それはそれで使い道の１つとして良いかもしれません。仮に私が当社のコンサルとしてWebサイトの改善を検討しているとしましょう。そこでソースの部分の「検索」をクリックし、「今後のSIに求められるものとしてどういったものが考えられるでしょうか。」と入力してみます。※ちなみに弊社の「SI」は「シリアルイノベーター」の略になります。詳しくは弊社サイトをご覧ください企業情報 | 株式会社ネクストスケープするとNotebookLM（Gemini）がその言葉を元に色々なソースを取得してくれますので、ソース元に設定したいものを選んで「インポート」します。今回はとりあえず全て設定してみましょう。すると以下のように「ソース」に情報が追加されますので、チャットで「ネクストスケープのサイトで改善すべき点を教えてください」と質問すると上記ソースに基づいた回答が得られます。出力結果・内容については割愛させていただきますが、単純に出力内容の行数だけで比較しても当社のURLのみをソースとした場合は30行、上の画像のようにソースを追加した後は60行近く出力されており、（その内容の良し悪しはともかくとして）ソースの追加による影響は明らかです。メモのソース化そして、出力された内容については以下のように「メモに保存」というボタンがあり、それをクリックすると右側の「メモ」に追加されます。このメモはNotebookLMによって出力された内容も対象になりますが、その名の通り自身でメモした結果も保存することができます。そして、各メモをクリックすると以下のように「ソースに変換」というボタンがありまして、これをクリックするとこのメモが「ソース」に追加されます。つまり、今までのやり取りで得られた結果を更にソースにすることで情報を追加し、精度を上げ、階層的・構造的により良いものにしていくことができるわけです。その他雑感このようにNotebookLMは１つの事柄について理解し、深堀するために必要な様々な機能が盛り込まれています。Xで他の方の利用方法を見ると膨大なPDFの資料を要約してもらい、更にCursorで整理するといったように複数のAIツールを組み合わせた使い方も紹介されています。また、このNotebookLM、ソースとしてGoogleドライブ、Youtubeの２つが指定できるというのが強みではないでしょうか。特にYoutubeの解析・要約は他のAIツールでもできるのではと思ったのですが、私がChatGPTやClaudeで実際試した限りでは動画内容を読み込むことができませんでした。同じGoogleのサービスだから可能なのかもしれませんが、Youtubeの学習系の動画というのは視聴するのにそれなりの時間を要しますので非常に助かります。また、最初の方で書いた通り、GoogleのサービスであるためにGoogleドライブをソースとすることができます。会社によってはGoogleドライブに資料を集約しているところも多いかと思います。そういった方々にはNotebookLMであればすぐに活用できると思いますので是非使ってみてはいかがでしょうか。NotebookLMは、「Web全体の情報から答えるAI」ではなく、「自分が読み込ませたソースに特化したAI」というコンセプトなので、個人の研究、ビジネス文書、会議記録などに集中させ、他のAIサービスのように余計な知識を挟まないようにさせることができるというのが大きなメリットとなります。つまり、信頼できるソースを厳選することでハルシネーションの発生を抑えることができます。ただ、これも他のAIサービス同様絶対に抑えられるわけでありませんので、ソース含め出力された内容については各自確認した上で利用してもらえればと思います。料金もGoogleアカウントを持っているユーザーであれば誰でも公式ページからログインしてすぐに使い始めることができます。興味のある方は是非ご利用ください。最後に当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

生成AIノートアプリNotebookLMの紹介

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です。ここ最近の当社ブログではGithub CopilotやCursor、Firebase Studio等々、生成AIに関する記事を書いてきました。blog.nextscape.netblog.nextscape.net今回は「Vercel v0」（以下v0）を触ってみましたのでこれについて記事を書いてみたいと思います。Vercel v0概要このv0、Next.jsの開発元であるVercel Inc.が開発した生成AIツールになりまして、AI関連のXの投稿を見るとちょいちょい見かけていたため非常に気になっておりました。v0のサイトでは「生成UIツール」とあり、「UI生成」「プロトタイピング」「ペアプログラマー」といったことに役立つと書かれています。プログラミング言語に関してはVercelが作成しただけあってReact、Next.jsといったように主にUI周りに強みを持つツールのようです。現時点（2025/05/04）での最新の料金プランは以下。Freeプランもありまして今回はFreeで試してみたいと思います。Webアプリ作成新規登録、ログインを行うと以下のような画面に遷移し、他の生成AIを用いたツール同様、チャットで依頼する形になります。今回は以下のようなプロンプトでWebアプリの作成を依頼してみます。今回は今までの私の記事のような雑な依頼ではなく、プロンプトにそれなりの粒度で依頼内容を記載してみます。プロジェクト名: 「学習トラッカー」概要:ユーザーが自分の学習状況を管理し、進捗を追跡できるWebアプリを作成してください。ユーザーは学習目標を設定し、達成度を確認できます。機能要件:・学習目標設定: ユーザーが学習目標を設定し、達成期限を指定できる機能。・進捗管理: ユーザーが学習の進捗を記録し、達成度を確認できる機能。・学習履歴: 過去の学習履歴を表示し、どの目標が達成されたかを確認できる機能。・通知機能: 学習目標の期限が近づいた際に通知を送る機能。・ユーザー登録: ユーザーがアカウントを作成し、学習状況を保存できる機能。デザイン要件:ユーザーフレンドリーなインターフェースレスポンシブデザイン（モバイル対応）と、以上の内容を依頼してみます。すると数分経過して以下のような画面が表示されます。左側がチャットでのやり取り、右側が生成された結果となりまして、今回依頼した「学習トラッカー」の画面が表示されています。タイトルの「学習トラッカー」の隣にあるリンゴのアイコンが何か微妙な印象を与えますが、全体的にシンプルでありながらあまり安っぽくもない今どきのレイアウトのように思われます。後ほどお見せしますが、ログイン画面や新規登録画面もありまして、ログインすると以下のような画面になります。既にサンプルデータが入っています。プログラミングの学習用に使っているというイメージですね。進捗率もグラフィカルに表示されて機能要件が一通り満たされている印象です。ここまでのチャットのやり取りは以下のようになります（文字が小さい方はブラウザの拡大機能でご確認ください）。（続き）もう少し画面をお見せしますと新規アカウント登録は以下のようになります。追加改修・変更ただ、あくまでモック、プロトタイプとなりまして、例えば以下の赤枠部分「詳細を見る」ボタンを押すとソースコードが表示され、まだ実装されていませんでした。そこでもう少し頑張ってもらいます。（続き）最初の依頼と打って変わって雑な依頼にもかかわらず、かなり詳しく考えてくれています。そして実際にもう一度詳細画面へ遷移するボタンをクリックした結果が以下。サンプルデータがちゃんと書かれていることもありますが、学習カテゴリや残り日数等、UIが非常によく、細かいところがしっかり作りこまれているイメージです。新しい学習目標を作る画面は以下のようになります。では、白黒では寂しいので以下のように依頼してみます。「もう少し色を付けたいです。但し学習用アプリなのであまり派手になりすぎないように」と依頼した結果が以下になります。進捗が赤と緑で表され、より分かりやすいものになりました。では改めてコードを見てみましょう。左上の「</>Code」をクリックします。するとファイルツリーとエディターが表示され、以下のようにNest.jsで書かれていることがわかります。フォルダで区別する形なのか、あくまでとりあえず作成したという意味なのか、ファイル名が全て同じでいまいちですが、コードの内容自体は適度にコメントが日本語で入力されており、Nest.js初心者の私から見てもわかりやすく書かれています。テストコード生成テストコードも依頼してみます。依頼した直後のやり取りが以下。テストコードの実行方法も手とり足とりという感じで教えてくれます。「テストコードは一部でいいので」と依頼したためなのかはわかりませんが、拡張方法までちゃんと書いてくれます。実際にエディタ画面で見てみると、Next.jsでは「__tests__」というフォルダ配下にテストコードのファイルを配置するのがセオリーなのですが、今回もちゃんとそのようになっています。プレゼン資料生成さて、プロトタイピングだけでは前回のFirebaseと変わりませんのでもう少し色々試してみましょう。Xの投稿を見ると「v0でプレゼン資料を。。」といったつぶやきがあったのでこれも試してみます。以下のように依頼してみます。するとHTMLをゴリゴリ書き始め、「プレゼンテーション」と「全スライド」のタブと共にプレゼンテーション資料が作成されました。こういうタブが用意されるということはv0の使い方として想定しているのですかね。。？以前、パワーポイントのCopilotで同様の内容を試した時は表形式での出力が行われなかったのでそこにやや不満を感じていたのですが、今回はちゃんと表も書かれています。ちなみにVS CodeのCopilotで同じ内容を依頼すると以下のようにMarkdown形式で書いてくれます。これはこれでいいのですが、「プレゼン資料」ではないですね。他のツールとの比較ここまで試してみてUI周りに非常に優れている印象が強まってきたので、バカの一つ覚えのBMI計算ツールを作成してもらいました。以前Firebase Studioで投げたプロンプトと同様「BMIを計算するWebアプリを作成して」というレベルのざっくり指示です。その結果が以下。今までと違ってアプリの説明がタイトルの下に書かれているのと、単位をキロとポンドで切り替えられるようになっています。更に「計算」と「BMIについて」というタブがあるので「BMIについて」をクリックします。すると。。おお。。以下のようにBMIの説明の画面が別途用意されています。注意点までちゃんと書いています。しかも文字の色もうまく使い分けられていて非常にわかりやすいです。素晴らしいですね。画面遷移図ここまで来てこれだけ色々出力できるのであれば「アレ」ができるのでは。。とふと思いまして先ほど作成した「学習トラッカーの画面遷移図を作成して」とお願いしてみました。以下がその結果です。と、このように画面遷移図を書いてくれました。ここでダウンロードできるファイルはMermaid形式で作成されていまして（MermaidとはMarkdownライクな記法でダイアログが書けるJavaスクリプトライブラリです）、以下のようにMermaidに対応したビューワーで開けます。いかがでしょうか。非常にわかりやすく図示されています。これを手を動かすことなくあっという間に生成できるのです。最後にUIに強みを持つこのv0、FirebaseやCopilot、Cursorとはまた違った良さを持っています。出力される文章の内容についてもまださわりでしかないものの、他のツールと比べてもかなり詳しく、丁寧な印象を受けました。Firebase Studioと比べた場合に依頼に対して確認することなくどんどん作業を進めてしまい、インタラクティブなものではありませんでしたのでそこがもう少し。。ではあったものの、それを補って余りある便利さ・魅力を感じました。このようにFreeプランでも色々使えますので是非皆さまもお試しください。当社ネクストスケープは新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

生成UIツール Vercel v0の感想

はじめに株式会社ネクストスケープ エンタープライズサービス部の小野塚です。前回の記事では弊社の椎がCursorを紹介してくれまして、社内の人間としても興味深く読ませてもらいました。blog.nextscape.net今回はその流れ？でGoogleの「Firebase Studio」を触ってみたので記事を書いてみました。このFirebase Studio、こちらは今月４月９日に公開されたサービスでまだプレビュー版となります。まずは「Firebase Studio」ではない「Firebase」についてなのですが、スマホアプリ開発に携わった方であればこのサービスを聞いた、もしくは使ったことがある方は多いかと思います。ご存じの方には釈迦に説法となりますが、FirebaseはGoogleがアプリケーションの開発者向けに提供している、モバイル・Webアプリケーションのプラットフォームです。いわゆるMBaaS（Mobile Backend as a Service）と呼ばれるもので、もバイアルアプリ開発に必要な様々な便利機能が提供されています。NoSQLやクラウドストレージ、認証システム構築機能といった様々な機能を持っており、このFirebaseを利用することで開発コストの大幅な低減が可能になりました。Firebase Studioとは今回発表・公開された「Firebase Studio」は「～ Studio」というネーミングから伺い知れるように生成AIを取り入れた統合開発型のプラットフォームになります。FirebaseやGoogle Cloudといったサービスとシームレスに統合されています。Geminiを利用できることに加え、アプリの作成、テスト、公開といった流れ全てがブラウザベースで一気通貫で利用できるのが大きな特徴でしょうか。具体的にはプロトタイプ作成、エミュレータ、開発環境の提供等の機能を持っているとのことで、今回はプロトタイピング機能を触ってみたいと思います。早速TOPページから「Try Firebase Studio」で試してみましょう。ちなみに無料で３つのワークスペースが使用できるそうです（Firebaseの機能を利用する場合はFirebaseの料金体系に準じます）。firebase.google.com以下がTOPページです。「Try Firebase Studio」押下で以下のような画面に遷移します。テキストボックスの上に「Prototype an app with AI」と書かれています。「AIでアプリケーションのプロトタイピングが行えます」ということですね。筆者は元々モバイルアプリの開発を行っていたのですが、その時に始めて作ったアプリはBMIを計算するものでした。なので今回はBMI計算アプリを作ってもらいましょう。日本語で「BMIを計算して表示するアプリを作って欲しい」と書いてみます。身長、体重の入力等もあるわけですが、一旦そのあたりは割愛し、上のようなざっくりした指定でお願いしてみましょう（本当はちゃんとしたプロンプトを書くのが望ましく、あまり情報を割愛すべきではないですが。。）。「Prototype with AI」というボタンが表示されるのでクリックしてみます。すると５～１０秒ほどで以下の表示が。「App Blueprint」つまり「アプリの設計図」ということで「Features」、機能を色々考えてくれました。身長・体重の入力やBMIの計算、表示等、必要な機能は揃っているようです。「STYLE GUIDELINES」では色合いやレイアウト等が記載されています。最低限の内容は揃っているようなのでとりあえず「Prototype this App」で次に進んでみましょう。するとゴリゴリ自動的にコードが書かれていきます。最終的に以下の画面が表示されました。これがプロトタイプのようですね。身長・体重の入力欄もあります。では早速操作してみましょう。試しに適当な身長・体重を入れて（筆者の身長・体重ではありません。。）、「Calculate BMI」をクリックします。BMI値と「Normal」と表示されました。標準ということですね。100kgだと「Obese」、いわゆる肥満と表示されました。作られたファイルが右下に表示されています。「～.tsx」と「～.css」というファイル、そして設計書としての「blueprint.md」が存在しているようです。そこで青いボタン「Edit the Code」をクリックしてみましょう。すると以下のようなVS Codeチック（というかほぼVS Code？）なエディタの画面が表示されます。これもCursorのようにVS Codeをフォークして作られたものなのでしょうか。左側のツリー表示を見ると他にも色々ファイルが生成されており、１つのプロジェクトとしてプロトタイプを作成してくれました。直接コードも書き換えられるようですが、せっかくのAIですのでアプリの変更を再度Geminiに依頼してみましょう。ボタンの色を変えてみたいと思います。先ほどの画面上のボタンは緑でしたので「ボタンの色を赤にして」と入力してみます。上のようなインタラクティブなやり取りの結果、ファイルが変更されたようです。「Review Changes」を押してみます。すると以下のように変更点の差分が表示されています。そして「Update File」を押すとコード上に変更が反映されます。本当に反映されたのか試してみたいですよね。右上の小さいアイコン、「Switch to Prototyper」をクリックしてみましょう。すると先ほどの画面に戻ってボタンが赤になっていることが確認できます。生成AIではハルシネーションが起きうるということで検証を行う必要があります。そこで「テストコードを書いて」とお願いしてみます（ことごとく雑なプロンプトでスミマセン。。）すると上のような表示があり、ファイルの変更・作成があったことがわかります。一覧の一番下にある「src/tests/page.test.tsx」をクリックすると、確かにテストコードを書いてくれています。身長と体重に応じたBMI値と肥満、普通等の文字列による結果とが一致するかを検証してますね。まとめさて、とりあえずAIによるプロトタイピングを試してみましたが、この部分に関して言えば前回の記事で紹介されたCursorや他の生成AIを利用したサービスでも同じことができます。ただ、Firebase Studioでは先ほどお見せしたように作業の中でインタラクティブなやり取りがあり、まずはBlueprintを作成してユーザーに確認させたり、変更する場合でも差分を一旦ユーザーに見せるといった「ユーザーとの対話」がそこには存在しています言い方が悪いかもですが、Cursorで上と同じことをやるとユーザーの確認を待たずにどんどん作成・変更を行ってしまうため、あくまで個人的な感覚ではありますが、よりユーザーに寄り添った印象を受けます（どちらが良い悪いでは無くCursorも素晴らしいツールだと思います）。そして何よりも全てブラウザベースで完結しているため、CursorやVS Code等のエディタ自体のインストールや実行・テスト環境の準備も必要ありません。CursorでNode.jsのコードを書いて実行する場合、実行・テスト環境の準備もAIが手伝ってはくれますがその構築自体の作業・手間は必要になりますし、ローカルPCに色々な設定が必要となるため、PCの環境も汚れてしまいます。Firebase Studioであればブラウザベースなのでそういった煩わしさから全て解放されます。また、何もよりもここでは紹介できなかったものの、既存のFirebaseの各種機能も利用できるというのが一番の強みではないでしょうか。もう少し触ってみまして興味深い機能等を見つけましたらこのブログで紹介できればと思います。当社ネクストスケープは新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net （以下当社お問合せフォーム）Microsoft Forms

Firebase Studioでプロトタイピングをしてみた

Cursorを使ってみる

はじめに株式会社ネクストスケープ ソリューションビジネス部の小野塚です。RDRAに関する締めくくりの記事としてLLM（大規模言語モデル）によるRDRAを紹介したいと思います。直前の記事は以下になります。blog.nextscape.net今までの当社のRDRAに関する記事の流れをお話ししますとRDRA1.0ー＞RDRA2.0ー＞スプレッドシートを用いたRDRA。。という流れでRDRAは進化をしてきまして、それぞれの内容について私の理解も交えて説明させていただきました。そしてここ近年のAIの発展や各社・各ツールのAI導入に伴い、私が把握する限りでは2023年の6月頃から既に神崎さんもRDRA＋AIの組み合わせを使って色々取り組まれていました。私も神崎さんのオンラインセミナーを拝見して、どこかでキャッチアップできればと思っておりました。その神崎さんの成果が「RDRAZeroOne」というツールになりまして、以下のサイトで公開されています。vsa.co.jp今回はこのRDRAZeroOneの使い方・注意点等についてご紹介したいと思います。RDRAZeroOneの立ち位置、使い方そもそもRDRAの利点として、要件定義に多少不慣れな方でもRDRAのフレームワークに従えば、ある程度要件定義が可能となります。ただ、要件定義の対象となるのが「全く知らない業種・業務」になりますと、それに対する自身の勉強・キャッチアップと同時にステークホルダーの方々との打合せにおけるファシリテーションやインタビュー等でいっぱいいっぱいになり、RDRAのようなフレームワークがあったとしても、要件定義は非常に困難を極めることは容易に想像がつくと思います。もっと具体的に言えば、知識ゼロの状態ですのでステークホルダーの方々にこと細かく聞き取りをしなければならず、そうなるとお互いにストレスが溜まっていってしまいます。そこでAIの出番となります。AIを使うことで知らない業種・業務であってもある程度概要・内容を（内容の正否・精度はともかくとして）把握することができますので、それをベースにRDRAを進めていこうというものになります。ただ、ここからが注意点です。AIとそのツールも色々と進化してきまして、要件定義をサポートしてくれるものも出てきました。しかしながら今までAIを使われてきた皆様もご存じの通り、その出力内容は一般的なものであったり、内容が浅かったり、どこかしら間違っていたりしますので、そのまま受け入れることはできません。神崎さんご自身でもセミナー等で触れている通り、あくまでRDRAZeroOneは・自身の理解のための壁打ち・ステークホルダーとの打合せのための叩き台といった目的のために使用するものであることに注意が必要です。そういう意味ではRDRAは1.0より様々な進化をしてきましたが、その根本にある「要件定義のためのコミュニケーションツール」であるという考えはRDRAZeroOneでも変わっていません。RDRAZeroOneで出力された内容を元にコミュニケーションを取り、「いや、そこは違う。うちの会社にはこういう条件が存在する」「実はうちの業務ではこういうアクターが存在し、こういった作業を行う」といったその会社と求めるシステムにおける情報を取り入れ、更にRDRAを使って繰り返し内容を詰めていく。。というものになります。従ってプロンプトもこういうシステムを作りたいから要件定義を。。と丸投げするのではなく、RDRAの進め方に基づいた形でプロンプトを投げます。要件定義を丸投げするのでなく、「人がRDRAを使って要件定義を行うためのサポートをしてもらう」のが重要であり、人が考えることを放棄してはいけません。他のAIを使ったツールにも言えることですが、「AIに使われるのではなく、AIを使いこなす」ようにならないと要件定義もうまくいかないと思います。神崎さんがRDRAZeroOneのページの最初に挙げている「あなたはLLMが出力した要件定義に責任をもてますか？」というのはそういう意味だと思っています。RDRAZeroOneのサンプルではそれなりの出力内容となっていますが、実際に試してみた結果、もっともらしいことが書かれていながら全然違うということもあります。あくまで「叩き台」なので、そのあたりをちゃんとステークホルダーからヒアリングを行い、内容を見直す必要があります。これも重要なポイントです。RDRAZeroOneの使い方、作業の流れでは、RDRAZeroOneの使い方、作業の流れについて軽く説明します。まず、準備としてOpenAIもしくはGeminiのAPIキーを取得してください。以下のダイアログが表示されますので、取得したAPIを登録します。以上が準備作業で、ここからがRDRAZeroOneを使った作業です。このRDRAZeroOneですが、以下の4つの段階に分けてRDRAに必要な情報を洗い出していきます。１．文脈理解２．ビジネスアイディア３．ビジネスデザイン４．システム化検討まずは「文脈理解」ですが、ビジネスの背景、概要を入力してください。これがAIに渡すプロンプトになりますので、できればRDRAZeroOneで提供されるサンプルを参考にして書いてみてください。いつもの図書館システムになると以下のように結構色々と書かれていますが、AIモデルの進歩のおかげもあり、それほどに情報量が無くてもなかなかの出力をしてくれるようです。一通り書けましたら右端の「RUN LLM」ボタンをクリックします。すると以下のようにダイアログが表示され、そこにLLMから得られた情報が出力されます。同時に裏側のRDRAZeroOneの画面にも同じ内容が書き込まれます。そして以下のようにまずは「アクター」「外部システム」を洗い出し。。といったようにいつものRDRAの手順と同じ流れで解析を行ってくれます。残りの３つの段階においても同様に「RUN LLM」により出力が行われ、以下のようにユースケースまで出力が行われます。ちなみにRDRAZeroOneの紹介ページでも同様の注意書きがありますが、RDRA独自の言語ではLLMが理解できないため、「業務」はBUC、つまりビジネスユースケース、「仕事」はアクティビティ、「分類」は業務orコンテキストと読みかえてください。RDRAでいうところの「状態」や「情報」も出力してくれますので、ハルシネーションに気を付けさえすればRDRAの学習にも役立つかもしれません。最初に文脈理解でそれほど情報が無くてもかなりの情報が得られると書きましたが、「それなり」といえば「それなり」なのも確かです。その場合は得られた結果を元に再度文脈理解に戻ってビジネスの背景や概要を追記すればそれに応じて再度出力結果が詳細化し、解像度が上がります。これも今までのRDRAと同様「繰り返し」が肝となります。ちょっと横道にそれますが、RDRAZeroOneにおいてOpenAIとGeminiで使用しているモデルは以下になります。　OpenAIのModel：”gpt-4o-mini”　Gemini：”gemini-2.0-flash-latest”私はOpenAIで実行してみまして、4段階それぞれにRUN LLMを実行した結果、APIの呼び出しにかかった料金は0.02ドル、円レート150円とした場合3円となりました（2025年3月22日現在の情報です）。当然実際にRDRAZeroOneで叩き台レベルまで持っていくためには4回では済まず、何度も繰り返す必要はありますが、それでも十分安く実施できるのではないでしょうか。ツールとしての使い勝手の向上「LLMによって叩き台が得られる」というのはRDRAZeroOneの大きなポイントですが、もう１つ、「ツールとしての使い勝手」も非常に良いものとなっています。前回の記事で紹介した通り、スプレッドシートによるRDRAツールやRDRAGraphにより、図示が非常に楽になりました。しかしながら人間の欲には際限が無く、スプレッドシートによるRDRAももっと簡単に書けたらなと。。思った方もいらっしゃるかもしれません。RDRAZeroOneはその点も改善されています。上部メニューの「TO RDRA」をクリックします。そうするとダイアログが出た後にRDRA用スプレッドシートが開きますので、「ファイル」ー＞「コピーを作成」を選択し、新しい「書き込み可能な」スプレッドシートを開きます。そして、スプレッドシート内の「ZeroOne」シート移動し、一番右上のA1セルで貼り付けを行い、「Import」をクリックします。そうするとスプレッドシート内の他のシートにRDRAZeroOneの内容が出力されます。便利ですねー。。次に今までであればスプレッドシートの内容を元にRDRA Graphで図を出力していたのですが、今回はそれもRDRAZeroOneから１クリックで可能です。RDRAZeroOneの上部メニューから今度は「TO GRAPH」をクリックします。そうするとRDRAZeroOne内のデータを一発でRDRA Graphに出力できるのです。これでRDRAZeroOneー＞スプレッドシートー＞RDRAGraphの行き来が非常に素早く簡単にできるようになりました。神崎さんが元々RDRAに求めていた「高速にRDRAを回していく」ということがこれで更にやりやすくなったわけです。また、AIが出力した文章だけですと出力した本人でも理解しづらい場合があるため（自分が書いているわけではないので）、これをRDRA Graphで図示することにより理解が進むというメリットもあります。先にお話しした通り、AI及びAIを使ったツールを「使いこなす」ことによって時間に余裕ができ、その時間を使ってより良いものを生み出す。RDRAZeroOneを使って生まれた余裕・時間を有効活用し、ステークホルダーの方々ともっとコミュニケーションを取ったり、思考する時間に費やすべきです。当社に限らず皆さんにおいてもRDRAのフレームワークやツールを用いることで、よりベターな要件定義ができればと思います。最後に繰り返しになってしまいますが、RDRAZeroOneによって作られた内容はあくまで叩き台となります。これによって得られたユースケース等は実際の業務・システムに完全に合致しているわけでありませんので、ステークホルダーの方々とRDRAを使って要件定義を進めていくことになります。RDRAZeroOneを使ってその名の通り０から１へ、更にRDRAを使って１から１００へと近づけていくというのが私の理解です。色々と偉そうなことを語ってしまいましたが、私の記事は私の考えに基づく部分が大きいこともあり、RDRAについて詳しく知りたい方は神崎さんの書籍『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』や、神崎さんのセミナー等を受けてみてください。https://vsa.co.jp/img/service.pdf(↑神崎さんの会社、バリューソースのサービス一覧)vsa.co.jp神崎さんもXでこれまでの当社のRDRAに関する記事をツイートいただきました。この場でお礼を申し上げます。当社ネクストスケープは新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

LLMによるRDRA　RDRAZeroOneの紹介

初めに株式会社ネクストスケープ ソリューションビジネス部の小野塚です。今回もRDRAの記事となります。これで第3回目となります。1回目が以下の記事で、ざっくり概要を説明させていただきました。blog.nextscape.net2回目が以下になりまして、バージョンによる違いは何かを私の考え交えて記述しました。blog.nextscape.netさて、今までの記事においてはRDRAは幾つかの図＝モデルを書くことで要件定義を進める方法でした。そして、1.0から2.0になって不要なモデルも無くし、より簡略化・洗練されてきた。。というのがここまでの流れです。しかしながら、RDRA2.0であってもそれなりの規模のプロジェクトになってしまうとアクターを初めとした各要素の数が非常に多くなり、関連を表す線が蜘蛛の巣のように入り乱れる形となり、少々見づらくなることがありました。そこで一昨年～昨年頃から神崎さんが考えられたのがGoogleスプレッドシートを用いたRDRAになります。RDRA2.0では表形式、一覧で表せるものは一覧で表そうという考えがありましたが、これを更にRDRA全体に適用したものがこのGoogleスプレッドシートによるRDRAです。まずは以下のリンクでRDRA用スプレッドシートを開いてみてください。2.RDRA定義分析_V1.0 - Google スプレッドシートこれはRDRAを考えた神崎さんが作成されたもので、閲覧のみ可能な所謂テンプレート的なファイルですので、メニューバーの「ファイル」から「コピーを作成」を選択し、自身のGoogleスプレッドシートにコピーします（Googleアカウントが必要になりますのでご注意ください）そして、改めてこのファイルを見ると色々なシートがありますのでそれぞれについて触れていきたいと思います。表形式によるRDRA 概要ファイル名に「V1.0」とありますが、実は先日2月15日にバージョンアップされまして、それまでは0.98が最新でした。今まではRDRA定義とRDRA分析ということで別々のスプレッドシートになっていたのですが、V1.0で統合された形となります。今までのダイアグラム形式でのRDRAは「パッと見の」わかりやすさや自由度において秀でた点がありましたが、この表形式のRDRAではスピード感を重視しています。RDRAというのは各RDRAレイヤーにおける各要素同士の「関連」を確認することがポイントであり、ダイアグラム形式では線で結ぶことで関連を明らかにしていましたが、表形式では同じ行に並べることで関連を表すようにしています。また、モデル間では名前で関連付けていましたが、表形式でも（シート間の）名前で関連付けています。今回は実際に今までのRDRAで用いられてきた図書館システムのサンプルデータを入れつつ各シートの内容をご紹介できればと思います。「アクター」等、RDRAで使われる用語の説明であったり、こういった要素を挙げてどうするの？といったRDRAの基本的な内容については割愛させていただきますので、そのあたりは神崎さんのセミナーや著書、そして私の記事等をご覧ください。「アクター」シート・「外部システム」シートまずはRDRAにおける最初のモデル、「システムコンテキスト」ですが、これは要件定義の対象となるシステムに関連するアクターと外部システムを以下のような図で表したものになります。※本記事でのRDRAモデルについては以下の神崎さんの書籍からダウンロードできるパワーポイント資料から抜粋もしくは利用させていただきましたhttps://www.amazon.co.jp/dp/B07STQZFBX『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』表形式では「アクター」シート、「外部システム」シートがありますので、それぞれにアクター、外部システムを挙げていきます。まずは「アクター」シート。過去の記事やRDRAの書籍で例に挙げられていた図書館のシステムでは図書館を利用する「会員」と、図書館員である「図書館員」と「司書」の３つのアクターが挙げられますので上のようになります。アクター群はアクターをまとめるグループ名です。次に「外部システム」シートでは今回のシステムに関連する外部システムを挙げます。外部システム群はアクター同様、グループ名です。上で書いた通り、RDRAでは他のモデルとの関連は名前で結びつけるようにしていますが、「モデル間」が「シート間」に代わるだけですので名前は統一させるようにしてください。このようにスプレッドシート上に羅列していくだけですのでこれだけでも図に書くよりも素早く定義できることがわかると思います。要求モデルとしての「機能要求」・「非機能要求」シート次にRDRAでは要求モデルを記述するわけですが（以下の図がそれです）、表形式では「機能要求」「非機能要求」シートがあるのでここで挙げていきます。これもダイアグラム形式で書くのとあまり変わらないため、違和感も無さそうですね。ビジネスコンテキスト図・ビジネスユースケース図次に「業務」と「ビジネスユースケース」を洗い出していきますが、RDRAのモデルでは「ビジネスコンテキスト図」「ビジネスユースケース図」がこれにあたります。まずは「BUC」シートのA列が業務に該当しますので挙げていきます。図書業務の例ですと「貸出・返却」「会員管理」「蔵書管理」となります。そして各業務に関してビジネスユースケース図を書いていきます。以下は「会員管理」業務の例です。この図は「BUC」シートで表しますのでA列に「業務」、B列に「BUC」を入力し、更に「関連モデル２」列に「アクター」を設定し、「関連オブジェクト２」列に具体的なアクターの名前を入力します。※上のスクリーンショットでは途中に存在する列を非表示にしていますのでご注意くださいユースケース複合図としての「BUC」シート神崎さんのRDRAのサイトではこの後は「情報と状態の洗い出し」ー＞「アクティビティ、UC、アクター、外部システムの洗い出し」ー＞「UCに情報・画面・イベントを繋げる」ー＞「条件とバリエーションの洗い出し」といった流れになりますが、私としては「アクティビティ、UC、アクター、外部システムの洗い出し」ー＞「UCに情報・画面・イベントを繋げる」。。の順番の方がやりやすかったです。ただ、ダイアグラム形式のRDRAと同様、繰り返し見直すことになりますので順番はあまり重要ではないという理解です。プロジェクトの性質・内容やステークホルダーの方々の知見によってどの順番が洗い出しやすいかも変わってくるかと思いますので、実際にやってみて最終的に抜け漏れが発生しなければOKです。「BUC」シート　ー　アクティビティ次に各BUCに紐づくアクティビティを挙げていきます。私だけかもしれませんが、後述のユースケースとアクティビティがごっちゃになりがちです。そのあたりは今までのRDRAの手順と同様、繰り返し見直すことで修正していきます。「BUC」シート　ー　情報、状態次に同じく「BUC」シートに情報を書いていきます。例えば図書館システムであれば「貸し出されている本」「蔵書情報」「予約されている本」といったところです。前回の記事でも書いた通り、本であればタイトルや作者等、様々な情報があるかと思いますが、RDRAではそこまで細かく上げることはせず、上で挙げたようにある程度まとまった括りで列挙していきます。「BUC」シート　ー　ユースケース次に「F」列にUC、ユースケースを書いていきます。RDRAでのユースケースは「要件定義の対象となるシステムを利用する作業」になります。ですのでビジネスユースケースの「貸出フロー」のアクティビティの１つに「蔵書を貸出す」というものがあった場合、そのユースケースは（システムを使って）「蔵書の貸出を登録する」というものになります。「BUC」シート　ー　画面次に各ユースケースに対応する画面を挙げていきます。画面名称をここで深く考えてもしょうがないので、ユースケースをそのまま画面名にするという考えで良いと思います。例えば上の例のように「蔵書の貸出を登録する」ユースケースであれば画面名は「貸出登録画面」といった形です。変に名前を凝ってしまうと何をする画面かわからなくなってしまうので。。今までの流れですと「情報」を挙げて、その後「画面」を、となるのですが、個人的には画面を先に挙げて、「その画面で扱う」情報を考えていく方が情報を挙げやすいような気もしているのですが、それは私がエンジニアでシステム寄りに考えてしまうからかもしれません。例えば上の内容であれば、「蔵書を貸出す」アクティビティで「貸出登録画面」（「貸出画面」の方がわかりやすいかも）を挙げ、その画面で表示・もしくは変更されるべき情報は「貸出図書情報」、「蔵書情報」、「貸出予約情報」があるよね。。といったように考えていくのではないかと思います。とはいえ、それはある程度想像がつくシステムだからだと思いますし、結局は抜け漏れが無ければよいわけです。途中にも書きましたが、繰り返し見直して追加・変更・削除を繰り返すところは今までのRDRAと変わりませんので、自身と各ステークホルダーの中で話し合いつつ、順番はあまり気にせずにとにかく必要と思われる情報を挙げていくという気構えで良いのではと思っています。アクター、外部システムとの連携次に「アクター」シート及び「外部システム」シートに挙げたアクター、外部システムと、それに関連する「H」列の関連オブジェクトを探し、BUCシートの「I」列に書いていきます。これでRDRAのビジネスコンテキスト、システムコンテキスト、ビジネスユースケースが網羅できることになります。「条件」シート次に「条件」シートです。図書館システムであれば貸出期限といった条件をこのシートで挙げていきます。そしてここで挙げた条件が「BUC」シートのどのユースケースに使われるか確認し、以下のように「BUC」シートの「G」及び「H」列に追記していきます。「バリエーション」シートあとは「バリエーション」シート、例えば会員であれば大人と子供の２種類存在するのであれば以下のように記述します。「状態」シート次に「状態」シート。状態遷移が発生する要素をここで挙げておきます。遷移先と遷移元、そして遷移のトリガーとなるユースケースをこのシートに記述します。「情報」シート「BUC」シートに挙げた情報もこちらの「情報」シートにまとめるようにしてください。先ほどの「バリエーション」と「状態」はこの「情報」に紐づくはずなので、このシートでその関連性を記述するようにします。「不整合」シートそして今回のスプレッドシートによるRDRAのポイントの１つとなるのが「不整合」シートです。今までのRDRAと今回のスプレッドシートにを用いたRDRAの違いとしては各モデルで図として表していた内容をスプレッドシートに落とし込んでいくというものになります。そして、スプレッドシートに変えることで数多くの情報を一覧として見れたり、手軽に書けたりといったメリットがありました。しかしながらそれ以外にももう幾つかこのスプレッドシートによるRDRAのメリットがありまして、その１つが「不整合」シートになります。RDRAでは各モデルとの関連性を確認し、関連が存在しない要素が存在する場合はそれが不要な要素であったり、もしくは存在すべき（関連すべき）要素が別にあるということで見直しの対象となります。ただ、要素が増えれば増えるほど各モデルにおける要素の関連性の有無が見つけ出しにくくなるという問題がありまして、これを解消するのがこのシートになります。つまり、もしそういった関連性が無い要素があればこのシート上にそれを表示してくれるのです。例えばアクター。下の「不整合」シートのスクショでは何も表示されていません。つまり、全てのアクターが関連付けされていることになります。次にあえて「アクター」シートから「司書」を削除してみましょう。この「司書」というアクターは「BUC」シートには記載されています。そうすると以下のように「司書」が「不整合」シートに表示されます。他の要素についてもこういった形で表示され、関連の有無をここで確認できるわけです。「RDRA Graph」との連携そしてもう１つのポイントが「RDRA Graph」という、これも神崎さんが作られたツールですが、このツールにスプレッドシートで作成したデータを投入することで図として表現できるというものです。まずは「関連データ」シートを開き、そのシートの右側に書かれた指示に従って特定の範囲のデータをコピーします。そして、以下のリンクをクリックし、RDRA Graphを開きます。vsa.co.jpRDRA Graphの上部メニューからDATAー＞Import Dataを選択します。以下のようなダイアログが表示されるのでその中に上でコピーしたデータを貼り付けて「取込」ボタンを押します。すると以下のように入力データがRDRAのモデルとして表現されます。以下の図の「貸出・返却」をクリックしてみましょう。以下のように「貸出・返却」のビジネスユースケース図が開きます。更にビジネスユースケースの「貸出フロー」をクリックすると以下のように「貸出フロー」に紐づくアクティビティやユースケース、そしてそれらに紐づくアクターや情報・条件が、RDRAモデルでいうところのユースケース複合図として表示されます。スプレッドシートにすることで図として表すことをあきらめたわけではなく、別ツールを用意することで簡単に図示することもできるようにしたわけです。また、最初に書いたように要素が多くなるとRDRA2.0でも見づらくなってしまいますが、RDRAGraphは単純に図示するだけでなく、上位階層同士の関係のみを表現することもでき、それにより全体を俯瞰できるようにもしています。RDRAは要件定義のための優れたツールだと思うのですが、RDRAの各モデルを書くにあたって、神崎さんは図を書くためのツールとしてEnterprise Architectやパワーポイントを挙げていました。またそのためのプラグイン等も提供いただいています。ただ、それでも利用することにややハードルの高さを感じる方もいたかと思います。特にEnterprise Architectは操作に多少慣れも必要になりますので。更にEnterprise Architectもパワーポイントも有料ですが、Googleスプレッドシートは無料です。そしてRDRA Graphも無料で利用できます。このスプレッドシートとRDRA Graphを使う方法であればその最初のハードルが非常に低くなり、より簡単にRDRAを導入できると思います。ただ、要件定義の初期の段階ほどダイアグラム形式の方が複数のステークホルダーが集まって話し合う場合にわかりやすいと思うので、１．最初の段階はEAやPowerPointで図を書く２．ある程度のところまで話が進んだらそれをスプレッドシートに落としてそれ以降はスプレッドシートで進める３．スプレッドシートとRDRA Graphとを行き来しつつまとめていくという流れであったり、あるいは最後までRDRA Graphに頼らずに各種モデルを自ら書いていく。。という方法でも全然良いと思います。神崎さんはそれを禁止しているわけではありませんので。終わりに今回の記事はここまでとします。RDRA2.0から更に進化し（記述方法が変わっただけなのでバージョンは2.0のままのようですが）、扱いやすいものとなりました。ダイアグラム形式は「わかりやすさ」に重点を置き、表形式は「視認性の良さ」「書きやすさ」というところに重点を置いたものだと考えていますので是非皆さんのやりやすい方法で取り入れてみてもらえればと思います。さて、これだけでも十分素晴らしい進化だと思うのですが、神崎さんは昨年夏からこのRDRAを更に進化させており、私もキャッチアップしているところです。近々その成果をアウトプットしたいと思います。今までの記事でも紹介させていただきましたが、RDRAについて詳しく知りたい方は最初に挙げた書籍『RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法』や、神崎さんのセミナー等を受けてみてください。https://vsa.co.jp/img/service.pdf(↑神崎さんの会社、バリューソースのサービス一覧)vsa.co.jp当社ネクストスケープは新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

スプレッドシートによるRDRA・RDRA Graphの紹介

はじめに株式会社ネクストスケープ ソリューションビジネス部の小野塚です。前回の私の記事ではRDRAという要件定義のフレームワークについて、その概要を紹介させていただきました。blog.nextscape.netこのRDRAを私が最初に知った時のバージョンは1.0でした。以下の著書で2.0に進化していたので改めて内容を確認し、それをアウトプットするのが目的だったのですが、前回はそこまで辿り着けませんでしたので、今回は1.0と2.0の違いについて言及したいと思います。Amazon.co.jp: RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法 eBook : 神崎善司: KindleストアRDRA1.0と2.0の違いとしては以下の３つが挙げられていまして、今回はそれらの違いについて私の考えも交えつつ紹介できればと思います。ダイアグラムのシンプル化業務フロー、利用シーンを洗い出す方法の明示ビジネスルールの記述方法の明示前回同様、本記事では私の考えや意見も含まれておりますのであらかじめご了承ください。モデル数の削減一番の違いはこのモデル数の削減に尽きるのではないでしょうか。神崎さんも自著で触れられており、更に当社でRDRAを利用するメンバーにおいても同様の意見があったのですが、モデル（＝図の種類）が多く存在していたためにそれらを作ることが目的となってしまいがちであったり、それらを更新し続けることが負担となっている場合がありました。例えばAというアクターが必要だったと気づいた場合に複数のモデルにそれを追加して。。ということになり、モデルの数が多いために修正・メンテナンスの手間も増えてしまうという問題がありました。今までの神崎さんの経験やRDRAを使っている方のご意見を元に、使わないモデルはRDRAから外し、一覧で済ませるものは一覧で済ますことでモデルの数が減りました。これにより元々神崎さんが目指していた「軽く、最速で要件定義を行うための手法」に立ち返ることができたのではと思います。関連性の確認がより容易に行えるようになったRDRAの要件定義の進め方として、・要求モデルと利用シーンが繋がっているか　⇒・利用シーンがユースケースと繋がっているか　⇒・更にユースケースとイベントモデルが繋がっているかといった形で各レイヤー・各モデルにおける要素の関連性を確認する必要があるため、モデルの数が多いとその確認の手間が増えたり、確認しづらくなるという問題がありました。そこでRDRA2.0での大きな変化として「ユースケース複合図」というのが用意されました。そう書いてしまうと「モデルをせっかく減らしたのに新しいモデルを作ったのか」と思われそうですが、そうではなくて複数のモデルをまとめた形になります。例えば前回も例として挙げた図書館システム、その中の貸出業務のユースケース複合図は以下になります。アイコンの図柄でなんとなくおわかりかと思いますが、凡例も一応挙げておきますRDRA1.0では画面やユースケースはそれぞれ画面モデル、ユースケースモデルとして、画面だけ、もしくはユースケースだけでまとめられていましたが、そうなるとそれぞれの図を見返さないと要素の有無であったり関連性がわかりませんでした。RDRA2.0では上の図のようにユースケース複合図として様々な要素を1つの図の中に書き表すことで一目で関連性がわかるようになり、メンテナンスもしやすくなりました。上の例には含まれていませんが、「イベント」も以前はイベントモデルとしてひとまとめだったのですが、ユースケース複合図に記述するようになっています。「業務フローモデル」というモデルはRDRA1.0から存在しているのですが、規模や複雑度が小さければ「ユースケース複合図、業務フロー、利用シーン付き」ということで業務フローも含めることも良しとしています。そうすることで本来別モデルとして記述される業務フローも1つの図の中で眺めることができるようになったわけです。画面モデルの除外上で挙げた通り、RDRA2.0では外された、もしくは簡略化されたモデルが幾つかあります。その中に「画面モデル」、「データモデル」というのがありました。画面モデルはどういったものかといいますと、画面の要素をクラス図のように表現する方法です。例えば、ログイン画面を表す場合、以下のように描きます。更にもう１つ区切りを設けてボタンや入力エリアといった画面そのものの構成要素を書く場合もあります。要件定義レベルでこういった形で画面(名)だけでなく、それが持つ細かい情報についても挙げておくことで設計フェーズに移行しやすいというメリットもあったと思うのですが、RDRAの考えである「要件定義ではWhyを追求すべきであり、Howを追求すべきではない」という考えから外されているようです。また、それなりのシステム規模になってしまうと画面や情報量も膨大になりますので、このレベルまで書き込んでしまうとメンテナンスがどうしても困難になってしまいます。そういう意味では今回の変更は当然の流れと言えます。ただ、RDRA2.0で外された他のモデルにも言えるのですが、神崎さんはこれらをRDRA2.0で扱わなくなっただけで「禁止」はしていません。つまり、RDRA2.0に補足する形で皆さんが必要であると考えるのであれば、一覧としてExcel等に記述するか、引き続き「そのモデルに関しては」1.0のフォーマットのまま利用していけばよいのかなと思っています。ただ、2.0でそれらのモデルを外した理由である「モデルを書くことが目的にならないように」かつ、要件定義のスピード感が失われないように留意する必要がありますが。。それはそれとしましてRDRA2.0ではユースケース複合図で画面名称のみ記述するようにし、別々のモデルだった時よりも各要素との関連を把握しやすくなりました。特に既存システムの解析においては画面が最も把握しやすく、「誰がそれを操作するか」であったり（アクター把握）、画面上の項目からシステムが扱う情報もわかりますので、画面を軸にして各モデルを書いていくとやりやすいかもしれません。より「Why」にフォーカスを当てる軽量化・高速化を目指し、「Why」を突き詰める。そのために変更したのは画面だけではありません。データモデルというものがRDRA1.0には存在し、顧客情報であれば「顧客名」「性別」といった情報を先ほどの画面モデルとほぼ同じフォーマットで記載するようにしていましたが、これもより「Why」にフォーカスを当てるために外されました。では、そういったデータはどういった形で扱うようにしているのか。例えばもう１度先ほどのユースケース複合図を例に挙げてみます。この図のうち、ノートとペンのアイコンが「情報」を表していまして、貸出図書蔵書といったものがそれに該当します。これらは「本」であるため「タイトル」「種別」「ISBNコード」等といった情報が本来であれば含まれているわけですが、RDRA2.0の要件定義においてはそのレベルまでは深堀りせず、「貸出図書」情報、「蔵書」情報といったレベルに留めています。我々エンジニアであればその後の設計・実装のためにタイトルやISBNコードといった細部のデータまで要件定義の段階で考えてしまうのですが、そこまで細分化・詳細化してしまうと「How」に踏み込んでしまう恐れがあります。あくまで「現場で使われている」情報を扱うというのが重要になりますのでざっくり「～情報」というくくりで捉え、扱うようにします。とにかく「How」ではなく「Why」を考える。そして、RDRAをより軽量にし、「最速」で要件定義を行うための思想がここにも表れていると思います。ビジネスルールの記述方法の明示現場で実際に使っている条件や規則、制約については「ビジネスルール」として、RDRAモデル内に記述するようにします。これもあまり複雑なものではなく、「バリエーション」もしくは「条件」として表形式でまとめるだけです。例えば遊園地の料金を例に挙げると以下のようになりまして、これをユースケース複合図に含めたり、別資料として他の条件・バリエーションとまとめて記述したりしています。そのままと言えばそのままなのですが、こういった形にすることで「誰でも、より簡単に書ける」・「わかりやすい」表現ができるようになりました。この「ビジネスルール」ですが、「システムの」条件や規則・制約ではなく、「現場における」条件、規則であることに注意が必要です。あくまでシステムを使うのは現場の人たちであり、システムを取り巻く環境を表すのがRDRAだからです。このビジネスルールは最初の記事に挙げた４つのレイヤーのうち、システム外部環境もしくはシステム境界に位置するものになります。RDRAで使われるツールRDRAはつながりを重要視するツールであるため、それを可視化することが重要となります。そのため、RDRAに必要なツールとしては元々Enterprise Architect（以下EA）というダイアグラムツールが1.0の頃から推奨されていました。RDRA用のテンプレートも提供されています。RDRA2.0でもEAが取り上げられていますが、今回新たにPowerPointもツールの１つとして紹介されています。最初に挙げた神崎さんのRDRA2.0の著書の中でPowerPointのテンプレートやサンプルがダウンロードできるURLが記載されていますので、興味のある方は購入してダウンロードしてみてください。RDRA2.0で要件定義を行うにあたり、このPowerPoint内で使われているアイコンでなければならないわけでは無いのですが、わざわざ一から探すよりは非常に便利だと思います。マクロを使うことでExcelへの出力や関連が存在するかどうかのチェックも行ってくれます。上で挙げたユースケース複合図もこのテンプレートから抜粋させていただきました。最後に以上の通り、RDRA2.0になってモデルを書くことのハードルが下がり、より使いやすく、かつ洗練されたイメージがあります。前回の記事でも書きましたが、あくまでRDRAはコミュニケーションツールであり、システム化しなくてはいけないものは何かを明らかにするための手法です。画面等をモデルとして別々に書くのではなく、ユースケースと組み合わせてそれがどう関連しているか、元々の思想として存在する「システムを取り巻く様々な情報を含めてまとめ上げる」というところをより重要視かつ、視覚化しやすくなりました。コミュニケーションツールであることはその書き方にも表れており、RDRA1.0ではUMLに準拠した書き方が多かったイメージがあるのですが、2.0ではUMLの書き方にあまりとらわれていません。例えば、要素同士の関係性を示す「線」についても以前は矢印付きで方向を示すことが多かったのですが、現在は状態モデル等のように方向が重要な意味を持つ図以外は基本的に矢印等も無い単なる線で関連を表しています。UMLには「集約」を表す線等、幾つかの種類があるのですが、UMLを知らない人達にとってはその意味がわかりませんので。。コミュニケーションツールとして扱うためにみんなが理解し、合意を得られるということが重要なのであり、図の書き方が重要なのではないというのが神崎さんの伝えたいところなのではないかと勝手に思っております。さて、RDRAは2.0へのバージョンアップを経て、更にここ1～2年、特に昨年においてRDRAは更に大きく進化を遂げ、扱いやすくなりました。次回の記事でそのあたりについて触れてみたいと思います。前回の記事も含め、あくまで私のRDRAの記事は私の理解と併せての説明となりますので間違っている部分もあるかもしれません。興味のある方は是非神崎さんの著書を読んだり、セミナーを受けてみてください。余談ではありますが、私や他の同僚はRDRAでがっつりと要件定義を行う必要の無い案件であっても「最低でも」基本となるコンテキスト図だけは作成してアクターや外部システム等をざっくりでもいいので書き表し、お客様との認識合わせを行うようにすることがあります。つまり、格好よく言えば「守・破・離」的な考えでプロジェクトや状況に応じてRDRAの一部だけを取り入れたりと臨機応変に利用しています。当社は新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

RDRAを使った要件定義その２　RDRA1.0と2.0の違い

初めに株式会社ネクストスケープ ソリューションビジネス部の小野塚です。当社が要件定義のツール、フレームワークとして利用しているものとしてRDRAがあります。このRDRA、こちらは株式会社バリューソースの代表、神崎善司さんという方が考えたものでして、このフレームワークに従って要件定義を行うことで誰でもある程度のレベル・粒度で資料を作成することができます。私自身がこのRDRAを知ったのが2014年頃なのですが、そこから更に色々と進化をしておりまして、改めて過去の理解が合っているかを見直し、現在の内容にキャッチアップすると共に多少私の考えや意見も交えてご紹介できればと思います。RDRAの概要・バージョンRDRAは以下の書籍を元に学びましたが、これがバージョンとしては1.0となるそうです。『モデルベース要件定義テクニック』https://www.amazon.co.jp/dp/4798039446そして現在は2.0にバージョンアップされています。RDRAはシステムそのものだけに目を向けず、「システムを取り巻く」様々な情報を含めてまとめ上げることを目的としています。そのための視点として以下の４つがあります。システム価値：システム化する目的や価値を明らかにし、要求を元にシステム化のゴールを共有しますシステム外部環境：システムがどのように使われるのかを明らかにするために、仕事の流れや場面として業務を明示しますシステム境界：システムとの接点となる入出力を明らかにしますシステム：ビジネスを駆動する用語を使ってシステム化したい情報と状態を明らかにしますこの４つが「RDRAレイヤー」と言われるものであり、この考えだけでも「システム」があくまで視点の１つであることがおわかりになるかと思います。RDRAの意義・思想システムを作るのに何故システムだけ見ていては駄目なのか。例えば機能１つとってみても、皆さんが今使われている、あるいは作っているシステムで、「この機能使っていない。。」とか、「この機能いらないんじゃ。。」といった機能は無いでしょうか。その機能はそれなりに期間やコストをかけて作成したのに関わらず。。です。そういったこともRDRAを使うことで防げるかもしれません。もう少しRDRAレイヤーについて説明することでその理由に答えたいと思います。以下がRDRAレイヤーと概要を表した図になります。例えば神崎さんの著書でも具体例として挙げられている図書館のシステムを例に挙げると、アクター：図書会員要求：借りたい本をWebで予約したいビジネスユースケース：Web予約画面：Web予約画面Web予約の状態：未予約、予約中等といった形になり、それぞれが右から左へ「Why」で繋がっています。・「未予約」や「予約済み」といった各状態は「何」によって変化するのか（or 「なぜ」変化するのか）⇒予約画面が存在するから・「なぜ」予約画面が存在するのか（必要なのか）⇒Web予約のビジネスユースケースが存在するから・「なぜ」Web予約のビジネスユースケースが存在するのか⇒Web予約が必要とされているから・Web予約という作業は「誰が」行うのか⇒図書会員といった形でWhy（Who、Whatもありますが、それもWhyに含めます）による依存・関連があります。この依存・関連が存在しないものについては「そもそもそれが不要なのかもしれない」、もしくは「何か関連する要素が抜けている」ということで見直しを行い、それを繰り返すことで最終的に要件定義が完了します。もう少しまとめますと、作業としては以下の流れを繰り返すことになります。まずはどのRDRAレイヤーからでもよいのでどんどん要素を挙げていく一通り挙げ終わったら関連性を確認・見直す関連していないものあれば要・不要や、それと紐づく要素が抜けていないかを検討するそして、抜け漏れを防ぐために極力関係者全員で行うということも重要です。RDRAはそもそもがコミュニケーションツールであり、お客様も含め全員でRDRAを用いてコミュニケーションを取ることで、もし設計フェーズ以降で機能追加・機能拡張が発生した場合は元々要件として存在していたのかどうかというのがRDRAによって確認できる可能性があります（「プロジェクトあるある」ですが、こういった問題は「確認できる」と断言できるほど単純なものではないのであえて「可能性がある」という表現に留めました）。注意点として、もし私が主導でRDRAを実施する場合、ファシリテーターは私になり、更にRDRAの各モデルを記述するのも私になると考えるのが妥当ではありますが、１人でこれを全て行うのは少々負担が大きいため、書記は別の人、つまり自身のチームの誰かにやってもらう形が望ましいです。そして上の流れを繰り返することで例えば他との関連が存在しない業務フローやビジネスユースケース、画面といったものが出てくると思います。そもそもアクターがどれとも関連が無く宙に浮いていることもあるかもしれません。そこが見直すべき箇所となります。実際はその宙に浮いている要素と関連する要素が存在するはずで、単に思いついていないかもしれませんし、もしかするとそもそも不要な（そのシステムとは完全に無関係な）要素であるかもしれません。RDRAは既存のシステムの把握・解析にも利用できますが、もし使われていない機能や画面があればそれは他の要素と関連の無い要素として浮かび上がるわけです。ちなみに要件定義の場合、RDRAレイヤーを左から右へと進めていく形になりますが、既存のシステムの場合は画面や情報ありきになりますので右から左へと進めていくことになるかと思います。ただし、それがルールではないので通常の要件定義も画面から思いつく場合はあるかと思いますし、それはそれで問題ありません。大事なのは最終的に必要な要素が全て洗い出せ、それぞれに関連性があることです。ここまでの抑えるべきポイントとしては以下になります。RDRAはHowではなくWhyを確認するためのものであること（Howは設計フェーズ以降で決めるものになります）RDRAはコミュニケーションツールであること一度に完璧を目指すのではなく、手順を繰り返すことで完成に近づける（アジャイル的な感じですね）最後に「さわり」だけでも結構な量になってしまいましたので続きはまた別途ということで一旦記事を終えたいと思います。最後にややRDRAそのものの話とやや外れるかもしれませんが、経験に基づく注意点をお伝えしておきます。上でも記述しましたし、神崎さんも著書で書かれていますが、RDRAは要件定義の結果を記述したドキュメントとして扱うというよりは、あくまで「コミュニケーションツール」として活用することを勧めています。例えば、要件定義の最終成果物としてWordベースの要件定義書やExcelでの機能一覧を想定している場合は、当然ながらRDRAでの作成物は成果物としてみなされず、別途要件定義書や機能一覧等の資料を作成する必要があります。それらの資料のベースというのはRDRAで作成した各モデル・各図になりますので、単に表現を変えただけではあるのですが、何を成果物とするかは各ステークホルダーと確認しておく必要があるかと思いますのでご注意ください。この後も何回かRDRAについて語らさせていただくかもしれません。ただ、あくまで私の理解になりますので、興味のある方は是非神崎さんの書籍を読んだり、セミナーを受けてみてください。当社は新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

RDRAを使った要件定義　概要

株式会社ネクストスケープ ソリューションビジネス部の小野塚です。本日は2025年2月10日、その3日前である2月7日にVS Codeの1.97がリリースされました。新しい機能としてCopilot Next Edit Suggestions（Copilot NES）がプレビューとしてリリースされましたので速報的に軽く試してみた内容を書いておきたいと思います。まずはバージョン確認とアップデートからということで、私のVS Codeのバージョンを確認してみますと1.96.2となっています。上部メニューからHelp→Restart to Updateを選択します。するとその名前通り再起動と共にアップデートが実施されます。再起動した直後。最新バージョンの1.97のRelease Noteが表示されています。次に設定でこのCopilot NESを有効にします。左下の歯車アイコンから「Settings」を選択して設定画面を開き。。設定画面よりCopilot NESを探します。正確には「GitHub Copilot」ではなく「GitHub Copilot Chat」にこのCopilot NESの設定があるのでこれにチェックを付けます。画面上部の検索バーから「github.copilot.nextEditSuggestions.enabled」で検索してもらってもいいと思います。ここでは省略しますが、事前に拡張機能であるGitHub Copilotをインストールしておく必要がありますのでご注意ください。では。早速試してみましょう。例えば以下のようなコードがあった場合に。。「let status」を「let playerStatus」に変更するとCopilotが次に変更すべきであろう処理・箇所を予測し、提案してくれます。以下のようにCopilotが提案した箇所には左側に矢印が表示され、具体的な変更内容がエディター内に表示されています。エンジニアの方々には説明するまでもないかもですが、playerStatusに変更したのでその後でこの変数を使っている箇所も変更するように促されているわけです。ここで矢印の部分をクリックすると以下のような表示になります（ここだけコードが別の内容になっていますがご容赦を。。）。Tabキーを押すことで提案内容が適用され、Escキーで却下となります。Tabキーを押してみると提案した内容が反映され、更に次に修正すべき内容が提案されます。上のようなピンポイントの提案だけでなく、以下のようなgetHelloモジュールを書き終わった後も。。以下のように新しいモジュールを丸々提案してくれます。「getHello」だから「getGreeting」、挨拶繋がりということですね。何回か試したところ「getGoodbye」というのも提案してくれました（それが私が求めているものかはともかくとして。。）。以上のようにCopilotが予測する形で編集の支援を行ってくれるのがCopilot NESになります。１行だけではなく、モジュールごと丸々提案してくれ、既存のオートコンプリート、コード補完機能からCopilotによって更に一歩進んだものと言えるかなと思います。個人的には、VS Codeの「フォルダーを開く」からプロジェクト全体を展開した場合にファイルをまたがって編集箇所を提示してくれることを期待したのですが、それはできないようです。これからできるようになるのかどうなのか。Release Noteでも「急速に進化しており。。」と書かれていますし、まだプレビューの機能ということもありますので、GAに至るまで更に進化していくと思います。当社は新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。www.nextscape.net（以下当社お問合せフォーム）Microsoft Forms

Copilot Next Edit Suggestions（Copilot NES）を触ってみた

はじめに株式会社ネクストスケープ ソリューションビジネス部の小野塚です。以前の記事でNestJS学び始めとして記事を書きました。今回はその続きとなります。blog.nextscape.net前回はNestJSの概要説明の目的もありましたのでローカル環境のブラウザにHello Worldを表示しただけで終了してしまいましたが、サーバーサイドの言語を紹介している以上、ローカルで動かしているだけでは意味は無く、サーバー、私の場合はAzureにデプロイすることを目指してみたいと思います。事前調査VMであれば上の記事がある程度そのまま流用できるので何の問題も無いのですが、できればPaaSであるAzure AppServices、もしくはAzure Functionsにインストールしたいところです。そこで調べてみたところ、NestJSが流行り始めたであろう2019～2020年頃に幾つか記事が書かれていました。どちらも私がやりたいことそのままなタイトルです。zenn.devqiita.comこれらの記事では以下の「azure-func-http」というモジュールが使われており、このモジュールを組み込んでFunctionsにデプロイすれば動作する。というものになります。github.comただこのモジュール、最新のNestJS環境には対応していないらしく、実行時にエラーが発生してしまいます。このモジュールから派生した別のAzure Functions対応のモジュールも見つけたのですが、これもうまくいきませんでした。ちなみにAWSではLambdaで動作することはわかっており、なおさらFunctionsで動かしたくなりました。上のモジュールはGitHubで公開されていることもあり、私がNestJSを知り尽くしているのであれば上記のモジュールを修正して。。ということもできるかもしれませんが、残念ながらそこまでの知識は無いため、別の方法を探してみた結果がこれから説明するコンテナを用いたデプロイとなります。コンテナを利用したデプロイ方法事前準備としてDocker Desktopをインストールする必要があります。それが終わりましたらいよいよ作業開始です。まずはAzure CLIでリソースグループを作成します。az group create --name myResourceGroup --location japaneast上のコマンドのうち、「myResourceGroup」がリソースグループ名になりますので好きな名前を設定してください。あとは「--location」の後にはリージョンを設定します。今回は「japaneast」、つまり東日本リージョンを設定してますが、これも好みのリージョンを設定してください。次にNestJSプロジェクトを「ローカル上に」作成します。 NestJS CLIのインストールも行っていますが、不要であれば「nest new」から実行してください。npm install -g @nestjs/clinest new my-nest-app無事作成できたら、そのプロジェクトのディレクトリに移動します。cd my-nest-app次にプロジェクトのルートディレクトリに 「Dockerfile」というファイル名（拡張子は無しでファイル名はそのまま「Dockerfile」です）のファイルを作成し、それをVSCodeで開いて上記の内容をコピペしてください。# ベースイメージとしてNode.jsを使用FROM node:20.10.0-slim# 作業ディレクトリを設定WORKDIR /app# 依存関係をインストールCOPY package*.json ./RUN npm install# アプリケーションのソースコードをコピーCOPY . .# アプリケーションを起動CMD ["npm", "run", "start:prod"]次に同じくプロジェクトのルートディレクトリに「docker-compose.yml」という名前でファイルを作成し、以下の内容を記述します。version: '3.8'services:  api:    build:      context: .      dockerfile: Dockerfile    ports:      - "3000:3000"    volumes:      - .:/app    command: npm run start:devDockerコンテナのビルドと起動以下のコマンドを実行して、Dockerコンテナをビルドし、起動します。docker-compose up --build色々と処理内容が表示され、以下のような表示になったらローカル環境での作業・確認はOKとなります（画面の文字が小さいかもしれませんが、必要に応じて拡大してください。。）。ここからはAzureに対する作業となります。コンテナを利用するにあたり唐突ではありますが、Azure Container Registry (以下ACR)というサービスを利用します。これはコンテナ管理用のサービスなのですが、ネスケラボではまだ紹介されていなかったようですので、これもどこかのタイミングでご紹介できればと思います。さて、Dockerイメージをビルドし、Azure Container Registry (ACR) にプッシュするのですが、まずはACRを作成します。「myuniqueregistryname」がACRの名前なので好きな名前を付けてください。お試しであればそのままでも構いません。az acr create --resource-group myResourceGroup --name myuniqueregistryname --sku BasicリソースグループとACRがちゃんと作られていることを確認次にDockerイメージのビルド。docker build -t myuniqueregistryname.azurecr.io/my-nest-app:latest .以下のようになります。ACRにログインし、az acr login --name myuniqueregistrynameログイン成功Dockerイメージをプッシュしますdocker push myuniqueregistryname.azurecr.io/my-nest-app:latestこれも正常に完了していることを確認ランタイムとバージョンを指定してAzure Functionsアプリを作成し、デプロイします。その前にストレージアカウントを作成します。az storage account create --name mystorageacct20241123 --resource-group myResourceGroup --location japaneast --sku Standard_LRS次にApp Serviceプランを作成az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --location japaneast --sku B1 --is-linuxそしてAzure Functionsアプリを作成します。このあたりのコマンドプロンプト上の結果については割愛しますが、それぞれ成功しているかどうかコマンドプロンプトとAzureポータルを確認することをお勧めします。az functionapp create --resource-group myResourceGroup --name myUniqueFunctionApp2024 --storage-account mystorageacct20241123 --plan myAppServicePlan --runtime node --runtime-version 20 --deployment-container-image-name myuniqueregistryname.azurecr.io/my-nest-app:latest実際にAzureポータルで今回作成したリソースグループを選択すると以下のように今まで作成したリソースが存在しています。次に環境変数を設定します。az functionapp create --resource-group myResourceGroup --name myUniqueFunctionApp2024 --storage-account mystorageacct20241123 --plan myAppServicePlan --runtime node --runtime-version 20 --deployment-container-image-name myuniqueregistryname.azurecr.io/my-nest-app:latest そして、Azure Container Registry (ACR)からDockerイメージをプルするための認証情報を設定するのですが、そのためにその認証情報を取得する必要があります。まずはAzureポータルでACRを選択します。①左側のメニューから「アクセスキー」を選択②「管理者ユーザー」にチェックを入れる③パスワード（passwordとpassword2どちらでも）の「表示」ボタンを押す④ユーザー名とパスワードをメモ以下のコマンドの「ユーザー名」と「パスワード」に上で取得したユーザー名とパスワードを設定し、実行してください。az functionapp config appsettings set --name myUniqueFunctionApp2024 --resource-group myResourceGroup --settings DOCKER_REGISTRY_SERVER_URL=https://myuniqueregistryname.azurecr.io DOCKER_REGISTRY_SERVER_USERNAME=<ユーザー名> DOCKER_REGISTRY_SERVER_PASSWORD=<パスワード>最後に認証情報を設定した後、Azure Functionsを再起動します。az functionapp restart --name myUniqueFunctionApp2024 --resource-group myResourceGroupこれで、NestJSプロジェクトを作成し、Dockerを使用してAzure Functionsにデプロイするという手順は完了です。FunctionsのURLにアクセスしてみましょう。前回の記事同様、「Hello World」のみの恐ろしく寂しい画面ではありますが、Azure Functionsで無事動作していることがわかります。以上が、Functionsにデプロイするための手順となります。もしこれ以降ソースコードを修正して再度デプロイしたい場合は「docker build」、「az acr login」、「docker push」、そしてFunctionsの再起動を行えばOKです。独自にコードをゴリゴリ書き、もしくは最初に挙げた既存のモジュールを修正してFunctionsにデプロイしている人もいるかもしれませんが、コンテナ、ACRを使った方法としてはこのやり方になるかと思います。最後に当社は新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

Azure FunctionsでNestJSを動作させる方法

こんにちは、Azureビジネス部の金重です。先日Microsoft様主催で開催された第4回 AI Challenge Dayに、ネクストスケープ及びJBS（日本ビジネスシステムズ）の混合チームで参加しました。目次AI Challenge Dayとはイベント概要取り組むテーマネクストスケープ・JBSチームの提案融資業務における課題ソリューション概要アーキテクチャプロジェクトの進め方課題を見極める仮説を検証する今後の展望おわりにAI Challenge Dayとはイベント概要　AI Challenge Dayは業界の課題に対して参加した各社が生成AIを用いて解決する試みです。第1回に参加した際は世界遺産に関する質問に答えるチャットエージェントを構築しましたが、第4回の今回はFinancial Industryということで、金融業界における業界課題を生成AIを用いて解決する為の提案を3週間で考えました。　今回はエンジニア5人で参加し、金融の業務に詳しくない中で、どのように課題を定義し、ソリューションを提案したかご紹介します。また、その過程で技術的なソリューションを持つエンジニアが事業における課題を考えることの重要性を感じました。取り組むテーマ　今回は生成AIのCapabilityを活かした4つのアプローチとして、テーマが紹介され、その中で各社一つずつテーマを選定しました。監査や業務効率化を目的としたAIによるドキュメント処理詐欺や不正検出ウェルスアドバイザーAIアシスタントGraph RAGを活用した金融業務の高度化　ネクストスケープ・JBS混合チームでは、一つ目の「監査や業務効率化を目的としたAIによるドキュメント処理」を選択しました。とはいえ、金融業界と一口に言っても対象の分野や業務も広い為、創業計画書のチェックのような融資業務に着目し、人手でのチェックを生成AIで補助する提案を行いました。ネクストスケープ・JBSチームの提案　発表スライドを抜粋しながら課題、提案および技術的なソリューションをご紹介します。融資業務における課題　今回融資業務として想定する業務として、顧客が申込書類を提出し、営業担当者が記載不備をチェックし、審査用の書類を作成する過程に切り込みます。　一つ目の課題として、申込書類の記載不備の確認・修正に時間と労力がかかる点です。各入力項目の内容をチェックする上で、単に空欄の有無をチェックするだけではなく、事業計画の数字の計算根拠が合っているかといったチェックに時間がかかる項目もあります。場合によっては申込書類のフォーマットが顧客によって異なり、どこに何が記載されているか探すだけでも時間がかかります。　二つ目の課題として、申込書類の活用が難しい点にあります。申込書類は様々なフォーマットがあり、これらは記載不備をチェックした後に顧客フォルダに格納されますが、PDF形式で保存され後から確認するのみで、BIをはじめとしたデータの利活用につなげられない形になっています。ソリューション概要　この二つの課題に対して、AIを用いたデータの構造化及び記載不備の生成AIによるチェックの二つのソリューションを提案しました。　まず、申込書類を画像認識技術と生成AIを用いて、「事業計画はXXで、借入先はYYで…」といった意味をプログラムで扱える構造化データに変換します。そして、その各項目に対して、生成AIを用いて記載不備の有無をチェックします。　また、構造化データに変換することで、後で活用する際に、「各顧客の事業計画一覧」「借入先はどこが多いか」といった各項目を集計したデータやそれらを組み合わせた分析に活用できます（活用にあたって、データのコンプライアンスには留意する必要があります）。アーキテクチャ　まずはクラウド基盤であるAzureを用いたアーキテクチャの概観を紹介します。　左から順に、申込者はPDF形式で申込書類を提出します。提出された書類は、Azure Functionsの処理の中で順々にデータ形式の変換や入力チェックが実施されます。　まず、Azure Document IntelligenceというOCR画像認識技術によって、PDF中の文字や画像、表が認識されてプログラムで扱えるようになります。しかし、書類のフォーマットによっては損益計画がそのまま「損益計画」と記載されているものもあれば、「事業の見通し」という項目で記載されているものもあり、統一的にチェックすることができません。そこで、Azure OpenAI Serviceでフォーマットの統一化を実施します。ここでは、「この創業計画書の中で損益計画が記載されている箇所を抜き出してください」といった指示をするのですが、その際にデータの構造を定義します。例えば、「売上高は何円、売上原価は何円、計算根拠は文章で対応付けてください」といった形で指示します（実際にはSQLのスキーマを渡しますが、簡単の為に文章で表現しています）。　そして、統一フォーマット化されたデータを、再度Azure OpenAI Serviceを用いて入力チェックします。例えば「計算根拠と売上高に齟齬が無いかチェックしてください」といった指示を行います。ここで、チェック先のデータとして先ほど構造化された売上高の値、計算根拠の値といったデータを参照することで、元々PDFに記載されていたデータを生成AIでチェックすることが可能になります。プロジェクトの進め方課題を見極める　この提案を作成するにあたって、まず課題の定義からする必要がありました。今回のテーマ「監査や業務効率化を目的としたAIによるドキュメント処理」を見ていただけると分かる通り、ソリューションとなるAIによるドキュメント処理は指定されているのですが、監査や業務効率化の対象となる業務が何か？その業務の改善に効果はあるのか？といった点は定義されていない状態です。　生成AIに限らずプロジェクトの立ち上げでは、その問題を解く必要があるのか？と疑問が生じることがあります。安宅和人『イシューからはじめよ 「知的生産のシンプルな本質」』ではまさにこの点が指摘されており、解く価値のある問題の見つけ方が述べられています。世の中にある課題は解くべき価値があるかよく吟味する必要があります。その為、イベントの3週間という期間を、最初の1週間を課題の見極め、次の1週間を仮説検証、最後の1週間を検証結果に基づく提案のブラッシュアップという配分で、課題をいかに定義するかに注力しました。　今回エンジニア5名で金融業界に対する広い知識は無い中で課題を見つけ、その課題を解く価値を見極める為に、まずは情報収集を行いました。情報を集めるには業界の常識を本で勉強するだけでなく専門家の一次情報にあたることが重要と考え、社内の有識者へのヒアリングを実施しました。　ヒアリングの中で、ドキュメント処理に関する課題を聞くと、そもそも紙データのDX化が進んでいないといった話から始まり、記載不備のチェックという業務があることを知りました。そこで、実際に使用される書類を何種類か集めて見比べてみると、項目が多いうえにフォーマットもバラバラ、確かにこれを人手でチェックするのに時間がかかる上、そのまま保存しては後から利活用することも困難だと理解しました。　この過程を経た上で実際に人手でやっている業務を生成AIで補助した場合の人件費削減といったインパクトを概算し、融資業務における書類の入力チェックとデータ利活用の為の構造化が、今回のソリューションに合致する価値のある課題であると認識して進めることにしました。仮説を検証する　今回のイベントはいわばアイデアソンで、プログラムを組むことが目的ではありません。しかし、課題とソリューションを提案する上で、その課題の解く価値があることに加えて、実現可能であることを示す必要がありました。　提案の骨子を固めながら、アーキテクチャ図にあるような実装レベルでの処理の流れを整理しました。様々なフォーマットの書類を構造化データに変換して入力チェックをする中で、3つの検証ポイントが抽出され、これらを期間内に進める必要がありました。書類を綺麗に認識できるかデータ構造にフォーマッティングできるか構造化された各項目の入力チェックができるか　とはいえ、3週間のイベントの中で検証に失敗した場合に提案が困難になる為、打ち合わせ中に手元で簡単に確認してしまって「この検証ポイントはこの程度できそうなので進めましょう」とコメントする場面もありました。　一つ目の検証ポイントについては、Azure Document Intelligenceを用いてPDF形式のファイルを認識してMarkdown形式の文書に変換させた際、文字や表をどの程度綺麗に抽出できるか検証しました。実際の業務では顧客が複数の場所に申込書類を提出する為に手書きではなくExcelに入力する場合が多いと聞いていたこともありパソコンで入力した書類をメインにしたのですが、文字は綺麗に取得することができました。また、表は綺麗に認識できた部分も多いのですが、表の形が特殊な場合や文字に近い部分では認識できないこともありました。実はこの点については、表が崩れていても文字が認識できていれば次の検証ポイントでデータ構造を綺麗に格納できる場合がありました。　二つ目の検証ポイントについては、PDF形式のデータをSQLのレコード形式（検証時はSQLスキーマと互換性のあるJsonフォーマット）に変換しました。SQLのスキーマを自分たちで指定することで、業務としてチェックしたい項目を定義することで形式知化するメリットも暗に意識しています。実際に試してみると、Markdownの項目名は「今後の見通し」であっても内容を考慮して「損益計画」のスキーマに合致させることもでき、意味を考慮して各項目に対応づいています。　三つ目の検証ポイントについては、SQLのレコード形式で格納された各項目について、生成AIで入力チェックを行いました。スキーマの項目ごとにチェックしたい項目を指定し、それぞれ順番にチェックしていきます。例えば投資計画では、「必要な資金と調達する資金の合計金額が一致していること」、取扱商品・サービスでは「単価・席数・来店予想客数といった情報が記載されている」のように数字だけではなく、文字の意味を理解して書いてあるかを理解する必要があります。デモとしては数字の計算も含めある程度成功していたのですが、実際には数字の計算が弱いことが見込まれるため、そこは将来研究となりました。今後の展望　今回のイベントはアイデアソンであり、実際にシステムを構築するものではなく、作成物もデモンストレーションを行うにとどまりました。アイデアを提案するにあたって仮説検証は行いましたが、精度を上げる余地があります。例えば、損益計画の計算根拠をgpt-4oモデルを用いてチェックしていたのですが、本来生成AIは数字の計算に弱いと言われています。　これに対して、プロジェクト内で解の質を上げるには、Function Callingという仕組みを用いて計算は他の方法で任せてその結果の整合性を生成AIでチェックする、より計算に強いモデルを使用するなどの方法が考えられます。丁度本記事の執筆中にo1モデルよりプログラミングなどの論理的な課題に強いと言われるo3モデルの登場がOpenAI社から発表されたこともあり、今後数か月、数年での生成AIの進歩を待つことも一つの案になると考えています。　一方で、PDFの書類を綺麗に認識する方法については、直近での解決が困難であるとも感じました。生成AIについてはプロンプトエンジニアリングや今後のサービスの発展による直近での改善が期待できますが、ドキュメント認識の技術についてはユーザー側での開発のオプションが比較的少なく、今後のサービスの発展を待つか、或いは本腰を入れて表の認識に強いモデルを開発するなど、質を上げる為のソリューションにより高い技術力が求められます。また、今回は対象外としましたが手書き文字の認識は困難な課題であり、技術で解決するのか、運用面で対処するのか検討する必要があると考えています。　また、統一フォーマット化についても、様々な書類から項目を抽出するにあたって書類の例を覚えることで、プロンプトエンジニアリングとして例示する手法が使用できます。「以下のSQLスキーマに合致するようデータを構造化してください。例えばこんな項目はA、こんな項目はBに、こんな項目は…に対応付けてください。」と例を与えることで、より正確に統一フォーマット化ができると考えています。このように、実際のデータを集める、業務を理解することで生成AIに与える指示を強化することも可能になります。　提案の中では、解の質を上げるだけではなく、このシステムが実現した先にあるデータの利活用についても展望を述べています。今回は融資業務に着目しましたが、ソリューションであるデータの構造化と入力チェックの仕組みによって、他の業務についても展開することで各種業務特化AIの導入につなげられるのではないでしょうか。おわりに　今回、AI Challenge Day for Financial Industryに参加させていただいて、生成AIの技術への理解だけでなく、金融業界の業務や課題についても勉強させていただきました。特に、エンジニアの人達が金融業界に詳しい方々に囲まれて提案を行うことで、業務に理解がある人がコンサルティングを行うだけではなく、ソリューションを持ったエンジニアが業務を理解する重要性を感じました。　エンジニアが指示を受けて、エンジニアなりに考えて熱意をもって作ったものの現場にとって使いづらいシステムが出来上がり、使われないシステムとなってしまうことが多々あります。また、特に生成AIで顕著な課題として、生成AIに対する大きな期待から現実感の無いソリューションをイメージしてしまうことがあります。それに対して、エンジニアの側から、技術に即して実現可能性や工数も含めて地に足の着いたプロダクト実装を行う為の提案をするには、業務への理解が無いとまともに会話できないと理解しました。　私はよくイシューと解をWhat（何を）とHow（どのように）と表現します。何を解くか定義してどのように解くかという順番で物事を考えるよう意識しているのですが、現場ではこれが逆転することも多いと感じます。特に生成AIでは、生成AI（How）がある中で、どんな問題があるか（What）を探して定義する。一筋縄ではいきませんが、この順序で考える際に、HowばかりをきちんとWhatを考えて、最終的にイシューと解をセットにする力が求められるのだと思います。

【第4回 AI Challenge Day】エンジニアが金融の課題に生成AIで取り組む【ネクストスケープ・JBS】

■初めに今年もしんがりを務めます、ネクストスケープ小杉です。 毎年、このアドベントカレンダーで、何を考えてきたのか、何を伝えてきたのかを振り返る良い機会になっています。 昨年はAIの登場によってヒトに残されるのはGRIT力しかないんじゃないか、と書きましたが、この１年間のAIの進化を目の当たりにしながらも、改めてヒトに残された可能性について書いてみます。 ■ソリューションアーキテクトとは 技術も、マネジメントも、ビジネスも分かってできるヒトのこと。 そんなスーパーマンみたいな人っているのか？というと、まあ、居ると思いますし、要るんです。この言葉に出会ったのは２年前、親会社のJBSと共に検討中の海外アライアンスパートナー候補から、「このプロジェクトにおけるソリューションアーキテクトは誰だ？」 「ソリューションアーキテクトが必要だ」と何度も投げかけられたのが最初でした。会話の内容から推論するに、技術（この時は特にAI）を使って顧客の課題を見つけ解決し、ビジネスとして価値を最大化し、Deliverableにするようリスクコントロールし、Team（CoE）のパフォーマンスを発揮できるようマネジメントすることだと。 それってプロマネの仕事では？アーキテクトの仕事では？プリセールスとかコンサルの仕事では？と思い尋ねると「全部だ」という答え。  外資ではCoEなど、専門性を持ったロール（ジョブ）で分業が進んでいると思い込んでいたので、それらを繋ぐ、統合するソリューションアーキテクトというロールが明確に定義されていることに驚きました。 ■なぜソリューションアーキテクトが必要なのか 高度に専門分野が細分化・深化することにより、各分野の間にエアポケットが生まれます。例えば医療の分野においては、外科、内科、脳外科、心臓外科…といった具合に専門性の高い技術が発達してきました。一方で高度な課題を解決するために高度な専門性を持つ人が他の医療分野には明るくない、ということがおこります。更には組織の縦割り、タコツボ化などが起きると、専門外のエアポケットにある仕事は自分とは関係ないと考えて放置されます。僕は、プロジェクトにおいてこの事象が発生することを「四角い部屋を丸く掃く」と表現しています。医療における「エアポケット」を埋めるのが総合診療医（General Practitioner）ですが、海外では「専門職」として定義されているそうです。  思い返すと僕が出た学部は総合政策学部といって、本当に多様な分野の勉強をある意味広く浅く学ぶことができました。 その時代に教授たちから言われていたことは高度に専門化が進んだ社会においては、それらの知識を統合することが重要だと。さらに考えを深めると、イノベーションというのは全く新しいところから何かが生まれるのではなく、複数の分野の隙間を埋めるように生まれてくると。これがシュンペーターのいうところのイノベーション「（知識の）新結合」です。 ■分業じゃダメなのか 専門家の間には、何らかのコンフリクト構造があります。コンフリクトマネジメントの戦略としては、対立、回避、妥協、協調がありますが、かつての日本の製造業においては、この「すり合わせ」の妙が、高品質なプロダクトを産んできました。 しかし、このすり合わせには膨大な時間がかかってきました。それでも価値を提供し続けられたのは、（私が思うに）共通の自然言語、組織内部の莫大な暗黙知、ほぼ同質だと信じる人々の集団…であるが故の価値観共有が、お互いの主張や立ち位置の「のりしろ」として機能していたのではないかと推測します。  しかしながら、IT化が進み、グローバル化が進み、ソフトウェアのコンポーネント化が進んでいくと、すり合わせではなく組み合わせでMECE（漏れなくダブり無く）に、素早くデリバリーされていくようになりました。 不確実性が高く解決策が簡単にわからない状況では、すり合わせにコストと時間を割かずに、高速にインプリメンテーションして市場に問いフィードバックを受け、数多くの失敗の中から決定的な成功（必ずしも正解ではない）をつかみ取る、そんな世の中になってきました。 ■マルチエージェントAIとソリューションアーキテクト昨今のAIトピックは「自律型AIエージェント」とそれを統合する「マルチエージェントAI」の登場です。これは恰も高度な知識スキルを持つ専門家としての「自律型AIエージェント」と、それを統合的に扱う事ができるソリューションアーキテクトのような「マルチエージェントAI」にも見えます。 ヒトとしての専門家やソリューションアーキテクトはこのAIに代替されるのかが議論されています。しかし、現時点で私が知る範囲において、自律型AIエージェントとマルチエージェントAIは、それぞれの専門分野のナレッジをまとめて（要約）しているだけに見えます。イノベーションの原点にある「新結合」もなければ、コンフリクトをマネジメントする、つまり矛盾を扱うことによって見えてくる新しい光、希望のようなものはありません。 ■ソリューションアーキテクトであるために意識することSIerであるネクストスケープでは、ソリューションアーキテクトを一人でも多く輩出していきたい、そう考えています。（余談ですがネクストスケープにおいてSIerとは、System Integratorではなく、Serial Innovatorと定義しています） System Integrationは、実は組み合わせではなく、すり合わせの要素が大きい、つまり時間がかかる行為です。いかに素早くSystemをIntegrationし、少しでも早くDeliveryしていくためにはどうすればよいかを日々考えているなかで、私は、一個人の「ソリューションアーキテクト化」が高速化のカギだと考えるに至りました。 暗黙知に裏打ちされた「のりしろ」と、これを形式知化されたスキルやナレッジで、ソリューションアーキテクト自らの「のりしろ」を広げ、専門家の可能性を広げた「のりしろ」で張り合わせ、繋ぎ、統合していく。起こりうるコンフリクトと矛盾を楽しみ、自己の中で完結し、判断をする。これが結果として、ネクストスケープが目指す顧客とのSerial Innovationを引き起こすのではないでしょうか。 コンフリクトをマネジメントし、矛盾を楽しむこと。 これがソリューションアーキテクトであるための基本的なマインドセットだろうと考えています。

ソリューションアーキテクトについて 

みなさんこんにちは。システムインテグレーション事業本部の橋正です。この記事は「NEXTSCAPE Advent Calendar 2024」の22日目です。今年は何を書こうかな…と考えたのですが、約１年前に発生した能登地震を通じて、感じたことや、現在考えていることをお伝えしようと思いました。お付き合いください。---両親が同郷であったため､子供の頃の旅行の思い出は夏休みの両親の故郷である能登ばかりでした。毎年そこで一週間ほど過ごしました。魚を釣ったり､サザエを取ったり、カニやセミ、カエルを捕まえたりしながら、いとこ達と過ごしました。本当に楽しかったので、海から上がって井戸水で身体を洗っている時、東京ではあまりお目にかからないシマシマの小さな蚊に背中をさんざん刺されてもヘッチャラでした。海辺の村の畑を歩くと､知らないおばさんやおばあちゃんがやたらと話しかけてくれて、どこの子（≒誰の家の子）とよく訊かれました。小さな私にとってはその対応は面倒だったのですが､なんとなくこそばゆくて少し嬉しかったことを思い出します｡東京に帰る際は､祖父の寂しそうな笑顔や、祖母の涙を見るのが辛かったので、（なんでウチだけ東京なのかなぁ…）と毎年不満に思いながらクルマに乗りこむ際、鼻の奥がツンとしましたっけ｡そんな育ち方をしたせいか、両親の故郷がボクにとってもそのまま故郷のように感じていましたし、その想いは生涯変わりません。震源地から離れた故郷の波止場も地震により大きくひび割れていましたそんな奥能登は、元旦に大きな地震に見舞われました。東京でもかなり揺れたので、現地での被害を想像するのが怖いくらいでした。金沢に多く住む親戚は大方被害を免れましたが、奥能登に済む親戚の家は大小の差はありましたが、家屋を損壊しました。被害の大きかった輪島市に小学校の校長をしていた叔父（母の弟）が住んでいました。輪島は朝市で有名な奥能登の古い観光地です。震源地に近かったため、風情のある古い木造家屋の街並みは瞬く間に崩れ去りました。正月であったため、叔父の家には長女である私の従妹が一人息子を連れて帰省していました。叔父の家も例外ではなく倒壊し、大変不運なことに従妹の息子さんは11歳の短い生涯を遂げてしまいました。当時、町全体が瀕死な状態であった為、親類が手配してくれた金沢の火葬場まで彼を連れて行き、荼毘に付すこととなりました。私くらいの年齢になると、何度か悲しい場面に立ち会ったこともあるものですが、着の身着のままの若い母親が息子の棺の傍で、膝を崩して泣いている様子を目にするのは初めてであり、急遽金沢まで向かった私もかけられる言葉を持たず、ただ傍にいることしかできませんでした。 能登に行きたいとずっと思っていたのですが、仕事の関係上時間が取れませんでした。が、10月になって休暇を頂き、思い切って行ってきました。能登には親戚に限らず、たくさんの苦労を越えた上、生きていくための様々な選択をした人達がいました。災害の爪痕が残る輪島市もクルマで行けるようになっていたため、現場に伺い亡くなった彼に花を手向けることが出来ました。現場はまだ当時の残骸がそのままの状態で、ここからよく助かった人がいたなぁ…と感じた次第です。亡くなった彼は本当に優しい､親想いの良い子でした。（これからの人生で、やりたいことがいっぱいあったのだろうに…）献花の際、知らない内に私は彼の魂の無念さに思いを馳せていました。倒壊（横転）した輪島市内のビル。10月になっても撤去作業が始まっていませんでしたもちろん人生の意味は長さで決まるものではありません。では幸せというか､充実した人生とは何か…と真剣に考えてみると、自分が本当にやりたいことをやり切る事にあるのではないのだろうか…その時強くそう感じました。自分の意志でより能動的に生きて、やりたいことの選択肢を広げて､やるべきことをやり切る人生を送りたい。彼の死を悼むとともに、今生きている私はそんなふうに思います。でも、もう少し俯瞰して考えてみますと。（一度の人生を充実させるために）努力することや挑戦する事、そのひとつひとつの行程を踏むそのこと自体が幸せな人生の断片なのではないか…そんな考えに思い当たりました。だからこそ、若くして亡くなった彼も本当に幸せな人生を送ることが出来たのだと信じています。悲しいお話を書いてしまいました。でも私にとって身近な存在であった彼から教えてもらった、これらのお話をしたいと考えました。私も年齢に抗って、努力を続けたいと思います。そして幸せの断片は、毎日の暮らしの中に確実に存在するということを確かめたいと思います。来年が良い年になることを信じながら。能登の名所「白米千枚田（輪島市）」（2016年撮影）発災後、田んぼは枯れてしまったのですが、現在は修復に向かった活動が継続されているそうです。

幸せの断片について

昨年読んでいただいた方はご無沙汰しております。今年初めて読んでいただいた方は初めまして。ネクストスケープの和田です。　昨年の4月からネクストスケープ所管で1年9か月が経ちました。もとはJBSという会社で32年勤務していましたが、昨年よりネクストスケープを担当することになりました。もともと管理部門を受け持っていましたが、今年の4月より営業部門も受け持つことになりました。　　改めて、今年1年を振り返ると（というか社会人生活毎年感じていますが）激動の1年となりました。所管が増えたこともありますが、その中でも新たに経験したり取り組んだことも多く、それらの経験を通じて今年のお題目は「初心」と「チャレンジ」にしてみました。　前から思っていたことではありましたが、人間は生涯勉強していくことが重要だと思っています（なかなかすべてできていないのですが・・・）。「人間の限界」というものはどうやって決めるかというと、「自分が決める」ということです。自分で限界だと決めてしまうとそこで成長がストップします。IT知識、ビジネス知識、人との関わり、自分の趣味などなど、自分の能力はここまでと決めてしまうとそこで成長がストップします。　昨年よりロードバイクを始めたのですが、社内にはすごい方たちがいっぱいいてその中の一人（社長なんですがね）から、もっと乗らないと成長しないといつも言われています。確かにレースが見えてくると頑張って乗る機会を増やすと乗れるようになる実感が湧くのですが、少しでも空いてしまうと目に見えて体力が低下しているのが実感します。　仕事に追われてとか、夜の会食がというのは言い訳に過ぎず、それを限界と決めつけると成長しない、身近で実感できる「継続は力なり」ということです。ロードバイクだけではなく、仕事面でもその方（改めてうちの社長なんですが）はすごい努力を今でも積み重ねています。本当にスーパーマンが身近にいるんです！ 　年齢を重ねてくると新しいことへのチャレンジ（変化をさせると言いましょうか）にも躊躇してしまいがちです。過去の成功体験に囚われすぎると、次のチャレンジに一歩踏み出すことができないということも、皆さん経験があるのではないでしょうか？よく社員の方にも話をすることがあるのですが、新しい領域など何かチャレンジしようとしていてなかなか思うように進めない人にこういった話をすることがあります。　学生時代の部活は何をやっていましたか？　今、自転車は乗れますか？（車でもよいのですが）文科系や体育系の部活をやっていた、当然自転車乗れますよと答えが返ってきます。　すかさず、1年生の時の部活のレベルと、3年生の時の部活のレベルどちらがうまくできていましたか？そうすると当たり前に　3年生の時ですと答えが返ってきます。自転車（車）の話も同じで、最初はなかなかうまく乗れなかったはずで、何回も練習してようやく乗れるようになり（免許取れた）、その後は乗った回数だけうまくなっていく。この回答ではなかった人はこれまで見たことはありません。　では、それを新しい領域（ビジネス）にチャレンジするということに置き換えてみたらどうでしょうか？最初はうまくいかなくて当たり前。いっぱい勉強したり、経験したりすることを繰り返してどんどんできるようになっていく。　言われると当たり前なのですが、年を重ねるとリスクがとか自分が能力がないとか自分で「限界」を決めてしまうようになってしまっているのです。昔はできていたことができなくなってしまうのではなく、自分で何かの理由をつけてやらなくなっているだけなのです。（偉そうに言っていますが、私もすべてできているわけではありません（トホホ）） 　ある方から今年言われたことがずっと頭の中に残っています。その方とは長年お世話になっている方で、今年一番忙しかった時に少し愚痴も聞いてもらった（笑）ときに、　「社会人生活の中で、50代が一番忙しく、一番仕事ができた」と。その方はすでに70代の方なのですが、今でもご活躍しています。年齢などは関係なく、いつでも良い意味で昔に立ち返り「初心」に立ち戻って、いつの時にも「チャレンジ」する心を忘れないそんなことを改めて強く感じた1年でした。　是非、これからの人生（社会人生活）に少しでもお役に立てられたらと今回のアドベントカレンダーでお伝えしました。来年も皆さんにとって良い年になりますように。

「初心」と「チャレンジ」

はじめにこんにちは。ソリューションビジネス部の荒井です。2024年4月に新卒として入社しました。この記事は「NEXTSCAPE - Qiita Advent Calendar 2024 - Qiita」の20日目です。この記事では入社してからどのようなことをしているのか、紹介したいと思います。新卒入社で働くことを検討している方のご参考になれば幸いです。入社後ネクストスケープでは半年間新人研修があります。外部研修（4月～6月）4月～5月は、ビジネスマナーやプログラミング言語のC#、HTML/CSS、データベースについて学びます。6月には、これまで学習した技術を活用してチーム開発演習を行いました。課題は「架空のECサイトの改修」。他のメンバーと相談しながら役割分担を決め、実装を進めていく経験は、実際の仕事のシミュレーションのようでとても勉強になりました。内部研修（7月上旬～中旬）社内ではネットワークやクラウドの基礎を学習しました。模擬プロジェクト（7月下旬から9月）ネクストスケープでは、毎年研修の締めくくりとして、これまで学んできた知識を活かして社内システムを開発する模擬プロジェクトを行います。今年は「資格管理システム」の開発に取り組みました。このシステムは、社員が取得した資格を登録・管理できるものです。例年、新卒社員のみで進めるのが通例ですが、今年は新卒社員が1名だけだったため、先輩社員2名がプロジェクトマネージャー（PM）として参加してくださいました。当初は作り切れるかどうか不安でしたが、多くの人のサポートを受けて無事にシステムを開発することができました。模擬プロジェクトでは多くの学びが得られたので紹介したいと思います。スケジュールの意識詳細なスケジュールを立てることで、各タスクの期限や進捗状況を把握しやすくなります。遅れに早めに気づくことで、迅速に対策を取ることも可能です。実際、今まで使ったことのない技術に手間取り、進捗が遅れる場面がありましたが、先輩に相談し、一部の実装やテストを手伝ってもらうことで、無事に期日に間に合わせることができました。実装する機能について優先度をつけることの重要性ソフトウェア開発では時間が足りない場合、「時間」「予算」「品質」「スコープ」という4つの観点から調整を考える必要があります。具体的には、リリース日時を延ばす、作業人数を増やす、品質を下げる、またはスコープ（実装する機能）を削る、という選択肢です。模擬プロジェクトはスケジュールがタイトだったため、打ち合わせを行って機能の優先度を決め、必要最低限の機能を実装しました。配属後（10月～）10月からは運用プロジェクトに携わっています。運用については研修で学ぶ機会がなかったため、まさに1からの勉強です。初めて触れる業務ばかりで戸惑うことも多いですが、配属後に学んだことの一つは、「システムを運用する視点の重要性」です。研修中は、システムを期限内に完成させることを最優先にしていたため、「どのように運用しやすくするか」という観点が抜けていたことに気づかされました。現在は、システムを納品した会社からの問い合わせ対応を担当しています。迅速かつ正確な対応ができるように、日々努力しています。まだまだ課題は多いですが、一つ一つ経験を積み重ね、早く自信を持って対応できるようになりたいです。おわりに私はプログラミングの経験がほとんどない状態で入社しましたが、多くの方のサポートを受けながら、社内システムを作り上げることができました。ネクストスケープは、手厚い研修とサポート体制が整った会社だと実感しています。この記事が、IT企業に興味のある方や、新卒入社を検討されている方の参考になれば幸いです。皆さんとお会いできる日を楽しみにしています。

ネクストスケープ新入社員の入社1年目

はじめに株式会社ネクストスケープ ソリューションビジネス部の小野塚です。この記事は「NEXTSCAPE Advent Calendar 2024」の17日目の記事となります。色々ありましてNestJSを学び始めました。当社ブログでは扱われていなかったものの、既に様々なブログに取り上げられている言語ではございますが、実際に触ってみたところ、なかなか良さげな雰囲気もあり、そのアウトプットとして本記事を書いてみました。NestJS はNode.jsをベースとしたサーバーサイドフレームワークであり、更にTypeScriptをフルサポートしています。そのため、型安全なコードを書くことができ、更にモジュール構造や依存性の注入等の特徴を持っています。このNestJSは2017年頃に発表され、Googleトレンドを見る限りでは2022年の初めにはNode.jsと同レベル、もしくはそれ以上の検索回数になっています。Jestというテストフレームワークもデフォルトでサポートしており、ユニットテスト等も簡単に実施することができるということで、非常に良さげです。まずは簡単な実行環境を作りつつ、その特徴を私なりに説明したいと思います。準備まず必要なものですが、先ほどお話しした通り、NestJSはNode.jsをベースとしていますのでNode.jsのインストールが必要です。更にはnpmというパッケージマネージャ、つまり、必要なライブラリやツールをインストールしてくれるものが必要になりますが、npmはNode.jsに同梱されているのでNode.jsのみインストールすれば大丈夫です。以下のURLから最新（LTS）のバージョンをダウンロード・インストールしてください。この記事を書いている2024/12/8であればv22.12.0が最新です。nodejs.orgNestJSの基本構成構成上このタイミングで基本構成を説明しますが、この後説明するサンプルプロジェクトの作成後、もう一度こちらを読んでもらうと良いかもしれません。色々なNestJSの資料を読む限りでは以下の構成が一番わかりやすいかなと思います。①main.ts：NestJSアプリケーションのエントリーポイント。ここから処理が始まります②app.module.ts：NestJSアプリケーションのルートモジュールであり、アプリケーション全体の構成を定義するファイル。モジュールが追加される場合、ここに追加されます。③～⑤：あとは各モジュールごとにモジュール、サービス、コントローラの３つで構成され、モジュールを追加するごとにこれらのファイルが作られます。デフォルトで作成される「app.～.ts」もモジュール、サービス、コントローラの３つで構成されていますサービスはビジネスロジックを担当し、コントローラはクライアントからのリクエストを受け取ってサービスを呼び出し、レスポンスを返します。このように、サービスとコントローラは連携してアプリケーションの機能を実現します。と、私を含むNestJS初心者の方々にはこのタイミングで書いても「なるほど」としか言えないと思いますので、繰り返しになりますが、以下のサンプルプロジェクトを作成し、動作確認を行ったところでもう一度読み返してみてください。恐らく納得いただけるのではと思います。NestJS のマニュアルを見ると、あとはミドルウェア（Middleware）、デコレーター（Decorators）といったものも基本構成として挙げられてはいるのですが、まずはモジュール、サービス、コントローラの３つを押さえておくのがよいのではないでしょうか。サンプルプロジェクトの作成では、次に実際にサンプルプロジェクトを作成し、動作させてみましょう。NestJSにおける「Hello World」です。nestjstestというプロジェクトを作って、それをローカル環境としますまずはプロジェクト作成。「npm i -g @nestjs/cli」でNestJSのCLI（コマンドラインツール）をインストールします。そして、プロジェクト作成のため、「nest new」の後にプロジェクト名を入力します。今回は「nestjstest」というプロジェクト名にします。npm i -g @nestjs/clinest new nestjstestパッケージを聞かれるのでnpmを選択します。? Which package manager would you ❤️  to use? (Use arrow keys)❯ npm   yarn   pnpm しばらく進捗状況が作成された後に「Successfully created project nestjstest」というメッセージが表示されたら、プロジェクトが作成できたことになります。そのプロジェクト直下のディレクトリに移動しましょう。cd nestjstestSwaggerのインストールのため、プロジェクトまで移動したら、ターミナルで以下コマンドを入力npm install --save @nestjs/swaggermain.tsをテキストエディタで開くと以下のようになっています。import { NestFactory } from '@nestjs/core';import { AppModule } from './app.module';async function bootstrap() {  const app = await NestFactory.create(AppModule);    await app.listen(3000);}bootstrap();最初のimport文に以下の行を追加して、import { SwaggerModule, DocumentBuilder } from '@nestjs/swagger';bootstrap()内のconst app～とawait app.listenの行の間に以下のコードを書き加えてください。const config = new DocumentBuilder()     .setTitle('(APIのタイトルを入力)')    .setDescription('(APIの説明を記載')    .setVersion('1.0')    .addTag('(タグ名。省略可)')    .build();const document = SwaggerModule.createDocument(app, config);SwaggerModule.setup('api', app, document);そして実行します。実行するときは以下のコマンドを叩いてください。npm run start特にエラーが出ないようであれば（入力待ちのような状態になるはず）、以下にアクセスしてみてください。http://localhost:3000/apiSwaggerの画面が表示されるはずです。Swaggerでも確認はできますが、以下のURLを叩けば、http://localhost:3000/以下のように文字列が返される（ブラウザ上に表示される）はずです。依存性の注入のサポート先に書いた通り、NestJS では依存性注入（DI）の概念がフレームワークとして組み込まれています。先ほどの流れでサンプルプロジェクトが作られましたのでこれを元に軽く説明しておきます。まずはサービス部分、app.service.tsは以下のようになります。「@Injectable()」と書かれた行、これは@Injectableデコレータというもので、このクラスがDIコンテナに登録されることを示しています。import { Injectable } from '@nestjs/common';@Injectable()export class AppService {  getHello(): string {    return 'Hello World!';  }}次にモジュール、app.module.tsが以下になります。import { Module } from '@nestjs/common';import { AppController } from './app.controller';import { AppService } from './app.service';@Module({  imports: [],  controllers: [AppController],  providers: [AppService],})export class AppModule {}このようにproviders配列にAppServiceが含まれていることで、NestJSのDIコンテナにサービスが登録され、必要な場所で注入できるようになります。実際にサービスを使用するコントローラー、app.controller.tsを見てみましょう。import { Controller, Get } from '@nestjs/common';import { AppService } from './app.service';@Controller()export class AppController {  constructor(private readonly appService: AppService) {}  @Get()  getHello(): string {    return this.appService.getHello();  }}本来コントローラー内で手動でサービスを作成しなければならないのですが、依存性の注入によりそれが不要となります。Node.jsでも依存性の注入は可能なのですが、別途専用のモジュールをインストールする必要があり、NestJSのようにすぐに使えるというわけではありません。テストフレームワークのサポート「テストフレームワークのサポート」についても説明しておきます。main.ts等が配置されているsrcディレクトリを見ると、通常のモジュールやサービスのファイル以外に「app.controller.spec.ts」というファイルがあります。この「～.spec.ts」というファイルがテスト用ファイルになりまして、以下の場合ですとコントローラ用のテストファイルが自動的に作成されていることになります。ファイルの中身は以下のようになっておりまして、自動的に作成されたgetHolloを検証するコードが既に書かれています（見づらい方はブラウザで拡大してください。。すみません）。言わずもがなかもですが、テストコードの内容が書かれているのはこれがサンプルであるためでして、自身が作成したコードに対しては当然自身でテスト処理を書く必要があります。ちなみにCLIで独自のサービスやコントローラーを作成するとテストファイルも自動的に作成されますが、これはガワのみとなりますので中身を自分たちで書くことになります。ガワだけであってもそうやってファイルを作成してくれると「テストコードを書かないといけないな」という気持ちにさせられます（私だけかもですが。。）。テストを行うにはJestというJavaScriptのテストフレームワークが必要ですが、Node.jsのインストールで併せてインストールされているはずです。実行するには対象のプロジェクト内で「rpm run test」を実行します。すると配下の「～.spec.ts」ファイルに対してその中に書かれたテストプログラムを一通り実行します。もし特定のファイルのみテストしたい場合は「npm run test」の後に「～.spec.ts」ファイル名を指定します。今回は先ほど書いた通り既にテストコードが書かれているため、何も考えずにすぐに試すことができます。その結果が以下になります（ディレクトリ名が違うのはご容赦を）。無事「pass」していることがわかります。Node.jsでもユニットテストは同じように行えるのですが、先に説明した依存性の注入により実際のオブジェクトの代わりにモックを注入したテストもできますので、より効率的に開発が進められます。いかがでしょうか。結構至れり尽くせりなフレームワークかと思われます。最後に（NestJSのデメリットも含）以上、色々とNestJS万歳的な感じで書いてきましたが、当然デメリットもあります。色々言語仕様を知り尽くせばもっと出てくるかもですが、パッと思いつくのは以下のようなものです。【学習コストの高さ】NestJSを学ぶ前にTypeScriptやNode.jsの知識が必要になります【情報が少ない】まだ比較的新しめのフレームワークなので情報が、特に日本語の情報が少ないので学習がやや大変【コミュニティがまだ小規模】国内外でNestJSの普及や紹介をしてくれているところはあるのですが、これも上に書いた通り新しめ故に十分に情報が得られない可能性がありますとはいえ、非常に魅力的なフレームワークですので、特にNode.jsを知っている方々、そして型安全の言語を好む方にとってはおススメできます。以上がNestJS についての簡単な説明・紹介となります。正直なところ、このあたりはNestJS の基礎的な内容ですので知っている方には今更感満載の記事となりますが、実はこれに続きがありまして、NestJS をAzureリソース上で動かすために色々と試行錯誤した経緯を次回の私の記事で説明しようと思っております。今回はその前準備、イントロ部分となります。記事公開は恐らく来年になるかと思いますが、よろしくお願いいたします。最後に。。当社は新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。nextscape.net（以下当社お問合せフォーム）Microsoft Forms

NestJS学び始め

この記事は「NEXTSCAPE Advent Calendar 2024」の14日目の記事です。qiita.com2024年から2025年にかけての年末年始休暇は、12月28日（土）から1月5日（日）までの9連休という方も多いのではないでしょうか。もしかしたら、前後に有給休暇をくっつけて、10日超えの連休にする、という方もいらっしゃるかもしれません。そんな長期休暇にこそオススメしたい書籍をご紹介いたします。私が積読している書籍もありますが、この長期休暇を機に一緒に読んでいきましょう。     マネジメント系『ピープルウェア　ヤル気こそプロジェクト成功の鍵』（トム・デマルコ、ティモシー・リスター）『PMBOK®ガイド第7版対応 アジャイル型プロジェクトマネジメント』（中谷 公巳）技術系『悲劇的なデザイン　あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか？』（ジョナサン・シャリアート、シンシア・サヴァール・ソシエ）『ていねいな「文章大全」　日本語の「伝わらない」を解決する１０８のヒント』（石黒 圭）エンターテイメント系『天久鷹央の推理カルテ』シリーズ（知念 実希人）おわりに マネジメント系『ピープルウェア　ヤル気こそプロジェクト成功の鍵』（トム・デマルコ、ティモシー・リスター）ピープルウエア　第3版作者:トム デマルコ；ティモシー リスター日経BPAmazon1冊目は、いわゆる”デマルコ本”と呼ばれている、トム・デマルコ著のマネジメント本の中の一冊です。アメリカで1987年に初版が出版されていますので、40年近く前の本です。1998年には改訂した第2版、2013年にはさらに改訂が加えられた第3版が出版されました。古い本ではありますが、いまだに良書として紹介されるほど息の長い本です。さて、次の文章は、本書のテーマを端的に表していると思う文章です。ソフトウェア開発のプロジェクトに多く入ってきた人ほど、頷けるのではないでしょうか。私自身、初めて読んだときは何度も大きく頷いてしまいました。実際のところ、ソフトウェア開発上の問題の多くは、技術的というよりは社会学的なものである。『ピープルウェア』第2版 P4弊社はリモートワークの社員も多く、場合によっては直接顔を合わせたことのない社員と一緒にプロジェクトを進めることもあります。そうすると、問題となりがちなのは技術的なことよりも社会学的なもの。つまり、人に関することです。できる限りプロジェクトを成功に近づけるためには、人に関するトラブルは避けたいですよね。本の内容は高尚な理論、ではなくソフトウェア開発の現場あるあるがまとまったようなもの。ユーモアある文章で書かれていますので、読みやすいです。個人的に、オフィス環境を書いている章が、在宅勤務の環境を作るのに参考になりました。集中できる環境づくりというのはとてもとても大事だな、と思いました。プロジェクトメンバーにヤル気を持ってもらうためにはどうしたらいいかを悩んでいる方にオススメの書籍です。 『PMBOK®ガイド第7版対応 アジャイル型プロジェクトマネジメント』（中谷 公巳）PMBOKガイド®第7版対応 アジャイル型プロジェクトマネジメント作者:中谷 公巳日本能率協会マネジメントセンターAmazon2冊目は、プロジェクトマネジメント知識体系ガイド、通称『PMBOK®ガイド』第7版に対応したアジャイル型プロジェクトマネジメントの解説と、プロジェクトによる価値の実現、そして成果を上げる最高のチームづくりをテーマにした本です。勉強されている方は周知の事実ですが、『PMBOK®ガイド』第7版は、それまでの第6版から大きく変わりました。第6版までは、プロセスベースのプロジェクトマネジメント方法でした。しかし、2022年に発売された第7版からは、原則ベースのプロジェクトマネジメント標準に変わったのです。理由は、実際のプロジェクトの半分程度は、ウォーターフォール型ではなく、アジャイル型やハイブリッド型が使用されているため、とのこと。今までずっとプロセスベースを勉強し、実際のプロジェクトにもできる限り適用しようとしてきた身としては、急に原則ベースと言われてもなかなか受け入れられず、『PMBOK®ガイド』第7版の理解が追いついていませんでした。本書と『PMBOK®ガイド』第7版と見比べることで、少しずつ理解できてきたような気がしています。読み終える、ましてや理解するには時間がかかりそうですが、年末年始も読んでいきます。 『PMBOK®ガイド』第7版を受け入れるのに苦労している方や、アジャイル型プロジェクトマネジメントを知りたいという方にオススメの書籍です。 技術系『悲劇的なデザイン　あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか？』（ジョナサン・シャリアート、シンシア・サヴァール・ソシエ）悲劇的なデザイン ―あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか?作者:ジョナサン・シャリアート,シンシア・サヴァール・ソシエビー・エヌ・エヌ新社Amazon3冊目は、著者が考える「ひどい」デザインが、どんな形で人を傷つけるのかを紹介し、その悪影響とそこから得られる教訓がまとめられた本です。せっかく開発するのだから、使いやすいシステム、使いたいと思われるシステムを作りたいと考えるのは、エンジニアあるあるだと思います。その考えが強く出てしまい、力が入りすぎた結果、使いづらいデザインになってしまうことも。しかし、本書を読むことで、これはやっちゃダメというデザインの NG パターンを学ことができます。知識があれば、意図せず人を傷つけるようなデザインを作ることを避けることができます。デザインをまったく勉強したことのない私にも理解することができるくらい、画像が豊富で説明もわかりやすいです。人が触るモノやサービスのデザインをしている方や、これからデザインを始めようとする方にオススメの書籍です。 『ていねいな「文章大全」　日本語の「伝わらない」を解決する１０８のヒント』（石黒 圭）ていねいな文章大全: 日本語の「伝わらない」を解決する１０８のヒント作者:石黒 圭ダイヤモンド社Amazon4冊目は、最後まで読まれる文章の書き方を、108課にわたって徹底的にトレーニングする本です。2024年から2025年にかけての9連休は、この本を読むためにあると言っても過言ではない！……かもしれません。文章を読み書きするのも仕事のうち。そうは言っても、最後まで読むのに苦労する文章を目にすることがありますよね。そして、自分も読みづらい文章を書いているのではないか、と不安になりました。感じた不安を解消するため、タイトルに惹かれて本作を購入。届いてびっくり。大全という名の通り、500ページを超える大作でした。仕事や家事、育児に追われる状況でこの本を読み進めることは容易でありません。そのため休みの間、しっかりと腰を据えてこの本に取り組むつもりです。私と同じように、読みづらい文章を書いているんじゃないかと不安に思う方にオススメの書籍です。 エンターテイメント系『天久鷹央の推理カルテ』シリーズ（知念 実希人）天久鷹央の推理カルテ　完全版 (実業之日本社文庫)作者:知念 実希人実業之日本社Amazon5冊目は、2025年1月1日よりアニメ放映が始まるメディカル・ミステリーのシリーズです。医療ミステリは、外科医を中心として医局内の権力闘争を描くものを目にすることが多いですが、本作は頭脳明晰、博覧強記の天才女医・天久鷹央が、診断医としての能力と知識を駆使して事件を解決に導いていきます。しかも、主人公が解く謎は、病気だけではありません。警察でさえ解き明かすことのできない謎も解き明かしていくのです。こちらのシリーズは、2025年12月14日現在、短編集を含めて16巻刊行されていますので、長い休みに一気読みすることもできます。今までの医療ミステリとは違う作品を読みたい方にオススメの本です。ちなみに、こちらの作品の著者は、現役医師の方だそうです。おわりに年末年始などの長い休み。予定を立てずにのんびり過ごすのもよいですよね。ですが、仕事のことを考えずに集中してもいい期間と思って、今までページを開けなかった本に挑戦してみるのもよいのではないでしょうか。

長期休暇にオススメの書籍5選

こんにちは、ソリューションビジネス部の金子です。 この記事は「NEXTSCAPE Advent Calendar 2024」の12日目の記事となります。 本記事では、Microsoft Azureが提供するAI Servicesである「Azure AI Custom Vision」および、それを用いた簡単な実験を行ってみたので、解説しようと思います。 Custom Visionとは？Microsoft Azureが提供するAI Services(旧:Cognitive Services)のうち、「視覚」に特化した認知ソリューションの構築を行えるサービスです。これまで画像認識や画像からの物体検出などを行う際には、AIやデータサイエンスなどの専門的知識が必要でしたが、Custom Visionを用いることによって、これらの知識を必要とせずに、「画像のアップロード」「モデル学習」「タグ付け」など、機械学習を実施するうえで必要な操作をWeb上で簡単に実施できるようになっています。今回、Custom Visionに個人的に興味を持ったので、これを用いてとある実験をしてみました。 触ってみた背景個人的な趣味の話で恐縮なのですが、私は生き物が好きです。その中でも、特に海水魚が好きです。こんな感じの毎年の夏から秋に、海に出かけては海水魚採集をしています。採集方法はいろいろありますが、私は相模湾や駿河湾、伊豆諸島などの関東近郊の海に出向き、そこで潜って魚を採ることが多いです。シュノーケルと足ヒレをつけて、網を二本持って潜ります。酸素ボンベなどを使うと漁業規則に引っかかってしまうので基本は素潜りです。冬になると寒くなって海に潜れなくなるので、真夜中の海岸を歩いて漂着した深海魚を拾ったり、もしくは釣りに出かけることもありますが、最近はあんまりやってないです(寒いのが苦手なので…)。ミズウオ水深1500mくらいのとこにいる深海魚で、この時期になると静岡県の特定の海岸によく打ちあがります。海水魚採集の難点「捕まえた魚の名前がわからない」これに尽きます。一度採集したことがある魚や、よっぽど好きな魚などは別ですが、海で出会う魚は、大抵初めて見る、捕まえる魚です。いつも「捕まえたはいいけど、これなんて名前だろ…」と悩むところから始まります。そういうときは図鑑を使って種類を調べるわけですが、図鑑で調べるという行為は、思っている以上に難しいです。なぜなら…①そっくりな魚がいる上：シマキンチャクフグ(フグ目フグ科)下：ノコギリハギ(フグ目カワハギ科)図鑑でそれっぽいのを見つけたけど、同じ見た目をした魚が２種類いる…ということがたまにあります。代表的なのが上記画像のシマキンチャクフグとノコギリハギ。この2種はそっくりな見た目をしていますが、判別は比較的容易で、背びれと臀びれの形状で見分けることができます。ただ、こうした見分け方を知らない場合、図鑑を見ても種類がわからずじまいなことが多いです。見分け方が書いてない図鑑もありますし、場合によっては判別ポイントがもっとわかりづらい魚もいたりします。 ②成長度合いで全く違う見た目をしている魚がいる上：サザナミヤッコ 幼魚(こども)下：サザナミヤッコ 成魚(大人)生まれてから大人になるまで同じ見た目をしている魚もいますが、多くは成長するにつれて見た目が変わっていくことが多いです。そしてその中には、画像のサザナミヤッコのように幼魚と成魚でまるっきり違う見た目を持つ魚もいます。これは図鑑にもよるのですが、載っている写真はだいたいが成魚の写真です。幼魚の写真がないことも多く、「これ誰…？」となることがあります。 ③そもそも何の仲間なのかわからない魚がいるエボシダイ電気クラゲとして知られているカツオノエボシの触手の中に生息しています見た目だけだと「そもそも君は何の仲間なの…？」という魚もいます。図鑑は、基本的には分類ごとに分けられて掲載されているため、見た目から分類のアテがつかないような魚は調べるのが本当に大変です。だって何の仲間かわからんし…。画像のエボシダイは、スズキ目エボシダイ科という非常に影の薄いマイナーな分類群に属している魚で、初めて捕まえたときに図鑑を見ても名前が全くわからず「これ新種じゃね？」と勘違いするほどでした。 AI魚図鑑が欲しい…と、こういった感じで、図鑑で名前を調べるのは意外と大変だったりします。そんな時、「写真撮ってアップロードしたら、内容を解析して名前を導き出してくれるようなアプリないかなー」と思うことがあります。いわゆるAI魚図鑑みたいなものですね。そういったAI魚図鑑ですが、実は結構あります。ググったら出てきますし、アプリストアなどでも、AIによる種判別が行えるようなアプリはいくつかリリースされています。…が、こう言っちゃなんですがどれも判別精度が低いです。正確な名前を出してくれないとかはよくあるのですが、中には「なんでそう判断した？」と突っ込みたくなるくらい全然違う生き物の名前を出してくるアプリもあったりします。昔とあるアプリでサメの写真をアップロードしたら「これはイリエワニです」と言われてリアルに頭を抱えたこともありました。爬虫類…。もちろんアプリケーションによって、使用しているプラットフォームも学習方法も違うでしょうが、それでも共通して精度が低いことには若干の疑問と興味を持ちました。なので自分でも、画像認識の仕組みを使って、どれくらい正確に種類を判別できるのかを試してみようとしたところ、今回のCustom Visionに行き当たった、という感じです。というわけで、以下の実験を行いました。 実験してみた実験条件Custom VisionのQuick Trainingを使用し、テスト対象の魚の画像と、それに似ている3種類の魚の画像を、それぞれ30枚ずつ学習させました。その後、画像の判別を行うQuick Testでテスト対象の魚の画像をアップロードし、正しく判別してくれるかどうかを確認します。なお、Custom Visionでは、解析した画像が何であるかを、パーセンテージを使って表します。なので、だいたい80%を超えたら正しく判別できている、ということにして実験を行いました。テスト対象ハタタテダイ Heniochus acuminatus今回はハタタテダイを使って実験を行いました。似ている魚3種類も、それぞれ「ちょっと似ている」「けっこう似ている」「すごく似ている」ものをピックアップして実験してみました。 手順①Azure Portalからリソースを作成した。 ②Custom Visionにサインインし、新しいプロジェクトを作成した③[Add Images]から、学習用の画像アップロードとラベル付けを実施したMy Tags(タグ名)には、魚の和名を登録しました④[Quick Training]を実施し、モデルの学習を実施した学習が完了すると、以下のように評価指標が表示されます。Precision(精度)モデルがどれだけ正確に分類を行ったかの割合を指します。たとえば、モデルが100枚の画像を「りんご」と識別し、そのうち99枚が実際に「りんご」の画像であれば、精度は99%となります。 Recall(再現率)実際のカテゴリに属するアイテムが、モデルによってどれだけ正しく識別されたかを示す割合を指します。たとえば、実際に「りんご」の画像が100枚あったとして、モデルがそのうち90枚を「りんご」と判定していれば、再現率は90%となります。 ⑤[Quick Test]を実施した画像のURLを貼るか、ローカルからファイルをアップすることで、学習データを基に、アップロードした画像が何であるかをパーセンテージで判別してくれます。 結果テストパターン① ~ちょっと似ている魚~テスト対象のハタタテダイと、ちょっと似ている魚であるツノダシをそれぞれ学習させてテストを行いました。上：ハタタテダイ下：ツノダシパッと見同じだけど、よく見たら全然違う見た目をしています。テスト用画像をアップロードしたところ、ハタタテダイが98.7%、ツノダシが1.2%という結果になりました。ちゃんと学習して判別してくれているようです。 テストパターン② ~けっこう似ている魚~テスト対象のハタタテダイと、けっこう似ている魚であるオニハタタテダイをそれぞれ学習させてテストを行いました。上：ハタタテダイ下：オニハタタテダイ同じじゃね？って思うかもしれませんが、ハタタテダイは顔の黒い模様が目の上にしかありません。対してオニハタタテダイは、顔全体が真っ黒に塗りつぶされたような形で模様が入っています。テスト用画像をアップロードしたところ、オニハタタテダイが86%、ハタタテダイが13.9%という結果になりました。あれれ…。学習させた画像がよくなかったのか、原因はわかりませんが正しく判別できませんでした。形態の差はちゃんとあるはずですが、予想外ですね…。 テストパターン③ ~すごく似ている魚~テスト対象のハタタテダイと、すごく似ている魚であるムレハタタテダイをそれぞれ学習させてテストを行いました。上：ハタタテダイ下：ムレハタタテダイQ.何が違うの？A.こちらをご参考ください ↓ハタタテダイ2種とツノダシの見分け方｜海のいきもの｜海の生き物｜Marine Diving web（マリンダイビングウェブ）全く同じ見た目をしていますが、ちゃんとそれぞれ別の種類です。正直私も見分けられないです。テスト用画像をアップロードしたところ、ムレハタタテダイが57.8%、ハタタテダイが42.1%という結果になりました。正しく判別はできませんでしたが、だいたい半々の確率になると思ってたので予想通りではありました。 考察テストパターン②、③は判別精度がよくありませんでした。ほぼ同じ見た目の③はまだしも、見た目に差がある②もうまく判別できなかったとなると、学習のさせ方を見直さないといけないような気がしています。 一般的に画像認識をさせる際、学習データはなるべくいろいろなパターンを使うとよいと言われています。例えば、「りんご」を学習させるのであれば「りんご」「皮をむいたりんご」「カットしたりんご」など、様々な画像を使って学習させる、ということです。今回、学習用の画像は「観察ケースで撮影した魚」「水族館で撮影した魚」「ダイビングで撮影した魚」といった形でさまざまなものを使用しましたが、背景に対象以外の魚が写ってたり、魚の向きが左だったり右だったりと、形態を学習を阻害してしまうような要素が入っていたのが、判別がうまくいかなかった原因なのではないかと考察しました。そのため、種判別を目的とした学習をさせる際は、魚が写っている向きを統一し、被写体以外の余計な要素(背景やほかの魚など)を極力排除した画像を使うことにより、精度が上がるのではないかと予想しました。 また、今回は学習にQuick Tariningを使用しましたが、これ以外にもAdvanced Trainingという学習機能も存在します。これは時間がかかる代わりに、高精度で学習を行ってくれる機能になります。今回は時間がなかったのでQuick Trainingを使用しましたが、Advanced Trainingを使うことにより、判別精度をもう少し上げられるのではないかと思いました。 所感なんだかんだいろいろ書きましたが、高精度のAI魚図鑑は、実現は難しいのではないかと考えました。日本産の海水魚だけでも膨大な種類がいますし、それに加えて成長段階で形が違ったりすることもある。さらに種類によっては学習用の画像が全然用意できない、なんてこともあり得ます。仕組みを作る時点でもう難しいのではないのかなと、今回の実験で思いました。なので、種類を調べる際は地道に図鑑をめくっていくしかなさそうです。 長くなってしまいましたが、ここまで読んでいただきありがとうございました。引き続き、ネクストスケープのアドベントカレンダーを楽しんでいただけますと幸いです。(本記事の執筆において、一部の画像をryotazukanさんより提供いただきました。ありがとうございます) 株式会社ネクストスケープでは、開発エンジニア(Web,スマートフォンアプリ,xRなど)やプロジェクトマネージャーを募集しております。ご興味がありましたら、採用ページのエントリーフォームよりご応募いただけますと幸いです。

Custom Visionを使って、似ている魚を判別できるか試してみた

事業計画とプロダクトコンセプト設計はじめに：情熱と覚悟が不可欠な新規事業IoT市場は成長を続け、無限の可能性が広がっています。しかし、IoT事業を立ち上げ、継続して成功させるためには、単なるアイデアや市場分析以上に重要なものがあります。それは、「自分自身がそのコンセプトやニーズを心の底から信じられるか」という覚悟です。ビジネスの成功は、アイデアの質だけでなく、それを信じ、貫き通す情熱にかかっています。この覚悟がなければ、立ち上げには成功しても、常に発生する想定外の問題や壁にぶつかったときに継続できません。少なくとも5年10年と継続する覚悟が必要になります。この記事では、その覚悟を持つために考えるべきことと、実現に向けた最初のステップについて、お伝えできればと思います。自分が本心から信じられるアイデアとは何か自分の価値観とアイデアの一致を見つめ直しましょう。新規事業を立ち上げるとき、まず重要なのは「そのアイデアが自分自身の価値観と本当に一致しているか」を問いかけることです。例えば、私がAlterLockを立ち上げたとき、出発点にあったのは「ロードバイクの盗難の不安を解消して、安心してサイクリングをできるようにしたい」という想いでした。自転車を愛する人にとって、盗難の被害は単なる物の損失ではなく、大切な時間や体験を奪われることです。絶えず付きまとう不安は少なからずサイクリングの可能性を狭めています。その課題をITやIoTの力で解決したいという情熱が、事業を進めるエネルギーとなりました。アイデアを練る際には、次のような質問を自分に投げかけてみてください：その課題を本気で解決したいと思えるか？自分自身がその課題に直面したとき、どう感じるか？解決に向けてのアイデアを語るとき、他人に情熱が伝わるか？このプロセスを経て、心の底から信じられるアイデアが見つかったとき、ただの「ビジネスチャンス」ではなく、人生の一部として事業を推進していく覚悟が持てるでしょう。事業計画を立てる対象となる市場、ユーザー、製品の差別化ターゲット市場を明確にするアイデアを具体化するには、ターゲット市場を絞り込むことが欠かせません。ターゲットが漠然としていると、どんなに優れたプロダクトも市場で埋もれてしまいます。具体的なペルソナを設定するAlterLockの場合、「ロードバイクに情熱を持つサイクリスト」「サイクリング、ロングライドやレースなどで使う愛車を大切にしている人」など。顧客のニーズをデータで裏付けるアンケートやSNS、オンラインフォーラムを活用して、どの課題が実際に重要視されているかを調査します。競合分析を行い、差別化ポイントを明確にする次に、競合製品を徹底的に調査し、どの部分で優位性を持てるかを明らかにします。競合がすでに存在する市場であれば、「どう差別化するか」「どこに優位性があるのか」が成功の鍵です。市場にまだ存在しないカテゴリの製品であれば、類似する製品やそれらの課題点、どのように価値を伝え市場を作っていくのかも考える必要があります。プロダクトコンセプト設計：顧客のニーズに応える形を具体化するユーザーインタビューでリアルなニーズを掴む情熱を持って取り組む課題であっても、実際に顧客が何を求めているかを確認する作業は必須です。自分の想いだけで突き進むと、市場からズレた製品ができあがるリスクがあります。具体的には以下のような方法があります。現場の声を直接聞く：ターゲット顧客に実際に会い、彼らの課題や日常のプロセスを深掘りする。リアルな課題を把握する：「盗難が不安」といった抽象的な意見を、実際に「どのような状況で」「何が解決策となるのか」に落とし込む。IoTならではの付加価値を検討するIoTデバイスを使うことで、どんな「特別な価値」を提供できるかを考えます。競合が単なるGPS機能を提供しているなら、そこに「アラーム」「即時通知」「アプリで見守る」など、付加価値を加えることで差別化することができます。ビジネス規模や価格を考える新規事業におけるビジネス規模や価格設定は、単に数字を決めるだけではなく、顧客の視点や市場の現実を反映した戦略が求められます。ターゲット市場の規模を見積もるまず、自分の製品やサービスがどれくらいのユーザーにリーチできるのか、現実的なターゲット市場の規模を見極めましょう。価格設定の重要性価格は市場における成功を左右する重要な要素です。「高すぎても買われない」「安すぎても価値が伝わらない」というバランスが存在します。顧客目線の価格設定顧客に「この価格なら買いたい」と思える価格帯を探るため、PSM分析（価格感度測定）などの手法を活用しましょう。実例で考えると、1万円なら10万人が購入する可能性がある製品も、2万円では100人、1000人しか買ってくれないかもしれません。このようなシミュレーションを通じて、最適な価格帯を決定します。原価とのバランス価格設定にあたっては、開発・製造・流通にかかるコストを正確に把握し、利益が確保できる価格にすることが必要です。マーケティングについて考える次に、自分の製品をターゲットとなる顧客にどう届けるかを考えます。マーケティングは単に広告を打つだけではなく、製品を正しく理解してもらい、価値を伝えるプロセス全体を指します。顧客に認知してもらうための道筋を描くマーケティングの第一歩は、自分の製品をどのように顧客に届けるかを設計することです。販売チャネルの選定オンライン販売（ECサイト）だけでなく、実店舗や代理店での販売も検討し、最適なチャネルを見つけます。販売店の意見を聞きながら、どのような流通ルートが適切かを模索しましょう。顧客目線での販売体験の設計顧客が製品を購入する際に、スムーズかつ満足度の高い体験ができるようにすることが重要です。例えば、WebサイトのUXや店舗でのPRなどを工夫します。プロモーションのアイデア現代ではSNSやWeb広告を活用することが不可欠です。そういった部分を外注できるサービスも多数存在します。しかし、IoT製品のようなニッチな市場では、発案者自身が情報を発信し、対象となるユーザー層に認知を広げていく活動も重要です。SNSの活用：XやInstagramを通じて、顧客との直接的なコミュニケーションを図ります。動画コンテンツの制作：YouTubeやPR動画で製品の価値を視覚的に伝えると効果的です。業界メディアの活用：業界向けWebメディアや雑誌に広告を出稿し、業界自体や顧客層にアプローチします。インフルエンサーとのコラボ：ターゲット顧客層に影響力のあるインフルエンサーと提携し、製品の価値を伝えます。マーケティングの知識を広げる技術者にとってマーケティングは馴染みが薄い分野かもしれませんが、専門外の分野を学ぶことはビジネス成功の鍵となります。展示会やセミナーに参加する：大規模な広告・マーケティングの展示会では最新のトレンドや実践例を学べます。ツールの活用：デジタルマーケティングを効率化するツール（Google Ads、SEO分析ツールなど）を試してみましょう。Googleだけでなく、ChatGPTやPerplexityなどのAIツールも情報収集に活用できます。製造をどう進めるかIoT製品の場合、クラウドサービスやスマートフォンアプリなどのソフトウェアだけでなく、ハードウェアや通信モジュールも必要になるため、専門的な知識やパートナーシップが重要です。製造のパートナーを探す多くのIoT事業を行う企業は、自社内で全ての開発・製造プロセスを行うのではなく、専門企業と提携しています。特に以下のポイントを考慮しながら、適切なパートナーを見つけましょう。製品設計のノウハウ：金型設計、筐体の強度、防水構造など、製品を量産するための設計ノウハウと実績がある企業を選ぶ。通信開発のノウハウ：Bluetooth, Wi-Fi, GPS, LTE-M, アンテナ設計などの通信部分の開発をスムーズに進められる企業を選ぶ。通信規格と認証の対応：技適認証、Bluetooth SIG、海外展開時する場合は各国の認証規格に対応できるパートナーが必要です。量産品質：量産を行う際にも特有のノウハウがあり、高い量産品質を確保するための様々な試験設備や経験に基づいた手法があります。展示会での情報収集製造業界には多くの展示会があります。IoT開発や通信技術に特化した展示会に参加することで、最新の技術情報を収集し、製造業者との関係を構築することができます。自社製品の製造に強みを持つ企業を見極める目を養うと同時に、そこで得た情報や人脈がパートナー探しに繋がり、製品開発の成功につながります。アイデアと情熱を持つ人を応援します：ぜひ相談を！もしあなたが、情熱と覚悟を持ち、本心から実現したいアイデアがあるならば、ぜひ一歩踏み出してください。私たちも同じように試行錯誤を重ね、失敗と成功を繰り返しながら事業を形にしてきました。また、「自分のアイデアが本当に価値があるのか」「次のステップをどう踏めばいいのか」という悩みを抱えているなら、ぜひ相談してほしいと思います。一緒に課題を深掘りし、解決の糸口を見つけるお手伝いをしたいと考えています。新規事業を形にするためには、何よりも「その課題を解決したい」という情熱と覚悟が必要です。そして、その情熱が周りの人々に伝わるとき、初めて事業は動き始めます。あなたの情熱が、まだ誰も気づいていない課題を解決し、世の中を少しでも良くする力になることを願っています。

IoT新規事業を形にする最初のステップ

はじめまして。ネクストスケープに入社してもうすぐ１年になる鈴木です。アドベントカレンダー「NEXTSCAPE Advent Calendar 2024」に参加することになり、何を書こうか悩みました。１年を振り返ってみると、楽しいこと、大変だったこと、箸にも棒にも掛からぬようなことなど色々ありましたが、今年は資格試験にチャレンジしたのでそれについて書こうと思います。「資格より実践だ！」「習うより慣れろ！」そんな文化で育った昭和生まれの私が、様々な環境に身を置くことでプロジェクトマネジメントについて考え直し、PMPに合格するまでのお話です。     ◆プロジェクトマネジメントが得意と思っていたがそうでもなかった件わりと頼りになる存在だったんです青天の霹靂！？◆PMP受験することでプロジェクトマネジメントを体系的に学ぼうかPMP受験の学習期間　～35時間公式研修～PMP受験の学習期間　～盛大な中だるみ～PMP受験の学習期間　～そろそろ本気出す～◆PMP受験本番受験日前日受験日当日受験後の帰路にてテンションアップからのダウンそして再びアップ◆まとめ ◆プロジェクトマネジメントが得意と思っていたがそうでもなかった件今年ネクストスケープに入社した私ですが、それまでに２つの会社を経験しています。 わりと頼りになる存在だったんです１社目では、自身のプロジェクトのプロマネをする傍ら課長もしていました。プロジェクト絡みだと、部下たちがマネジメントするプロジェクトにアドバイスしたり、炎上すればサポートに入ったり、事が起きれば新幹線に乗って謝罪に行ったり（日帰りで往復10時間の時も！）と、何だかんだ頼れる存在だと自分でも思っていました。あ、いえ、当時はとても頼りになる存在だったと今でも思ってます(笑) 青天の霹靂！？長く務めた会社を辞めて２社目に入ったとき、文化の違いなどたくさんの衝撃がありました。中でも自分のプロジェクトマネジメントについて、1on1で上司から言われた一言。「あなたはコミュニケーション能力はありますが、リスク管理は苦手なんですね」そのときの私は、先回りして色々考えて動いているのにリスク管理できてないの！？と、衝撃を受けました。数日後、前の会社の同僚に確認したところ、２名から非常にわかりやすい回答をもらいました。Ａ「リスク管理というか、コミュ力一本で何でも乗り越えてきたのでは？」Ｂ「アンチを味方につけることはできても、アンチのままの人を納得させることはできないのでは？」そうか、私はリスク管理はできていなかったんだ。とそのとき初めて気づきました。よくよく考えると、プロジェクトメンバーが「もし～～～だったら～～～」みたいな話が出たら、「ネガティブなこと言う人だな、お客さんと話し合えばいいじゃん！」と思っていたような・・・お恥ずかしい。２社目には１年も在籍していませんでしたが、他にもいろんな気づきがあり良い経験でした。 ◆PMP受験することでプロジェクトマネジメントを体系的に学ぼうか今年１月ネクストスケープに入社後、何かきっかけがあったわけではなく、ふとプロマネの勉強をちゃんとしてみようかなと思ったのが２月。せっかくやるならPMPホルダーになろうかしら。と、思ったらすぐにPMPの35時間公式研修に申し込みしました。（そうと決めたら行動は早い方です）そして、上司に「暖かくなると気が緩んで遊んでしまうので、それまでには取りたいんです」と伝えました。この先自分が、盛大に中だるみすることを想像すらしないで。。。 PMP受験の学習期間　～35時間公式研修～35時間公式研修は、やる気のあるうちに受講したかったので２月の休日を選びましたが、休日に7時間×5日間の研修はとっっっても大変でした。膨大な情報量でしたが、事前にテキストを流し読みしておいたおかげもあり授業についていけないということはありません。（事前準備って大事だな）では、何が大変だったかというと、体力です。平日勤務、休日研修、また平日勤務、休日研修、またまた平日勤務・・・体を動かすわけではないので、そんなに疲れないだろうと高を括っていましたが、休日に7時間みっちり研修を受けるのは相当疲れましたね。みなさんも、休日に研修を受ける場合は覚悟してください！ PMP受験の学習期間　～盛大な中だるみ～35時間研修を終え、変な達成感があった私。研修後は、PMP関係のYouTubeを見たり、PMBOKについての講習動画を見たりと、動画によるINPUTだけで満足していました。そんな時、家族が怪我をして勉強から遠ざかってしまいました。離れて暮らしているので、心配したところで何にもなりませんが、勉強しない理由を見つけてしまったのです。そのまま春が来てGWになり、今度は遊ぶことに全力！！伏線回収でしょうか。事前に上司にお伝えしたとおり、暖かくなるとダメなんです私。とはいえ、PMPを受験しようと思ったことは辛うじて覚えていた私が、隙間時間にやっていたことがあります。それは、無意味なネット検索。「PMP　勉強方法」「PMP　合格率」「PMP　受かる気がしない」←勉強する気あるのか！？ PMP受験の学習期間　～そろそろ本気出す～そんなこんなでたまーにINPUTをするだけになっていた私ですが、６月になりこのまま夏が来てしまったらまた遊んでしまうと思い・・・まずはOUTPUT中心の学習スケジュールを立てました。受験日までにやることを洗い出し、それぞれの工数を見積り、スケジューリング。それにより、すべての学習を終えられる日がわかったので、その翌日を受験日として申し込みしました。仕事ならここでバッファを作るべきですが、これはプライベートですし自分の堕落した性格を十分わかっている私はバッファなしにしておきました。毎日21時にスマホのアラームかけて、1日3時間ずつ勉強しました。とはいえ、飲み会などで時間が取れない日や、見たいドラマがあればそちらを優先（ドラマ大好き世代なので）しました。ネットを見ると、どんなに短時間でも必ず毎日学習しろとあったので、そこだけは愚直に守りました。また、当初立てたスケジュールから遅れた分は土日にオンスケにしていました。◆PMP受験本番自分に合った学習計画を組んだおかげで予定していた学習はクリアしていましたが、合格できる自信は持てませんでした。PMP試験には過去問がないこと、暗記問題ではなくシミュレーション問題が大半であることが、イマイチ自信が持てなかった理由だと思います。 受験日前日前日は受験における注意事項を確認しました。受験前のチェックでポケットの中身を見せるというのを知り、パツパツのジーンズではなく、ゆったりしたパンツで行くことにしました。また、冷房がキツイから上着があると良いとあったので、上にシャツを羽織ることにしました。受験日当日田舎に住んでいる私は、受験のため上京。午後からの試験のため、行きの特急ではお弁当を食べてゴキゲンでしたが、着いたらまさかの大雨でちょっとテンションが下がった状態で会場入りしたのを覚えています。そして、前日にしっかり予習してきた受験前のチェック。試験官にポケットの中身を見せるよう促され、素早くそして得意げにポケットをビロンと裏返して出す私。その後「腕まくりをしてください」と言われ焦りました。腕まくりなんで聞いてません。冷房対策のシャツはボタンを外さないと上までまくれませんから。シャツの袖を引っ張り上げ、腕の肉がムチっと残念な形になっているのを試験官に披露し「これ以上はムリです」と伝えました。その後さらに「後ろを向いて髪を上げてください」と言われて、試験官にうなじを見せる私。全体的にシュールすぎて、緊張が解けたので結果的に良かったと思っています。 受験後の帰路にてテンションアップからのダウンそして再びアップなんやかんやで、無事に試験を終えて最後に英語で何やら書いてある紙をもらって会場を出ました。帰りの特急の中で紙を見てみると「congratulation」の文字を見つけて、一気にテンションが上がる私。でもよくよく見たら「once again, congratulations」と書いてあって、英語力ゼロの私は「もう一度受ければおめでとうになるよ」という意味かと思いテンションだだ下がり。そのあと、スマホのカメラで翻訳かけたら「改めて、おめでとうございます」と訳されたので、またテンションが上がる。何はともあれ、英語は多少読めた方がいいですね。◆まとめ本来、世のためになるブログなら学習方法を記すべきでしょうが、そこは探せばいくらでも情報が出てくるので割愛しました。今回私がPMP受験についてお伝えしたかったことは以下の３つです。35時間研修は想像より疲れる自分に合った学習スケジュールを立てることが大事受験前の儀式が念入りすぎて緊張が解ける私のように盛大に中だるみをしてしまっても、再開後にコツコツ学習すれば合格できたので、もしPMPの受験を考えている方はチャレンジしてみる価値は十分あると思います！

プロマネをしていた私がPMPを受験するまでの長い長い道のり

この記事は「NEXTSCAPE Advent Calendar 2024」の5日目の記事です。年末に向けて恒例となりつつあるアドベントカレンダー企画。多くの企業やコミュニティが、12月の1日から25日まで毎日ブログ記事を公開する取り組みを行っています。しかし、多くの執筆者を取りまとめ、期日を守りつつスムーズに運営するのは意外と難しいものです。弊社では今年、Microsoft PlannerとPower Automateを活用してアドベントカレンダーの進捗管理を効率化しました。本記事ではその仕組みをご紹介します！アドベントカレンダー運営の課題アドベントカレンダー運営では、以下のような課題が発生することがよくあります。執筆者のスケジュール管理：複数の執筆者がいると、投稿予定の重複や期日を過ぎるミスが発生しやすくなります。進捗状況の見える化：執筆状況や確認作業が滞ると、予定日に投稿できなくなる可能性があります。リマインドの手間：執筆者に「投稿期限が近づいています」とリマインドする作業が負担になることも。これらの課題を解決するために、PlannerとPower Automateを組み合わせた仕組みを構築しました。Plannerを活用した進捗管理まず、Microsoft Plannerを使って執筆スケジュールを管理しました。Plannerグリッド画面タスクの作成投稿日ごとにタスクを作成し、各タスクに以下の情報を設定しました。タスク名：投稿日付と担当者名担当者：執筆者開始日：投稿予定の3営業日前期日：記事の提出期限バケットで進捗を可視化各タスクに「未着手」「執筆中」「レビュー待ち」「投稿済（レビュー不要）」「投稿済（レビュー済）」などのバケットを設定し、ステータスを一目で確認できるようにしました。Power Automateでリマインダーを自動化Plannerだけでなく、Power Automateを使うことで、リマインダー作業を自動化しました。Plannerからタスク情報を取得Power Automateの「Plannerコネクタ」を使用して、すべてのタスクとその期日を取得。リマインダー条件の設定タスクの開始日あるいは期日の場合、該当タスクの担当者に通知するよう設定。通知の送信Microsoft Teamsを使い、リマインドメッセージを自動送信。通知に「アダプティプ カードを投稿して応答を待機する」を使用することで、進捗状況の収集を行っています。Power Automate フロー実際の運用で得られた効果この仕組みを導入したことで、以下の効果を実感しています。期日管理の負担軽減スプレッドシートや手動でのリマインダー管理では、担当者への通知を漏らすことがあり、進捗確認に多くの時間と心的負担を割いていました。これが自動化されたことにより、管理者の作業が大幅に減少しました。タスクの見える化Microsoft Plannerでタスクをバケットに分け、ステータスを一目で確認できるようにしたことで、進捗確認のために個別に連絡する手間が減少しました。執筆者の安心感リマインダーが人間ではなくボットから送られる仕組みによって、「進捗確認されている」という心理的な圧迫感が軽減される効果が……あるかもしれません。ここは今年のフィードバックを楽しみにしようと思います。 まとめアドベントカレンダーの運営は、多くの人が関わるため管理が難しくなりがちです。これに Microsoft PlannerとPower Automateを組み合わせることで、タスク管理とリマインダー通知を効率的に行う仕組みを構築できました。このようにツールを活用することで、運営側の負担を軽減しつつ、執筆者も安心して執筆に集中できる環境を作ることができます。今年のアドベントカレンダー運営で、ぜひ試してみてはいかがでしょうか？ 参考【Power Automate】今日期限のPlannerタスクをTeamsで通知【フロー作り方解説】 | ていじテックTeamsのPrivateチャネルにPower Automateでリマインド投稿をする #PowerAutomate - QiitaPower AutomateでTeamsにメンションを付けて投稿する方法を解説します！ | てじらぼPower AutomateでTeamsにメンションする方法(ユーザー/タグ/複数人) - unite365Power Automateでアダプティブカードで応答を待機する方法！ | てじらぼPower Automate の Teams コネクタでアダプティブカードを利用する際の TIPS①【アダプティブカードで入力した内容を受け取る】 #PowerAutomate - Qiita

アドベントカレンダーの運営を効率化！PlannerとPower Automateで実現するスムーズな進捗管理

この記事は「NEXTSCAPE Advent Calendar 2024」の4日目の記事です。 紆余曲折あって、私はこの春から営業セクションを担当している。今まで、案件やら部門やらのマネージメントをやって来た私にとって、ほぼすべてが初めての経験だった。分からないことは多いし、失敗することもあるし、当初は辛さが勝っていたが、漸く最近になって、新しいものや知らないものに携わる楽しさを感じるようになってきた。ネクストスケープの「営業セクション」って、実は今まで、アルようでなかったり、ナイようであったり...私が入社した2018年より前は違ったのかも知れないが、過去の詳しいことは分からない。ライセンス販売等の一部業務は例外として、少なくてもこの春の時点で「営業セクションの役割」などという定義は、存在していなかった。ネクストスケープでは、既存顧客に対するフォローや取引拡大のための活動は、案件のPMやチームメンバーが一貫して担っている事が殆どだ。新規顧客の開拓という点では、トップセールスか、有難くも外部から頂戴するご紹介が機会となっている。この手法でも、毎年度見事に予算を大幅に超えてくる部門もあるし、トップセールスは高確率で結果をだすので、良くも悪くも「営業セクション」が存在しなくても、誰も困らなかったというのが経緯だと思っている。そんな環境で、私は今、営業セクションを担当している。今までは何とかなっていたのだが、このご時世「何等かの事情で既存顧客との取引が突然停止する」とか「トップがプロのロードレーサーに転身する等と言い出す」とかいった事が現実に起こりえる。そしてなにより、会社を成長させ続けることを考えた時、そう遠くない段階で、スループットが限界に達してしまうと思う。故に、今改めて「営業」という機能を会社として獲得することが必要になっているのだと考えているし、それを信じて日々業務にあたっている。さて、ここまで「営業」という言葉を使ってきたが、それは具体的に何を表しているのか。便宜的に「マーケティング」、「インサイドセールス」、「フィールドセールス」、「カスタマーサクセス」の4つで言うなら、私が思うネクストスケープにおける「営業」とは、この全てのプロセスを主導するものだ。「マーケティング」や「インサイドセールス」では、幅広い知識と洞察力を求められるし、「フィールドセールス」や「カスタマーサクセス」においては、時に泥臭い（人間味あふれる）人付き合いなんてものも求められる。一般的には、夫々のプロセスに専任のセクションが設けられていることが殆どだと思う。なるほど、では、そういった幅の広い業務をこなすために「営業セクション」を立ち上げ直そうとしているのかというと、それは否だ。私たちが目指すべき「ネクストスケープの営業」とは「人」でもなければ「セクション」でもない。個人的には、世の中に種々議論がある通り、究極はSIerに営業の専門職は不要になるのだろうとさえ思っている。では、いったい何を目指すのか?私は「営業」というのは、一人一人が顧客に価値を提供できるようになるために、身に付けなくてはいけない「技法」と捉えたいと思っている。例えば、「データベースに詳しい」+「営業もできる」とか「プロジェクトマネージメントの経験が豊富」+「営業もできる」とか。ものの本にも書いてあることだが、この形がネクストスケープには一番マッチするんだと思う。その「技法」を身に着けられる環境を作っていくのが私のミッションだと信じている。悲しいかな今は「営業」というワードから何を連想するのか、「事務処理やっといて」とか「打ち合わせの日程調整しといて」とか。ま、やりますけど。あぁいかん。これはただの愚痴。 でもそういうことをやりたいんじゃない。目指す未来を実現するには、本当にやることが多い。方法論を学ぶのに加えて、現場でリアルな経験を積む必要もあるだろうし、そういった環境をあまねく全社員に提供できるのか?とかとか。でも、ネクストスケープがさらに強くなるためには絶対に必要なことだと感じているので、今は信じてこの道を進もうと思う。