はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ？」 「基本設計との違いって何だったっけ？」 「基本設計と詳細設計の区別って？」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて１からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部（特に要件定義や基本設計、詳細設計のサンプル）を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか？」「なぜこれをやってるんだっけ？」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
この記事で言いたいことは、まとめると以下のような内容になります。 ・「面倒くさくて複雑」といフローは、例外もあるものの、基本的には不適切であるか、そのフローが必要とされる前提の方がおかしい ・けれど世の中には、「面倒で複雑なフロー程正しいし価値がある」と考える人が案外多い ・「面倒くさい」と言える人は貴重なんだけど冷遇されがち ・不要なJOIN句は敵だし、JOIN句の使い回しなど絶対してはならない よろしくお願いします。 さて、言いたいことは最初に全部言ってしまいましたので、後はざっくばらんにいきましょう。 先日、Twitterでこんなことを呟きました。 エンジニアをしていると「面倒くさいやり方は大抵間違っているか、あるいはそのやり方を必要としている前提の仕組みの方がおかしい」という思考は割と普通だと思うんだけど、どうも世間的には「面倒くさければ面倒くさい程正しい、ないし価値がある」と思っ
連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「要件の範囲が食い違ったことにより生じた紛争」を解説する。 ユーザーが望む機能がシステム開発の要件から抜け落ちたがために発生する紛争は、本連載でこれまでにも何度か取り上げてきた。 IT紛争の類型は種々さまざまであり、過去の判例が全てそのまま適用できるわけではないが、裁判所が「たとえ要件としてユーザーから明示されていなくても、その機能が契約の目的を果たす上で、当然に必要な事柄であるとベンダーが認識し得る状態にあれば、ベンダーにはその機能を作り込む義務（債務）がある」と判断した例が幾つもある。 要件定義書よりも契約の目的の方が重いとする考え方だ。 今回取り上げる判例も、「ユーザーが必要と考える機能が、ベンダーの作成した要件定義書から抜け落ちており、これを作り込まなかった」というものだ。これまでと少し異なるのは、パ
東京でWEB制作をひとりでやってる。 興味ある人いるかわからんけど、現状こんな感じ。 自分の中で整理も兼ねて。 やってる仕事自分はWEBプログラマなんだけど、直接お客さんのところに行って要件聞いてきて必要なシステムがあれば自分で組む。 いわゆる「ホームページ」の作成もやってる。 デザインはできないから、デザイナーに基礎デザインと基本的なHTMLコーディングはお願いして細かいところは自分で埋め合わす感じ。 ディレクションからサーバの選定からセットアップ、ドメインの取得とDNS設定なんかは丸っと含めてやってる。 年間の売り上げは1200万程度会社始めた頃は結構浮き沈みあったけど、ここ5年間はこれくらい。±100万程度はあるけど全く変わらない。不思議。 別にこの金額を目指してるわけでも、この金額に行ったら仕事セーブするとかそういうのは全く無し。 何故かこの金額に落ち着く。毎月100万円も請求書を
「なんで、俺たちが、そんなことしなきゃいけなんですか？」 ある社内プロジェクト会議で、ベテランのエンジニアが、営業の責任者にかみついていました。 なんとしても数字を挙げたい営業が、本来かかるであろう金額の2/3程度を提示し請負案件で受注したのだそうです。新規のお客様でもあり、今後の受注も期待できると踏んで、勝負をかけたとのことでした。しかし、蓋を開けてみると、いろいろと問題があることが分かりました。 まず、ひとつは、金額積算に当たって、お客様と合意をとらないままに、「ここまでは、お客様にやってもらおう」という前提の下で、工数減らしたのだそうです。お客様が、こちらの都合の良いように行動してくれるという前提ありきの見積です。そんなことなどありえません。 本来であれば、「最悪のケースを想定し全部を自分達がこなしたらどうなるか」という前提で見積り、その上でコストを下げるためにどうすれば良いかをお客
「御社のシステムの問題は、この点にあると思います。私達の製品を使えば、この問題を解決することができると思います。」 こんな説明をすると、「おいおい、うちのシステムの問題とはどういうことだ。ちゃんと使えているし、問題なんてあるようには思わないけどねぇ」などと、意地悪な突っ込みをされるかもしれません。 「問題」という言葉を、こんな風に使うのは、適切な使い方ではありません。そこで、「問題」を「課題」に置き換えてみてはいかがでしょうか。 「御社のシステムの課題は、この点にあると思います。私達の製品を使えば、この課題を解決することができると思います。」 では、「問題」と「課題」、何が違うのでしょうか。 例えば、「国際会計基準に対応した会計システムを導入する」という「あるべき姿」つまり、お客様が「結果として実現したい姿」があったとしましょう。しかし、「現在の会計システムは国際会計基準に対応していない」
「ITは鉛筆、消しゴムと同じで道具に過ぎない。それをどう使いこなすが大切だ。」 こういう説明をされる方も多いように思います。私も以前はそうでした。しかし、最近は、この表現はすこし乱暴ではないだろうかと思うようになりました。 企業価値を高めるためのIT コスト削減、期間短縮、競争力強化など、ITは企業価値を高めるために使われます。その使い方には「道具としてのIT」、「仕組みとしてのIT」、「思想としてのIT」があります。 道具としてのIT スマートフォンやパソコン、サーバーなどのハードウェア、ワープロやスプレッドシート、電子メールなどのソフトウエアは、鉛筆や消しゴム、手帳などの道具を置き換えるものです。これらを使うことで、仕事の効率や品質を高めることができます。これらを「道具としてのIT」と呼びます。コストや使いか勝手の良さ、さらには多くの人が広く使っていることで、お互いにやり取りが容易にな
Web会議とテレビ（ビデオ）会議の違い 唐突ですがみなさん、「Web会議とテレビ会議の違いを説明して」と言われて簡単にできるでしょうか。ほぼ一緒じゃないの？…という印象を持たれてる方も多いと思います。そこでまずは違いを確認しておきましょう。 「Weｂ会議」とは、実務作業で必要となる資料やソフトウェアを共有するための機能に音声や映像、チャットなどのコミュニケーション機能を統合させた、共同作業を行うための新しいコミュニケーションツールです。その名の所以は「Webブラウザ」を使う点にあります。 次に「テレビ会議」ですが、Web会議との大きな違いは次のような点にあります。 解像度の高い映像データの共有が目的 専用端末が設置された場所に参加者が集合して参加 重要会議が行われる これらをまとめると、「テレビ会議」は「Web会議」が実務レベルの共同作業を行うのに比べて、専用端末のある場所に全員が集合し
Office 365 フォーラムで SPF レコードが設定されていないメールを受信したときにどんな動作をするのか？というスレッドがあったので確認してみました。 送信側 SPF レコードの内容確認 実験台にするのは例のドメインです。 このドメインは Office 365 で使用しているので こんな感じで SPF レコードが設定されています。spf.protection.outlook.com を参照するように指定されていますね。 # dig kazuakix.jp TXT ;; ANSWER SECTION: kazuakix.jp. 3599 IN TXT "v=spf1 include:spf.protection.outlook.com -all" spf.protection.outlook.com を確認してみると、Office 365 がメールを送る可能性のある IP アドレスが
派遣社員を募集するため企業が提示する時給は、先月まで２４か月連続で前の年より上がっており、いわゆる「マイナンバー制度」への対応で企業や自治体から需要が高まっている「ＩＴ・技術系」の業種を中心に人材の引き合いが強まっています。 それによりますと、５月の平均時給は１５９０円と、去年の同じ月より５４円上昇し、２４か月連続で１年前を上回りました。業種別にみますと、システムエンジニアなど「ＩＴ・技術系」が去年の同じ月より１１１円上がって２０３８円、次いでデザイナーなどの「クリエイティブ系」が７０円上がって１６７９円、事務などの「オフィスワーク系」が１８円上がって１４６９円と、幅広い分野で時給が上がっており、特に「ＩＴ・技術系」の上昇が目立ちます。 これについてリクルートジョブズは、来年１月に運用が始まるいわゆる「マイナンバー制度」に向けて準備を進めている全国の企業や自治体からこの分野で需要が高まって
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレク
御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1 IT業界における営業の役割をちょっと考えさせられている。ほとんど営業が居なくても、仕事が回ってしまう現実を複数社で見た上で、客先の課題に対して自社の持ち玉すらぶつけられない営業の姿も見ると、そもそも営業の存在意義ってなんだとか思う。客と酒飲むだけですか？的な。 2011-01-14 23:11:56 御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1 個人的には営業は必要だと思うし、一時期、臨時とは言え営業統括までやった経験でいうと、営業を御することができるのは営業経験者だけだと思うし、なにより顧客のリレーションを保持するのは最終的には営業の役回りだという信念はある。 2011-01-14 23:14:46
IT業界の営業かくあるべき論 - Togetterが面白かったので首を突っ込んでみます。 上記で言われている営業は「パッケージ導入やオリジナルでの受託開発業をやっているシステム屋の営業」という前提のようです。僕もこの前提で書いていきます。 良く聞く話ですが、エンジニアからすると最たる不満の１つに「営業は不勉強」というのがあると思います。自分が売り込もうとしている商品が技術を武器にしているのにも関わらず、システムや技術のことを知らずに言葉だけで売るのはいかがなものか、という問題です。 これらの知識が無いと何がマズいかと言うと、 顧客の要望のインパクトがどれほどのものかわからない。 できない事に対する代替案が提案できない。 判断できることが少ないのでスピードが落ち、エンジニアに負担がかかる。 などがあります。 システムの営業の難しいところは、顧客のニーズはあくまでシステムがもたらす効用(ソリュ
資料のフォーマットを作ることはとても重要です。プログラミングにおける設計と同じです。ある作業を行う際、資料のフォーマットがあれば、経験の少ない人でもそのフォーマットに沿って、穴埋めしていくだけで、一定レベルの品質を担保できるからです。どこの会社も独自の資料フォーマットを持っていて、それがノウハウの1つとも言えます。資料フォーマットがない場合、その業務に対するノウハウがないと考えて先ず間違いありません。 インターネット上で公開されている議事録のテンプレートにあまり良いものが見当たらなかったので、議事録のテンプレートを作成しました。良ければご活用ください。他にも良いものがあれば、私に教えて頂きたいです。 議事録_ZopePlone開発_ひな形.xls SE(システムエンジニア)というお仕事で議事録を軽視している人や IT 系企業に入社する新入社員がいたら、声を大にして伝えてほしいです。 ちゃん
2013-12-09 顧客に価値を届ける、ってなんだっけ 開発 日記 最近、@syobochimのブログを読んでいたら、こんな言葉が書いてあった。 顧客に価値を届けたい。 私はいま、価値届けられてるんだろうか。 アジャイルサムライを読んだら意識高まってつらい - そこに仁義はあるのか(仮) 僕はどうだろうか。今のプロジェクトはありていに言えば"炎上"している。 そんな中で「誰の考え方が一番正しい」のか分からなくなった。ので、今日はそんな話を書いてみようと思う。 この話の登場人物 あやぴー 僕です。 マツダさん 僕と同じ会社の先輩。エンジニア歴10年位。 モリさん 僕と同じ会社の上司にあたる人。エンジニア歴20年位の大ベテラン。 イノウエさん 元請けの会社に8月くらいに中途で入社したエンジニアさんで立場的にはプロジェクトリーダー(PL)的な感じ。転職するまでPL1とかVBとかのお仕事を
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） 読んでいて、実用書なのに涙が止まらない本に巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら？」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い
この元増田は他の業界のものも含めて設計をお願いしたことって多分無いと思うんだよ。 家の場合だったら、普通は設計図と各パーツの詳細見積りで初めて契約だろうが。 見積りの根拠出してくれっていったら、金くれって言われたよ その設計図は増田が事細かに出した要望を元に一から作ったものなの？って話。 つまり、出来合いのものを適当に組み合わせたものには設計料は掛からないし、そうじゃないものには設計料が掛かるってだけの話ですね。 当然だけど、システムの設計もただではない。大まかな流れを示すと以下な感じ。ちょっと適当。 ・発注元に（ちゃんとした）システム部がある場合 要求仕様を作成し、それに基づいた提案をシステム会社に依頼する。この時点で要件がある程度はっきりしている場合、概要設計を元にした詳細見積もりが可能。出来合いのものを流用できるような要件であれば精度は高く、そうでなければ概算部分が生じる（要件定義フ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
