ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ - 勘と経験と読経
読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。 #51 V字モデルの深淵を覗き込んで反省する：「単体テストの考え方（UTPPP）」を読む（後編） - 勘と経験と読経 #50 V字モデルの深淵を覗き見た気分：UTPPPを読む（前編） - 勘と経験と読経 #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる？ #デッドライン読書会 - 勘と経験と読経 #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経 #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経 さ
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
情報システムの再構築戦略についての現時点の理解整理 - 勘と経験と読経
1月に公開されたIPA/SECさんの「システム再構築を成功に導くユーザーガイド」と、最近読んだ「レガシーソフトウェア改善ガイド」を踏まえて情報システムの再構築戦略について再整理してみる記事。再構築における、リファクタリング／リアーキテクティング／リライト／リホスト／リビルド／リプレースなどの各戦略について考えてみたことなど。 システム開発における上流工程の課題を解決するユーザガイドを公開 コードがレガシーになる原因のほとんどは、人間に関係している～『レガシーソフトウェア改善ガイド』より (1/2)：CodeZine（コードジン） レガシーソフトウェア改善ガイド 作者: クリス・バーチャル出版社/メーカー: 翔泳社発売日: 2016/11/14メディア: Kindle版この商品を含むブログ (1件) を見る 再構築戦略の再整理 実際にはこれ以外にも手法があるのかもしれないけれど、「システム再
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
ITアーキテクトとは何か - 勘と経験と読経
割と身近なところで頻繁に「ITアーキテクト」という単語か飛び交っていて、もやもやしたので情報を整理しながら書く記事。オチはない予定。 photo by SantiMB.Photos ITアーキテクトの定義 例えばIPAの共通キャリア・スキルフレームワークでの(システムアーキテクトの)定義はこんな感じ。 http://www.ipa.go.jp/jinzai/itss/csfv1.html システムアーキテクト 人材像の役割 ビジネス戦略 に対して最適 なシステムを デザインする。 IT戦略を受け、ソリューションを構成する、又は組込み製品開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計する。 情報処理技術者試験における(システムアーキテクトの)定義は次のとおり。 IPA 独立行政法人 情報処理推進機構：制度の概要：システムアーキテクト試験 情報システム戦略を具体化するた
目標設定ゲーム - 勘と経験と読経
目標設定とか会社の評価制度に関するブログの記事をいくつか見た感想。個人的にはこの手の制度は「殴ったら手が腐る」ものだと思っている。ゲームとして考えたらいいんじゃないだろうか。 ITエンジニアの評価制度をどげんかせんといかん - ぐだぐだ言ってないでコードを書けよ、ハゲ。 目標管理シートドリブン開発はくそ - razokulover publog 目標管理制度（笑） - カレーなる辛口Javaな加齢日記 「目標による管理」そのものが理屈として成立しにくい この手の評価制度の根底にはドラッカーの「目標による管理」が根底にあるのだと思うのだけど、たぶんこれを適用するシチュエーションから間違っているような気がする。 目標による管理 - Wikipedia Wikipediaの記事を読むだけでイマイチ感が満載。 前提として「組織の大目標が個人レベルまで分割できる」必要があると思うのだけれども、組織の
マークアップ、Excel方眼紙 - 勘と経験と読経
自分の所属がSIerだからなのかもしれないけれど、一定比率で「文書はExcelで書くのが効率的」と主張する輩が周りに出現する。Excelはやめてと言っても聞いてもらえない。いわゆるExcel方眼紙。とはいえ、SIばっかりやっていて、おバカになってるのだけが理由とも思えないので、いろいろ考察してみたりした話。ちなみに自分は反Excel派。 公務員が公開するネ申Excelが日本の生産性を落としている話 - Togetterまとめ 「ネ申 Excel」問題 - 奥村研究室 - 三重大学(PDF) ExcelがWYSIWYGなのじゃないか仮説 Excel派の話を聞いていると、なんとなくExcelこそがWYSIWYGだと思っているような気がする。 Wordは、思ったように資料を作りにくい。文書構造を意識したり、各種のワードプロセッシングが煩い。あと罫線引いたりが難しい PowerPointは、自由自
保守開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
前回公開したエントリ「開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経」へのフィードバックで、保守には設計書が必要なのではないか、というものがあった。その点については思うことがある。というわけで、保守という観点でソフトウェア設計書に関する考えをまとめてみた。ソフトウェア構築時に必要とされる設計書と、保守の際に必要とされるものは異なるのではないかと考えている。 議論の前提：仕様書と設計書 再掲になるけれども、ここでは仕様書と設計書という用語を以下のように定義する。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 そして、改めて説明する必要は無いと思うけれども仕様書は保守
開発プロジェクトのリカバリープラン - 勘と経験と読経
ソフトウェア開発プロジェクトでは、どんな開発方式をとっていたとしてもスケジュール等に遅れが発生することはある(それが人の御業である限り)。そんな時にはプロジェクトを立て直す(リカバリーする)ためのプランを立てて実行することになるが、これをリカバリープランと呼んでいる。リカバリープランを自分で立てることもあるし、人のリカバリープランを見ることもあるけれども、おさえておくべきポイントがあると思う。 科学的に取り組む。精神論で立ち向かわない。 単純にブラックであること以上に、精神論で状況に立ち向かうことは関係者に多大な迷惑をもたらす。サイコリバカリーはよくない。 利害関係者と状況を共有することができない。 「今やってます」という回答を繰り返す、いわゆる蕎麦屋の出前状況になってしまう。 何らかのタスクの終了を待っている人が見通しを立てられない。 利害関係者からの協力がやりにくい。 もし少しでも状況
ソフトウェア設計にプログラミング経験は必要か、あるいは再びログハウスの例え - 勘と経験と読経
ソフトウェア設計にプログラミング経験は必要か。私なりの結論は「ある部分についてはプログラミング経験(というか完成までの全工程の経験)があったほうがいいけれども、全部ではない」だ。オーダーメードのソフトウェアを作ろうとした場合、無限とも言える選択と意思決定が可能となる。選択肢の範囲が広い部分と、狭い部分では必要なスキルも違うのではないだろうか。 本記事は、以下のブログエントリを参考に書いたもの。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 以前に書いたログハウスの例えはこちら ログハウスの例えとソフトウェアの特性と - 勘と経験と読経 ログハウスの例え、ふたたび 一部省略しているけれども、以前こんなふうに書いた オーダーメイドのソフトウェアは、例えるならログハウスを作ろうとしているようなもの 対象としているビジネス領域が「土地」であ
ソフトウェア開発のベストプラクティスを組織内に求める愚 - 勘と経験と読経
最近とある人とかわした会話についての考察。ソフトウェア開発のベストプラクティスを組織の内側に求めても効果的ではない、というのが個人的な見解。むしろ害になることもあるのではないかと思っている。 以前に書いたこの記事も関連。 成功事例には興味がない - 勘と経験と読経 「ソフトウェア開発」とベストプラクティス Wikipediaで「ベストプラクティス」を引くと、こうある。 ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。最善慣行、最良慣行と訳されることもある。また、仕事を行うために最も効率のよい技法、手法などがあるという考え方をいう。すなわち、適切なプロセスを確立し、チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果が得られると考える。ベストプラクティスは、多くの人々によって反復され、最も効率的で最も効果的であることが時間をかけて証明されてきた
上流工程の失敗カタログ - 勘と経験と読経
他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF) (2019/4/19 リンク切れを修正) 「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む 「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。 本来あるはずのレアケース、例外に関する要求が出てこない 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手
ソフトウェア開発における多能工の問題 - 勘と経験と読経
ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェクトが大規模より中小規模・短工期にシフトしていることが、専門家(単能工)による開発を難しくしつつある状況も、開発エンジニアの多能工化を後押ししている。しかし、多能工によるソフトウェア開発はベストプラクティスかというと、そうではないと思う。多能工アプローチの問題点について考察して望まないと、思わぬところから足をすくわれる事がある。 なぜ多能工なのか？専門家(単能工)はなぜだめなのか？ ファクトリー型アプローチは一時期流行し、いまなお一定の価値をもってはいるが、ほとんどのアプリケーション・ソフトウェアの開発には、現在これよりも有効な手法が存在している。 ソフトウ
アジャイル手法によって生産性が上がりプロジェクトは成功するか？（いいえ） - 勘と経験と読経
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？ その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
