イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
2021年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。開発本部 オンボーディングチームの酒井（@sakay_y）です。社内のオンボーディングコンテンツを、どんどん社外へ公開することを夢見ています。 2021年もエンジニア新人研修を行いましたので、軽い紹介と、講義資料および一部講義動画（New!）を公開いたします。 2021年のエンジニア研修について 講義資料公開 Webアプリケーション基礎 HTTP/DNs ソフトウェアライセンス ソフトウェアテスト テスト自動化 アクセシビリティ Docker Chrome Developer Toolsの使い方 サイボウズのアジャイル・クオリティ デザインの役割と関わりかた データベース CI/CD セキュリティ モブに早く慣れたい人のためのガイド ITコミュニティ文化と情報発信に共通する成長と貢献の要素 正規表現 Kubernetesを使った開発入門 モニタリング入門 gRPC入門 日本語話
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。 本記事では、 sEのAさん デザイナーのBさん の二人が画面デザインをする過程を比べながら、その思考の違いを整理してみます。 3.sEのAさんの
2022.05.21 scrum Fest Niigata 2022 Main Hall 10:00-10:45 Proposal https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16425
界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Miz Kushida
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿で
好きなポッドキャストについてまとめる
そもそもポッドキャストって何？映像のない YouTube のような存在が ポッドキャストです。 つまり、ラジオのようなものです。 YouTube のように、素人も投稿できる音声 メディアです。 どうやって聞けるの？iOsからであれば、Apple Podcast Androidからであれば、Googleポッドキャスト ※Googleポッドキャストは、YouTube musicに統合の話が出ている 他にspotify、Amazon music、radikoからも聞けるらしい。 おすすめのポッドキャストヤング日経経済系の番組はおじさんがしゃべっていることが多いが、この番組は若い大学生～大学院生の女の子が最近の経済について 話しており、非常に聞きやすく、軽い気持ちで聞けるのが良い。ポッドキャスト的な流し聞きに向いてる。 日経トレンディ ＆ 日経クロストレンド日経トレンディ及び日経クロストレンドとい
やさしいMCP入門
4/9(水) お昼にYouTubeでも解説します🙌 やさしいMCP入門 ＆ 実践LT会（KAGと学ぼう！勉強会） https://kddi-agile.connpass.com/event/351600/
私がよく参考にしているサイトまとめ
はじめに Twitter、Qiita、Zenn...といろんなところから情報収集するのはいいのですが、それぞれの有益な情報をそれぞれのサイトにお気に入りとして保存しているので、必要な情報を探すだけで一苦労です。 ここで一覧にしてまとめておくことにしました。 ただし、特定の言語に依存するような記事はあえて排除しています。 皆さんにとっても有益な情報があると、この記事を公開して良かったなと思います。 また、皆さんのオススメの記事がありましたら、コメントなどで教えてください。 コミュニケーション 質問 質問は恥ではないし役に立つ https://qiita.com/seki_uk/items/4001423b3cd3db0dada7 新卒からの質問をソシャゲっぽい仕組みにしたら捗った話 https://qiita.com/ysktsuna/items/fced3a9515c8f585ca50 会
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
この記事はこんな人に刺さるかも知れません🙂 ・デスクをすっきりさせるマガジンが好きな人 ・自宅のデスク環境を改善したい人 ・ガジェットが好きな人 ・スタンディングデスクが気になってる人 ・オーダー天板が気になってる人 ・ディスプレイを縦に並べてみようと思ってる人 ・MacやPCを天板裏に収納出来ないかアイデアを探している人 ・DIYが好きな人 ・ ・ ・ ・ケーブルの存在を消し去りたい人...🗑 こんにちは！ LONZ（ロンズ）という会社をやっている、鈴木と申します。 普段はWEBやアプリのデザインや設計を。週末は極たまにお寺の住職をしてます。 そして生涯現役ピンピンコロリな人生を模索しています😌 さて、ここから本題です。 2020年リモートワークの波。 デスク環境改善の無限にループにはまる♻️2020年はほぼ自宅で仕事をしていた関係で、こんなループにはまってました...（こういう人
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
社内勉強会向け 新作(2025/12/06 ) →https://speakerdeck.com/watany/its-only-the-end-of-special-time
こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ？」「どうして？」「つまり？」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
＊文字かすれ修正しました Developers summit 2022 発表資料です。 元ネタはこちらのnoteです。 https://note.com/miz_kushida/n/n103a7da460c5 Twitter https://twitter.com/miz_kushida
目標設定の基本
Tidy First? ―個人で実践する経験主義的ソフトウェア設計著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ出版社：オライリー・ジャパン発売日：2024-12-25単行本（ソフトカバー）：164ページIsBN-13：9784814400911AsIN：4814400918 脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック著者／訳者：Mark seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin出版社：オライリー・ジャパン発売日：2024-06-18単行本（ソフトカバー）：312ページIsBN-13：9784814400799AsIN：4814400799
問い合わせ率が3年間で半分になった
こんにちは。カンムで業務部長してます平湯（ひらゆ）です。 カンムは現在、Visaプリペイドカードの「バンドルカード」と手元の資産形成に活用できるクレカの「Pool」の2つの事業をやっています。今回はバンドルカードのお話です。 2022年末に過去の問い合わせ率を集計したところ、一番多かった時期と比べると問い合わせ率が半分になってました。（問い合わせ率 = 問い合わせ数 / 稼働会員数） 良きタイミングなので頑張ってきたことを振り返ってみます。 どんなことをやったか一次情報から課題特定 →問題提起 →オペ整備 →リリースのサイクルを回した結果です。何よりも一次情報の取得が大事です。時間がかかるし、単純作業なので苦しいんですが、生の声を読むことで感情や背景が頭に染み込みます。問題により深く入り込めているという感じでしょうか。 この課題の解決策をエンジニア・デザイナー陣と考えていきます。カンムはエ
2023年度リクルート エンジニアコース新人研修の講義資料です
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
syacyo @syacyo_twit みずほの件がお昼のニュースで取り上げられてたけど『言われたことしかやらないような担当者の意識を改革する』って言ってた。 これは日本独特の考え方。日本以外の作業者は普通は言われたこと以外はやらない。なので欧米はマネジメント層が優秀だし高給。 2022-01-14 12:41:18 syacyo @syacyo_twit 日本は精神論、根性論を盾にマネジメント層が圧力をかけて作業者がなんでもかんでも気を利かせて動くように強要する文化ができあがってしまっている。 本来はマネジメントする側が綿密に各自の作業内容を分担して、それ以外はやるな、とまで指示するのが正しい姿なのよ。 2022-01-14 12:44:06 syacyo @syacyo_twit だからオフショア開発で外国勢に作業依頼したときに成果物が酷くてなぜ◯◯していないんだ、と問い合わせると オ
先日、こんな記事を拝読しました。 ゲーム会社の「アイデアの押し売り」への防衛策が注目集める。一方的に送りつけられたゲームのアイデアが行き着く先とは この条項は一見すると、メーカーがファンのアイデアを奪おうと考えているようにも見えるかもしれない。しかし真意としては別にあり、アイデアを送付した人から“権利主張”されないように、そのように記述することがあるのだという。 そうした人は、何らかのかたちでアイデアのスケッチやイラストをメーカーに“一方的”に送りつけており、実際には開発陣は目を通していなかったとしても、自分のアイデアが勝手に使われたとして権利を主張してくるのだという。 なるほど。頼みもしないのにファンから「アイデア」が送りつけられて、しかもそれを後から「パクられた」などと主張されない為に予防線を張っておく必要がある、という話ですね。 一昨年に起きた京都アニメーションへの放火事件でも、犯行
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
ペアプロが嫌すぎて会社を退職した話 - Qiita
ペアプロ・モブプロアンケート結果発表 🎉 ペアプロに対するエンジニアの本音が分かります。こちらもオススメです。 はじめに 巷ではペアプロ、モブプロがホットワードになっており、あたかも開発生産性を向上する特効薬のように取り上げられている印象を受けます。一方、この記事では、ペアプロ、モブプロ開発のネガティブな部分を考え、私の経験から感じたペアプロ、モブプロのアンチパターンとその改善策をご紹介します。 どんなアンチパターンを踏んでいたのか？ 勤務時間は100%ペアプロを実施（ソロプロ禁止） ソロプロは悪、ペアプロが最高というチームの雰囲気 フロー効率を過度に重視する姿勢 どうなったか？ ＋) 開発生産性およびデプロイ頻度は上がった ＋) 4keysなどの数値上の指標はすべてプラスになった －) エンジニアとしての楽しさ、個性が抑制された －) 精神的な負担が蓄積し、最終的には退職に至った 学び
いわゆるエンタープライズ向けソフトウェア開発技術者向けにお勧めする本をまとめてみた、というか10年くらい前に書いた記事を見直したもの。後輩から「後輩に勧めたい本を教えてください」という相談を受けることがあって（白目）記事が古くなっていたことに気づいたのだった。10年前の記事と同様にsIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。なお学生、新人、初心者向けにはなっていないのであしからず。 10年以上前に書いた記事はこちら agnozingdays.hatenablog.com ソフトウェア開発ライフサイクル全般 IPA 応用情報処理技術者試験 プロジェクト管理 デッドライン 人月の神話 アート・オブ・プロジェクトマネジメント 見積もり ソフトウェア見積り ～人月の暗黙知を解き明かす～ アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
ユニコーン企業のひみつ
「ユニコーン企業のひみつ」という本を読んだ。 本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。 そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。 ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン（評価額10億ドル以上の未上場企業）に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にspotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ（spotifyもすでに上場しているので厳密にはユニコーンではない）。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応
「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」 たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画（いわゆる「予算」）、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。 だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登っ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回は有名企業で無料で公開しているエンジニア新人研修資料をまとめました。 昨今、新人向けの研修資料を公開する企業が増えています。 クオリティーがかなり高いものが多く、初級者から中級者でも学びがある資料となっています。 資料の作り方も勉強になるので「勉強会で登壇している人」「企業の研修担当の人」にも有益な資料になっています。 この記事の主な対象者 有名企業の研修資料を網羅的に知りたい人 エンジニア初級から中級者の人 独学で学習をしている人 研修思慮の作成担当 MIXI新卒研修2024 まずはじめに紹介するのは、毎年新人向けの研修
ソフトウェア設計について、YAGNIやsOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、sOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
準委任契約に基づく報酬請求と善管注意義務違反 東京地判令2.9.24（平28ワ28934） - IT・システム判例メモ
開発は途中で終わった場合でも、準委任契約に基づく報酬請求はできるが、適切な計画立案・実行ができていなかったとして善管注意義務違反が認められた事例。 事案の概要 イベント企画会社Ｙは、自社の企画するイベントを管理するためのシステム（本件システム）の開発をＸに依頼することとした。 平成28年3月にＸは開発に着手したが、その時点では契約書が取り交わされておらず、4月になって、Ｘ・Ｙ間で以下の内容（抜粋）の契約書が取り交わされた（本件契約）。 1条2項 本件契約は，Ｘが（中略）業務に従事する技術者の労働をＹに対し提供することを主な目的とし，民法上の準委任契約として締結されるものとする。したがってＸは，善良なる管理者の注意義務をもって（中略）業務を実施する義務を負うものとし，原則として成果物の完成についての義務を負うものではないものとする。 3条3項 前各項にかかわらず，Ｙは，Ｘの本件サービスの業務
要件定義、基本設計、詳細設計の流れを総復習
はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ？」 「基本設計との違いって何だったっけ？」 「基本設計と詳細設計の区別って？」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて１からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部（特に要件定義や基本設計、詳細設計のサンプル）を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
変化に強いテーブル設計の勘所 / Table design that is resistant to changes
# DBリファクタリングの勘所と所感 - https://soudai.hatenablog.com/entry/2017/12/27/080000 # アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - https://agilejourney.uzab…
「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball
界隈で話題になっている（と私は認識している）「世界一流エンジニアの思考法」を早速読んでめちゃくちゃ良かった, とにかく人に勧めたいぞ！ という現役エンジニア（私）による書籍の感想エントリーとなります. 話題の本めちゃ良かったです. このブログを書く数日前にkindleで買って読む→めちゃいいやん！→紙版も買う←今ここ ってぐらいすごく良かったです*1. 世界一流エンジニアの思考法 (文春e-book) 作者:牛尾 剛文藝春秋Amazon 何が良かったか一言で言うと, 「強いエンジニアの習慣がここまでいい感じに言語化されている！！！」 という所ですね, 割と余すところなく詰まっていると思いますし, 一つ一つのTipsは再現性もあると思います（真似できるかどうかは別として真似は可能*2）. そんな「世界一流エンジニアの思考法」の感想を手短に書きます, 気になる方はお付き合いください. TL;D
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発
前提 この記事は内製開発をしているsaasの中の人であるエンジニアが、saasの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
PMBOKとはPMBOKは「Project Management Body of Knowledge」の略語で、日本語に訳すと「プロジェクトマネジメントの知識体系」です。読み方は「ピンボック」です。米国のプロジェクトマネジメント協会（PMI）が1986年にPMBOKのガイドブックの初版を刊行してから、ほぼ4年ごとに改訂され今では「プロジェクトマネジメントの世界標準」とされています。 本来「PMBOK」は体系そのものを指しますが、PMBOKのガイドブック「PMBOK GUIDE」を指す言葉としても用いられています。 【参考】PMI日本支部 2017年に発刊されたPMBOKの第6版はA4判750ページの大冊でしたが、第7版は250ページと1/3のボリュームになりました。目次の構成もガラリと変わっています。この大改訂にショックを受けたのが、プロジェクトマネジメント協会が主催するPMP試験（プロジ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イーロン・マスクのロケット製造５つのステップがサイコーだった
「時間がない」症候群、その傾向と対策
中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
理想のデスク環境を追い求めた話【2021年3月版】｜鈴木 潤一 / LONZ
エンジニアに許された特別な時間の終わり
「なぜ」と聞かずに理由を引き出す！「詰めてる」感を減らす言い換えテク - Qiita
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか
現代的システム開発概論
市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
"言われたことしかやらないのはダメ"という日本の考え方は独特→海外委託で衝突する原因やマネジメントの機能の話へ
ただの思い付きを「価値あるアイデア」と思い込む人が分かっていないこと
おっさんITエンジニアの後輩に勧める10冊の本 2025年版 - 勘と経験と読経
プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から
【最新版】有名企業のエンジニア向け研修資料まとめ - Qiita
ソフトウェア設計についての原則や法則についてまとめてみた
エンジニアの技術土台となる知識を得るための本の紹介 - Qiita
「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
PMBOKとは？第7版でPMBOKの内容が劇的に変更された理由
marsyatoissyo-yo.com
www.youtube.com
karin1.ag.ebb.jp
asahi-musicschool.com
anond.hatelabo.jp
zenn.dev/2b2t