ソフトウェアアーキテクトが知るべき 97 のこと
【01】システムの要件よりも履歴書の見栄えを優先させてはならない by ニティン・ボーワンカー 【02】本質的な複雑さは単純に、付随的な複雑さは取り除け by ニール・フォード 【03】最大の問題は、たぶん技術的なことではない by マーク・ラム 【04】まずコミュニケーション、そのための明快さとリーダーシップ by マーク・リチャーズ 【05】パフォーマンスの決め手はアーキテクチャー by ランディ・スタッフォード 【06】要求仕様の本当の意味を探れ by アイナー・ランドル 【07】立ち上がろう！ by ウディ・ダーハン 【08】すべてのものは、かならずエラーを起こす by マイケル・ナイガード 【09】それは交渉だということに気付け by マイケル・ナイガード 【10】定量化を求めよ by キース・ブレイウェスト 【11】500 行の仕様書より 1 行のコード by アリソン・ランダ
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ 2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。
ソフトウェアデザインにおける構造設計を実践！マネーフォワードさんとワークショップを開催しました｜Goodpatch Blog グッドパッチブログ
Goodpatchでは、UIの構造設計を重視したデザインプロセス「モデルベースUIデザイン」を推進しています。最初にコンセプト定義やユースケースを定義し、情報整理をして最終的に機能やビジュアルなどの具体的なところを詰めていく考えをとっていくプロセスです。 今回は、マネーフォワードさんと「デジタルプロダクトのUI設計のプロセスと考え方を学び、実践することでスキルのベースを身につけること」をテーマに、モデルベースUIデザインについて理解・実践するワークショップを開催しました。本記事では開催の背景から当日の様子をご紹介します。 参加いただいたマネーフォワードのUI/UXデザイナーさんによるnoteもぜひご覧ください！ マネーフォワードがGoodpatchさんとUIデザインワークショップを実施しました！ ご相談いただいた背景 「お金を前へ。人生をもっと前へ。」をミッションに掲げる株式会社マネーフォ
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
「最悪のソフトウェアはマネージメントの問題」、よいソフトウェアを作る方法を政府のソフト開発を行う技術者が語る
by Austin Distel 「ひどいソフトウェアが生まれる場合、問題は特定のエンジニアリングではく、マネージメントにあることが多い」と語る、Googleのプロダクトマネージャーを経てシンガポールの公安部門向け技術開発を行うLi Hongyiさんが、「よりよいソフトウェアはどうやって構築するのか？」をつづっています。 How to Build Good Software https://www.csc.gov.sg/articles/how-to-build-good-software Hongyiさんは、ひどいソフトウェア開発の問題点を一文で「プロジェクトオーナーが解決すべき問題を明確にすることなく解決策としてのソフトウェア構築をスタートさせ、関係者からの長い要望リストを、フルスクラッチで開発を行おうとする外部の開発チームに委託すること」とまとめています。 一方で優れたソフトウェア開
ソフトウェア開発プロジェクトにはどうして遅延が生じてしまうのか
ソフトウェアの開発プロジェクトでは当初定められていた納期に間に合わず、想定外のコストがかかったり訴訟に発展したりするのがつきものです。どうしてソフトウェア開発プロジェクトで遅延が起きるのかを、ソフトウェア開発プロセスの第一人者であり、IEEEのフェローでもあるトム・デマルコさんが解説しています。 All Late Projects Are the Same (pdf)http://www.systemsguild.com/pdfs/DeMarcoNov2011.pdf ベル研究所に勤めていたデマルコさんは1960年代の初め、ハードウェアエンジニアからソフトウェアエンジニアに職を切り替えました。そして「ソフトウェアがいかに難しいか」を思い知らされたとのこと。また、そのことをプロジェクトマネージャーに分かってもらうのも難しいことだったそうです。 1990年代には、デマルコさんは訴訟のサポートを
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
技術的負債の「会計的」性質 – Ryohei Tsuda – Medium
負債とはなにかについてわたしたちが理解していないという事実そのもの、あるいはこの概念の融通無碍であることそれ自体が、負債の力の基盤である。 デヴィッド・グレーバー 「負債論」 ソフトウェア開発において、欠陥のある未熟な実装によって機能の追加や修正が難しくなることを、借金に喩えて「技術的負債」と呼ぶことがある（Wikipedia）。 現代のソフトウェアはもはや「サービス」に近い製品が多いが、サービスは顧客に受け入れられて初めて収益を生み出すことができる。広く使われているソフトウェアも最初は数少ない機能にたくさんのバグを添えてリリースされ、試行錯誤を経て顧客に受け入れられる。つまり、機能の追加や修正が難しくなることは、それ自体が潜在的な損失と言える。 しかし、私にはこの「技術的負債」という言葉は会計上の「借金」とは随分と異なる意味を持っているようにも思える。というのも極端な話、もし機能の追加や
コードコンプリートのチェックリスト抜粋 - shikaku's blog
要求仕様 要求仕様の内容 システムへの入力が、その発生源、正確度、値の範囲、頻度を含めて、すべて明記されているか システムからの出力が、出力先、正確度、値の範囲、頻度、形式を含めて、すべて明記されているか すべてのリポート形式が明記されているか すべての外部ハードウェアインターフェイス、ソフトウェアインターフェイスについて明記されているか すべての通信インターフェイスが、ハンドシェーク、エラー検出、通信プロトコルを含めて、明記されているか ユーザが期待する反応時間が、必要な操作のすべてにわたって明記されているか 処理時間、データ伝送速度、システムスループットなどのタイミングに関する考察が明記されているか ユーザの希望する処理タスクのすべてが明記されているか 各タスクによって使用されるすべてのデータおよび各タスクから得られるすべてのデータについて明記されているか セキュリティレベルについて明
3人以上ペアでやるとミスが多くなる - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ソースコードの質：気難しいプログラマ：エンジニアライフ
近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読
図書館のこと - COBOL技術者の憂鬱
最近また話題になっている例の図書館の事件なんですが、わたしも２年ほど前に、同じようなことを府立中央図書館に対してやっていたので、この件のことはどうにも人ごととは思えなくてとても気になっています。 もともとは、府立中央図書館が提供している検索サイトの使い勝手が悪すぎるので、自分でカスタマイズしてみようかと思って始めたことなのですが、当然図書館のサーバで保有している蔵書データを全てぶっこ抜いてくる必要に迫られました。で、自分も同じように秒間１アクセス程度で取得するスクリプトを書いて走らせていたんですが、どうも途中で図書館側のサーバが止まってしまうことが多かったんですよね。でもしばらく時間を置くと復活するので、そこでまたスクリプトを走らせる→サーバ止まるの繰り返しで、コンピュータ関連の書籍データ１万件を取得するだけで結構時間がかかったのを覚えています。 いや、これは今考えると冷や汗モノですよね。
ソースコード解析ツール Understand
ソースコードの構造や影響範囲をグラフィカルに可視化、ソフトウェアの品質を定量評価するメトリクス計測に対応 Understandは、大規模なプログラムや複雑なプログラムをすばやく理解するためのさまざまな機能を搭載しています。アーキテクチャから個々の機能まで、あらゆるレベルでソースコードを分析し、プログラムの制御フローや構造、クラス継承、関数や変数の関係など、多彩な角度からソースコードをビジュアル化します。 ソフトウェア品質保証 ソースコード解析 メトリクス計測 コードレビュー 影響分析 ソフトウェア品質向上
あなたのスキルで飯は食えるか？ 史上最大のコーディングスキル判定
あなたのスキルで飯は食えるか？ 史上最大のコーディングスキル判定：makeplex salon（1/2 ページ） この問題ができたから優秀な人材とは限らないけれど、できない人は“ほぼ確実に”優秀ではない――プログラマーの皆さまの実力を計るコーディングスキル判定問題を用意しました。あなたはこの問題が解けるでしょうか？ 新年度が始まり、新たに社会人となった読者の方も多いかと思います。あるいは、転職で心機一転がんばろうという読者もおられるでしょう。 あなたがもしプログラマーやSEといった職種であれば、ぜひ面白い仕事を手がけていただきたいと思いますが、そもそも開発分野で本当に面白い仕事とは何かを考えたことはありますか？ その答えを論ずる前に、少し前に話題となったトピックを取り上げたいと思います。それは、岡嶋大介氏の「人材獲得作戦」についてです。ご存じない方のために少し補足しておくと、岡嶋氏は、株価
【インタビュー】「罫線が大好きな日本人に米国人開発者が驚愕」 - グレープシティ 八巻氏 | エンタープライズ | マイコミジャーナル
日本のソフトウェア開発者、とりわけ.NET開発者にとって使いやすい"帳票ツール"はどれか。この観点で商用製品を選ぶときに、おそらく最初に名前が挙がるのがグレープシティの「ActiveReports」である。 .NETネイティブなコンポーネントとして提供されている同製品は、.NETのスキルさえあれば使いこなすことが可能。Visual Studioを使って開発を進められるうえ、特別な使い方を学んだり、独自スクリプトの書き方を習得したりする必要がない。 八巻雄哉――2003年グレープシティ入社。Microsoft MVP for Development Platforms - Client App Dev Jan 2009 - Dec 2009。PowerToolsシリーズのテクニカル・サポートを担当する傍ら、製品開発やマーケティングにも従事。現在は、WPF/SilverlightとPowerT
「オープンソース」の二つの意味 | OSDN Magazine
最近、「オープンソース」という言葉の意味を巡る論争が再燃したようだ。混乱が生じるのは、「オープンソース」という概念自体に、性格の異なる二つの要素が詰め込まれているからではないだろうか。 法的状態としてのオープンソース ソフトウェア開発の文脈における「オープンソース」という言葉は、あるガイドライン(「オープンソースの定義」)を満たしたライセンスの下で公開されているソフトウェア、という意味である。先行した「フリーソフトウェア」という概念の言い換えとして生まれたものだ。これを、「法的状態としてのオープンソース」と呼ぶことにしよう。 「オープンソースの定義」が試みているのは、ソフトウェアの第三者による利用、特に改変や配布に関して著作権者が課す条件に対し、一定の基準を設けるということである。これにより、法的状態としてのオープンソースが保証されているソフトウェアであれば、個別にはどのようなライセンスが
［続報］JALのシステム障害、原因は新機能追加
日本航空（JAL）は2009年6月3日、同日早朝に発生したチェックインシステムの障害（関連記事）の原因について、チェックインシステムと予約発券システムのバージョンアップ作業によるものと発表した。 JALは国内線の全面チケットレス化に関連する新機能を追加するために、2日夜からチェックインシステムと予約発券システムのプログラムのバージョンアップ作業を行った。バージョンアップ作業は、配信用のホストサーバーと全国の空港に設置するチェックイン用端末の両方で実施。羽田空港のチェックインシステムは起動直後の午前5時45分にダウンしたためチェックイン業務ができなくなった。新機能追加前の状態に切り替えて、障害発生から約1時間後の午前6時45分ごろに復旧した。ただし羽田発のWebチェックインは午前11時30分時点でも、利用できない状態が続いている。 JAL広報によると、羽田以外の空港のチェックインシステムは障
F's Garage：>「ソフトウェアの部品化」が失敗する理由を読んで。
この記事は考えさせられた。 「ソフトウェアの部品化」が失敗する理由 － ＠IT おそらくその1つの理由は、「部品化」という比喩が門外漢にもきわめて分かりやすいからだろう。部品化は以下のように理解されている。 部品を再利用すれば生産性が上がる 不具合が出るのは部品の品質基準がないからだ 汎用部品を使わず専用部品を作るから費用がかかる 完成品メーカーになれなくとも、高品質な部品を提供する産業として成長できる それに対する現実は、 実のところ、部品化とは 再利用は品質の安定期まではかえってコストが上がる 初期目的外のテストは過剰で、そもそも行われてない 汎用化を目的とせず使い捨てコードを書くことで、短期的コストは下がる 高い再利用性を持った部品群を作成する方が、使い捨てコードよりも高度な技術が必要 この文章を読んで、製品の部品化(ASSY)は同じものを繰り返し作る手間、品質を改善したが、ソフトウ
260万人の朝の足を直撃 プログラムに潜んだ“魔物”
週末の朝、260万人の足を直撃したのはプログラムに潜む“魔物”だった──10月12日朝、JR東日本や東京メトロなどの8都県662駅で自動改札機が起動しなかった原因は、「レアケース」という改札機の不具合だった。 同日早朝、SuicaとPASMOに対応した16事業者662駅で、日本信号が製造した自動改札機4378台（PASMO 470駅3050台、Suica192駅1328台）が起動しない不具合が発生。通常は駅構内のサーバから集中的に起動する仕組みだが、これが不可能に。各駅はサーバから改札機を切り離し、単体起動に切り替えるなどして対応。午前11時までに全面復旧したが、PASMOで約160万人、Suicaで約100万人の客に影響が出た。 日本信号によると、現時点で判明しているのはこうだ。原因は自動改札機のICカード判定部の不具合。判定部には毎朝、サーバから起動用データの1つとして、「ネガデータ」
氷山の秘密、明らかに - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/2/13 「うちの開発チームのどこが悪いのか分からない」とCEOは心の中でつぶやく。「プロジェクトを始めたころには何もかもうまく行っていたんだ。最初の2週間チームは馬車馬のように働いて、ちゃんと動くプロトを作ったんだ。ところがその後は進み具合が這うように遅くなった。単に連中が怠けてるだけということかもしれん」。彼はキャラウェイ製のチタンドライバを選び、キャディに冷たいレモネードを取りに行かせる。「2、3人首を切れば、連中の尻にも火が付くだろう！」 その間、もちろん開発チームの方は何が悪いのか全然見当も付かない。実際何もまずいことはないのだ。彼らはスケジュール通りに進んでいる。 こんなことがあなたの身に起こらないようにすることだ！あなたの人生を百万倍も楽にしてくれる、こういう非技術系マネジメン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
