※当サイトの記事には、広告・プロモーションが含まれます。

Azure Database for PostgreSQL フレキシブル サーバーの作成後の接続方法の変更はできない罠

productzine.jp

 優先順位付けについてまず指摘されたのは、議論の「土俵」の問題だ。小俣氏は「社内ステークホルダーとの会話は、機能やアウトプットの話に陥りがちです。そのほうが会話がしやすいからですが、機能単位だと合意は取りやすい反面、より本質的な『ユーザー課題』の議論が後回しになってしまいます」と指摘する。

「作る前」の意思決定が勝負を分ける──ジョーシス流プロダクトディスカバリーとPMの新たな役割 (2/2)|ProductZine(プロダクトジン)

 ユーザー課題はソリューションよりも上流にあるため、その優先順位を議論できる素地を作ることが重要だと小俣氏は強調する。インパクトの大きな意思決定ほど、課題起点の優先順位付けが問われるからだ。

「作る前」の意思決定が勝負を分ける──ジョーシス流プロダクトディスカバリーとPMの新たな役割 (2/2)|ProductZine(プロダクトジン)

 その素地を作るために実践しているのが、ペルソナごとに「満たせているニーズ」と「満たせていないニーズ」を整理するアプローチだ。必ずしも精緻な分析である必要はない。これを対話のベースとして持つことが、機能レベルの会話を課題レベルの議論へと引き上げる起点となる。

「作る前」の意思決定が勝負を分ける──ジョーシス流プロダクトディスカバリーとPMの新たな役割 (2/2)|ProductZine(プロダクトジン)

 AI活用やコーディングエージェントによるプロトタイピングが進み、プロダクトマネージャーの業務が高度化する中では、アイデア管理や優先順位付けを支える「基盤」も重要になる。

「作る前」の意思決定が勝負を分ける──ジョーシス流プロダクトディスカバリーとPMの新たな役割 (2/2)|ProductZine(プロダクトジン)

 セッションの締めくくりに、渡辺氏はそのソリューションとして「Jira Product Discovery」を紹介した。アイデアの一元管理から優先順位付け、ロードマップ作成、そしてJiraバックログとのシームレスな連携まで、プロダクトマネージャーが直面する課題に応えるツールだ。

「作る前」の意思決定が勝負を分ける──ジョーシス流プロダクトディスカバリーとPMの新たな役割 (2/2)|ProductZine(プロダクトジン)

⇧ まぁ、やる事が多いにもかかわらず、

youneedaken.hatenablog.com

⇧ 上記サイト様にありますように、「機能」、「非機能」的な「ソリューション」の「情報」の整理であっても、非常に困難という問題もありますしな...

そもそも、

  1. 要求
  2. 要件

に落とし込んでいく必要があるのが「ソフトウェア開発」であると思われるので、「機能」、「非機能」的な「ソリューション」の話に引っ張られるのは致し方ない気もしますが...

まぁ、「ソフトウェア開発」の一般的な「ベストプラクティス」のようなものが確立されていないことが現場をカオスにさせているとは思いますが...

とりあえず、

mag.executive.itmedia.co.jp

www.ipa.go.jp

⇧ 上記サイト様にありますように、

  1. 要求
  2. 要件

の粒度をハッキリさせて欲しい気はしますな...

Azure Database for PostgreSQL フレキシブル サーバーの作成後の接続方法の変更はできない罠

検証環境の構築をしていて、既存の構築手順に記載が無く「デフォルト」の設定で問題ないのだな、と思っていたら、然にあらず...

と言ったことがあるあるだとは思います、哀しいことですが...

公式の「ドキュメント」を見てみると、

learn.microsoft.com

プライベート DNS ゾーンを使用する

Azure 仮想ネットワークでプライベート ネットワーク アクセスを使用する場合は、DNS 解決を有効にするためにプライベート DNS ゾーン情報を指定する 必要があります 。 プライベート ネットワーク アクセスを使用して作成された新しい Azure Database for PostgreSQL フレキシブル サーバー インスタンスの場合は、プライベート アクセスを使用して Azure Database for PostgreSQL フレキシブル サーバー インスタンスを構成するときに、プライベート DNS ゾーンを使用する必要があります。

https://learn.microsoft.com/ja-jp/azure/postgresql/network/concepts-networking-private

⇧ とあるのだが、

learn.microsoft.com

⇧ 作成後に「変更」できないという罠...

これ、もうちょっと、目立つようにして欲しい...

サラッと書かれているが、「データ」を「永続化」するような役割の「リソース」に対して再作成が必要になるというのは、厳しいのよね...

 

まぁ、相当に重要な選択肢であるとは思われるのだが、構築手順に記載が無いのがなかなかに辛いのよね...

手順がメンテナンスされていない状況での環境構築、ストレスでしかない...

諦観漂うのだけれども、「味方に背中から撃たれる」という感じなのかな...

味方だと思っているのが自分だけというオチもあり得るので何とも言えませんが、このあたりが外様の辛みというところでしょうかね...

まさに、

計算機科学において、Garbage In, Garbage Out(ガービッジ・イン、ガービッジ・アウト/ガベージ・イン、ガベージ・アウト)、略してGIGOとは、欠陥のある、または無意味な(garbage)入力データは無意味な出力を生み出すという概念である。直訳は「ゴミ入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。

Garbage in, garbage out - Wikipedia

⇧ 上記の状況に否応なく陥っていると言える...

う~む...、今日も今日とて、不毛な時間を費やすだけの日々だった...

 

毎度モヤモヤ感が半端ない…

今回はこのへんで。