はじめに こんにちは、2026年6月入社のhyokoです！ 本記事では、2026年6月に入社したメンバー2名の入社直後の感想をまとめました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加したメンバーの振り返りとして有益なコンテンツになればいいなと思います！ hyoko 自己紹介 KINTO開発部で契約管理システムを担当しています。 今後、要件のとりまとめやリリースまでの進行管理を担当する予定です。 これまでは、SIer（2社）、ITコンサル、事業会社の社内SEを経験してきました

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  更改案件の「現行機能保証」を3つのサブテーマに分けて扱う3連作、その3回目（最終回）です。第3回で「現行」の実体を見て、第4回で合意できる「全体像」を作りました。今回のサブテーマは「検証し、予算を組み、配分する」です。 質問 #  更改案件で現行システムの仕様書を開いたら、最終更新は10年前でした。コードと一致している保証はなく、現場の人に聞くと「マニュアルにはないけど、実際はこうやっている」が次々に出てきます

はじめに こんにちは。職種横断ダイレクトリクルーティングサイト「ウェルミージョブ（旧カイゴジョブ）」でQAを担当している林です。 アジャイルな開発チームメンバーの一員として、よりよいQAを目指して日々トライを楽しんでいます。 エス・エム・エスではAIエージェントを積極的に業務へ活用しています。 ウェルミージョブの開発チームではGitHub Copilot、Claude Code、Codex、Devin、Geminiなど、用途にあわせて様々なAIエージェントやAIアシスタントを使っており、その中でも私はDe

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  更改案件の「現行機能保証」を3つのサブテーマに分けて扱う、その2回目です。前回（第3回）は、「現行」と呼ばれるものの実体が3つあることを見て、最後に「確定」という前提を疑いました。本稿では、発注側と合意できる「全体像」の作り方を考えます。 質問 #  既存システムの更改案件で、アジャイルで進める提案をしたところ、発注側から「見積の根拠として機能一覧を出してほしい」と言われました。「アジャイルは最初に全件を確定し

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  判断の積み重ねは、いつしか慣習になります。そして一度慣習になると、誰も疑問を持たなくなります。前例踏襲という「思考停止」の完成です。今回からの3回は、そのひとつ、更改案件の「現行機能保証」を扱います。対処するには3つの視点が必要で、それぞれをサブテーマとして、3回に分けて扱います。 第3回（本稿）: 「現行」の実体を見る 第4回: 合意できる「全体像」を作る 第5回: 検証し、予算を組み、配分する  この3本の

はじめに こんにちは！セーフィー株式会社の金原です。 先日（9月5日土曜日）、Agile459（アジャイル四国）と TOKUSHIMA Cyber Security Meetup が主催するイベント「Agile Japan 2025 サテライト 徳島」にお招きいただき、徳島で脅威モデリングワークショップを実施しました。 脅威モデリングは、システムの設計段階でリスクに気づくための強力なアプローチです。また、うまく活用できればセキュリティ文化醸成やセキュリティ組織能力を上げることもできます。一方で、「覚えるこ

アジャイルグループの中村です。 生成AIカンファレンス2026 に参加しました。生成AIの社会実装をテーマに、産業・開発・知能の3つの視点から、AIエージェントやフィジカルAIなど幅広いテーマを扱うイベントです。 AIで速くなった、その先への不安 # 2026年に入り、AIエージェントによるコーディングの高速化は一気に現実味を増しました。自身も個人開発アプリのメンテでPoC程度に触れましたが、その程度の経験でも「10倍の生産性」といった表現が、以前ほど大げさには聞こえなくなりました。エンジニアとしては、素

この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。 質問 #  うちのチームは既存システムの保守運用が中心です。不具合対応や改善要望への対応がメインで、大きな新機能をスプリントで計画的に作っていくような仕事ではありません。研修で習ったスクラムは新規開発が前提のように見えますし、うちは割り込みも多い。 うちにはスクラムは合わないのではないでしょうか？ 回答 #  合わないのは、スクラムではなく「スクラム解説の前提」のほうです。視点を変えると、保守運用はアジャイルにとっ

