2025年2月4日、株式会社ナウキャスト主催の勉強会「

本イベントは、「運用も含めてデータを用いて価値を出すために奮闘するエンジニアが集まり、知見を共有する」ことを目的とした会で、今回は3社（株式会社ナウキャスト、株式会社estie、株式会社アイスタイル）が登壇し、それぞれの現場におけるデータプロダクトやデータ基盤開発・運用の実践例が紹介されました。

昨今、データ活用が企業競争力の鍵となる一方で、

 という言葉が示すように、データの品質が低いままでは正しい分析や価値創出は困難になります。

本勉強会では、そうしたデータ品質を支える仕組みや組織、そして各社が実践するDataOpsの取り組みが紹介され、盛りだくさんの内容となりました。

1. マルチデータプロダクト開発・運用に耐えるためのデータ組織・アーキテクチャの遷移（ナウキャスト）

https://speakerdeck.com/mtpooh/evolving-data-org-architecture-for-multi-product-development

最初に登壇したのは、オルタナティブデータを活用したデータプラットフォームを提供する

同社では「データそのものをプロダクト」として扱うビジネス上、膨大なデータソースを収集し、様々な顧客企業にデータを提供しています。

スピード感ある開発と高品質な運用を両立するため、組織体制やデータ基盤のアーキテクチャをどのように変遷させてきたかが紹介されました。

「泥臭い取り組みを楽しみながら、全体最適をどう実現するか」が重要と強調されていました。

2.  自動と手動の両輪で開発するデータクレンジング（estie）

https://speakerdeck.com/estie/estie-data-cleansing-pipeline

2番目に登壇したのは、商業用不動産のデジタルインフラを展開する

オフィスや住宅など、さまざまなデータパートナーから集める物件情報のクレンジング手法が紹介されました。

大量データを自動でカバーしながら、残りを人手で正しく修正する

」仕組み作りが重要とのこと。

特に商業用不動産のように曖昧さや入力ミスが多い領域では、人間が入るプロセスをどう整備するかがカギになるそうです。

3.  データ基盤の成長を加速させる：アイスタイルにおける挑戦と教訓（アイスタイル）

https://speakerdeck.com/tsuda7/detaji-pan-nocheng-chang-wojia-su-saseru-aisutairuniokerutiao-zhan-tojiao-xun

コスメの口コミサイト「@cosme」を運営する

では、全社的なデータ基盤をGoogle Cloud上で刷新中。

構築〜運用の中で起きた課題と、その振り返りが共有されました。

組織再編で「データ基盤側 + 事業側」が連携するプロジェクト体制が整いつつあり、今後は「データ活用を主体的に行う分散的モデル」を目指しているそうです。

質疑応答では、データ基盤のコスト管理やプラットフォームチームの在り方、データガバナンスの推進方法など、各社共通の悩みや工夫が議論されました。

ビジネスの本丸としてデータを扱う

3社が、いかにデータ品質と運用体制を整えているかを具体的に共有してくれました。それぞれ異なる背景・アーキテクチャを持ちつつも、

といった共通テーマが見られ、リアルな実践知が詰まった会となりました。

データプロダクトが増え、データソースも広がっていく中で「どれだけ高い品質を効率よく保てるか」は企業にとってますます重要になります。今回紹介された取り組みや教訓は、多くのデータエンジニアやデータ活用部署にとって大いに参考になるはずです。

DataOps Nightは今後も定期的に開催されるとのことなので、引き続き情報共有の場として注目していきたいと思います。

DataOps Night #6 イベントレポート

toitech

本記事は ジンジニアアドベントカレンダーとして note で作成した記事  

チームメンバーなど人に関わる方がキャリアコンサルティングを学ぶべき２つの理由

 を掘り下げ、エンジニア領域でのキャリアコンサルティングについて記載します。

元の記事では以下のような内容について記載しました。

大まかに「エンジニア職として働く人が考えるキャリア」は以下のようなケースがあるように思います。

