NTT Com オンボーディングハンドブック
オンボーディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したオンボーディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/onboarding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『オンボーディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したリモートワークハンドブックや、チームビルディングのプラクティスをまとめたチームビルディングハンドブックも参照ください。 読み始める #こちらから本編に進めます。 はじめに
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか？ スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ その コメント GitLab Handbookで面白かったもの@コミュニケーション編 GitLabのリモート統括責任者が語る 日本企業が「まずやるべきこと」 を読んだ。主題はGitLab社の https://about.gitlab.com/handbook/ である。 2022.02追記 GitLabで学んだ最高の働き方 Developers Summit 2022-02-18 2022.01追記 リモートワークのいま学びたい、GitLab Handbook非同期コミュニケーションのススメ - Qiita Handbook要点 「GitLab社ではリモートワークの中でも生産性高く働
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。 IT技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載「プロジェクト成功確率向上の近道とは？」では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。 連載1回の「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」、第2回の「サンプル例に見る
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
「Design doc とは何か」・「何を書けばよいのか」を説明するスライドです。 関連するプレゼンテーション「読みやすいコードの書き方」: https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571 © 2023 Munetoshi Ishikawa, supported by LINE corporation
鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」の動画を公開しました：ITpro Challenge! ブログ：ITpro
お待たせいたしました。第2弾，Debian Project／Google ソフトウェアエンジニア鵜飼文敏さんの講演動画です。
Software Engineer in Google 鵜飼 文敏
ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門：プロジェクト成功確率向上の近道とは？（1）（1/2 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。 連載目次 はじめに 本連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基本的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。 筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ
overlasting.net
overlasting.net 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
移転しました http://please-sleep.cou929.nu/20091116.html
私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。 会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。 デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。 追記: その2も書きました。最後の方に記事へのリンクを貼っています。 追追記: 思った以上に反響あり、この記事のおかげでこれまで非常に多くの スタートアップの方々とお話しさせていただく機会をいただき
これは何? React(Next.js)アプリケーションのテンプレートのための Design Doc React(Next.js)アプリケーションのテンプレートとして実装したリポジトリ shimpeiws/react-boilerplate-2022 の設計についてのDesign Docです SSR/ISRはせずnext exportしてStatic Fileを出力する構成です API Routesを使っていますが、API接続コードをローカルで動作させるためのもので本番動作させるためのものではありません Design Doc 本ドキュメントは実装したリポジトリの構成、ライブラリの選定理由など設計についての背景を示すためのドキュメントという位置づけです 「デザインドックで学ぶデザインドック」(https://www.flywheel.jp/topics/design-doc-of-desig
http://steps.dodgson.org/?date=20090705より。 Google社員によるWebKitのWeb Socketに関するdesign docがchromeの開発ML上で公開されている事を知った。 WebKit Web Socket design doc http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh 鵜飼さんなど日本人Googlerによるdesign docらしい。 Googleの講演などでdesign docをよく書く文化があると言う事は知っていたが、実際に見るのははじめて。このdocの場合だいたい以下のような構成になっている。 目的 Web Socketでブラウザ＝サーバー間双方向通信のための新しいAPIを定義するよー 背景 Ajaxとかでブラウザ＝サーバーの双方向通信をよくやっているけど、httpを無理
デザインドックで学ぶデザインドック | フライウィール
エンジニアの太田です。 皆さん、デザインドックはご存知でしょうか？いわゆる設計書ですが、エンジニアによって書かれ、書いた本人またはチームによって実装される点と、技術的な詳細を明確にし技術的な議論をすることにフォーカスがある点が特徴です。他人に開発を依頼するための設計書や、既存のシステムを解説するための文章とは性質が異なります。 デザインドックを書くことの利点としては以下のような点があります。 開発を始める前に全体のシステムを考察する機会を得る文章化することで、曖昧な部分が明確になる早い段階でチームメイトや専門家、関係者からフィードバックを得る機会を得るシステムの設計について明確な承認を得られる新しいメンバーがシステムの概略を理解する手助けになる弊社でもすでに多くのデザインドックを利用しており、エンジニア間での議論の活発化を担っています。 具体的にどのような内容を書けばいいのでしょうか？今回
Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.
こんにちは! ソウゾウのSoftware Engineerの@ogataka50です。連載：メルカリShops 開発の裏側 Vol.2の9日目を担当させていただきます。 9日目はメルカリShopsを開発する中でのDesign Docsの運用について紹介させて頂きます。 Design Docsとは Design DocsとはGoogleなどで取り入れられているシステム設計ドキュメント手法です。開発をする前にプロジェクトの背景や目的、設計、検討した代案などをdocument化します。そしてそれを持って関係者との共有、議論を行うことによって事前に全体を考察し、精度を高め開発後の手戻りを減らすなどが主な目的になります。 例として、GoogleでのDesign Docsについては下記にまとめられています。 Design Docs at Google メルカリShopsでのDesign Docsのte
GoogleのDesign Docについて調べました．Design Docとは，Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメントです． 一般的にDesign Documentというと，設計仕様書のことをさすようです．設計仕様書はソフトウエアのシステム的な設計がどのように行われているかを記したドキュメントです．一方でGoogleのDesign Docは，あるソフトウエアについて，何を・なぜ・どのように作るかを記したもののようです．両者ともあつかっている対象や，対象としている読者が少しずつ異なっています．このエントリーではGoogleのDesign Docについて扱います． Design Docの内容 Design Docについては，Googleの鵜飼文敏さんによる以下のプレゼンテーションで触れられています． 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」
Companies Using RFCs or Design Docs and Examples of These
RFCs - requests for comment - or Design Docs are a common tool that engineering teams use to build software faster, by clarifying assumptions and circulating plans earlier. There are some similarities between writing automated tests for your code, and writing RFCs before you start working on a non-trivial project: Software engineers who write tests for their code - and ask for code reviews on it -
連載中くらいはと思い webkit-dev を購読したけれど, 案の定ぜんぜん読んでいない. 今日は一念発起して 300 通くらい目を通した(= "j" を連打した). だいたい二ヶ月ぶん. 外野にも興味深い話題がいくつかあったのでぱらぱら書いてみたい. (過労気味といいつつ野次馬は別腹でよろしくおねがいします.) まず JavaScript 関係から. ARM 用 JIT をめぐるいざこざ 4 月頃, ハンガリー Szeged 大学の面々が SquirrelFish (Nitro?) を ARM に移植中だと アナウンスした. trunk には入っておらず, 彼らの git 上で開発が続いている. その後の 6 月, Apple は独自に実装した ARM ポートを ひっそりとチェックインした. それを発見した件の大学チームのメンバが 全然オープンじゃなくてガッカリだ と不満を表明. Ap
このエントリは、パッケージソフトウェア開発 Advent Calendar 2014 の 7 日目の記事です。 はじめに 普段、仕事でパッケージソフトウェアを作っています。 具体的には、DataSpider Servista という EAI（Enterprise Application Integration）で、ざっくり数十万～数百万円くらいする、企業向けのソフトウェアです。 パッケージソフトウェアの開発 パッケージソフトウェアの開発というのは、既存ユーザや（特に企業向けソフトの場合）見込みユーザの要望を適宜取り入れながら進めます。 多くのユーザに使ってもらうパッケージなので、単に特定のユーザの要望を満たすだけではだめで、製品の戦略や設計思想、また互換性にも配慮しつつ、仕様を考える必要があります。 使いやすさ、UI/UX のよさというものも忘れるわけにはいきません。*1 Design D
Design docs are a fundamental tool for communicating software design decisions–but communicating things is hard and so is writing design docs. Time for an overly detailed exploration into what would happen if one wrote a design doc for design docs. May 19th, 2015 Status: Draft Authors: Malte Ubl Note: While this post continues to be independently useful, I have published a more approachable write-
by Angela Zhang How to write a good software design docPhoto by Estée Janssens on UnsplashAs a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project. This article is my attempt at describing what makes a design documen
Scalable Go Scheduler Design Doc Dmitry Vyukov dvyukov@google.com May 2, 2012 The document assumes some prior knowledge of the Go language and current goroutine scheduler implementation. Problems with current scheduler Current goroutine scheduler limits scalability of concurrent programs written...
Hacker Software Engineering ITPro Challenge! 2007/09/07 ? Hacker 1. 2. ( ) 3. Hack value 4. 5. (ex. A UNIX hacker) ( ) Hacker ethic 1. hacker ( ) 1. • 2. • 3. • 4. • 5. • 6. • ? ? ? ? • ? ? • ? ? • ? Design document • • API • • • Code reading, code review • Code Reading Code Review / API ? ? ? • •
Painless Functional Specifications – Part 1: Why Bother?
I’m Joel Spolsky, a software developer in New York City. More about me. Read the archives in dead-tree format! Many of these articles have been collected into four books, available at your favorite bookstore. It’s an excellent way to read the site in the bath, or throw it at your boss. Ready to level up? Stack Overflow Jobs is the job site that puts the needs of developers first. Whether you want
Go 1.3+ Compiler Overhaul
Go 1.3+ Compiler Overhaul 共有ログインお使いのブラウザのバージョンはサポートが終了しました。 サポートされているブラウザにアップグレードしてください。閉じる ファイル編集表示ツールヘルプユーザー補助機能デバッグ
Industrial Empathy
This is Malte Ubl's personal blog. I write very occasionally about large-scale software design and web development. New on the web Software design and architectureBuilding towards a new default rendering model for web applications (vercel.com) 09 Nov 2023Why all software migrations should be incremental (vercel.com) 30 Aug 2023Frontend & Backend Defined 08 Aug 2023Version Skew 21 Jun 2023Principle
Game Name Here Game Design Document Copyright notice / author information / boring legal stuff nobody likes PLEASE NOTE: You can copy this into your Drive by going to “File” >> “Make a copy…” You do not need to request permission to edit this document if you make a private copy. Index�Inde...
Roger Dingledine, The Free Haven Project, arma@freehaven.net Nick Mathewson, The Free Haven Project, nickm@freehaven.net Paul Syverson, Naval Research Lab, syverson@itd.nrl.navy.mil Abstract We present Tor, a circuit-based low-latency anonymous communication service. This second-generation Onion Routing system addresses limitations in the original design by adding perfect forward secrecy, congesti
This document describes the adversary model, design requirements, and implementation of the Tor Browser. It is current as of Tor Browser 7.0.11. This document is also meant to serve as a set of design requirements and to describe a reference implementation of a Private Browsing Mode that defends against active network adversaries, in addition to the passive forensic local adversary currently addre
Security/Features/Application Reputation Design Doc - MozillaWiki
Goal Document application reputation implementation decisions so that other people than the author can debug it. Background Google has offered an application reputation feature to detect malicious downloads as part of Google Safe Browsing since 2012 [1]. Although this part of the Safe Browsing API is not documented, they have offered it to us for use in Firefox. Malicious download detection is sep
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「書く」のは特別な道具 - naoyaのはてなダイアリー
Design Docs at Google
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
リモートワークのいま学びたい、GitLab Handbookと徹底した文書化への狂気 - Qiita
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門
YouTube - Google Developer Day Tokyo - 鵜飼 文敏
ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門
Google の Design Doc について - フリーフォーム フリークアウト
プロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc｜kosuke mori
Design Doc for react-boilerplate-2022
Googleのdesign docを眺めてみる - kenmazの日記
WebKit Web Socket design doc Authors: ukai, yuzo, tyoshino Status: Draft (as of Sept 2, 2009)
Design Docs の逡巡- Message Passing
メルカリShopsでのDesign Docs運用について | メルカリエンジニアリング
Google の Design Doc について
webkit-dev 近況 - Backnumbers: Steps to Phantasien
パッケージソフトウェアの新機能開発で Design Doc を書いてみた - この国では犬が
Design docs - A design doc
How to write a good software design doc
Scalable Go Scheduler Design Doc
HackersSoftwareEngineering.ppt
Game Design Document Template - Google ドキュメント
Tor: The Second-Generation Onion Router
The Design and Implementation of the Tor Browser [DRAFT]