マガジンのカバー画像

リーン開発を理解し実践する

9
開発の生産効率を2,3倍にするための知見を体系的に整理し、まとめております。 以下のような課題を感じている、エンジニア、経営者、PdMが対象読者です。 - 機能追加等に時間がかか…
運営しているクリエイター

記事一覧

未知の技術導入におけるドキュメント作成のすすめ

多くのエンジニアやプロダクトマネージャーが、ドキュメントを書く必要があると感じつつも、なかなか取りかかれないことが多いのではないでしょうか? 今回は、私がどのようにドキュメントを作成しているか、そのサンプルを紹介しつつ、未知の技術を導入する際のポイントについても触れていきます。 ドキュメントを書く目的ドキュメントを書く目的はいくつか考えられます。例えば: 認識齟齬を減らす:チームメンバー間での共通理解を確立するため。 将来の誰かに向けて残す:後からプロジェクトに参加する

Design Docを書くことで、保守性と開発スピードを上げる

今回は、Design Documentを書くことで開発スピードを上げ、コードの保守性を向上させる方法について取り上げます。 記事に対する疑問や感想、意見などXでのポストや記事へのコメントをいただければ、今後のコンテンツの改善に役立てさせていただきます、よろしくおねがいします。 Design Document日本だと2007年の Google Developer Day Tokyo での鵜飼氏のプレゼン等によって、広まっていった記憶があります。 「Googleのソフトウェア

【シングルタスクのススメ】開発とQAプロセス改善の実例

マルチタスクの問題とは?今回は、マルチタスクの問題についてお話しします。 例えば、2週間で終わる作業が2つあるとします。一つずつ順番に行うと4週間で終わりますが、これを2つ同時に進めると6週間かかることがあります。これ、実体験で感じた方も多いのではないでしょうか。 ワシントン大学のメディナ氏の研究によると、マルチタスクによって「仕事が完了するまでの時間が50%増加し、ミスの発生も50%増加する」とのことです。 2つのムダ 機会損失 最初のタスクが2週間で終われば、すぐ

変更のリードタイム改善事例

前回までの振り返りhi-outcomeの中森です。 前回の記事で、エンジニアチームの生産性を測る指標として「リードタイム」「サイクルタイム」ではなく「変更のリードタイム」を計測すべきという話をしてきました。 今回は、私自身が行った「変更のリードタイム」改善活動について紹介したいと思います。 私の取り組みさて、リードタイムは作業時間と待ち時間に分割して考えることができます。 ここで、待ち時間に注目してみて「開発における待ち時間の代表であるレビューを究極に短くする方法は何だろ

「変更のリードタイム」採用のススメ

はじめにHi-Outcomeの中森です。 エンジニアリングプロセスにおいて、質とスピードはトレードオフではなく、両立可能な指標であることがわかっています。 t_wadaさんの講演『質とスピード』や、その講演の元となったState of DevOpsレポートでは、この点が詳しく説明されています。 エンジニアチームの生産性が企業の業績の予測要因になることが統計的な事実として示されている以上、エンジニアチームの生産性を可視化することは非常に重要なことです。 4keysの指標の

リードタイムを短くせよ。具体と理論と統計-その2

はじめにhi-outcomeの中森です。 前回の記事で、封筒の実験、ジャグリングの実験、キングマンの公式、統計的側面を通してバッチサイズを小さくし、稼働率を抑えることがリードタイムの短縮につながり、組織全体のパフォーマンス(収益性・市場占有率・生産性)の予測要因になることを説明してきました。 今回は、歴史の視点からリードタイムの短縮がリーンの本質であることについてアジャイル・リーン生産方式・DevOpsの文脈からお話をしていきたいと思います。 余談:なぜ歴史の話もするの?

リードタイムを短くせよ。具体例と理論と統計から理解する-その1

はじめにhi-outcomeの中森です。 本連載では、実験・理論・統計・歴史の観点からソフトウェア開発の文脈でリードタイムを短くすることが決定的に重要であることを説明したいと思います。 我々ソフトウェア開発者が改善活動を行う際にはいくつもの方法があります。 しかし、その効果が個人の体験談に基づく再現性の低いものであったり、自身の置かれた文脈によって全く実行不能であったりするためにうまくカイゼン活動が推進できないことも多いと思います。 そこで、今回と次回に分けてリードタイムを

事業を伸ばすリーンとスクラム

本記事の目的スクラムはリーン開発を実践していくために、有用なフレームワークの一つです。 リーンの本質を理解した上で、スクラムを基本を再理解し、スクラムというフレームワークの効用を向上できると考えています。 チームで効率的に開発することはスキルです。近道や銀の弾丸はなく、先人の知恵や理論を理解し、実践を通して、習得していく必要があります。 現段階でイメージできない部分もああると思います。しかし、プログラミングを始めたばかりの頃、今のようにスムーズにコードを書ける日が来るとは想

リーン開発で開発効率を飛躍的に向上させる

はじめに私達は、製造業で生まれたリーンの哲学と現代的なエンジニアリングの知見を、日本のソフトウェア産業に根付かせ、日本のソフトウェア産業の生産性に高めるために貢献したいと考えています。 そして、エンジニアリングをより加速させるシンプルなアイデアと実践方法をお伝えします。 現状以下のような状況の企業をたくさん見てきました。 多くのまたは大きな機能要望が開発チームに投げられ、開発チームが疲弊している。 エンジニアが大規模の機能開発を行い、QA等のテストで不具合が見つかり手