このような様々な方向性に対し、エンジニア職の方々に関する情報はかなり多くのものが公開されており、近年ではこれまでなかった職種も生まれてきています。（フロントエンドエンジニアという名前が出てきたのが2005年ごろ、ITの領域でのデザインエンジニアという名前は2020年ごろのようです）

情報の取捨選択が得意な職種ではあるものの、キャリア戦略を考えるにあたってはスピードも激しく、転職サービスに登録すればスカウトもくる。周囲との比較もしやすくなっている分、向こう3年位を見据えると「悩み」というよりも「迷い」が出てくるタイミングの多い職種ではないかと思います。

「悩む」と「迷う」と「考える」

」には「悩む」と「考える」の違いを

答えが出るか出ないかという前提 

に置いています。エンジニア職は業務の特性上「考える」ことは機会としても多いものの、違いを意識しないで取り組んでしまうといつのまにか悩んでしまうことがあるのかもしれません。

また、「悩む」「考える」ともに勘違いしやすいのが「迷う」ことです。

「AとBどちらが良いのだろうか」という際の多くのケースはだいたいの場合において「迷う」になったまま行ったり来たりしているのです。「考える」プロセスを経る際に、メリット・デメリット（プロコン）をリストアップするものの、そこから基準を明確に決めることができずに「迷う」プロセスに入りがちです。

キャリアカウンセラーのためのスーパービジョン

」では、「不安」「心配」「やっかいな問題」などを、相談者が抱える「悩み」として表現しているが、その原因を

自身が肯定し、自尊感情のよりどころとしている自己概念、良しとしているものの見方や考え方が揺らぐ経験

これらを踏まえると、「なぜ悩むという状況に至ったのか」を整理し、その結果としての自身の価値観等のゆらぎがどのように起こったのか（例えば興味関心と、その選択肢を選んだことによる収入の増加が見込まれるかなどのギャップ、あるいはそこにチャレンジしたときの失敗に対しての恐れなど）という、自身の選択軸がどこにあるか寄り添っていくことで自身が結論に至る支援ということが一つの鍵になってくるのではないかと思います。

以上のようにエンジニア職の環境面での特徴として、「迷い」に陥りがちな環境であり、ふとした外部刺激でそのモードに入ってしまうと、考えることやその材料集めがやや得意であるからこそハマってしまうという傾向があるのではないかという仮説について書きました。

他の職種の中にはそもそも選択の幅が比較的狭い「キャリアパス」が限定的な職種もあります。この20年くらいでキャリアの選択肢が広がっていることを良しとして捉え、仕事理解のみならず自己の判断基準を経験を通して見直していくことで主体的な選択ができることをご支援できればと思っております。

エンジニア領域におけるキャリアコンサルティングの特徴

てつのすけ＠エンジニアｘキャリアコンサルタント

2025年2月3日（日本時間）にChatGPT 「deep research」がリリースされました。

多段階リサーチを自動化するAIエージェント

ウェブから大量の情報を収集・分析し、包括的なレポートを作成できます。

指示を一度出すだけで、まるでリサーチアナリストのように自律的に調査を進めるのが特徴です。

今回は、deep researchを使って、「スポットコンサル（エキスパートネットワーク）サービス」のグローバル動向をレポートにしてみようと思います。

 モデルを選択しつつ「詳細なリサーチ（deep research）」を選択する。

② チャット形式でレポートの観点を指定

以下のようなレポート（約15000文字）が8分ほどで生成されました。

30件のWeb上の記事が参照されているようです。

日本語で公開されていない情報も適切に収集して網羅的なレポートができているように見えました。英語圏はもちろん、中国語の情報もカバーしており非常に有益な情報が得られました。

いっぽうで、特定のメジャーな企業についてのレポートを依頼すると参照先のほとんどがwikipediaになりwikipedia読んだ方がはやいって感じになります。

情報が世界中に多言語で分散していて、情報の非対称性がある領域に非常にマッチするように思いました。

