「プログラミングを学ぶ」ではなく「要件定義を学ぶ」 田中邦裕氏（以下、田中）：あと13分ぐらいになったので、今後の展望にいきたいのですが、その前に、質問が7個ほど来ているので、みなさんに聞きたいと思います。 一番投票数が多い質問が、「非エンジニアでAIを使ったスマホアプリを作りたいんだけれども、プログラミングをそもそも学ぶべきか？」という質問です。 生成AIがある今、何をどのように学ぶべきなのか。プログラムを学ぶべきなのか、それ以外になにか手段があるのか。目的によっても違うのですが、ざっくりとしたこの質問に対して、なにか答えられる方はいますか？ 比戸将平氏（以下、比戸）：じゃあ、私から。 田中：はい、お願いします。 比戸：先週ぐらいに、NVIDIAのジェンスン（Jensen Huang氏）が、「今後はAIがプログラムを書くから、もうプログラムを学ぶ必要はないよ」と発言したのが切り取られて、
今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と
tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ
こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ？」「どうして？」「つまり？」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク
ありがたいことに、いわゆる文系・ビジネス職からベイエリアでソフトウェアエンジニアになった前回の記事は多くの方に読んでいただきました。改めてお礼を申し上げます。とはいえ、当然ですが、ソフトウェアエンジニア（以下、SWE）になって終わりではなく、SWE になってからもそれ以上に大切であり、実際に SWE 転向後、どのような経験をしたのか、現実的な点も含めて、この記事では書いてみようと思います。 結論から言うと、初めは知識や経験の浅さから苦労しましたが、最終的には社内査定でも最高評価をいただき、なんとか昇進、異動する運びとなりました。 SWE になってみてまず、ポジティブな面から、状況整理も兼ねてお話しすると、自分は多くの方に使っていただいている製品・機能の Android アプリ（≠ Android OS）及び、そのバックエンドを担当することになりました（つまり、Android アプリがメイン
スクラムフェス大阪2024の登壇資料です。 スクラムマスターとして、あるチームでエンジニアとQAの間に見えない壁があり、それが崩れるまでを眺めた。しかし、チームは時間をかけて壁を崩すことができ、その結果、よりユーザーと価値に向き合えるようになった。チームの状況は、初めてアジャイル開発やスクラムに触れるメンバーが多くいたよくあるプロダクトチームであった。スクラムマスターは、なぜ壁崩せたのか、なぜ見ていられたのかを語る。この物語は、あなたのチームでも起きうることであり、アジャイル開発に取り組む上での示唆になるはずです。
スタートアップ企業が実践する「身の丈スクラム」の現在地 / Current State of 'Right-Sized Scrum' Practices in Startups
Scrum Fest Osaka 2024で発表した内容です。 https://www.scrumosaka.org/ https://confengine.com/conferences/scrum-fest-osaka-2024/proposal/20059 ■リンク 後回しにされがちな問題を改善するための「改善デー」「やさしさデー」のご紹介 https://tech.layerx.co.jp/entry/2023/12/27/171319 Q. 完成の定義と受け入れ基準の違いは何ですか？ https://www.ryuzee.com/faq/0077 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法 https://speakerdeck.com/moriyuya/product-management-rsgt2023
先日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を最後まで読
こんにちは! SmartHR プロダクトエンジニアの @sakata と @hypermkt です。 SmartHRではほぼすべてのチームでスクラム開発を行っています。スプリントプランニングとスプリント進行中における課題に対し、私たちのチームでは「予言の書」という取り込みを行っています。本記事では、この「予言の書」の概要とその効果についてご紹介します。 予言の書が必要な背景 スクラム開発で、チームが消化できるキャパシティからタスクを選定したにも関わらず、すべてのタスクの消化ができなかったという経験はありませんか？ 私たちはたくさん経験したことがあります。そこにはスプリントプランニングにおける計画とスプリント進行の難しさがありました。 すべてのタスクが終えられるか不安がある まだ作業タスクには何も着手していないので当たり前ではありますが、チームが消化可能なキャパシティからタスクを選定し、優先
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「尖った人ではなく、暗黙知を形式知に変換する人がほしい」 “均質人材”を育成してきた日本でこれから求められる能力とは
ウォータフォールはやめて2024年の開発をやろう！｜牛尾 剛
高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
「なぜ」と聞かずに理由を引き出す！「詰めてる」感を減らす言い換えテク - Qiita
ソフトウェアエンジニアになってから: 昇進と異動（と最高評価）｜Hiro Tsujino
エンジニアとQAの壁が崩れていくのを眺めていた #scrumosaka | ドクセル
『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita
スプリントプランニングの未来予測： 予言の書 - SmartHR Tech Blog