実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
要件定義ではHowじゃなくてWhatを語れという話 - 勘と経験と読経
ソフトウェア開発における要件定義では「要件定義ではHowじゃなくWhatを語れ」とか「UIの議論の前にシナリオ／ユースケースを整理しろ」という話を最近何度かすることがあった。この考え方は過去のいろいろな学習経験とプロジェクト経験から来ているのだけれども、そういえばちゃんとまとめたことがなかったと思い、まとめてみることにしたという記事。 要件定義ではHowじゃなくWhatを語れ どういう意味かというと、具体的にはこんなことを言いたいのだ。 いきなり要件定義段階で、構築予定ソフトウェアの画面など機能の話をするな ユースケースもしくはそれに類する形で要求を整理しろ ユーザーの要求を動詞で整理しろ なお現代的にはユースケースより、ユーザーストーリーといった形で整理するのが良いかもしれない（これは読者の属するドメインによる）。 なぜHowを語るべきではないのか 要件定義でHow、すなわちソフトウェア
忙しい人は勉強をしている？ - 勘と経験と読経
以下のブログ記事が面白かった。勉強会に出ないと不幸になるのか。読んで考えたこと。 2013-11-17 ちなみに勉強したから偉いとか、勉強会に参加することが良い事だとも別に思っていない。 忙しい人は勉強をしている？ 以前に参加した勉強会でこんな話をしたことを思い出した。 本当に「忙しいから学習しない」のか？ 実際には忙しい人ほど勉強会などに参加しているのでは？ 忙しい人は、実際には業務をこなしている 『忙しいから勉強するのだ』 この発想ができない人が、いる。 Devlove HangarFlight -BlizzardSailing- に参加して社内内弁慶について話した - 勘と経験と読経 ところで「忙しい」というのはどんな状態のことを言うのだろう。 という形だといまいちしっくりこない。 こんな状態だろうか。 結局は能力が高いか低いか、なのかもしれない。 基本的には「どうやって左から右にシ
もしもソフトウェア開発のPMがTRPGのGMだったら - 勘と経験と読経
妄想妄言の類い。工程の区切りで正気度チェック！という話ではなく。InfoQで「ロールプレイングゲームのダンジョンマスタとして学んだことをアジャイルコーチングに活用する」という記事を読んで考えたことなど。ちなみに「TRPGのGM」は、「テーブルトークロールプレイグゲームのゲームマスター」のこと。 テーブルトークRPG - Wikipedia ゲームマスター/ダンジョンマスターの役割 TRPGのGMの役割は、わたしの理解ではざっとこんな理解である。 物語りの背景と舞台、大まかなシナリオを用意する メンバーの振る舞いに応じて少しずつシナリオを進めて、メンバーと一緒に物語を作り出す メンバーの行動を指示することは出来ないが、舞台設定である程度行動の方向性に影響を与えることはできる 「轟音とともに洞窟の入り口は崩れた岩によって塞がれてしまった。どうやら後戻りはできないようだ」 この「メンバーの行動を
単体テストフレームワーク(xUnit)に関すること - 勘と経験と読経
このブログエントリの言いたいことがわかるようでわからなかったので、整理してみる記事。ドキュメントベースの単体テストとxUnitの類いの単体テストフレームワークの違いに関する私見。ツール(手段)の話ではなく、目的を中心に考えれば良いと思っている。 もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません。xUnitは小さなプログラムを動作確認するために作られたツールです。 ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと | DevelopersIO ドキュメントベースの単体テスト 例えばこんな「ドキュメントベースの単体テスト」が行われていて、いきなりxUnit類のツールを適用するとかなり混乱すると思われる。 割と「単体テスト」というものを実施するこ
負の生産性のこと - 勘と経験と読経
メモ。2013-10-15を読んだ。お説ごもっとも。とはいえ、ソフトウェア開発の世界にはさらに「負の生産性」があるので、そのことについて。 負の生産性について よく、PGの生産性はピンキリであり、倍率は3倍だとか10倍だとか100倍だとかいう人がいる。おおむねあっているのだが、しかし重要な、不足している概念がある。生産性はマイナスになるよ！ということだ！ I am gathering you:人月問題解決の糸口にどうぞ。「PGの生産性にマイナスの概念の導入」 という上記記事は冗談めかして書かれているけれども、実際に検証された事実でもある。 Augustineの調査で観察されたのは、一部の人は一切の実のある貢献をしない（タッチダウンをしないクォータバック、特許を持たない発明家、事件を解決していない探偵など）ので、おそらくデータは実際の生産性におけるばらつきを過少評価しているのだろう、というこ
思考停止ワードとコミットログとコードコメント - 勘と経験と読経
古い記事になるのだけれど、バージョン管理ツールにコミットログのNGワードを登録するという話が面白かった。ソフトウェアは思考がそのまま品質につながるようなところがある。思考停止に近しいワードを禁止してしまうのも手かもしれない。 コミットログのNGワード 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 コミットコメントを意地でも書かせたい - almost nearly dead 単にコメント無しを規制するだけではなく、思考停止してしまうようなワードを禁止しているのが素敵。 また、これに加えて会社名や人名も禁止してしまうのはうまいやり方だと思う。人の名前が出てくるとそこで情報が隠蔽されてしまうし、「問題 VS 我々」のスタンス
顧客の権利 - 勘と経験と読経
だいたい毎月1回実施している「やさしくわかるBABOK」読書会に今月も参加した。大遅刻してしまったので参加者の議論のまとめを聞く程度だったのだけど、いくつか興味深いキーワードはあった。その中から「顧客の権利」について少し書いてみようと思う。 やさしくわかるBABOK 「やさしくわかるBABOK」で紹介されている顧客の権利 今回の読書会は「第三章 引き出し」が対象である。この章で取り上げられている「顧客の権利」がなかなか良いという意見が出ていた。 顧客の責任： 要求を提供し、明確にし、繰り返して細部をつめていくために必要な時間を費やさなければならない システムの要求について情報を提供するときは、明確かつ正確でなければならない 求められた場合は、要求についてタイムリーに決断を下さなければならない 顧客の権利： 開発者にあなたがわかる言葉で話してもらえる 開発者にあなたの業務と目的について学んで
コタツモデル・リローデッド - 勘と経験と読経
ソフトウェアさかばさんでコタツモデルが取り上げられていた。コタツモデルは、要求開発で比較的よく持ち出されるメタファーの一種。要求開発は前身がUMLによるビジネスモデリングの研究会であったこともあり、基本的にUML指向・モデリング指向の方法論となっている。しかしこの「コタツモデル」自体は一種独立した発想であって、UMLやモデリングとは独立した思考法として成り立っている。あらためて、コタツモデルについて整理してみようと思った次第。 コタツモデルとは コタツモデルに関する解説については、2008年に日経ITProに記事を書いていたが、これが一番わかりやすいと思う（そんな記事を書いたことはすっかり忘れていた）。 要求開発とコタツモデル(1)－－失敗パターンに陥らないために | 日経クロステック（xTECH） 要求開発とコタツモデル(2)－－アンチパターンを活用する | 日経クロステック（xTECH
CCPMを使って組織にアジリティを注入するのは冴えたやり方 - 勘と経験と読経
先日公開された「NTTデータはどうやってCCPMを導入したのか？」という資料を見ての感想。アジャイルという言葉を前面に持ってこずに、しかし結果として主にスクラムを中心としたプラクティスを現場に注入している(ような気がする)。CCPMを使って組織にアジリティを注入するのは冴えたやり方だなぁと思った。 そういえば、技術士の二次試験の口頭試問で自分のプロジェクトの進め方を説明した時に試験官から「制約理論を勉強されたのですか？」と聞かれたことを思い出した。自分としては(制約理論は知っていたけれども)プロジェクトの特性に合わせてアジャイルプラクティスをつまみ食いして運営していたつもりだった。結果としてCCPMに近いことをやっていたのかもしれない(ごっちゃになっていたのかも)。 部分最適が現場を悲惨にしている 制約理論(TOC)というとピンと来ないかもしれないが、10年以上前にベストセラーになったゴー
「工業製品」としてのソフトウェア - 勘と経験と読経
ソフトウェアの品質というと国際基準や規約というものがまずあるのだけれども、そういった観点とは別に「工業製品としての品質」という考え方もあるのではないかと思っている。美しいコードは品質が高いと言われているけれども、それは「芸術品」を目指したものではないか。われわれが作っているものは「芸術品」なのか「工業製品」なのかということを考えるべきではないだろうか。 そのソフトウェアに「品質過剰」は無いか？ 知り合いのプロジェクトで「複数のシステムが使う共通検索機能」があって、スケジュールの関係もありバラバラに(共通化せず)構築してしまった話を最近聞いた。そのプロジェクトでは開発フェーズの終盤で顧客からクレームがあり、該当の機能は苦労して再度共通機能として作りなおしたそうだ。比較的よく聞くたぐいの話だけれども、いくつかの点で少しひっかかった。 内部実装がバラバラだったとしても、外見上の機能性がまったく一
ソフトウェア・エンジニアと武士道、騎士道精神（アジャイル話じゃないよ） - 勘と経験と読経
SIerがオワコンだったり新人SEが絶望する今日この頃。組織を憂う前に自分が技術者として終らないようにするほうがよっぽど建設的だと思っている。ひとこと「勉強しよう」というのは簡単。それよりも先に、職業倫理について考えてみるのはどうだろう。 職業がプロとして成熟した証の一つは、倫理規定または職業上の行為の水準が存在することである。 ソフトウエア開発プロフェッショナル 第20章 専門的職業の倫理規定（P239） マコネルの会社のエンジニアが最初に学ぶこと コンストラックスは、Code Completeで有名なスティーブ・マコネルの会社である。同社の専門技術者育成プログラムがソフトウエア開発プロフェッショナルに紹介されていて興味深い。英語版は以下からダウンロードできるようだ。 Construx Professional Development for Software Organizations
アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経
「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である
コードレビュー、修正前コードを残す悪習、構成管理警察のこと - 勘と経験と読経
コードと構成管理の取扱いについて。ソフトウェア開発プロジェクトで自分がプログラミングすることは基本的に無いのだけれども、プロジェクトマネージャとしてはかなりコードに触れるほうだと思っている。最近コードにまつわる興味深いブログ記事をいくつか見たので、これに対して自分の考えを少しまとめてみる。 コードレビューについて ここで紹介されている、構成管理システム(VCS)でのレビューコントロールがとてもエレガントだと思う。 レビューのために bug tracker や task management system を使うのはあまり良いとは思いません。 レビューでは非常に細かい点が議論されることがあり、これが仕事のタスクの一チケットに相当するとはとても思えないからです。 例えば、この変数名は短すぎて良くわからない、といったことのために bug tracker をブラウザで開き、チケットを切る、やってら
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
Making Softwareを読んで、ソフトウェア開発の技芸と工学について考えた - 勘と経験と読経
ソフトウェア開発は技芸（アート）か工学か、という問題についてときどき思い起こして考える。アジャイル開発やその周辺について学び考えている時はソフトウェア開発を技芸と捉えていることが多い。ソフトウェアは、高いマインドセットを持つ少数のエンジニアによって作られる作品だ。大規模ソフトウェアや、システムオブシステムズといった複雑なソフトウェアについて考えるときには、ソフトウェア開発を工学として考えている。生産性と品質を管理し、作業のパイプラインが淀みなく流れていくようにマネジメントするのだ。どちらが正しくて、どちらが誤っているということはない。境界に立って、腕をまくる・・・。 2011年9月に刊行された「Making Software ―エビデンスが変えるソフトウェア開発」を読んで、ソフトウェア開発の工学的な側面についてまた考えることになった。 本書はひとことで言うと(私の理解では)『ソフトウェア開
イベント「DevLOVE vs スクラム道」に参加して理想のソフトウェア開発について考えた - 勘と経験と読経
釣りタイトルに騙されてついうっかりDevLOVE vs スクラム道というイベントに参加してしまった。詳細なレポートはこちらやこちらを参照のこと。イベントの中で「理想のソフトウェア開発」について何人かとお話したことについて。皆の意見とわたしの意見はまったく違うものだった。 つくらない事 このイベントの参加者はアジャイル界隈で活躍中の人、アジャイル界隈に憧れている人が中心で、完全にアウェー。私とお話することになった方は、お一人がサービス提供側企業の方で、もう一人がフリーでサービスデザインなどをやられている方だった。 お二人の意見はそれぞれだったのだけど、ひとつの意見として「理想のソフトウェア開発は、つくらない事」というものがあって興味深かった。 価値を提供することが目的であり、ソフトウェアはその手段 究極的にはソフトウェアをつくらないことが理想的 （上記は私の記憶によるものなので、お二人が言い
永遠なるソフトウェア工学の諸問題 - 勘と経験と読経
マイケル.A.クスマノの「ソフトウエア企業の競争戦略」という本の中で紹介されている、1968年(!)に発表された「ソフトウェア工学の諸問題に関するNATO報告書」の内容を知って絶望したことについて。 ちなみに、「ソフトウェア工学」という言葉そのものも、ほぼこのあたりが発祥らしい。つまり、これから紹介する諸問題は「ソフトウェア工学」のはじめからあったということ。 たぶん原典はhttp://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDFだけどちゃんと読んではいない。 ソフトウェア工学の諸問題に関するNATO報告書（１９６８年） 顧客と設計者側のシステム要件に対する理解の欠如 見積もり技術の未熟さが原因の、経費および時間に関する大きな予実差異、要件変更に対応する期間延長の不履行、および作業分割の内容が十分に理解されないうちに実施され、
朝会を進捗会っぽくしない - 勘と経験と読経
朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれることはある。 朝会のミニ進捗会化 デイリースタンドアップ／スクラムはスクラムマスタのためのものではない そもそも朝会のようなコミニュケーションの場は特殊で、（日本人にとって）普通に学校や社会で学ぶような機会はあまりないと思う。いちばん経験するのはトップダウンの情報共有（先生や上司の話を聞く）かボトムアップの報告（上司やリーダーに報告連絡）だから、放っておくと朝会もそうなりやすい。 うまくいっていない朝会だと、そもそもメンバーの会話を他のメンバーが聞いていない。というか、自分が発言するまでは「なにを発言するか」ばかりを気にしているし、自分の番が終わるともう終わっ
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