【OpenAI】ChatGPT deep research で業界動向レポートを作成してみた

この記事では、プロダクトマネージャー（PdM）であれば必ず知っておきたい「要求定義」と「要件定義」の違いを徹底解説します。

日本語ではどちらも似たような言葉に思われるかもしれませんが、実は「インド」と「インドネシア」くらいに違うもの。。

ここを誤解してしまうと、プロダクト開発の方向性がズレたり、エンジニアとのコミュニケーションがかみ合わなかったりします。

多くの現場では、PdMの担当範囲が「要求定義」にまでとされることがほとんどです。では「要求定義」は何を指し、「要件定義」とはどう異なるのでしょうか？

本記事では、要点を押さえつつ、例え話や海外との比較も交えて解説します。

多くの開発プロジェクトでは「要件定義」という言葉自体は耳にするものの、その前段階にある「要求定義」とどう違うのかを明確に区別できないケースが散見されます。とくに日本の企業文化では、仕様策定までPdMが担当することも珍しくありません。そこで「要求定義」と「要件定義」の大枠を整理し、PdMとして押さえておくべきポイントを中心にご紹介します。

まずは本題である2つの用語の定義を確認しましょう。

ユーザーや顧客の課題・目的を定義し、プロダクトとしてどんなゴールを目指すかを言語化します。ビジネス要件やUXの観点でのゴールを明確にし、

（Why）を深掘りするフェーズです。

要求定義で明確化された目的を達成するために、どんな機能が必要か、どのような技術的選択肢をとるべきか、システム要素を具体化します。いわゆる

”（What）を詰めるフェーズです。

要求と要件は、日本語で見ると言葉が非常に似通っているため、つい混同しがちです。もともと英語圏では両方とも「Requirement」という単語で表現されるため、「誰の要求か」で区別されることが多いのも混乱の元かもしれません。

このように英語では「User」「System」など、主語を分けることで区別するケースが一般的です。しかし、日本語では同じ「要求」「要件」という単語に置き換わってしまうため、どこで線を引くべきかが曖昧になりがちです。

例：「旅行計画」で考える要求と要件

ここでは分かりやすく「旅行計画」に置き換えてみましょう。あなたが友人と一緒に旅行の計画を立てるとします。友人は言います。

これが「要求」にあたります。要するに「楽しくリラックスしたい」という“

”です。一方、要件としては「どうすればその要求を実現できるのか？」を具体的にリストアップしたものになります。

たとえば以下のような要件が考えられます。

これらは「楽しくリラックスしたい」という要求を実現するための“

”です。もし宿を手配せずに出かけたり、移動手段の確保を怠ったりしたら、大変なことになりますよね。

また、友人Aの要求を掘り下げると、もしかしたら「一緒にインスタ映えする写真を撮りたい」「普段仕事が忙しいから、とにかく昼過ぎまで寝ていたい」といった、本当のニーズが隠れているかもしれません。その場合、要件の内容も変わってきます。

ここでもし、要件が抜け落ちていると「温泉つき旅館を取っていなかった…」「移動方法を決めていなかった…」といった問題（要件漏れ）が起きます。これが旅行計画における“要求”と“要件”の違いです。

英語表現から理解する要求と要件

前述のとおり、英語圏では要求も要件もまとめて「Requirement」という言葉が使われます。ただし、

「誰にとっての要求・要件か」

を明確にするのが一般的です。

プロダクトの開発プロセスでは、

User Requirements（ユーザー要求）からスタートし、それを満たすためのSystem Requirements（システム要件）

を決めていく流れが王道です。

PdMの役割と「要求定義」が重要な理由

日本の開発現場ではPdMに幅広い業務が求められがちですが、基本的にはプロダクトマネージャーは「何がユーザーの課題で、どんな価値を提供すべきか」という要求定義までを担うことが大半です。具体的にシステムの構造やアーキテクチャ、詳細仕様をどうするかといった部分は

