ドキュメントとしての詳細設計書と、プロセスとしての詳細設計 - 勘と経験と読経
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
「Docs for Developers」を読んだ - 勘と経験と読経
最近知った興味深いPodcast e34.fm で紹介されていたので興味を持って読んでみた本「Docs for Developers: An Engineer’s Field Guide to Technical Writing」に関するメモ。 2023/3追記：翻訳されたようだ。ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング e34.fmwww.oreilly.com この記事の目次 「Docs for Developers」はどんな本なのか 全般的な感想 各章に関する覚え書き Front Matter Chap 1. Understanding your audience Chap 2. Planning your documentation Chap 3. Drafting documentation Chap 4. Editing docum
「Retrospectives Antipatterns」を読んだ - 勘と経験と読経
先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみた。アンチパターン好きなもので。すごい有用な本だった。 Retrospectives Antipatterns 作者:Corry, Aino,Corry, Aino発売日: 2020/11/02メディア: ペーパーバック 著者サイトはこちらのようだ。https://metadeveloper.com/ 全体的な感想 えてして「ふりかえり」のファシリテーターは孤独だと思う。特にファシリテーションすること自体を主な仕事にしている場合、「より良い
障害発生時の対応フロー（初期対応、本格対応、再発防止） - 勘と経験と読経
タイムラインで目に付いたこの記事を読んで考えたこと。 システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita そういえば障害発生時の対応フローは、割と標準的なものが無いような気がする(不勉強で知らないだけかもしれないけれど)。共通フレーム2013でも細かい定義は無かったし、他の書籍で読んだ記憶も無い。というわけでいったん経験的な知恵をアウトプットしてみようかと。 基本的な流れ 割と自分のイメージと似た障害対応フローが公共系システムのドキュメントとして公開されてたので流用する。ここから拝借したもの。 図にもあるように、基本的な流れは リカバリー対応（初期対応、一次対応） トラブル復旧作業（本格対応） 再発防止 が一般的だと思っている。 初期対応のフレーム 初期対応で考えることはだいたいこんな感じ。あわててプログラムを修正する前にやることがある。 問題調査のために
ソフトウェアエンジニアのコンピテンシとか倫理とか - 勘と経験と読経
自戒を込めて。割とこだわっているソフトウェアエンジニアのコンピテンシと倫理について。「IPA/SEC Journal に寄稿: ソフトウェア品質プロフェッショナルに求められる専門性と倫理性: 知識、スキル、コンピテンシ、倫理綱領 | Reliable Software Engineering, Washizaki Laboratory」という記事が興味深かったのでその感想など。 IPA/SEC Journal に寄稿: ソフトウェア品質プロフェッショナルに求められる専門性と倫理性: 知識、スキル、コンピテンシ、倫理綱領 | Reliable Software Engineering, Washizaki Laboratory photo by Dunechaser コンピテンシなどについての様々な枠組み 上記で公開されている寄稿は「スキル、知識、コンピテンシ、倫理要領」に関するものなのだけ
いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経
今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型本 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍（most thoroughly useful book）」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛
社内勉強会をやらない理由 - 勘と経験と読経
ときどき「社内勉強会をやってほしい」という事を言われることがあるのだけれども、基本的には断るようにしている。その理由について。 社内勉強会は言われて始めるものじゃない 「社内勉強会をやってほしい」と人に言われても基本的には断っている。こういったことを言うのは自分の上司や関連部門の偉い人に多い。言う人は、きっとこんな期待をしている。 メンバーの底上げやレベルアップ 生きた知識を現場間で情報共有する メンバー間の交流でより良い結果が得られるようになる でも実際に言われるがままに勉強会を企画しても、 人が集まらない 発表者が偏る 発表者の負担が増えていき、開催されなくなる ということになるのがわかっているから、実施しないのだ。 どうしてこんな事が起こるのかというと、単純にマーケットが小さすぎて、企画が成立しないのだからだと思っている。そもそも、コミュニティ活動を真っ当に実施できているエンジニアは
コードレビュー、修正前コードを残す悪習、構成管理警察のこと - 勘と経験と読経
コードと構成管理の取扱いについて。ソフトウェア開発プロジェクトで自分がプログラミングすることは基本的に無いのだけれども、プロジェクトマネージャとしてはかなりコードに触れるほうだと思っている。最近コードにまつわる興味深いブログ記事をいくつか見たので、これに対して自分の考えを少しまとめてみる。 コードレビューについて ここで紹介されている、構成管理システム(VCS)でのレビューコントロールがとてもエレガントだと思う。 レビューのために bug tracker や task management system を使うのはあまり良いとは思いません。 レビューでは非常に細かい点が議論されることがあり、これが仕事のタスクの一チケットに相当するとはとても思えないからです。 例えば、この変数名は短すぎて良くわからない、といったことのために bug tracker をブラウザで開き、チケットを切る、やってら
朝会を進捗会っぽくしない - 勘と経験と読経
朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれることはある。 朝会のミニ進捗会化 デイリースタンドアップ／スクラムはスクラムマスタのためのものではない そもそも朝会のようなコミニュケーションの場は特殊で、（日本人にとって）普通に学校や社会で学ぶような機会はあまりないと思う。いちばん経験するのはトップダウンの情報共有（先生や上司の話を聞く）かボトムアップの報告（上司やリーダーに報告連絡）だから、放っておくと朝会もそうなりやすい。 うまくいっていない朝会だと、そもそもメンバーの会話を他のメンバーが聞いていない。というか、自分が発言するまでは「なにを発言するか」ばかりを気にしているし、自分の番が終わるともう終わっ
上流工程の失敗カタログ - 勘と経験と読経
他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF) (2019/4/19 リンク切れを修正) 「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む 「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。 本来あるはずのレアケース、例外に関する要求が出てこない 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手
ソフトウェア開発における多能工の問題 - 勘と経験と読経
ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェクトが大規模より中小規模・短工期にシフトしていることが、専門家(単能工)による開発を難しくしつつある状況も、開発エンジニアの多能工化を後押ししている。しかし、多能工によるソフトウェア開発はベストプラクティスかというと、そうではないと思う。多能工アプローチの問題点について考察して望まないと、思わぬところから足をすくわれる事がある。 なぜ多能工なのか？専門家(単能工)はなぜだめなのか？ ファクトリー型アプローチは一時期流行し、いまなお一定の価値をもってはいるが、ほとんどのアプリケーション・ソフトウェアの開発には、現在これよりも有効な手法が存在している。 ソフトウ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
