エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
プロダクト開発はなぜ直観に反するのか - 弁護士ドットコム株式会社 Creators’ blog
この記事は、弁護士ドットコム Advent Calendar 2023の25日目の記事です。 前日は tsuchiya さんの「ログや例外についてレビューや実装時に意識していること」でした。 はじめに: 人と成りては童子のことを棄てたり インターネットの海には、不幸な開発プロジェクトの話が溢れています。例えば「とにかく言われた通りに作ればいいんだ」「スケジュールにコミットしろ」「遅れは徹夜で取り戻せ」「障害を起こしたら減給だ」など*1。 プロダクト開発に携わる人であれば、こうしたやり方が無意味どころか逆効果であることはご存知でしょうか。では、なぜこうしたやり方が提唱されてしまうのでしょうか。 それは、旧来のビジネスの常識*2に照らせば、ある意味でまっとうなやり方だからです。問題は、プロダクト開発においてはビジネスの常識が通じないことにあります。 (加えて、にも関わらず旧来の常識が押し通され
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
仕事を読み解くキーワード：納得感のある音を鳴らす｜採用情報｜任天堂
ゲームの世界で鳴るさまざまな音は、サウンドデザイナーとサウンドプログラマーが協力して作り上げています。たとえば、オブジェクト同士が接触したときに材質や形状、衝撃の強さなどに応じて変化する音になるよう、サウンドデザイナーが音のデータを作成し、サウンドプログラマーがそのデータを鳴らします。『ゼルダの伝説 ティアーズ オブ ザ キングダム』では、私はサウンドプログラマーとして、サウンドデザイナーが作りだす多彩な音を、リアリティを感じられるように鳴らす役割を担いました。 このゲームには、さまざまな種類の材質や形をしたオブジェクトが登場します。プレイヤーはこれらを自由に動かせるだけでなく、複数のオブジェクトをくっつけることができるため、自由な発想で武器を作ることも、乗り物を作って動かすこともできます。そして高い自由度があることで、私たち開発者の想像を超える遊び方が生まれることもあります。 開発を進め
「コードがむずかしい」からの脱却
コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT https://findy.connpass.com/event/300912/
API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita
本記事は、Mohammad Faisal氏による「22 Best Practices to Take Your API Design Skills to the Next Level」（2021年4月15日公開）の和訳を、著者の許可を得て掲載しているものです。 REST API設計のための実践的アドバイス Photo by Andrea Piacquadio from Pexels はじめに すべてが分かりにくく、ひどいAPIに不満を感じたことはありませんか？私はそうです。 マイクロサービスの世界では、バックエンドAPIの一貫した設計が不可欠です。 今日は、知っておくべきベストプラクティスについて、簡潔に説明します。さあ始めましょう！ 用語 API設計は、リソース指向設計というものに従います。3つの重要な概念で構成されています。 リソース：データの一部（例：ユーザー） コレクション：リソー
今さら聞けないログの基本と設計指針 - Qiita
はじめに 皆さんのログに対する理解はどんなものでしょうか？仕組みから設計方法まで完璧に理解しているエンジニアもいれば、なんとなく使用しているエンジニアも多いことでしょう。 ログとは、システムに着いてエラーや障害の発生、利用者による操作や設定の変更、外部との通信などを時系列に記録したものです。ログに関する理解を深めることで、複雑なシステム開発や運用が可能となります。また、AWS、Azure、GCPなどのクラウドサービスを利用している場合はシステムの開発が可能になるだけでなく、経費削減に繋がる可能性も考えられます。 本記事では、ログの基本を押さえるためにその設計方法について解説します。少しでも自信がない方は、ご一読ください。 ログを出力する理由は？ ログの基本や、ログの設計について解説する前にそもそもログを出力する理由を押さえましょう。大きく4つの理由が考えられます。 ・問題が発生した時に調査
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
なぜDone is better than perfectなのか考えてみた #techtekt Advent Calendar 2021 - techtekt
はじめに この記事はtechtekt アドベントカレンダー2021、24日目の記事です。 こんにちは。 テクノロジー本部 エンジニアリング統括部 サービス開発部でエンジニアをしております、吉次（よしつぐ）と申します。 普段はサラリーズというサービスの開発・プロジェクトマネジメントをしています。 サラリーズは2021年5月に正式版をリリースし、日々機能追加や改善に取り組んでいます。 不確実性の高い新規サービスの開発をマネジメントする中で、 Done is better than perfect という言葉について考える機会があり、自分なりの整理をしてみたので記事にしてみました。 Done is better than perfectの意味 Meta社（前Facebook社）のマーク・ザッカーバーグ氏の言葉と言われています。 素直に翻訳すると「完璧にするよりもまず終わらせた方が良い」というよう
クックパッドマートの失敗したデータ設計 Before / After 大放出
https://cookpad.connpass.com/event/249346/ にて発表。
【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
ＡＩの設計・開発・運用をガイドラインでサポート
産総研マガジンは、企業、大学、研究機関などの皆さまと産総研をつなぎ、 時代を切り拓く先端情報を紹介するコミュニケーション・マガジンです。 2020年6月、産総研は、人工知能(AI)を設計・開発・運用するためのガイドラインを策定し、公開した。このガイドラインを活用すれば、従来のソフトウエアと比べて格段に難しい「AIの品質管理」を適切に実行できるというものだ。AIは、これまで人手で一からプログラミングしていた各種の機能を、大量のデータを用いた機械学習技術によって半ば自動的に作成することができる。その一方で、ＡＩが意図せぬ動作をしたり、時には暴走するといった懸念があった。今回のガイドラインでは、達成したい安全性、精度、公平性のそれぞれについてレベルが定められ、関係者が品質について合意形成できるようになる。この合意の実現に必要な、データや性能評価手法の条件を具体的に列挙しており、これらを満たすこと
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
情報系研究者のための研究ノート - Qiita
Abstract 計算機科学研究での記録のとり方 を書いてから半年ほど過ぎて、さらに知見がたまったので書き直します。情報系研究者が、紙ベース以外で研究ノートを取る場合に何をすれば良いか とにかく効率よく研究するにはどうするか をいくつかまとめました。改善案があればコメント希望、自分も研究効率をあげたいので教えてほしいですね。半年ぐらい経ったらたぶんまた書き直すと思います。 Introduction 本記事は、締め切りの明確に定まっている文章(上位国際学会論文、国際学会論文のrebuttal(反論)データ、学位論文)のための実験を円滑柔軟に行う上での効果的なノウハウを提案する。この内容は、筆者のいる研究室でのゼミ内容を幾分反映してはいるが、それだけにはとどまらない。内容はいくつかの段階に分けられる。 実装段階での工夫 実験デザイン段階の工夫 実験実行段階での工夫 Preliminaries
Unity開発で使える設計の話 ＋ Zenjectの紹介
Unity開発で使える設計の話 ＋ Zenjectの紹介 1. Unity開発で使える設計の話 ＋ Zenjectの紹介 2017/11/26 @toRisouP 2. 自己紹介 • 名前 とりすーぷ（@toRisouP） • Qiitaとかよく書いてる • 同人ゲーム作ってる 3. ハクレイフリーマーケット • 2017年10月にリリースした東方二次創作ゲーム • オンライン対戦対応のパーティゲーム 4. おしながき • 設計とは – 設計とは何か、設計の何がよいのか – モデリングとクラス設計 • 覚えておくべき基礎知識 – クラス図の読み方 – SOLID原則 – デザインパターン • Zenjectの紹介 – 依存性注入とは何か • まとめ 5. 設計とは何か 6. 設計とは何か • 何をどうやって作るのかを決定する作業 – そもそも何を作ろうとしているのか？ – 必要な機能はどう
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
目的と抽象化の関係性から分かる、システムの設計精度を高める考え方 / purpose abstraction design
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
system-design-primer/README-ja.md at master · donnemartin/system-design-primer