もちろん、PdMがエンジニアリング知識をまったく持っていないと、適切な判断ができないケースもあります。しかし、だからといってPdMが要件定義から仕様策定までを1人でやりきるのは、効率的とは言えません。

チームで分担し、それぞれの専門性を活かすのが理想

要求定義を誤るとどうなるか？

要求定義が曖昧なまま要件定義を始めてしまうと、開発が進むにつれて「そもそも何のためにこの機能を作っているんだっけ？」という根本的な疑問が浮かび上がることがあります。この状態は非常に危険で、プロダクトが完成したときには本来ユーザーが抱えていた課題がまったく解決されていない、という悲劇にもつながりかねません。

PdMとしては「ユーザーの課題は何か？」「なぜそれを解決する必要があるのか？」「解決できた場合、ビジネス上どんなインパクトがあるのか？」を深く考え抜くことこそが、最も重要な役割です。

日本特有の「内製」と「受託」文化

なぜPdMが「要件定義」までやることがあるのか？

海外では社内に開発チームを抱えた

が一般的なため、PdMはあくまで「ユーザー課題の整理」や「方向性の決定」を行い、技術的な決定や詳細設計はエンジニアが担うことが多いです。

一方、日本のIT業界には長年、**外注（受託）**の文化が根づいています。クライアント企業が開発ベンダーに一括でシステム開発を依頼する場合、要件定義から仕様策定、実装、テストまでを「プロジェクトマネージャー」が主導して進めます。この場合、技術的な要件や仕様策定もPdMの範疇に含まれてしまうケースが多々あります。

結果、「要求定義」「要件定義」「仕様策定」が1人のPdMに押し付けられることもしばしば。ただ、これは日本特有の慣習であり、

本来はエンジニアリングの知見を持った専門家と協力して進めるべき工程

日本では受託案件が多いことから、どうしてもPdMが広い範囲をカバーしなければならない事例が目立ちます。ただし、最近ではSaaSベンチャーをはじめ、内製を強化する企業が増えてきており、PdMとエンジニアの役割分担がはっきりしている現場も少しずつ増えつつあります。

要求・要件・仕様をどのように整理する？

よく言われる整理方法としては「Why（要求）→What（要件）→How（仕様）」の三段階に分けるやり方があります。

それぞれが混同されないようにするためにも、議論するときは必ず「今はWhyについて話しているのか、Whatについて話しているのか、それともHowなのか？」を明確にするのがおすすめです。

最後に、本記事の内容を整理しましょう。

プロダクトマネージャーとしては、まずは

を突き詰め、それを整理・優先順位づけすることに注力しましょう。開発チームと手を組みながら要件（手段）や仕様（具体策）を固めていくのが、理想的なプロダクト開発の流れです。

今後、内製化がさらに進むにつれ、日本でも「要求定義をPdMが中心に行い、要件定義はエンジニアと共同で進める」というスタイルが主流になる可能性が高いと考えられます。自社開発のSaaS企業などではすでにそういった体制を敷いているところも多く、確実に文化は変化してきています。

最終的には「要求とは目的であり、要件とは手段である」という理解を忘れずに、プロダクトが生み出す価値を最大化するためのプロセスを整えていきましょう。そうすれば、チーム全体がやるべきことを見失うことなく、スムーズに開発を進められるはずです。

プロダクトマネージャーとして、ぜひ自社の開発体制やプロセスがどうなっているのかを振り返り、要求と要件の切り分けがうまくいっているかチェックしてみてください。きっとプロダクトの品質向上やチームの効率化につながるはずです。

【PdM必見】要求定義と要件定義の違いを徹底解説：目的と手段を正しく理解する

【ほぼ無料】WordpressをCloud Run+GCS+Supabaseで動かす

AIエージェントが非常に盛り上がってきましたね！

いま、AIにコーディングさせるなら、最も有名なのは

