並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 19 件 / 19件

新着順 人気順

アジャイルの検索結果1 - 19 件 / 19件

  • 「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita

    こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ?」「どうして?」「つまり?」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク

      「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita
    • ウォータフォールはやめて2024年の開発をやろう!|牛尾 剛

      今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と

        ウォータフォールはやめて2024年の開発をやろう!|牛尾 剛
      • 高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean

        tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない? 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で1ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ

          高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
        • 45分登壇で75%効率化したMarkdown+生成AIスライド作成術 - Qiita

          KDDIアジャイル開発センターのpiyonakajimaです。 突然ですが、あなたは登壇スライドの作成にどれぐらいの時間をかけていますか? 6/21-22に開催されたScrum Fest Osaka 2024に登壇した際、Markdown+生成AIを活用して登壇スライドを作成しました。その際、45分の登壇資料作成を75%効率化(自分比)できました。 普段からMarkdownで資料を作成している方からすると、これまで時間かけすぎやろ、というツッコミが聞こえてきそうですが、登壇資料の作成時間に悩まれる方は沢山いらっしゃるのではないかと思います。今回はこの時に実施した工夫をお話します。 以下がMarkdown(Marp)と生成AIを使って執筆した45分の登壇資料です。一部PowerPointで作図した過去資料から流用しています。 Marpでは、たとえば以下のようなmarkdownを書くと、 --

            45分登壇で75%効率化したMarkdown+生成AIスライド作成術 - Qiita
          • ジェフ・ベゾスがAmazon創業時に紙ナプキンに描いた図 世界の見え方や行動が変わる、「円環化思考」のポイント

            業界業務の経験豊富な「その道のプロ」に、1時間からピンポイントに相談できる日本最大級のスポットコンサル「ビザスク」。そのビザスク主催のセミナーに、『武器としての戦略フレームワーク』の著者で、國學院大学 経済学部 経営学科教授の手塚貞治氏が登壇。「アイデア創出 実践論」をテーマに、マトリックスの4つの用途や、円環化思考のポイントを解説しました。 前回の記事はこちら マトリックスの4つの用途 手塚貞治氏(以下、手塚):次に、二次元化思考について見ていきましょう。 30年前、私が駆け出しの頃は、こうした二次元のマトリックスを描くと「おお、コンサルっぽいね」と言われましたが、今では誰でも書くようになり、珍しいものではなくなりました。 二軸のマトリックスを作り、そこの平面上で整理する方法です。 例えば、有名なフレームワークとして、製品が既存か新規か、市場が既存か新規かで成長の方向性を考える成長ベクト

              ジェフ・ベゾスがAmazon創業時に紙ナプキンに描いた図 世界の見え方や行動が変わる、「円環化思考」のポイント
            • 生産性の可視化こわい - masayuki5160's diary

              TL;DR 立場によっては、組織全体の生産性の可視化が必要なのはわかる。 ただ、チーム単位での生産性の細かい可視化の話はちょっとこわい。チーム単位での生産性に関しては、ある期間にそのチームがどんな機能をリリースして、それがどうだったか、を評価して、をすればだいたい良いような。 生産性の可視化? 全然知らなかったんだけど、開発生産性の可視化を支援するSaaSがあると先日知った。こちら。 findy-team.io なるほど最近はすごい便利なものがあるなーと思った。 一方で、このツールと日々にらめっこしてるチームはなんか僕が目指したいチームではないなと思った。だから、僕はこういうツールは今の僕の立場としてはいらないなーと思った。 でも、組織に所属するエンジニアが100名、200名とか規模になってるようなとき、その組織のCTOなりVPoE、組織横断の課題を解決するチームなどはこういったツールは必

                生産性の可視化こわい - masayuki5160's diary
              • 読まないと後悔する技術書30選 - Qiita

                はじめに 現代の人に名著以外の本を読むような時間はない こんにちは、Watanabe Jin (@Sicut_study)です みなさんは何か新しい技術を学ぶときにどんなコンテンツを利用するでしょうか? 最近ではUdemyなどの動画講座を利用する人が多いと思いますが、本を読んで学ぶという人もまだまだ多いのではないかと思います 今回は私がこれまで5年間読んできた150冊以上の中から厳選した30冊の本を紹介します。広く多くの人に役立つものから、特定の技術の書籍までどれを読んでもあなたの大切な一冊になるのでぜひ読んでみてください 現代人には時間がない なぜ働いていると本が読めなくなるのかという本が話題になりました 現代人は本を読む時間がなくなっています。 仕事に追われてしまい、プライベートで本を読む暇などなくなっているのです。 しかし、エンジニアは「技術職」なのでプライベートの時間でも学習をして

                  読まないと後悔する技術書30選 - Qiita
                • エンジニアとQAの壁が崩れていくのを眺めていた #scrumosaka | ドクセル

                  スライド概要 スクラムフェス大阪2024の登壇資料です。 スクラムマスターとして、あるチームでエンジニアとQAの間に見えない壁があり、それが崩れるまでを眺めた。しかし、チームは時間をかけて壁を崩すことができ、その結果、よりユーザーと価値に向き合えるようになった。チームの状況は、初めてアジャイル開発やスクラムに触れるメンバーが多くいたよくあるプロダクトチームであった。スクラムマスターは、なぜ壁崩せたのか、なぜ見ていられたのかを語る。この物語は、あなたのチームでも起きうることであり、アジャイル開発に取り組む上での示唆になるはずです。

                    エンジニアとQAの壁が崩れていくのを眺めていた #scrumosaka | ドクセル
                  • コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey

                    読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か? 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ

                      コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
                    • [入門]ドメイン駆動設計 ――基礎と実践・クリーンアーキテクチャ

                      2024年7月1日紙版発売 2024年7月1日電子版発売 増田亨,田中ひさてる,奥澤俊樹,中村充志,成瀬允宣,大西政徳 著 B5判/160ページ 定価2,200円(本体2,000円+税10%) ISBN 978-4-297-14317-6 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle honto この本の概要 ソフトウェア開発でドメイン駆動設計が注目されています。ソフトウェアデザイン誌で大変好評だった,ドメイン駆動設計特集の過去記事(2024年3月号,2023年2月号など)を再編集し,1冊にまとめました。ソフトウェアの設計は現在さまざまな視点で検討されており,開発の成功をいかに実現し達成するか重要になっています。本書は,ドメイン駆動設計の第一人者である増田亨氏を中心に,現場でドメ

                        [入門]ドメイン駆動設計 ――基礎と実践・クリーンアーキテクチャ
                      • 「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」 - Qiita

                        「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」アジャイル要求ユーザーストーリー はじめに ◆この記事は何? アジャイル開発における「要求」や「ユーザーストーリー」を細分化する記事です。 ◆対象は? 要求やユーザーストーリーを整理する方 アジャイル開発に関わる方 ◆ねらいは? アジャイル開発に関わる方が、何気なく使っている「要求」や「ユーザーストーリー」の解像度を上げること エンジニア人生に影響を与えたフレーズ 「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」は、書籍『テスト駆動開発』に出てくるフレーズです。 そして書籍『テスト駆動開発』の中で、私が最も印象に残っている文章です。 この文章に出会ってから、私は「言われた通りにシステムを作る」から脱却して、「

                          「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」 - Qiita
                        • 大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫 | MEDLEY Developer Portal

                          2024-07-02大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫はじめにこんにちは。CLINICS カルテの QA 担当をしております QA エンジニアの かみむら です。 医療プラットフォーム本部 CLINICS 開発チームでは、2年以上に渡り自社レセコン1の開発を行っています。プロダクトは公開済みであるものの鋭意追加機能の開発を続けており、今後も継続して開発する予定になっています。 QA エンジニアの大切な役割の1つとして、プロセス改善があります。ふりかえりはプロセス改善のアイデアを関係者全員で話し合うための肝となるアクティビティですので、規模の大小問わず取り入れたいものです。 この記事ではレセコン開発におけるプロジェクト体制構築時の黎明期から現在の成熟期に至るまでに行った、四半期毎のふりかえり手法や効果について、かいつまんでご紹介します。 プロジェクトの状況

                            大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫 | MEDLEY Developer Portal
                          • 「よーしパパ、Ollama で Llama-3-ELYZA-JP-8B 動かしちゃうぞー」 - Qiita

                            はじめに こんにちは、KDDIアジャイル開発センターのはしもと(仮名)です。 エンドレス水出しコーヒーの時期になりましたね。 今回は、Ollama を使って日本語に特化した大規模言語モデル Llama-3-ELYZA-JP-8B を動かす方法をご紹介します。 このモデルは、日本語の処理能力が高く、比較的軽量なので、ローカル環境での実行に適しています。さあその性能は如何ほどに!!!!????はやくAIは俺から仕事を奪え。 Llama-3-ELYZA-JP-8Bとは Llama-3-ELYZA-JP-8Bは、ELYZA社が開発した日本語に特化した大規模言語モデルです。Meta社の「Llama 3」シリーズをベースに、日本語での追加学習を行っています。80億パラメータという比較的小さなモデルサイズながら、「GPT-3.5 Turbo」や「Claude 3 Haiku」、「Gemini 1.0 P

                              「よーしパパ、Ollama で Llama-3-ELYZA-JP-8B 動かしちゃうぞー」 - Qiita
                            • 『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita

                              先日The Registerを見ていたらアジャイル開発の失敗率は268%も高い Study finds 268% higher failure rates for Agile software projectsという記事が目に入りました。 The RegisterはITニュースサイトで、日本で言うところのITmediaやWIRED、GIGAZINEみたいなところですかね。 その記事は元記事を紹介しているもので、『元記事はImpact Engineeringの宣伝ではあるが、アジャイル開発は期待ほどうまくいかないという疑念を抱かせるのにも十分である』というようなまとめになっていました。 ではImpact Engineeringってなんなんだよと元記事268% Higher Failure Rates for Agile Software Projects, Study Findsを最後まで読

                                『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita
                              • モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

                                公開日 2024/06/25更新日 2024/07/01モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 ご好評頂いているアーキテクチャ特集の第三弾となる今回は、BtoB SaaSを提供する企業10社にご協力頂き、技術選定のこだわりや今後の展望をご寄稿いただきました。アーキテクチャを通して、各社の事業特性や設計思想にも触れられる内容となっております。※ご紹介は企業名のアルファベット順となっております 株式会社あしたのチーム あしたのチームは「誰もが "ワクワク" 働ける世界を創る」をビジョンに掲げ、人事評価制度の構築・運用・クラウド化で "人と組織の成長" を支援しています。今回は、2024年4月にリリースされた同社の新サービス:パフォーマンスマネジメントプラットフォーム『Cateras™』のアーキテクチャについてご説明します。 アーキテクチャ選択の背

                                  モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
                                • 誇り高き「マネージャー」を全うするために。“理想のEM”小田中氏を支えた珠玉の5冊 レバテックラボ(レバテックLAB)

                                  誇り高き「マネージャー」を全うするために。“理想のEM”小田中氏を支えた珠玉の5冊 2024年6月20日 株式会社カケハシ EM 小田中 育生 筑波大学大学院修了後、外資系半導体企業を経て、2009年に株式会社ナビタイムジャパンに入社。2019年からはVPoEを務める。2023年10月に、EMとして株式会社カケハシに入社。薬局DXを支えるVertical SaaS「Musubi」をコアプロダクトに位置づけ、「しなやかな医療体験」を実現するべく新規事業のプロダクト開発にコミットしている。著書に『いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法』(2020年、インプレス、共著)がある。 X note エンジニアがマネジメントに踏み出すとき、今まで向き合ってきた「技術やシステム」と、マネージャーとして向き合うべき「組織や人」の特性の違いに戸惑う人も少なくありません。 エ

                                    誇り高き「マネージャー」を全うするために。“理想のEM”小田中氏を支えた珠玉の5冊 レバテックラボ(レバテックLAB)
                                  • 45分登壇で75%効率化したMarkdown+生成AIスライド作成術 - Qiita

                                    KDDIアジャイル開発センターのpiyonakajimaです。 突然ですが、あなたは登壇スライドの作成にどれぐらいの時間をかけていますか? 6/21-22に開催されたScrum Fest Osaka 2024に登壇した際、Markdown+生成AIを活用して登壇スライドを作成しました。その際、45分の登壇資料作成を75%効率化(自分比)できました。 普段からMarkdownで資料を作成している方からすると、これまで時間かけすぎやろ、というツッコミが聞こえてきそうですが、登壇資料の作成時間に悩まれる方は沢山いらっしゃるのではないかと思います。今回はこの時に実施した工夫をお話します。 以下がMarkdown(Marp)と生成AIを使って執筆した45分の登壇資料です。一部PowerPointで作図した過去資料から流用しています。 Marpでは、たとえば以下のようなmarkdownを書くと、 --

                                      45分登壇で75%効率化したMarkdown+生成AIスライド作成術 - Qiita
                                    • なぜ顧客は「本当に欲しいもの」を言ってくれないのか? - Qiita

                                      ある日の我が家 ワイ「う〜ん・・・」 ワイ「どないしたら実現できるんやろなぁ・・・」 娘(8歳)「パパ、どうしたの?」 ワイ「おぉ、娘ちゃん」 ワイ「いやぁ」 ワイ「実は、面白いアイディアを思いついてな?」 娘「へぇ、どんなアイディア?」 ワイ「AIと連携した技術記事投稿サイトがあったら面白いんちゃうかな、って」 娘「何だか、フワッとしたアイディアだね」 娘「よく分かんないけど、パパが自分で作ってみたら?」 ワイ「いや、ワイはフロントエンドしかできへんから」 ワイ「記事投稿サイトはちょっと、作る自信ないわ」 ワイ「サーバサイドとか、データベースとか」 ワイ「よう分からんし」 娘「じゃあ、私が作ってあげるから」 娘「要件を教えてよ」 ワイ「AIがいい感じに記事をアレしてくれるサイトや」 娘「いや、だからフワッとしすぎなんだって」 娘「そのサイトを作りたいと思ってるのは、パパなんだからさ──」

                                        なぜ顧客は「本当に欲しいもの」を言ってくれないのか? - Qiita
                                      • 『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268%も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~ - Qiita

                                        『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268%も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~アジャイルポエムプロジェクト管理メンタルケアコミュニケーション 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268%も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら(その調査自体を行なったのもEngprax社) 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は? そもそもアジャイルできてなくね? 下記が失敗するのはアジャイルかどうかとは関係

                                          『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268%も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~ - Qiita
                                        1