システム開発の定例会議を改善する8つのプラクティス システム開発における定例会議は、関係者の認識をそろえ、必要に応じて課題を議論し、意思決定する場にもなります。ただし、定例会議を唯一の意思決定の場にすると、次の開催日まで判断や対応が止まりかねません。顧客を含む多くの関係者が参加する会議では、目的と参加者に合った議題を扱い、その場で資料を読み始めたり、一部の担当者にしか関係しない議論を続けたりしないことが大切です。 本記事は、定例会議の目的を明確にし、会議待ちによる遅れを減らすための8つのプラクティスを説明します。PMIに掲載された実務記事、GitLabの公開ハンドブック、Atlassianの会議運営ガイドなどを参考にし、システム開発の定例会議への適用方法として整理しました。 プラクティス 定例会議で避けること なぜ避けるべきか? 重要情報を定例会まで持ち越さない(No Surprises) 重要情報を定例会まで持ち越す 顧客が影響を確認する時間を失い、必要な調整や対応の開始も遅れるためです。 目的に合った議題と参加者を守る(Agenda Discipline) 目的や参加者に合わない話題を、その場で長く議論する 必要な議題を扱う時間が減り、関係しない参加者も待たせるためです。 資料を事前に共有し、不明点を確認する(Pre-read) 会議で初めて資料を読む、全員で読み上げる 各自で確認できる内容に、参加者全員の時間を同時に使うことになるためです。 集まる目的がなければ開催しない(No Agenda, No Meeting) 共有・議論・判断することがないのに集まる 会議で得られるものがなく、準備と参加の負担だけが生じるためです。 対応事項を定例会待ちにしない(Action Item Management) 定例会まで担当決めや作業開始を待つ 着手できる作業が会議待ちになり、定例会の開催間隔が進捗を制限するためです。 決定済みの内容と根拠を共有する(Decision Log) 決定済みの事項をその場で蒸し返す 同じ議論を繰り返し、決定済みの内容を前提に進む作業にも混乱を招くためです。 保留した論点を記録し、担当者へ引き継ぐ(Parking Lot) 論点を保留するだけで、記録や引き取り先を残さない 必要な確認が抜け落ち、同じ話題が繰り返し定例会に持ち込まれるためです。 責任者と決定者への確認経路を明確にする 定例会の出席者に判断を委ねる 判断権限のない人が決めたり、本来の決定者への確認が遅れたりするおそれがあるためです。 重要情報を定例会まで持ち越さない(No Surprises) 重要情報の共有を、定例会議の開催日まで待ってはなりません。 納期遅延、追加費用、重大な品質問題などは、把握した時点で共有し、必要な対応につなげます。既に把握していた重要情報を、定例会で顧客に初めて知らせることを避けます。

I Built a Browser-Only WBS/Gantt Chart Project Management Tool Even in agile development, there are moments when you need to work out a schedule while keeping track of cross-sprint dependencies, release dates, and who’s available when. Issue trackers like JIRA or Backlog are great for day-to-day task management, but when you need to reason about a WBS hierarchy, task dependencies, and each person’s workload together, you often end up putting the plan together separately anyway. And every time a single task’s schedule changes, re-checking the knock-on effect on downstream tasks and everyone’s workload gets tedious fast.

ブラウザだけで使えるWBS／ガントチャート型プロジェクト管理ツールを作成しました アジャイル開発でも、スプリントをまたぐ依存関係、リリース予定、担当者の稼働状況を見通しながら計画を調整したい場面があります。課題をJIRAやBacklogで管理していても、WBSの階層やタスクの依存関係、担当者の負荷を含めて日程を検討するには、別途計画を整理することが少なくありません。あるタスクの日程を変更するたびに、後続タスクや担当者の負荷を確認し直すのは手間がかかります。 Project Scheduler は、依存関係、マイルストーン、リソース、スプリントを考慮して自動スケジューリングできる、WBS／ガントチャート型のプロジェクト管理ツールです。サーバーやアカウント登録、インストールは必要ありません。Live Demoをブラウザで開くだけで、日程案を検討できます。オフラインで利用したい場合は、単一HTML版の project_scheduler.html をダウンロードできます。画面表示は日本語・英語を切り替えられ、Claude Code向けのSkillを使えばAIエージェントに日程調整やBacklogとの同期を任せることもできます。

Jevでナレッジグラフの関係を低レイテンシに評価する - CoDExを用いた精度検証 ナレッジグラフは、人・組織・製品・場所などをノード、その間の意味のあるつながりをエッジとして表すデータ構造です。文章だけでは検索や集計が難しい情報も、つながりを明示することで「ある会社の製品を探す」「人物が所属した組織をたどる」といった処理に利用できます。 ナレッジグラフとtriple ナレッジグラフのレコードは、(主語, 関係, 目的語)という3要素、すなわちtripleで表します。主語と目的語がノード、関係が両者を結ぶエッジの種類です。

約0.2秒で文章を判定するTypeSafe AIのJevを試してみる TypeSafe AIのJevは、分類先やスコアなど、プログラムが次の処理を決めるための判断結果を高速に返すことに特化したAIモデルです。ChatGPT(GPT)やClaudeなどの従来のLLMとは異なり、生成モデルとして機能するのではなく、あらかじめ定義した選択肢からの選択やスコアリングに特化しています。業務システムなどの組み込みで単独でも利用可能ですが、従来型のLLMと組み合わせて利用することで、コストや応答時間の面での削減が期待できます。 今回、桃太郎のあらすじを使って、PythonからJevを利用する方法と処理速度を確認してみました。

Claude Codeのステータスラインに契約アカウントと利用枠の残量を表示する Claude Codeをサブスクリプションで利用する場合、5時間・週間の利用枠の残量を確認しながら作業を進めたい場面があります。また、仕事用と個人用など複数のアカウントを使い分けていると、どの契約アカウントでログインしているかも確認したくなります。ということで、契約アカウントのメールアドレスと利用枠の残量を、Claude Codeのステータスラインに表示する方法を紹介します。スクリプトを保存し、設定ファイルに追記することで、画面下部に以下のように表示できます。

プロジェクトのスケジュールをProject Schedulerで調整し、タスクをBacklogで管理する プロジェクト管理ツールとして有名な Backlog 用のCLIツールとして bee がリリースされました。CLIツールは単独で使っても便利ですが、最近はAIエージェントから利用することを想定しており、ご多分に漏れずbeeもAIエージェント用のSkillを提供しています。

進行中のガントチャートをAIで引き直す - Claude CodeとProject Schedulerによるスケジュール調整 プロジェクト開始後のスケジュール変更は、計画時より難しくなります。完了済みタスクの実績は変えず、着手済みタスクの開始日も維持したまま、残りの計画だけを引き直す必要があるためです。

ガントチャートの日付を手で直すのをやめる - Project Scheduler実践チュートリアル 実装の見積もりが3人日から9人日に増えたとき、後続のテストとリリース日はどうなるでしょうか。担当者に二つの実装を同時に割り当てたとき、その計画は本当に実行できるでしょうか。

SAML連携しているCognitoで認証して、PostmanからGraphQLリクエストを送信する AWS AppSyncの認証にAmazon Cognitoを使用しており、さらにCognitoが社内IdPなどとSAML連携している構成の場合、AWSコンソールのAppSyncのクエリ画面(テストクエリ)からGraphQLリクエストを送信しようとしても、コンソール上で完結してテストすることができません。 PostmanのAuthorization機能(OAuth 2.0 / Authorization Code With PKCE)を利用して、Cognitoの認証(SAML連携によるログイン)を行い、AppSyncにGraphQLリクエストを送信する方法を紹介します。