ClineはVSCodeのExtensionとして利用でき、Human-In-the-loopで人間がAIをリードする形で半自動でコーディングさせる最高のツールです。

Clineをフォークしたプロジェクトも非常に多く出てきており、最高の盛り上がりを見せているといっても過言ではありません。

もっと自動でAIにコーディングをサポートしてもらう。

具体的には、Slackで要件を投げるとPR作成まで行ってくれるサービスに

 と月額$500という業界最高水準の価格設定が課題です。エンジニアを1人雇うと考えれば安い…などいろいろと考え方もありますが、ちょっと試すには勇気のいる金額ですよね。

Devinのオープンソース版ともいえるOpenHands（旧: OpenDevin）は無料で使えます。

Slackとの連携はできませんが、なんといっても無料で使えるのは非常にうれしいですね。

今回は、OpenHandsを使って、実際に

GitHubと連携し機能開発を行いPRを作成

させるところまで自動で動作させてみたいと思います。

全く同じプロンプトを用いてClineで開発したときの差分を比較

し、使用感についてまとめています。

おまけとして、Devinはブラウザを扱えるため、ブラウザを使ったユースケースについても簡単にまとめておきます。

自分で実証実験を行うにはちょっとヘビーな内容をまとめてみた

ので、ぜひ気になるところだけでもご覧ください。

本記事の手順を手元で実行するために必要な知識

Dockerイメージを利用してOpenHandsを立ち上げる

OpenHandsはDockerイメージが提供されているため、 

 を長ったらしく書くのは好きではないので以下のような 

version: '3.8'

services:
  openhands-app:
    container_name: openhands-app
    image: docker.all-hands.dev/all-hands-ai/openhands:0.21
    pull_policy: always
    environment:
      - SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.21-nikolaik
      - LOG_ALL_EVENTS=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ~/.openhands-state:/.openhands-state
    ports:
      - "3000:3000"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    tty: true  # -t オプションに対応
    stdin_open: true  # -i オプションに対応
    


 にアクセスするとAPIキーが求められるので、お好きなprovider / model のAPIキーを入力して使ってみます。

OpenHandsにHacker newsの人気記事を日本語で要約させる

Hacker newsの上位3件を日本語で5行程度に要約して

 と単純なプロンプトを投げてみます。

極めて単純なプロンプトですが、実際にブラウザを起動しています。

さらに各ページにアクセスし、タイトルだけではなく内容までFetchしたうえで日本語の要約を作成してくれています。

要約の内容は以下のようなもので、日本語としても全く問題ないものでした。

「強化学習による推論能力の進化」（671ポイント） 
DeepSeek-R1という新しいLLMモデルが発表され、強化学習を通じて推論能力を向上させる手法が提案されています。
従来のLLMと比べて、より論理的な思考と推論が可能になったとされています。

「Steam Brick：画面もコントローラーもない、電源ボタンとUSBポートだけのデバイス」（417ポイント）
極めてミニマルなゲーミングデバイスのコンセプトが提案されています。
必要最小限の機能だけを備え、シンプルさを追求した設計が特徴です。

「強化学習による推論の出現」（89ポイント） 
AIシステムにおける推論能力の発達について研究された論文が公開されました。
強化学習を用いて、より高度な推論能力を持つAIシステムの開発方法が示されています。


１年前にこのようなフローを実装しようとした場合、クローラーを自前で用意するか、

 のようなクローリング可能なAPIとLLMを連携させてフローを作成する必要がありました。

ワークフローの作成を全く意識することなく、ただプロンプトを一行書くだけでやりたいことが実現できました

。この自由度は圧倒的で、まさに未来を感じる体験です…!!

とはいえ、これだけなら手動でワークフローが組めてしまうのも事実。

OpenHands の本領たるプログラミング領域のことをやらせてみましょう。

これをクリックするとさらにダイアログが出現し、ConnectからGitHubのアクセストークンを発行することが出来ます。

発行後、フォームにトークンを入力するとOpenHandsにGitHubへレポジトリの閲覧やPR作成の機能が解放されます。

