並び順

ブックマーク数

期間指定

  • から
  • まで

201 - 240 件 / 2152件

新着順 人気順

agileの検索結果201 - 240 件 / 2152件

  • (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book

    本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl

      (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
    • 雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try

      (この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました) 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト(TDD)で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする&機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO(プロダクトオーナー)に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな

        雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
      • システム思考とプロダクトマネジメント

        システム思考とプロダクトマネジメント ※プロダクトオーナー祭り2021 Spring - PO祭り2021Springでの登壇資料です https://postudy.connpass.com/event/202404/

          システム思考とプロダクトマネジメント
        • 期限ギリギリで低品質な物を作り上げる人のスケジュールと期限内に高品質な物を余裕を持って仕上げる人のスケジュール

          ヒツジモチ @hitsujimo_chi 完成させた瞬間経験値が入るシステムってツイートと、このスケジュールの話は関係あって、このスケジュールの右側ってつまるところ配分が変わっているだけで、5回完成させてるんだよね。左側は1回しか完成してない。完成数が違うから品質が変わる。 twitter.com/jmatsuzaki/sta… 2020-10-20 19:26:27

            期限ギリギリで低品質な物を作り上げる人のスケジュールと期限内に高品質な物を余裕を持って仕上げる人のスケジュール
          • 「スタートアップだからテストを書かない」は正しいか - An Epicurean

            スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートア

              「スタートアップだからテストを書かない」は正しいか - An Epicurean
            • 納期がなぜ生産性をぶち壊しにしているのか?|牛尾 剛

              昨年NewsPicks さんに取り上げてもらって最近動画が公開されました。そこでもお話させてもらっていることなのですが、アメリカで働きはじめると日本人からすると「納期が無い」感覚が物凄く衝撃的だった。 最近、納期が無いことと生産性について頭の中で整理がついてきたのでシェアしておこうと思う。ちなみに、動画も含めて、私の発言は私の体験と意見であり、所属会社には全く関係が無いことを改めてお断りしておきます。 日米納期の感覚の違い アメリカで働いていると、日本人からすると納期がほとんどないという感じを受ける。もちろん納期があるものもあるが「本当に必要なもの」に限られる。例えば、大きなカンファレンスで何かの製品を発表するとかそんなのだと納期はもちろんある。そうでなれけばほとんど無いという感覚だ。私の所属会社だけではなく、北米の他の会社の人も同じような感覚らしいので文化によるものだと思う。 常に納期が

                納期がなぜ生産性をぶち壊しにしているのか?|牛尾 剛
              • プライベートメソッドのテストは書かないもの? - t-wadaのブログ

                この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA@IT で回答したものです。残念ながらQA@IT のサービス終了(2020/02/28)と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回

                  プライベートメソッドのテストは書かないもの? - t-wadaのブログ
                • ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴

                  www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている(ご存じの方は彼にご一報を)。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80%、いやもしかしたら90%をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく

                    ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴
                  • 最高裁無罪判決のご報告|モロ

                    こんにちは。モロ(@moro_is)です。 4年近く続いておりましたコインハイブに関する裁判について、昨日、最高裁にて「無罪」の判決を賜りました。 地裁、高裁と繰り返しになってしまいますが、非常に多くの方のご助力あってこそ勝ち取れた判決と感じております。 多大なるご支援、心からありがとうございました。 判決について 専門外となってしまうためあまり難しいことはいえませんが、地裁に続き、 ウェブサイトの運営者が閲覧を通じて利益を得る仕組みは、ウェブサイトによる情報の流通にとって重要である というクリエイターの目線に立った一文を添えていただけたことを非常に嬉しく思います。 また、無罪であったとはいえ私の方にも反省する点は多く、今後はよりユーザーの目線に立った制作者たるよう、肝に銘じて精進いたします。 若輩者ではございますが、引き続き何卒よろしくお願いいたします。 無罪のびろーんについて 「無罪」

                      最高裁無罪判決のご報告|モロ
                    • NHKが持っているデータをオープンに 1人のエンジニアの熱がオールドメディアを根幹から変えるかもしれないよ|NHK取材ノート

                      毎日めまぐるしく変わる新型コロナウイルスのデータを、24時間いつでも、誰にでも、わかりやすく伝えることは簡単ではありません。 NHKの新型コロナウイルス特設サイトの担当エンジニアとして奮闘しているのがこの「ジャージ男」。テクニカルディレクターの斉藤一成くんです。サッカー好きの彼のことをここでは「カズ」と呼ばせてもらいます。 NHKのエンジニアのほとんどは「放送」に関わる仕事をしていますが、そのなかでカズはウェブ周りのシステムの設計から開発、運用までを手がけるいわゆる「フルスタック」のエンジニアとして異彩を放ちまくっています。 「できるものはすべてオープンにしたい」というカズの提案で去年12月に始まったのが、NHKのサイトにある新型コロナ感染者のデータを誰でも自由にダウンロードできる取り組みです。 下のページにアクセスするとグラフの下に「データーのダウンロードはこちら」というリンクがあるのが

                        NHKが持っているデータをオープンに 1人のエンジニアの熱がオールドメディアを根幹から変えるかもしれないよ|NHK取材ノート
                      • スクラムと見積り

                        スクラムと 見積り やっとむ 合同会社やっとむ屋

                          スクラムと見積り
                        • Webフロントエンド基礎研修 ~歴史から学ぶ、現場のスタンダードな開発~

                          Webフロントエンド基礎研修 ~歴史から学ぶ、現場のスタンダードな開発~ 2022年デジタル新卒研修 デジタル編成ユニット Yuta IDE

                          • ふりかえりを拡張する「ふりかえりチートシート」 - Qiita

                            はじめに あなたのふりかえりを拡張するふりかえりチートシートを公開いたします! この記事では、技術書典7以降配布している「ふりかえりチートシート」の説明を行います。 ふりかえりチートシートは、ふりかえりの手法84個とその特徴を網羅した一覧表です。下記画像はイメージです。 pdfはBoothで無料DLできます。 DLはコチラ => (DL版)ふりかえりチートシート ふりかえりチートシートとは ふりかえりの様々なシチュエーション(ひとり、チーム、プロジェクト、組織)で利用可能なふりかえりの手法をまとめたチートシートです。 ふりかえりの各手法を「ふりかえりの5つの流れ」と「ふりかえりの8つの型」に沿って分類しています。 B5の2ページ分のpdfファイルで、両面印刷したものをイベント等で配っています。 DLしていただいたものは、ご自由に印刷&ご利用ください。 ふりかえりチートシートの想定利用対象者

                              ふりかえりを拡張する「ふりかえりチートシート」 - Qiita
                            • 「フロントエンド領域」を再定義する

                              Frontend Study #1 訂正: 最後のzennの記事のリンク先は、正しくは https://zenn.dev/mizchi/articles/c638f1b3b0cd239d3eea です

                                「フロントエンド領域」を再定義する
                              • エンジニア採用強化各社はいかに優秀なエンジニアがすでに在籍してるかよりいかに優秀なプロダクトデザイナーやマネージャーが在籍しているかをアピールしてくれ - まいくろ🍣きりみん

                                ポエムです。パッと勢いで書くので反論の余地があるかと思います。 あと何にやりがいを感じるかも多分かなり人それぞれだとは思います。 経緯 最近あらためて思うのが、よほど高度な技術を使っていない限りWeb系企業におけるエンジニアってあくまで守の存在なんですよね。プロダクトのやりたいことを妨げないために堅実にしっかりと物を動くものを作っていく。ただしそれは必要条件でしかなくて、事業が駄目なら成功しない— きりみんさん(きりみんちゃんのマネージャー) (@kirimin) November 6, 2019 エンジニアがどこまで仕様に口を出せるかは組織の体制や規模にもよるけど、やはり事業開発においてエンジニア一人がプロダクトの成功に与えられる影響力はあまりにも小さい。失敗に与えられる影響力は大きいけど🤭— きりみんさん(きりみんちゃんのマネージャー) (@kirimin) November 6,

                                  エンジニア採用強化各社はいかに優秀なエンジニアがすでに在籍してるかよりいかに優秀なプロダクトデザイナーやマネージャーが在籍しているかをアピールしてくれ - まいくろ🍣きりみん
                                • Masanori Kusunoki / 楠 正憲 on Twitter: "COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k"

                                  COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k

                                    Masanori Kusunoki / 楠 正憲 on Twitter: "COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k"
                                  • 企業技術ブログ: エンジニアの技術ブログコミュニティ

                                    “あの会社”の技術を学ぼう今日から業務に活かせる! 企業ではたらくエンジニアのための、実例全振り技術ブログコミュニティ。もっと詳しく

                                      企業技術ブログ: エンジニアの技術ブログコミュニティ
                                    • 数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021

                                      CI/CD Conference 2021

                                        数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
                                      • 2022年に起きたフロントエンドの変化

                                        Burikaigi 2023 https://burikaigi.dev/ Twitter https://twitter.com/__sakito__

                                          2022年に起きたフロントエンドの変化
                                        • 素材の組み合わせだけのゲームが5万本セールス!? 「ほぼ1枚も描いていない」という『Overdungeon』作者に訊くWeb的ゲーム開発

                                          ──え、溝辺さんってSTORYS.JPの開発者だったんですか! それはJPモルガンの在籍時に片手間でやられていたんですか? 溝部氏: そうですね。 ──JPモルガンは副業とかって……。 溝部氏: もちろん駄目ですね(笑) そのSTORYS.JPは、ギリギリ黒字か赤字という収益性まで持っていけたのですが、このままではダメということで「ビットコイン面白そうじゃない?」と「Coincheck」【※】というサービスも始めました。 ※Coincheck……2012年に設立された仮想通貨の取引所サービス。複数種類の仮想通貨の売買や取引が行える。 (画像は「Coincheck」公式サイトより)──どちらも有名なWebサービスですね。それぞれ溝部さんが20代のころに立ち上げメンバーとして関わったということですか? 溝部氏: そうなりますね。STORYS.JPは、「LinkedIn」という世界最大のビジネス

                                            素材の組み合わせだけのゲームが5万本セールス!? 「ほぼ1枚も描いていない」という『Overdungeon』作者に訊くWeb的ゲーム開発
                                          • QiitaやZennよりも便利? IPAの資料を読もう!

                                            はじめに 飲み物じゃないIPAをご存じでしょうか? 漢字でいうと、独立行政法人 情報処理推進機構ですね。情報処理技術者試験を実施いる謎の組織という認識の方も多いと思います。 実はIPAはいろんなドキュメントを公開していてQiitaやZenn以上にお役立ちなサイトなのです。 まあ、AWSをどうこうとか、FireabaseやNext.jsのようなキラキラした奴は基本載ってないので特に代替えするものではないですが、ブログとかはまた種類の違った情報があるので個人的には結構使うことあります。しかも 「日本語」! こういう感じの事をTwitterでつぶやいたところ意外にイイねをされたので、せっかくだしどんなドキュメントがあるかちょっと紹介したいと思います。 セキュリティ関連NIST文書 まずはNISTドキュメントの翻訳版! これは良いですよね。NISTはアメリカの米国国立標準技術研究所で、セキュリティ

                                              QiitaやZennよりも便利? IPAの資料を読もう!
                                            • 勉強法について考え続けた自分が行き着いた『アジャイル勉強法』というひとつの答え

                                              🏃 はじめに 今度、このような勉強会が開催されます。 ここで、「もし自分が"勉強法"を説明するならどうするか?」をふと考えていると、観点が2つあることに気づきました。 学習のワークフロー 学習の方法それ自体 この二つの観点から自分の勉強法について言語化してみようと思います。ただし前提として、ソフトウェアエンジニア向けというのがあります。 📚 アジャイル勉強法が Zenn Book になりました!! この記事で説明している以上に詳しい内容を Zenn Book の方には書かせていただいております! この記事を読んでみて、より詳しく知りたいとなった方はぜひ Zenn Book の方もよろしくお願い致します。 1 章は無料で読めます! ⏰ 学習のワークフロー サイクルはこんな感じです。 年間の計画を立てる タスクに細分化して GitHub Project に登録していく 週単位で消化するタス

                                                勉強法について考え続けた自分が行き着いた『アジャイル勉強法』というひとつの答え
                                              • 「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita

                                                「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして

                                                  「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita
                                                • チームにノリをもたらした時にいた「二人目に踊る人」の共通点

                                                  Scrum Fest Osaka 2023 https://confengine.com/conferences/scrum-fest-osaka-2023/proposal/18546 「Fun Done Learnのうた」はこちら https://developers.kddi.com/blog/1dqKXhrd73q0V65NKuOYrp 一緒に働く人募集中 https://kddi-agile.com/recruit

                                                    チームにノリをもたらした時にいた「二人目に踊る人」の共通点
                                                  • ソフトウェアエンジニアと技術力 / developer-lifework

                                                    Hamee様 開発合宿 2021年(前半戦)の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://soudai.hatenablog.com/entry/2017/06/03/183508 - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://speakerdeck.com/twada/worse-is-better-understanding-the-spiral-of-technologies-20

                                                      ソフトウェアエンジニアと技術力 / developer-lifework
                                                    • 今のチームに来てから最も生産性が上がった考え方|牛尾 剛

                                                      多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある

                                                        今のチームに来てから最も生産性が上がった考え方|牛尾 剛
                                                      • 何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog

                                                        不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認

                                                          何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog
                                                        • 起業家7年生。シンデレラバスト向け下着ブランド「feast」の失敗を経て得た学び|ハヤカワ五味

                                                          「五味ちゃん 起業家7年生」連載の第一弾です。 第二弾は今月中にどこかで!25歳、起業家7年生。 こんにちは、ハヤカワ五味です。 そう、実は起業家としては7年生になってしまいました。 7年生ということは、小学1年生が中学1年生になるくらいの年数を起業家として費やしてきたということですが、正直この7年は自分にとって有意義ながら遠回りだったなと思います。 趣味で作ったものをSNSにアップしたら幸運にも話題となり、それを受けて法人化したのがシンデレラバスト向けランジェリーブランド「feast」の立ち上げの経緯ですが、そもそも私はコンシューマーゲームのプランナーか広告代理店のアートディレクターを目指していました。だから、事業を継続する気はまったくありませんでした。 そんなめちゃくちゃな立ち上がりをしたfeastなので、運営する中でも問題ばかりだったのですが、ここ半年〜1年くらいでいいメンバーとも出

                                                            起業家7年生。シンデレラバスト向け下着ブランド「feast」の失敗を経て得た学び|ハヤカワ五味
                                                          • 安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド|面川泰明

                                                            みなさん、コードを書く前に設計書を書きますか? 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し

                                                              安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド|面川泰明
                                                            • スクラムとアジャイル開発の本を12冊一気に読んでみた!その中から初心者、中級者、上級者向けのおすすめを紹介|Dentsu Digital Tech Blog

                                                              スクラムとアジャイル開発の本を12冊一気に読んでみた!その中から初心者、中級者、上級者向けのおすすめを紹介 こんにちは電通デジタル開発部エンジニアのリチャードです。弊社で開発している社内プロダクトEASIではスクラム開発を採用しており、開発部内には認定スクラムマスターも在籍しています。一方で私個人はこれまでスクラム開発を経験してはいたものの、断片的な知識と経験で乗り切っていた部分が強く、改めてスクラムやアジャイル開発の基本を学び直そうと思い立ち、12冊の本を一気読みしました。ちょうど数ヶ月前に電通デジタルへと転職したばかりだったので、よい機会だったと思います。 今回読んだ本の一覧はこちらです!過去に読んで改めて今回読み直した本もあるため、冊数は多くなっています。 初心者向け 1. いちばんやさしいアジャイル開発の教本 2. SCRUM BOOT CAMP THE BOOK 中級者向け 3.

                                                                スクラムとアジャイル開発の本を12冊一気に読んでみた!その中から初心者、中級者、上級者向けのおすすめを紹介|Dentsu Digital Tech Blog
                                                              • コードレビュー虎の巻 - Qiita

                                                                レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 (作業成果物の欠陥と改善の機会を探すレビュー) 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考: あなたのおっしゃるレビューってどのことかし

                                                                  コードレビュー虎の巻 - Qiita
                                                                • 『ドラゴンボール』と『ナルト』の元担当編集が語る「ジャンプ」の裏側 ― 絶対に敵わない『ワンピース』に勝つために『ナルト』が取った戦略とは【鳥嶋和彦×矢作康介×鵜之澤伸×松山洋】

                                                                  (画像はDRAGON BALL 1 (ジャンプコミックス) | 鳥山 明 、僕のヒーローアカデミア 1 (ジャンプコミックス) | 堀越 耕平、鬼滅の刃 1 (ジャンプコミックス) | 吾峠 呼世晴 | Amazonより) そんな『ジャンプ』の強さの秘密はどこにあるのか。そして紙の雑誌の売れ行きが急速に落ち込んでいる現在、『ジャンプ』を中心とした少年漫画はこの先、どんな方向を目指していくべきなのか。 それは漫画業界だけでなく、『ジャンプ』の連載漫画を原作とした作品が大きなウェイトを占めているゲームやアニメなどの世界においても、大きな関心事だと言えるだろう。 2019年8月27日にDiscordで配信されたラジオ「居酒屋:でんふぁみにこげーまー」では、ホスト役にTAITAI編集長と鳥嶋和彦氏、鵜之澤伸氏、そしてゲストにサイバーコネクトツーの松山洋氏と、集英社の矢作康介氏を迎えて、「漫画はこの

                                                                    『ドラゴンボール』と『ナルト』の元担当編集が語る「ジャンプ」の裏側 ― 絶対に敵わない『ワンピース』に勝つために『ナルト』が取った戦略とは【鳥嶋和彦×矢作康介×鵜之澤伸×松山洋】
                                                                  • SQLインジェクション対策不備の責任 東京地判平30.10.26(平29ワ40110) - IT・システム判例メモ

                                                                    SQLインジェクション対策をしていなかったことについて開発会社の責任が問われた事例。 事案の概要 Xは,Yに対し,Xの提供する車・バイクの一括査定システム(本件システム)の開発を約320万円で委託し,平成24年9月に納品を受けた。 その後Xは,平成28年12月に,IPA*1から,中国のサイトに本件システムの脆弱性に関する情報が掲載されているという指摘を受けて,Yに対し,その調査と報告を依頼した。 その結果,本件システムには,SQLインジェクション対策が不十分という脆弱性が判明したことから,XはYに対し,その脆弱性はYの被用者の故意過失によって生じたものであるから,使用者であるYには使用者責任があると主張して,民法715条1項所定の損害賠償請求権に基づき,緊急対策費用47万5200円,詳細な調査,抜本的な修正費用640万円,サーバー移転費用35万6400円,セキュリティ対策のための本件システ

                                                                      SQLインジェクション対策不備の責任 東京地判平30.10.26(平29ワ40110) - IT・システム判例メモ
                                                                    • やはり予想を超えてこなかったGPT-4と、GPUの未来、ホビイストへの手紙

                                                                      やはり予想を超えてこなかったGPT-4と、GPUの未来、ホビイストへの手紙 2023.03.16 Updated by Ryo Shimizu on March 16, 2023, 08:00 am JST 3月14日の早朝、GPT-4が公開され、筆者は早速試した。 その後、開けて3月15日の早朝、APIも部分的に解放され、筆者はそれも試した。 その上で、先週書いた記事の内容についての確信が深まった。 やはり、GPT-4は期待を超えてはこなかった。 GPT-4は、ChatGPT Plusに入会すると誰でもすぐに使うことができる。APIだけは招待制だが、それも筆者と同じくらいのタイミングでアンロックされた方も少なくないのではないか。 100倍規模のパラメータがあっても、アプローチには限界があるのである。 また、ChatGPTが注目を集めたことで、これまで下火になっていた他の大規模言語モデル(

                                                                        やはり予想を超えてこなかったGPT-4と、GPUの未来、ホビイストへの手紙
                                                                      • 1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita

                                                                        1. はじめに 本稿は、私が1年以上の期間をかけて、成長し続けるチームに変わることができた施策を紹介します。 本稿は長文なので、忙しい人は太字だけを拾い読みして、興味をもった施策だけを詳しく読んでいただければと思います。 なお、本稿の内容で「Developers Summit 2020 KANSAI」というカンファレンスで発表した結果、ベストスピーカー賞1位をいただきました。発表を視聴してくださった方々に感謝しております。 発表資料と発表動画はコチラ 2. 施策の効果 私の開発チームは当初(1年と数ヶ月前)は、以下の状態でした。 あまり積極的に今のやり方を変えようと思っていないチーム メンバーは、中堅(私)が1名と入社2年目と3年目の3人(後に新人が配属して途中から4名に) 全員、技術記事を書いたことがない 全員、社外の勉強会などのイベントに参加したことがない 全員、開発知識は、業務で教え

                                                                          1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita
                                                                        • アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey

                                                                          はじめまして。そーだい(@soudai1025)です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化

                                                                            アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
                                                                          • 非プログラマの人に「なぜ変更は難しいのか」と聞かれたら使う「六法全書の例え」「時刻表の例え」が秀逸

                                                                            yourbugs @buggylion 非プログラマの方に「どうしてそんなに変更するの難しいんですか?」って聞かれたら、「六法全書を思い出して欲しい、条項の中から一文探し出して、それが他と矛盾しないかもチェックして欲しい、もちろんその変えるべき条項文は依頼側は分からないので、そっちで全て調べてください」って伝えてる 2020-12-05 10:32:24

                                                                              非プログラマの人に「なぜ変更は難しいのか」と聞かれたら使う「六法全書の例え」「時刻表の例え」が秀逸
                                                                            • よく聴いてるポッドキャスト

                                                                              はじめに 自分が fukabori.fm を配信しているのもあるけど、インプットソースとしてポッドキャストをよく聴いている。この記事では、聴いてるポッドキャストをサクサク紹介していきたいと思う。 基本はTech系ポッドキャスト。たまに、違ったのをちょいちょいぐらい。 実際に以下で書いてないポッドキャストもあるけど、少なくとも5エピソードは聴いたかな、ってものを紹介していく。 ポッドキャスト列挙、コメントつけて 以降は A-Z 順で、自分のPodcastクライアント(Podcast Addict)でSubscribeしているものを順番に。 ajito.fm suzukenさんが主宰しているポッドキャスト。VOYAGE CTOの makoga さんがよく登場する。技術的に濃いネタから、組織的なネタまで幅広い。 すごく印象に残っているepは ajitofm 29: Chiki Chiki Mon

                                                                                よく聴いてるポッドキャスト
                                                                              • 【資料公開】アジャイルについてマネージャーが知るべき97のこと

                                                                                みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし

                                                                                  【資料公開】アジャイルについてマネージャーが知るべき97のこと
                                                                                • タッチパネル式食券機を作ってる連中ってバカなの?

                                                                                  もういろんなところで言われてるけど、最近よく見るタッチパネル式の食券発券機ってなんであんなに無駄なステップが多いの? 行きつけのラーメン屋でノーマルラーメンを頼もうと思ったらこんだけの画面を経なきゃならない。 ・ラーメン、サイドメニュー、ドリンクからラーメン選択 ・ラーメン、チャーシューメン、煮卵ラーメンなどからラーメン選択 ・トッピング選択画面でトッピング無しを選択 ・麺普通、大盛から普通を選択 ・お支払方法選択ボタンをタッチ ・電子マネー、現金から電子マネーを選択 ・いくつかの選択肢からたとえば交通系ICを選択 ・カードをタッチ→発券 こんなのこうすりゃ簡単じゃん。 ・注文画面(=初期画面)で注文する品を選択→他メニューやトッピングも追加選択できる状態で「電子マネーをタッチ、あるいは現金を入れてください」の表示 ・カードをタッチあるいは現金を投入して発券(どの電子マネーかは自動判別)

                                                                                    タッチパネル式食券機を作ってる連中ってバカなの?