イーロン・マスクのロケット製造５つのステップがサイコーだった
イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
「最悪のソフトウェアはマネージメントの問題」、よいソフトウェアを作る方法を政府のソフト開発を行う技術者が語る
by Austin Distel 「ひどいソフトウェアが生まれる場合、問題は特定のエンジニアリングではく、マネージメントにあることが多い」と語る、Googleのプロダクトマネージャーを経てシンガポールの公安部門向け技術開発を行うLi Hongyiさんが、「よりよいソフトウェアはどうやって構築するのか？」をつづっています。 How to Build Good Software https://www.csc.gov.sg/articles/how-to-build-good-software Hongyiさんは、ひどいソフトウェア開発の問題点を一文で「プロジェクトオーナーが解決すべき問題を明確にすることなく解決策としてのソフトウェア構築をスタートさせ、関係者からの長い要望リストを、フルスクラッチで開発を行おうとする外部の開発チームに委託すること」とまとめています。 一方で優れたソフトウェア開
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
スクラムチームのためのカンバンガイド by Scrum.org
※本記事は旧版です。最新版（2019年9月）はオフィシャルサイトからPDFをダウンロード可能です。 この作品は The Kanban Guide for Scrum Teams の翻訳です。クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。 目的カンバンにおけるフローベースの考え方は、スクラムフレームワークとその導入を強化・補完する。チームがこれからスクラムを使う場合でも、これまで長年スクラムを使ってきた場合でも、カンバンは適用可能である。 この「スクラムチームのためのカンバンガイド」は、Scrum.orgのコミュニティのメンバーとカンバンのコミュニティのリーダーがコラボレーションして生み出した結果である。その両者が協力して「スクラムチームのためのカンバンガイド」を支援している。カンバンとスクラムを組み合わせれば、プロのソフトウェアの実践者が恩恵を受
カンバンの基本のキ - Qiita
この記事は Rakuten Advent Calendar 2016 の記事です。 こんにちは、アジャイルモンスターこと及部敬雄（@TAKAKING22）です。 現在は最近できたスタートアップの部署に所属しており、エンタープライズスタートアップの成功例をつくるべく、チームづくりからプロダクトマネジメントから越えられる壁はすべて越えるつもりで日々奮闘しております。 今日はカンバンについて取り上げてみます。 ペンと付箋があれば始められる オンラインサービスも数多く存在する アジャイル開発を取り入れているか否かに関わらずエッセンスを取り入れることが可能である など導入のしやすさから、今ではメジャーなソフトウェア開発手法の1つになっています。実際に皆さんの現場でもカンバンを運用している、あるいはまわりで運用しているチームがいる方も多くいらっしゃるのではないでしょうか？ 楽天でも、私がカンバンを始め
5分で理解するリーンな「かんばん」
Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー（PO）の役割で、青い人たちが開発チーム（DEV。ここでは2名ずつ2チーム）、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP（Work in Progress：仕掛り作業）が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。
Pairs事業部全体での「カンバン」をまたまた作り直しました。
これまでの「カンバン」の課題週一で行っているプロセス改善委員会にて、いくつかカンバンV2に関する課題点などがエンジニア・POなど職種問わずあがるようになりました。いくつか代表的な課題点についてまとめます。 「エピック」「ストーリー」など言葉の定義から認識がバラバラで、チケットの大きさがわからないカンバンV2では、各ストーリーやタスクなどを紐付ける大きな単位として「エピック」を定義し各エピックごとに横軸のレーンを用意、それぞれのレーンの中でストーリーやタスクなどを動かし、プロジェクトのステータスを表していました。 しかし、運用していくにつれ、各チーム間でエピックやストーリーとして言われているものの粒度がバラバラに・・。エピックとして扱うものがストーリーとしてカンバン上に鎮座し何週間も動きがないチケットがあったりと、それぞれのプロジェクトチームごとに異なる粒度でチケットが定義されていました。
なぜWIPの制限が重要なのか
みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2. タスクの切り替えが減る一節によればタスクの切り替えは20%程度のムダが発生するとも言われています。 ちなみにタスクの切り替えはトヨタ生産方式における7つのムダのうち運搬
パッケージソフトだか何だか知りませんが、現行システムと同じの作ってくださいよ
連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「要件の範囲が食い違ったことにより生じた紛争」を解説する。 ユーザーが望む機能がシステム開発の要件から抜け落ちたがために発生する紛争は、本連載でこれまでにも何度か取り上げてきた。 IT紛争の類型は種々さまざまであり、過去の判例が全てそのまま適用できるわけではないが、裁判所が「たとえ要件としてユーザーから明示されていなくても、その機能が契約の目的を果たす上で、当然に必要な事柄であるとベンダーが認識し得る状態にあれば、ベンダーにはその機能を作り込む義務（債務）がある」と判断した例が幾つもある。 要件定義書よりも契約の目的の方が重いとする考え方だ。 今回取り上げる判例も、「ユーザーが必要と考える機能が、ベンダーの作成した要件定義書から抜け落ちており、これを作り込まなかった」というものだ。これまでと少し異なるのは、パ
「AI開発ミステリー ～そして誰も作らなかった～」 とある大手製造業の怖いハナシ (1/5) - ITmedia NEWS
「AI開発ミステリー ～そして誰も作らなかった～」 とある大手製造業の怖いハナシ：マスクド・アナライズのAIベンチャー場外乱闘！（1/5 ページ） ITmedia NEWS読者の皆さん、はじめまして。マスクド・アナライズと申します。自称“AI（人工知能）ベンチャーで働きながら、情報発信するマスクマン”です。 日々、さまざまな企業から相談を受ける立場として、記事を通じてAI開発のリアルな現状をお伝えしたいと思います。AIやIoT、データ分析における華々しい成功事例やプレスリリースとは一線を画し、道理の通らぬ世の中にあえて挑戦する“シュートスタイル”を目指しております。 口火を切ったITmedia NEWSによる取材記事もご参照ください。 「開発の丸投げやめて」 疲弊するAIベンダーの静かな怒りと、依頼主に“最低限”望むこと 今回は「AI開発ミステリー ～そして誰も作らなかった～」と題し、AI
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
超高速な開発ができるわけ | Yakst
あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時？それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール
企業をデザインシフトさせる方法と今後のデザイン戦略
Schoo：企業をデザインシフトさせる方法と今後のデザイン戦略 https://schoo.jp/class/3241 世の中に「デザイン」という言葉が浸透しつつあるなかで、企業の事業戦略においてもデザインの重要性が高まってきています。 この授業では、そんな中で、デザインが大事という事は理解し始めているが「やり方がわからない経営者やプロデューサーの方」「社内への説得方法がわからないデザイナーの方」を対象に、企業が「デザインシフト」するために必要な考え方や仕組み化すべきことを授業で説明します。 具体的には、私自身がDeNAでゼロから100名弱のデザイン組織を作った実例を交えた実行方法や失敗談、そしてデザイナーのキャリアパスについて、今後のデザイン戦略を交えながらお伝えしたいと思っています。
アメリカよりもクラウドよりも「デザインファースト」
「誰でも知っているが日本語に訳しにくい言葉がある」。社会生態学者ピーター・ドラッカーのほぼ全著作を翻訳された上田惇生氏と話していて、こう言われたことがある。一例として上田氏は「アート（Art）」を挙げた。「デザイン（Design）はどうですか」と尋ねたところ、「デザインも訳しにくい言葉の一つ」と仰った。 手元の岩波英和辞典で“Design”を引いてみた。最初の意味は「計画する」であり、「目論む」「企てる」「志す」といった訳語が並ぶ。2番目の意味として「設計する」があり、「下絵、設計図、図面を描く」などと書かれていた。 もう一つ、別の書籍に出ていた説明を紹介する。テクノロジー利用に関わる「デザイン」の定義である。 「資源を、人間の要求や欲求に対処し得る製品やシステムに作り変えたり問題を解決するために、計画を作成する反復的な意志決定のプロセス」――。 分かりにくいが要するにデザインは「意思決定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
提案依頼書に含まれる 無理難題の分類
プロダクト開発における結果目標の功罪、そして状態目標へ
ソフトウェア開発の見積もりにおける問題点は何ですか？
スクラムチームをやめて、20人でカンバン運用してきた半年間の軌跡 / Stop Scrum Start Kanban
TechCrunch | Startup and Technology News