OpenHandsに自然言語で指示してPRを作成してもらう

GitHubとの連携後に、Open a Repo で作業したいレポジトリを選択してプロジェクトをつくってみると、以下のようなサンプルが提供されます。

 からREADMEを作ってもらいましょう。

今回はexampleとして提供されているプロンプトが英語なので、作成されるREADMEも英語でした。そこで、「日本語に要約して」という指示を送るとちゃんとREADMEを作成してくれました。

今回はDiffもよさそうだったので、

すると、PRが自動で作成されています！！

PRまで作ってくれるのはOpenHandsのとても良いところですね。

READMEだけだとありがたみが少ないので、実際に機能開発もさせてみましょう。

また、Human-In-the-loopなClineでも同じ機能開発をして、比較も行ってみます。

OpenHandsで機能開発のPRを作成してみる

によると、100行を超えない程度の単一の機能開発が推奨されています。

https://docs.all-hands.dev/modules/usage/prompting/prompting-best-practices

ちょうど現在個人開発しているアプリについて、インメモリストレージに保管しているデータを、ローカルDBに保存する処理だと100行未満の良い題材になると思うので試してみました。

app/lib/screen/stock_screen.dartで記事をストックするとき、
インメモリに保存されるようになっていますが、
isarに保存されるよう修正してください

プロンプトは上記のようにして実行した結果がこの通りです。

プロジェクトのアーキテクチャを理解したうえで、適切な箇所にコードを生成することが出来ています。

今回Fllutterのプロジェクトの機能開発を行ってもらったのですが、立ち上げたコンテナには Flutterをインストールしておらず、OpenHands内では動作確認できませんでした。

しかし、OpenHandsは動作確認が不十分であることを理解し、動作確認項目としてチェックリストを作ってくれます。

したがって、開発時にはゼロから開発を行う必要はありません。動作確認リストに従い修正を行っていけば良いというスタイルです。

OpenHandsとClineのアウトプットを比較してみる

2025年1月現在、AIコーディング支援ツールの主要プレイヤーとしてClineが存在します。

ClineにはPRの作成はありませんが、

単一の機能開発レベルではOpenHandsとどのような差分が出るのか、どちらもClaude-3.5 sonnet を用いて実験

ClineはOpenHandsよりもかなり細かくファイルの確認を行い、ユーザーに同意を求め

また、Cllineはローカルで実際にコマンド実行が可能なので、 

 のようなコマンドを逐次実行し、着実にコード修正を進めていきました。

細かい変更が確実に動くという意味ではClineの方が安心感

プロジェクトのアーキテクチャ

をしっかりと理解しているかという点においては、

具体的には、Flutterで利用するローカルストレージのisarは、特定のmodelだけではなく複数のmodelを扱うため、共通化しておくような設計をしておく方が使い勝手が良いと言えます。

OpenHandsは上記のアーキテクチャを理解し、最初から一発でそのようにコーディングしてくれました。

一方、Clineは愚直にProviderの中でisarを初期化して呼び出していました。

アーキテクチャ設計の観点では、OpenHandsがより優れたコード生成能力を示しました。

また、「StorageをインメモリからローカルDBに変えてくれ」という指示に対し、

OpenHandsは表示部分でもローカルDBの内容を反映

するようコーディングしてくれました。

しかし、Clineはプロンプトの内容通り、データ周りのみ反映しただけで、表示部分は改修してくれず、気が利かない部分があるなと感じました。

Clineは下記のように3ステップの指示が必要でした。

OpenHandsは、最初の指示のみでClineの1-3までの手順をすべて実行してくれました。

Clineの場合、途中で人間の指示を都度必要とすることも相まって、コーディングのスピードもOpenHandsの方が数倍早いことも特筆すべき特徴です。

もちろん、VSCodeとのシームレスな連携機能はClineの強力な利点と言えます。

まとめ：AIコーディングツールの現状と選択基準 