ピーナッツ @1zA5ijpgBABKIy2 前職で、どうやっても設計解がないと思われた製品にエースエンジニアが投入され、翌日にあっさり大枠をまとめて来たことがあった。 「え、何やったんすか?」って聞いたら「めちゃくちゃ散歩したんだよ」って言われて言葉を失った。生産性とは余白なのだわ。 2022-08-05 17:35:16
「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設計、時刻の扱い、データローカリティのようなシステム寄りの話題、またライブラリの選択、分散システムの一貫性と原子性、バージョニングのようなより抽象度の高い内容まで、さまざまなシチュエーションにおけるトレードオフの実態と、その失敗例をとり上げます。 本書は日々のプログラミングにおける解決策のヒントを得るだけでなく、より幅広い設計上の知見を広める上でも役に立つでしょう。 正誤表 ここで紹介する正誤表には、書籍発行
プログラミングとはコードを書くことだけではありません。どういった構造にするのか、データはどう扱うのか、どのライブラリを使うのか、いくつもの設計を踏まえてコードを書くのです。設計を表現したものがソースコードです。 設計の良し悪しは品質に影響します。では、良い設計を作るスキルは一体どうやって身につけることができるのでしょうか。プログラミング言語の文法は知識なので、独学でも学ぶことができますが、設計に関してはそうはいきません。 本稿では、プログラミングにおける設計力を高めるためにはどうすれば良いのかを考察します。ここで言う設計は、画面や仕様ではなく、ソフトウェア内部の設計ですが、抽象化するとクリエイティブな仕事全般に通じるかもしれません。 本稿の内容は「良い設計」について論じたものではなく、どうすれば身につくのかを考えたものになります。また、私たちソニックガーデンで行っている、良いコードを書ける
概要 Design Documentと聞くと何を想像しますか? 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの?」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは? Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。(まじで意味不明) いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおk。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。(そのうち消したい) システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
色々な原則や方法論はあれど、つまるところいかに変更容易性を確保するかと言う話に帰結するのでは。極論すれは、正しく動いていて変更する必要が無ければどのような作りになっていても構わない。一方、Web アプリケーションを稼働し続ける上で全く変更しなくて良いということもない。— Masashi Shinbara (@shin1x1) 2021年5月30日 ソフトウェア設計、開発には多くの原則や方法論がある。例えば、DRY 原則や SOLID 原則、デザインパターンにレイヤードアーキテクチャ、クリーンアーキテクチャなどある。さらに DDD にも多くの原則や方法論が含まれている。これらを変更容易性を高めるための手段として原則や方法論を捉えるというのが本エントリの論旨である。 原則や方法論の捉え方 変更容易性 本質的な変更と副次的な変更 外部変更容易性と内部変更容易性 原則を適用する指針 さいごに 原則
はじめに 2020年7月に契約し、夢のマイホームの設計が始まりました。 筆者は学生時代、『ユビキタス社会』に強く憧れておりました。 社会人となり数年、気が付いたら様々なIoT家電がインターネットへ接続し利用者に恩恵をもたらす便利な世の中になりました。 筆者もIoT家電をいくつか購入し生活に取り入れ便利な生活を送っております。 しかし・・・ ある日、これは生活が豊かになるに違いないと自信をもってスマートロックを導入したところ、インターネット経由での鍵の開閉ができず、妻には「エラーばかりでもたつくから普通の鍵のほうが早くて間違いない。これ意味あるの?」と文句を言われてしまいました。今までの人生を否定された気持ちで、必死に原因を調査したところ電波の混信のせいでした。 個人利用だとしても快適にIoT製品を利用するためには、安定した無線ネットワーク環境を用意する必要があるとそのとき筆者は強く考えまし
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel(最近資金調達しました!記事はこちら)で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト(リソース・運用) ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論(アーキ
2冊目も公開中なのでみてください! https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。(※社内勉強会用資料の公開版です。) TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。(かくいう私もNext.jsからTypeScriptデビューしたわけですが) TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか? 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
DB設計の管理や作成に疲弊してません?こんにちは。ukmshiです。今日はDB設計の共有と管理に便利なツール、dbdocsについてお話しします。dbdocsを使えば、設計の可視化や共有がめちゃくちゃ簡単になるんです。今回は、その魅力と利点、そして実際の使い方について詳しく説明します。 dbdocsとは? dbdocsは、コードベース(DBML)でDB設計を管理し、URLで共有することが可能なツールです。データベースのテーブル構造や関係性を可視化し、それを他のチームメンバーやステークホルダーと手軽に共有することができます。 DBMLについてはこちらを参考に dbdocsの利点 dbdocsの利点について詳しく見ていきましょう。 無料 まず最初に、dbdocsは基本無料です。コストを気にせずに利用できるので、チームの誰もがアクセス可能です。 コードベースで管理 dbdocsはコードベースでDB
DDDではよく「モデリングが重要だ!」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
こんにちは、あるいはこんばんは。村山です。皆さまGoogleアナリティクス4(以下、GA4)との戯れには慣れてきましたでしょうか。GA4の使い方は「完全に理解した」という方もいれば「まだまだこれから計測実装していくから触っていない」みたいな方もいらっしゃるのではないかと思います。 今回は、後者である「これからGA4を計測実装していく」方にむけて、どのようにGA4の計測実装を推進したら良いのか書いていこうと思います。 どのようなイベントを計測するべきか? データに関わる方が1名と少ない場合 データに関わる方が2名以上の場合 データ計測の設計書となるドキュメントが必要だ GA4はさまざまなイベント計測方法がある GA4管理画面内の「イベントの変更」 GA4管理画面内の「イベントの作成」 GA4管理画面内の「オーディエンストリガーイベント」 GTM内からイベントタグの発火 GA4の計測設計にはN
「難しい本ばっかり読んで眠くなってませんか?いい本ありますよ!」 ご機嫌いかがでしょうか、豊崎です。 育成チームのリーダーを行なっている都合から、エントリー向けのインフラエンジニアの書籍を読むことが多くなっています。本日は、その中で読んだ、「インフラ設計のセオリー」という本についてご紹介させていただきます。 基本的にはIPAの非機能要求グレードに沿って特に重要な項目を説明していく内容になっています。 インフラエンジニアを始めるときに、教科書として読んでおけば 成長曲線が変わったんじゃないかな? と感じました。それくらい基礎的な知識の習得とイメージ付けには最適だと思います。 具体的には、非常に有益なドキュメントではあるものの、圧倒的な文章量で睡魔を送り込んでくる非機能要求グレードの活用について図や絵を多く交えて非常に理解しやすい文章で説明をしてくれます。 内容はしっかりしているのに、とても読
iPhone 12シリーズが発表され、iPhone 12/12 Proの予約も始まりましたね。23日配送予定で予約できたので、私も楽しみです。ユーザーとしてはその新しいデザインや機能にワクワクしますが、デザイナー・デベロッパーとしては悩みのタネが増えるかもしれません。 ビューポートのサイズの種類が増え、多くの解像度、アスペクト比、断片化が進むデバイスの複雑さがUIの設計にどのように影響するのかを紹介します。 iPhone 12 vs Designers by Michal Malewicz 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 iPhone 12のリリース だけど、このメタルとガラスの中には象がいる 2020年の現状 どのようにデザインすればよいか? 重要な要素は折り目の上に 終わりに iPhone 12のリリース 1
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 (Vモデルが必須と明言しているわけではなく、極端な例ですが)例え
どうもさいちゃんです。 AWSには利用者が仮想環境を構築していくのに役立つベストプラクティスと呼ばれるものがあります。 これからAWSでガンガン仮想環境を構築していくにあたって設計のベストプラクティスを復習してみようということで、今回はAWS公式から出ている「AWS 設計のベストプラクティスで最低限知っておくべき 10(+1) のこと」という動画を視聴したのでご紹介をしていきます。 登録さえすれば、無料で動画の視聴と資料のダウンロードができます。 こちらから受講が可能です。 はじめに このセッションはAWSにおける設計おベストプラクティスの理解を深める目的で、 クラウド導入を検討している方 オンプレミスからクラウドへの移行を検討している方 クラウドを使い始めたがベストプラクティスを適用できているか悩んでいる方 向けに細かくわかりやすくベストプラクティスについてを説明しているものになります。
ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 本発表では、私が普段どのように「状態」について考えているか、言語や環境を問わずできるだけ普遍的に使える形での言語化を試みます。本発表を通じて、「状態」をなんとなくではなく合理的に設計するためのヒントを提供します。 GoogleスライドのURL: https://docs.google.com/presentation/d/1PNzz69UV05HlKPuWGlooemnPslLbLKsyLwl3R4U_XqE/edit
増田の指摘は的を得ていて、内燃機関から電気に変わって何が変わるのと言うのは仰る通りだと思われる。 それは何故かと言うと、現在のEVは、内燃機関の基本設計を電動化しだけだから。 PHEVなどはまだエンジン積んでるから仕方が無いにしても、EVにするんだったら、もうちょっとEVだからできる事を追求するべきではないかと思う。 各社色々なコンセプトカーが出ているが、実際にはなかなか普及しない。 インホイールモータこれがEVで望まれるイノベーションの最たるもの。今までの内燃機関だと、中央に大きなエンジンがあり、それをシャフトなどを通じて物理的に力を伝え、2輪もしくは4輪を駆動するという仕組みだった。 その為の機構が存在する事から、設計に制限がある。 これを、車輪の中、あるいは車輪のすぐ近くにモータを置いて、直接タイヤを回してやろうという考え方がある。これを「インホイールモータ」などと言う。 これにする
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか? 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
こんにちは、エムスリー エンジニアリンググループ の鳥山 (@to_lz1)です。 ソフトウェアエンジニアとして 製薬企業向けプラットフォームチーム / 電子カルテチーム を兼任しています。 ソフトウェアエンジニアという肩書きではありますが、私は製薬企業向けプラットフォームチームで長らくデータ基盤の整備・改善といったいわゆる "データエンジニア" が行う業務にも取り組んできました。 本日はその設計時に考えていること / 考えてきたことをデータ基盤の設計パターンという形でご紹介しようかと思います。多くの企業で必要性が認識されるようになって久しい "データ基盤" ですが、まだまだ確立された知見の少ない領域かと思います。少しでもデータエンジニアリングを行う方の業務の参考になれば幸いです。 データ基盤の全体像 収集部分の構成 RDBデータ ログデータ 活用部分の構成 データマートの実例 「データ基
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント(ルートユーザー)の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
※追記あり。最後の追記は 2021/04/25 21:40頃※ タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。 この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく(易しく、ではない)ご指摘願いたい。 ※この記事では Web Application を前提とした話になっている。 DDDとは?https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 DDD、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ
こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ
私は開発寄りのエンジニアであり、テストやQA専門の方と同じチームで頑張る機会が少なかったのですが、「なるほど、こうやって考えて、こういうツールを使っているのか」と非常に勉強になりました。 こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉(@bun76235104)です。 最近ではアジャイル開発やスクラム開発が多く採用され、ビジネスのスピードに負けないようにプロダクト開発・リリースのスピードが求められれている中で、「いかに効率よく、かつ効果的なテストをしていけるか」というのはテスト担当だけでなく、開発メンバー全員で考える必要があると思います。 とはいえ、実際のチームには「専任のQAエンジニアやテストアナリストはいない」ということは非常に多いと思います。 基本的なテスト技法は本で学んできたけど、どういう時にどんな技法でテストを設計すればよいの? 本職のテスト
作ったもののイメージ ホテルの客室検索APIとは、チェックイン日やその他の条件を入力として受け取り、マッチするホテルの客室を返すものです。以下の画像はExpediaのものですが、赤枠で囲っている部分(他にもたくさんある)が入力になります。2022年4月頃に無事リリースされました。 この検索APIを構築を任された際に、何を考えて設計していったのかを以下に示していきます。 顧客からの要望 顧客の会社は当時エンジニアがおらず(やりとりしている社長は元エンジニアだが)、これまでも私と仕事をしたことがあったので依頼が来ました。顧客と密にコミュニケーションを取りわかったのは、以下のような要望でした。 このAPIは自社サービスとして第3者(要契約)に使ってもらえるようにしたい 完全に一般公開ではなくちゃんと契約を結ばないと利用できないようなもの 検索条件を柔軟に、かつ使いやすい感じで指定できるようにした
はじめに システム開発において詳細設計という工程があります。 プログラマーはこの詳細設計を確認しながら開発を行うことになります。そのため詳細設計ではシステムの構造や仕様、動作などを細かく定義することが必要になります。 詳細設計を行うことでシステム開発の方向性が明確になり、コーディングやテストをスムーズに行うことができます。 詳細設計の成果物としてはクラス図やシーケンス図、画面設計書やデータベース設計書などがあり、システムの動きや機能を具体的に表現するものです。 今回は詳細設計を作成する機会があったので、詳細設計の書き方についてまとめたいと思います。 詳細設計の目的やメリット 詳細設計の目的は、システム開発の品質や効率を向上させることです。詳細設計では、システムの仕様や動作を細かく定義することで、以下のようなメリットがあります。 開発工程でのバグや遅延を減らすことができる テスト工程での不具
【追記】たくさんのブクマをありがとうございます。1つ前のエントリにある、The Syria Campaignの国連加盟国宛て請願文と署名も、よろしくお願いします。【追記ここまで】 ネットでは無根拠な憶測や事実に照らして正しくない誤情報がバズりすぎるということは今やただの常識、「ネットってそんなもんでしょ」と言って済ませればいいだけのことかもしれないが、それにしたって日本語圏はひどい、という事例に今朝接したので、そのことについて簡単に書いておくことにする。ついでに見つけた英語圏の事例についても。 111年前の1912年に氷山に衝突して大海の藻屑と消えた豪華客船タイタニック号の残骸を見物するために、海底3800メートルにまで行く潜水艇 (submersible*1, 略してsub*2) が音信不通になったことが伝えられたのは、6月18日(月)だった(北米東海岸の時間)。以降の数日間、BBC N
はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG(ツナグ)の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
この機械ボタン押し続けな動かんな。せや!こうやったら押しっぱなしにできるで。生活の知恵や→こうして重大事故が起きる - Togetter フォロー・ブクマ外からクソリプ失礼します。 フールプルーフ機構を回避した結果、重大な事故が起き、更にはその回避方法によってそれが悪化するというシチュエーションについて話す場であるという前提のもとに、フールプルーフ機構の設計自体に問題がないかを設計者は考えるべきではないかという問題定義をさせて頂きます。 まず前提として、フールプルーフ・フェイルセーフを搭載しようとする判断自体は極めて正しいと思っております。 使用者に対して「完全に説明書を読み込み常に無限大の集中力を発揮すること」を求める設計は双方完全合意の極めて特別な場合以外は推奨されない設計であり、もし作る側が使用者に対してこのようなことを何の相談もなしに安易に求めるのならばそれはモノづくりとしては不誠
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く