Miro大好きjacopenです。エンタープライズなIT界隈ではおそらく日本でトップクラスにMiroを愛している自信がある。 さて今日はMiro Advent Calendar 2021の3日目。 今日は、人類がいかにWeb会議に不向きかという話と、そのギャップをMiroで埋めようという話。あとは自分が関わっているカンファレンスでMiroを使いまくっている話をする。 Web会議の8割はXX コロナ禍でだいぶ定着したWeb会議。でも、個人的には世の中のWeb会議の8割は上手くいっていないと思っている。数字に根拠はないけど。 何を持って上手くいっていないとするかだが、「対面の会議と比較して伝えられる度合いが低下している」とすると、8割くらいはそれに該当すると言っても過言ではないだろう。 何故そうなるかというと、基本的に人は言葉だけで物事を正確に伝えることはできないからだ。 人間の会話において、
※今回はほぼ実話です。 システム開発会社勤務 プログラマーワイ ワイ「さあ、今日も開発をしていこか」 ワイ「とあるWebサービスの管理画面を作らなアカンのや」 ワイ「今日は、どんな機能を作らなアカンのやったかな」 ワイ「せや、クライアントさんからもらった機能一覧.xlsを見てみよか」 ワイ「あとは、デザインデータも見ながら、詳細設計書でも作っていこか」 ワイ「・・・ふーむ、作るべき機能の一覧は書いてあるんやけど」 ワイ「なんか、やる気が出ぇへんなぁ」 ワイ「仕方ないから、社内のSlackで愚痴っとこか」 ワイ「今のプロジェクト、誰のために何を作ってるのかがイマイチ分からんから」 ワイ「モチベーションが上がらへんなぁ」 ワイ「この管理画面を使って、どんな課題を解決したいのか」 ワイ「どういう風にユーザーさんの業務をうまく回したいのか」 ワイ「そんなんがピンと来てないから、作るべきモノもはっき
鳥取県鳥取市で主にホームページの制作を行っている合同会社フットでWebディレクター兼エンジニアをしている岡村といいます。 このnoteは先日、各地でWebディレクターをされている方々と「Web制作の見積り」というテーマでZoomを使用した情報交換会を行った際に自身がカンペとしてまとめたものをnote用に加筆修正したものです。 情報交換会の実施後にTwitterで「こんなお話しましたー」とつぶやいたところ、普段あまり「いいね」がつかない僕のアカウントにしては結構反応を頂きました。 情報交換会でも「他の人の見積書の作り方を知る機会がないので新鮮だった！」「発見があった！」という声が挙がり、僕自身も新しい気付きがあったので、こういった情報を共有すると参考になる方がいるかも。ということで、非常にざっくりとしていますがまとめてみました。 タイトルにあるように、あくまでも僕たち（合同会社フット）の場合
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
『はじめよう！ 要件定義 ～ビギナーからベテランまで』はそのタイトル通り、ソフトウェア開発に携わるエンジニアやPM向けに、要件定義の進め方について優しく解説してくれる書籍です。かわいいイラストと平易な文章がとっつきやすく、するすると読めてしまいますが、要件定義って何をどうやったらいいの？とお悩みの方に対して、まずはこれだけやっておくべき基礎知識を得ることができる、とてもわかりやすい内容になっています。 そしてそして、ここからが本noteの主な趣旨ですが、この3部作はデザイナー目線で読み解くと、極めて明瞭で本質的で実践的な、ユーザー体験設計とUI設計の進め方について学べるデザイン教則本と言えるのです。 以下、その理由と、本シリーズを使ってUIデザインを進めていく方法を実例を踏まえて解説していきます。 要件定義とはUI・機能・データを決めることいきなり『はじめよう！ 要件定義 』のキモ・コンセ
プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。 1. プロジェクト概要1-1. 背景プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。 1-2. ゴールゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。 1-3. 目的プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5
ソフトウェア開発の見積もりにおける問題点は何ですか？
回答 (10件中の1件目) ITプロジェクトの実態とは！ - cagylogic とても有名なイラストですが当時(5年ほど前だったかな。。。)大笑いした記憶があります。見積もりにおける問題点にはフォーカスしていませんがそれぞれの立場で捉えた要件内容に違いがある事が原因なのは明らかです。簡単に言えば要件に解釈の余地がある場合ではないでしょうか。そのイマジネーションが膨らんでしまう余地がプロジェクトを良い方向に進めるケースは(希にある)ほぼないと心得て発注すべきだと思います。
GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
VTeacher所属のSatomiです。 ※ 本家Miroさんからコメントをいただいたので掲載します！ ミロジャパン高山です。本記事ではMiroについてご紹介頂き誠にありがとうございます。大変参考になります。もし本記事の趣旨にあっていればですが、以下の２つのテンプレートを日本語対応をしましたので、よろしければ、リンクを付与頂けますと嬉しいです。 スクラムボード：https://miro.com/ja/online-scrum-agile-tool/ マインドマップ：https://miro.com/ja/mind-map/ 或る日突然、「100万円のプロモーション予算がついたから急いで作って」と頼まれました。 ※ちなみにプロモーション予算（100万円）に人件費は含まれないそうです。 そして、偉い人から下の画像が送られてきました。 （「4月1日に夢を語る」という PR TIMES の企画だそ
はじめに タイトルの主張が少し強いですが、以下の本を読んでコミュニケーションスキルについて書かれている部分が有益だなと思ったので メモ程度 にまとめました。 元の本では具体例などが書かれていてわかりやすいので、その点を押さえたい方は購入をお勧めします。 コミュニケーションスキル 以下の3つがある ヒアリングスキル ミーティングスキル プレゼンテーションスキル 1.ヒアリングスキル A.質問 Open-Close Open 5W2Hを用いた質問 Why,What,Who,When,Where How(程度),How to(手段) Close yes,noで解答できる質問 認識の不一致が連続すると信頼を下げやすいので注意する 深掘り 目的 原因 影響・結果 手段 反復 「それ以外にありますか？」 明確化 曖昧な表現を明確にする 例：「うまくできない」→「納期に間に合わない」 論理性チェック A
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
はじめに この記事では、メインフレームでは異常時の処理でどのようなことをやっているのか、また、Linuxの異常処理との違いなどについて話してみようと思います。 この記事を書くに至った直接的なきっかけは、とある人からリクエストがあったからです。が、日ごろからメインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多いと感じていてはいました。 筆者は今でこそLinux Kernel周りの仕事をしていますが、20年ぐらい前のころはメインフレームのOS開発部隊に配属されていて、メインフレームのとあるコプロセッサのドライバを書いたりしていました。この際、その異常処理における考え方を体験する機会が多々あり、当時のその経験が20年後の現在でも大いに役にたっていると感じていたからです。 そもそもメインフレームは、これまで長年にわたっ
この記事は 「Develop fun!」を体現する Works Human Intelligence Advent Calendar 2020 21日目の記事です。 昨日の記事は@sparklingbabyさんのStream API がもっとわかる記事でした。 あらすじ 私は2019年にWorks Human Intelligence（正確には分社前の会社）に新卒入社し、 19年10月からプロダクト開発部門に配属され、SETエンジニアとしてとある製品のJava開発環境の改善に取り組んでいます。 ざっくりとプロダクト開発を紹介するとこんな感じです。 3万クラス程度ある大規模Java Webアプリケーション 開発環境はEclipseを使用 開発者のOSはWindowsのみ Before 私が開発チームに参加した時点では 部門として新規開発に注力しており、足下の環境改善をやる担当者がおらず、 い
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
techbookfest.org GUIの薄い本です。「入門 監視」ばりに主語デカタイトルです。 著者は私と f_subalさん、daiizさん、miyaokaさんで、座談会パートにはKeima Kaiさんが参加しています。 内容は「ドラッグ＆ドロップを始めとする作るのがしんどいGUI」をいちから書いてみようよ、という感じです。 GUIコンポーネントの使い方についての本はよく見かけますが、コンポーネント自作についての本というのはなかなか珍しいんじゃないかと思います。 概ね下記のようなノリの、ゆかいなGUIの本として読んでもらえれば、と思います。 私はセレクトボックスを実装してみようという章を書いています。最終的になぜかリングコマンドになりました。 中でも、最後の座談会パートは好評です。STUDIOの二人が参加しているので、先にSTUDIOを触ってみるとより文脈がわかると思います。 サンプル
なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ システム開発会社「アクシア」の代表として、自社・他社含め、さまざまなエンジニアのコードを読んできた米村歩さん。そんな米村さんの持論は、「コードの可読性は生産性に多大な影響を与える」ということ。可読性の低いコードはどんな弊害をもたらし、どうすれば改善できるのか――。チーム開発を効率化するコードの「可読性」について綴っていただきました。 プロフェッショナルのエンジニアには、「可読性」の高いコードを書くスキルは必要不可欠です。単に目的とする処理が実行できればよいわけではありません。しかし実際の開発業務の中では、可読性は意外と軽視されてしまいがちです。 経験の浅い駆け出しのエンジニアにとっては、可読性の重要さを肌感覚で理解するのは難しいかもしれません。また、新人エンジニアに対してプログラミング言語や開発ツールについて
忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
アジャイル手法提唱者が涙ぐんだ「日本発の論文」 | Japan Innovation Review powered by JBpress
新しいソフトウェア開発方法論「アジャイル開発」の一手法である「スクラム」の源流は、日本発の論文にあった。その論文著者の一人、野中郁次郎氏（一橋大学名誉教授、中小企業大学校総長）が語る「アジャイルの真髄」とは何か。（JBpress） 新しいソフトウェア開発手法として、さらに組織変革やビジネスの革新手法として注目を集めている「アジャイル」。「スクラム」はその中で最も普及している具体手法である。その「スクラム」提唱者の一人ジェフ・サザーランド氏が着想を得る原点となったのが、日本企業におけるイノベーションの成功要因を研究した日本発の論文なのだ。 サザーランド氏が、その論文を竹内弘高氏（現ハーバード・ビジネス・スクール教授）とともに執筆した野中郁次郎氏に実際に対面したのは、「スクラム」を提唱してから時間が経った2011年だった。サザーランド氏が着想を得た論文の中核部分は何か、またどのような経緯で対面
こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！ 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R
某大手企業のプログラマー「これから皆さんがマスターしておくべき言語ってなんだと思いますか？」→その答えがジョークかと思ったけど後にマジだとわかった
卜キワ・クロツグ🎂4/5 @TokiwaKrotzg 某大手企業のプログラマー「これから皆さんがマスターしておくべき言語ってなんだと思いますか？Java！C#！C++！Python！HTML！ハッハッハ惜しいですね～正解は日本語です！」 中学オレ「フッｗジョークだろ」 今専門オレ「あれマジだったんだなぁ…」 2021-06-14 11:13:16 卜キワ・クロツグ @TokiwaKrotzg 17歳(7周目)のバーチャル存在です。ガラナとケバブとあくタイプのポケモンが好きです。ししのうさはいいぞ。🤍@oofmi2 Code:Cistus Discord:TokiwaKrotzg#1044 モノリス閉鎖中 📡→@amlgam14 VRC:2018-08-15 vrchat.com/home/user/usr_…
先日、ウェブフロントエンドについて理解するためのただ一つの方法を記事にしました。それは「古い知識に頼るな。公式を読め」でした。たった一つの方法です。これをできない人は必ず行き詰まります。公式をひたすら読み込むことができる人は、たぶん大丈夫でしょう。 今回の記事は、その先にあるものです。 モダンフロントエンドの重要性ここでは少し前回の記事のおさらいをしておきます。 2020年のソフトウェアエンジニアリングの世界ではウェブ技術の重要度は増すばかりです。もちろんウェブ技術というのは広い分野です。ウェブ（HTTP/HTML/JS/CSSその他）によるサーバー・クライアント型のソフトウェアは、莫大な市場を背景にどんどか技術が投入されています。 ウェブ技術の中でも、ここ数年はフロントエンド技術の比重がとても大きくなりました。前回の記事にも書いた通り、少なくとも50%以上の影響力を持っています。 ソフト
『エルデンリング』の広大なオープンフィールドはいかにして作られたのか。6100ｍ×7400ｍの超巨大マップをエンジニア視点で大解剖するセッションをレポート【CEDEC2022】
『エルデンリング』の広大なオープンフィールドはいかにして作られたのか。6100ｍ×7400ｍの超巨大マップをエンジニア視点で大解剖するセッションをレポート【CEDEC2022】 8月23日から25日にかけて、ゲーム開発者向けカンファレンス「CEDEC2022」が今年も開催された。本記事ではイベント2日目に行われたセッション「ELDEN RINGのオープンなフィールドに対応するためのエンジニア取り組み事例紹介」のレポートをお届けする。 フロム・ソフトウェア初のオープンなフィールドを実装した『エルデンリング』は、同社が得意とする美麗なグラフィックで壮大かつシームレスな空間を見事に表現した。しかし、広大なスケールのフィールドはいかにして開発されたのか。 本セッションでは、そんな『エルデンリング』の広大で美麗なフィールドの開発過程を明らかにする。登壇者は本作にシステムデザインディレクターとして参加
ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ - 勘と経験と読経
読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。 #51 V字モデルの深淵を覗き込んで反省する：「単体テストの考え方（UTPPP）」を読む（後編） - 勘と経験と読経 #50 V字モデルの深淵を覗き見た気分：UTPPPを読む（前編） - 勘と経験と読経 #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる？ #デッドライン読書会 - 勘と経験と読経 #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経 #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経 さ
「ソフトウェアアーキテクチャの基礎」読書感想
2010年代を乗り越えてきた経験者が読むと良さそうという噂を聞いたので読んでみた。 内容まとめではなく感想です。各章のタイトルだけは丸々記載してますが、目次として上記ページで全て公開されているものです。 ちなみにこれ書いている私はソフトウェアアーキテクトではなく、フロントエンドアプリケーションの設計を担当するテックリードぐらいのレイヤーです。この書籍の中でいう「開発者」です。 業務ではフロントエンドアプリケーションの設計・実装をしています。 全体的な感想 1章（イントロダクション）、22章（効果的なチームにする）、23章（交渉とリーダーシップのスキル）が特によかった。 やっぱ "結局人" の部分が刺さってしまう。 心に書きとめておきたい3つを挙げるとしたら以下。 ソフトウェアアーキテクチャとは「構造」「アーキテクチャ特性」「アーキテクチャ決定」「設計指針」の4つから成る 「一見どう見えよう
こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの？出来なかったらどうするの？」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕
みずほ銀行のシステム開発裏話、なんかもう俺らからすると当たり前すぎて、逆に何言ってるか解らなくなるまである→「これはひどい」
𝕏 𝕃（おおきなえる）🌸⚒️ @ellnore_pad_267 雑談垢だよ。 ホロ沼にハマッているよ。 消費税を納税しているよ。 ふぁぼは既読マークだよ。 ＲＴは賛同じゃあないよ。 フォロバはしないよ。 Amazon アフィプログラムに参加してるよ。 ホロ箱推し member of 🌸⚒️🐏🌽🥐 sugaryo-pad.hatenablog.com
フロントエンドにおける「単体テストの考え方/使い方」
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している話
いぐぞー ✈️ 旅するプログラマー @igz0 旅とプログラミングをこよなく愛します。 アメリカ大陸🇺🇸を横断しました！！小学生からプログラミング→新卒SIer→Webに目覚め個人事業主兼会社員。テレビ出演経験あり。 Webサービス制作者。読書・IT関連を中心にツイートします！！ネタツイート有。アイコンは@ixy先生に利用許諾済み。Amazonアソシエイト参加。 note.com/igz0/ いぐぞー ✈️ 旅するプログラマー @igz0 Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」 > アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している これマジ？？ 日本のIT企業が、米国では「時代遅れ」のウォーターフォールを未だに信奉してるってコト！？ pic.twitter.com/jRofJKmAKM 202
エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 はじめに 工数管理はプロジェクトの成功に欠かせない要素です。工数を正確に見積もり、管理することで、プロジェクトの遅延を防ぎ、クライアントやプロジェクトメンバーの信頼を得ることができます。 本記事では、工数見積もりの重要性とその手法、そして失敗しないためのポイントについて書きたいと思います。 「もっとこうした方が良いよ！」 や 「うちの会社ではこの様な考えで取り組んでます！」 があればぜひコメント欄で教えていただけますと幸いです。 工数とは？ プロジェクトや業務を完了するために必要な作業時間のことを指します。 「人日」 や 「人月」 と呼ばれており、1人日は8時間、1人月は160時間（1日8時間、平日20日稼働）で表現するケースが多
友人「えっ、出版社に推しとかあるの笑」”好きな出版社”という概念は誰もが持ち得るものではないと知った話→皆さんの推し出版情報が続々と
佐原ひかり @sahara_hikari 友だちと本屋いったとき、「この出版社めっちゃ好きなんよな〜〜推し」と言うと、「えっ、出版社に推しとかあんの笑」みたいな反応が返ってきて、そうか、「好きな出版社」という概念は誰もが持ち得るものではないのだなと、ちょっとしたカルチャーショックだった。でも「好きな出版社」ってあるよね？ 2020-08-29 13:09:15
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
## 今回発表したイベントについて PeerQuest Inc. （ https://peer-quest.jp/ ）様主催の、#開発PM勉強会（ https://twitter.com/search?q=%23%E9%96%8B%E7%99%BAPM%E5%8B%89%E5%BC%B7%E4%BC%9A&src=typed_query ）の第7回目のイベント、「要件定義どうしている？共有LT」で発表させていただきました。 株式会社Speee プロダクトマネージャー 塚本尚 https://peer-quest.connpass.com/event/229463/ ## 発表した内容について 結局行き着いたのは、（あるある話だとは思いますが）**whyとwhatの定義をしっかりす定義すること** でした。 その過程で多くの失敗をしたので、当時私がやってしまった要件定義時の失敗について発表し
土田善紀 @tsuchidasama 「このプログラムを修正するより、私が一から書き直した方が早い」っていう、プログラマあるあるエピソードを素人の皆様にも直観でわかって頂ける、すごく良い例画像をFacebookで入手しましたので、共有いたします。 pic.twitter.com/unPeAahsyX 2020-06-09 16:42:58
「下手だなあカイジくん…！技術的負債の返済の仕方が下手…！」 ちゃんとシステムを構築しないと後で多く利子を払うことになる
米村歩@日本一残業の少ないIT企業社長 @yonemura2006 「技術的負債」という言葉があります。要するにちゃんとシステムを構築しないと後で多く利子を払うことになってしまうということです。無茶な納期や金額でシステムを作らせてたまたまうまくいったら最初は得した気分になるかもです。しかし後々の改修やらメンテやらで莫大な利息を払うことになります。 2020-06-24 07:49:11
アジャイル・DevOps時代の テストと品質保証 （完全版） / Testing and Quality Assurance in Agile and DevOps Era
この10年は多くの変化がありました。 ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。 技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。 一方で、テストや品質保証はどのように変わってきたでしょうか？ 私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。 そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。 このセッションでは、アジャイル・DevOps時代におけるテストと品質について、 - 現在 - 戦略と戦術 - 組織未来 のお話させていた
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人類はWeb会議に向いていないので、もっとMiroを活用すべき - Cloud Penguins
「なんのために作るか分からへん」と愚痴っていたらPMさんが救ってくれた話 - Qiita
見積書の作り方・考え方（僕たちの場合）｜岡村 旭 Webディレクター＆エンジニア / foot llc.
2024年Gitワークフロー再考 | フューチャー技術ブログ
『はじめよう！ 要件定義』（とそのシリーズ）を読んで、はじめよう！UIデザイン｜金 成奎
Webサイト制作の要件定義書の確認項目｜重松佑 / Shhh inc.
「急いで作って！」と言われたとき、私がまずやること→Miroだけでスクラム
要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
メインフレームの異常処理 - Qiita
新卒１年目が荒れ果てた開発環境に１年間でCIを導入し単体テストを布教した話 - Qiita
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
「入門GUI」が発売されました - No Regrets in Bathing
アジャイルと契約 / Agile Contracts
スケジュールにバッファを設けるのは悪か？ - ユニファ開発者ブログ
2020年のウェブフロントエンドエンジニアが学び実践すべきこと｜erukiti
スケジュールの見積もりを適当に答えたらコミットメントにされる問題について｜きゅーい / koyo
工数管理というものを理解する - Qiita
実践要件定義入門 - 勘と経験と読経
見積もりをがんばらない - forest book
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata @takehora もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている。 そして、経産省の契約モデルにあるとおり、要件定義は、準委任契約であるのが妥当。 引用ツイート nori @00oichan · 2022年12月3日 要件定義に関わる人は３億回くらい読んでほしい
3つの決めつけから見る失敗の要件定義
「プログラムを修正するより一から書き直した方が早い」という状態が直感でわかる例画像にゾワゾワする皆様