連載をはじめるにあたって #  この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  「豆蔵最後のアルバイト」という謎の肩書でお客様を煙に巻きながら、日々研修やご支援に従事している中で、同じような質問を何年にも渡って繰り返しいただいてきました。アジャイル開発が世に出て30年近い年月が経ち、実践者の世代交代が進んでいるので、かつて議論し尽くされた（かに見えた）質問が、打者一巡よろしく繰り返し話題にのぼるのも当然とも思います。  そうしたよくいただく質問を起点に、その背

こんにちは！レバレジーズでリードエンジニアのゲンシュンと申します！ レバレジーズにデータエンジニアとして転職して、ちょうどまる2年が経ちました。今はデータエンジニアチームのリーダーとして、メンバーのマネジメント評価育成、全社横断のデータ分析基盤やETLの構築、データ系職種の組織づくりといったデータエンジニアのお仕事をしつつ、全社の技術力の底上げや文化醸成を担うリードエンジニアとして、アプリケーションエンジニアとDDD勉強会を開いたり、技術広報、社外イベントの企画・登壇、さらには社内エンジニアイベントの運営

はじめに この記事は、BASEテックブログ夏のブログリレー11日目の記事です。 BASE Dept. Product Divにてバックエンドエンジニアをしている オリバ です。 ショップオーナーの発送領域を担当しており、バックエンドを中心に、フロントエンドやNew Relicなども触っています。 2026年5月、担当する「送り状一括印刷 App」の一部機能をリリースしました。しかし、リリース後に分かったのは、想定していた使われ方をされていないということでした。機能自体は動いていますが、開発チームが想定して

「だいたい○○ケースくらいですかね」の正体 テスト計画でスケジュールを立てるとき、テストケース数の見積もりはどうやっているだろうか。 正直なところ、多くの現場では「前回と同じくらいの規模感だから○○ケースくらい」「経験的にこの手の機能なら△△ケース」という見積もりが主流だと思う。自分もそうだった。 これで困るのは3つの場面。 初めての領域。 過去実績がないから「だいたい」が通用しない 説明責任。 上席に「なぜその工数なのか」と聞かれたとき、根拠を示せない 精度のばらつき。 見積もる人によって2〜3倍の差が

AI 駆動開発ライフサイクル (AI-DLC) の基礎を体系的に学べるコース「 AI-DLC Foundations 」の日本語版として「 AI 駆動開発ライフサイクル (AI-DLC) ナレッジバッジ 」が、AWS Skill Builder で公開されました。この記事では、コースの概要と全 8 モジュールの内容を紹介します。 今すぐコースを受講する場合はこちら コースの概要 AI 駆動開発ライフサイクル (AI-DLC) ナレッジバッジ は、AI-DLC について基礎から体系的に学べる全 8 モジュー

はじめに ITコンサルタントのKです。以前、Webサービスの新規開発に関わっておりました。機能開発の段階だったので、機能やビジネスロジックが正しいことの評価が大半で、運用の評価はもっと先という段階でした。 昨今のモダナイゼーションにおいて、開発と運用は切り離せない関係にあります。クライアントサーバー方式からクラウドネイティブなWebサービスへと進化させるプロジェクトを例に、 「継続的な価値提供」を支えるプロセスと品質の考え方 を、鉄道の仕組みになぞらえて紐解いてみたいと思います。 プロジェクトの背景：目指

「テスト＝QA」を卒業したい。でも何から？ 以前の記事で、テストとQAは違うという話を書きました。 テストは「測る」行為です。QAは「良いものが生まれる仕組みをつくる」行為です。勉強にたとえるなら、テストは問題を解くことであり、QAは勉強法そのものを改善することです。 反応をもらった中で一番多かったのが、「わかった。で、具体的に何をすればいい？」 でした。正直、自分も最初はそうでした。 品質戦略の担当になったとき、「分析しよう」と意気込んでパレート分析やODCの教科書を開きました。でもデータが整っていませ