【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
なぜ僕が「SPAはコストが高い」と考えているのか
どうもみなさんこんばんは ちょっと前に「個人開発者やスタートアップの初期からSPAで開発するのはコスト高いっすよね」みたいな事を書いたらフロントエンドエンジニアの皆様からバチバチに叩かれた僕です 彼らには彼らの考えがあるのでそれはどうでもいいのですが、どういう理由があってその発言をしたのか～と言う部分が気になっている方もいたようなので説明しておこうと思います ちなみに今でも全く意見は変わっておらず、この発言に同意できるかできないかは単純に視点の違い、規模の違い、スキルの違いだと思ってます 追記: もちろんSPAじゃないと実現できないようなサービスを作りたい場合はSPA一択ですし（インタラクティブにHPつくるサービスとか。でも世の中の95%くらいのサービスはそうじゃないと思います）、サイトの利用はログインした人にだけ提供するような業務系ツールなどはまた話が別です 前提の話 こういう記事ではコ
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（後編）。JaSST'22 Tokyo基調講演
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（後編）。JaSST'22 Tokyo基調講演 Jonathan Rasmusson（ジョナサン・ラスムッソン）氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」（オーム社,2011）や「初めての自動テスト」（オライリー,2021）、「ユニコーン企業のひみつ」（オライリー,2017）の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」（JaSST'22 Tokyo）の基調講演に登壇しました。
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
開発速度が速い #とは（LayerX社内資料）
Cloud Festa 2021 Winter 「デザイナー、データサイエンティスト、 クラウドエンジニア、で実現する共創の世界」 Tsuyoshi Hirayama
市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
質とスピード（2020春版） / Quality and Speed 2020 Spring Edition
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。｜じゅ ごん｜note
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 [Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」 と思っていたりします。こんな話、
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
AWSを学ぶために最初に構築するアーキテクチャパターン５選 - log4ketancho
先日書いた AWS の勉強方法をまとめた記事（AWSを学ぶ上でやってよかった勉強法５選 - log4ketancho）で、「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書きました。その中で、 今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで…… や 「２）簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。 というような利用料金が気になってしまう、、というコメントを幾つかいただきました。 この気持ちとても分かります！業務で使う分にはサーバー何台立てようが気になりませんが（は言い過ぎですがｗ）、個人でサービスを運営する場合はそうはい
フロントエンドエンジニアに求められるもの多すぎ問題 - フロントエンドの地獄
背景 postd.cc という記事がちょっと前にありました。 github.com Roadmap to becoming a web developer in 2018って最近のWeb技術のまとめみたいなもんもよく引き合いに出されます。 このまとめの中にフロントエンドのものありますが、これはフロントエンド技術自体のロードマップです。 これらの技術すべてに精通していればいいのかと言われるとそんな必要は全く無くて。 でも現場によって実際 フロントエンドエンジニアに求められているものはそれ以外にもたくさんあるんですよね。 会社によってマジでJavascriptプログラミングしかやらない人も、マークアップする人、デザインを作ってそれをCSSに落とす人、本当に一口にフロントエンドエンジニアと言っても幅広すぎ。 担当範囲が広すぎるフロントエンドエンジニアに関していろんな会社が募集してると思うんですが
Pinterestをスケールさせる中で学んだこと - ワザノバ | wazanova
https://www.youtube.com/watch?v=jQNCuD_hxdQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 PinterestのMarty Weinerによる goto; conference 2014の講演。 「webサイトどうやってつくるの？」という創業期から、現在に至るまで、段階的にテクノロジースタックがどう進化したか。 現在のPinterestのシステムアーキテクチャの全貌。 個別のテクノロジーの選択理由。 などを語った45分のビデオですが、goto; conferenceのサイトからスライドのPDFをダウンロード（初日の10:20のコマです。）できるので、そちらを見ていただいてもわかりやすいかと。 「サイトが落ちてしまうのである意味自然に学ぶことができてしまった。
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
[axure]コーディングしないで動きのあるプロトタイプを簡単に作成（デザイナー向け） | DevelopersIO
プロトタイプ作成ツールはいろいろありますが、実際にプロジェクトで使ってみてそれなりに使えるものがあったので紹介します。 axure axure 英語版はAxure社のサイトでダウンロードできます。 このツール自体はネイティブアプリです。 現在のバージョンは7.0です。 mac対応の日本語版はありません。 Windows対応の日本語版はNTT DATAが取り扱いされています。 英語版のほうが安いのでお勧めです。 英語については、この手のツールでよく出てくる単語程度しか出てこないので問題無いです。 日本だと流通してないように感じますが、英語圏だと比較的に流通しているようです。 プロ版とスタンダート版があって、 値段はそれぞれ$589、$289となってます。 また、30日間のフリートライアル版があるので興味があればそちらを試すことも可です。 こんな時におすすめ プロトタイプを短期間でコードを書か
![[axure]コーディングしないで動きのあるプロトタイプを簡単に作成（デザイナー向け） | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6f1fde3cff7767965729d2d96d3e31da5b8a643d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_developers.io_1200x630.jpeg)
UIデザイナーの私がPhotoshopからSketchへ乗り換えた9つの理由 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
初めまして。アメリカからやってきたUIデザイナーのCorey（コーリー）です。 LIGの転職サービス「Poole」でUIデザインをしています。 PhotoshopやIllustratorをメインとして使うデザイナーは多くいると思いますが、私はPhotoshopをほとんど使いません。1年前にSketchへ乗り換えたからです。 現在、日本のデザイン界ではSketchはそれほど使われてないかもしれませんが、海外ではSketchが大ブームになっています。 今回は私が最強なPhotoshopからSketchへ乗り換えた理由をお伝えします。 Sketchへ乗り換えた理由（Why I Use Sketch） http://bohemiancoding.com/sketch/ 1. UI Design中心 Sketchは完全にWebとモバイルUIデザインの専用ツールなので、それ以外の余計な機能が入っていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
System of Record と System of Engagement
技術的負債と向き合う
開発組織マネジメントのコツ - Speaker Deck
