コードレビューのスピード
コードレビューのスピード なぜコードレビューは素早く行うべきか？ Google では開発者のチームが協力してプロダクトを高速に開発するために最適化しており、開発者個人がコードを高速に書くための最適化はしません。 開発者個人のスピードは確かに重要ですが、チーム全体のスピードと比べると同等の重要性があるわけではありません。 コードレビューが遅滞するとさまざまなことが起こります。 チーム全体の開発速度が減少します。もちろん、レビューに素早く反応しなくても個人としては他の仕事を終わらせられます。 けれども、チームの他のメンバーが書いた新機能や不具合修正は、CL がレビュー待ち、再レビュー待ちになると何日も何週間も遅れることになります。 開発者がコードレビューのプロセスに不満を持ち始めます。 レビュアーが数日おきにしか返信しないのに毎回 CL への大きな変更が要求されると、開発者はストレスをためるし
大まかな前提条件はじめに要件定義、要件開発に関する記事、書籍は多くありますが（当然ながら特にシステム開発関連が多いですが）、ここではWebサイトのリニューアルに限定した要件定義の内容や進め方について、これまでの経験を元に、私なりにまとめていきたいと思います。 Webサイトについては今は、新規につくる場合のほうがレアケースかと思われるため、リニューアルにおける「要件定義」としています。 また、リニューアルの規模感によっても当然内容は変わってきますが、想定としては３ヶ月から１年程度の期間で行うリニューアルを想定した内容となります。 受託案件（発注側からは外注する）の想定となりますが、発注側、受注側双方の目線で記載しますが、基本受注側（制作者側）の内容として記載していきます。 対象サイトについて特に限定するものではありませんが、なんらかの『企業サイト』を想定しています。 Webサイトリニューアル
フリーランス向け！Web制作の単価の決め方と見積もり項目【WordPress対応】 2023 8/14 こんにちはTERUです。 フリーランスでWEB制作（コーディング と ディレクション業務）をしています。 読者の悩み フリーランスの単価の決め方について知りたい Web制作の見積もり項目について知りたい 本記事では、こういった疑問に答えます。 フリーランスを始めた頃、見積もり作業ではいつも頭を悩ませていました。 「何を基準に金額を決めればいいの？」「どんな見積もり項目を記載しとけばいいの？」 そこで今回は自分の経験から、単価の決め方とWEB制作でよく利用する見積もり項目について解説します。 本記事では、WEB制作の仕事内容についてある程度理解していることを前提にしています。 本記事の信頼性 フリーランスとしてWordPress案件を中心としたWeb制作を仕事にしている WordPress
sebook-ind.dvi
15 9 11 1 5 1.1 5 1.2 5 1.3 7 1.4 8 1.5 8 2 11 2.1 11 2.2 11 2.3 12 2.4 14 2.5 15 2.6 18 3 21 3.1 21 3.2 21 3.2.1 21 3.2.2 23 3.3 24 3.3.1 24 3.3.2 25 3.3.3 26 3.4 27 3.4.1 27 3.4.2 28 3.4.3 28 3.4.4 29 4 UML 30 4.1 30 4.2 30 4.2.1 30 4.2.2 31 4.3 32 4.3.1 32 4.3.2 32 4.3.3 33 4.3.4 34 4.3.5 34 1 4.4 UML 35 4.4.1 35 4.4.2 UML 36 4.5 36 4.5.1 37 4.5.2 38 5 39 5.1 39 5.2 40 5.3 Demarco 41 5.4 42 5.5
ある日突然上司から、「例の案件の要件定義を、至急作成してくれ」と頼まれたらどうしますか？ まずすべきことは、お客さんの要望を把握する「要求分析」とそれをベースにシステムの全体像を決定する「要件定義」の2つのステップがあることを把握した上で、そのプロセスを上司と共有し、顧客ニーズに関する資料を集めるべきです。 そして顧客（エンドユーザー）は何をしてほしいのか、そのためにどのような機能を実装し、どのように進めていくのかをヒアリングし、決定することです。それを文書に落としたものが、要件定義書です。 IT分野で発生するトラブルの実に40％は、要件定義の不十分さに起因すると言われています。 要件定義は、文章を作成する時の「5W1Hの法則-Who（誰が）、When（いつ）、Where（どこで）、What（なにを）、Why（なぜ）、How（どのように）」に似ています。 本記事では初心者の方向けに、要件定
要件と機能の関連を保つテンプレート
要件定義で使用するドキュメント 上流工程は、主に要件定義フェーズと基本設計フェーズに分けられますが、基本設計フェーズは次回お話しますので、今回は要件定義フェーズでのドキュメントについて述べていきます。 要件定義フェーズで使用するドキュメントにはどのようなものがあるでしょうか？ 要件定義の進め方としては、顧客の行っている業務、例えば「見積業務」「調達業務」「請求業務」単位で打ち合わせ日程を決め、それに従って構築するシステム要件のヒアリングを進めていきます。 顧客とのヒアリング時に打ち合わせ内容を記録する「議事録」や、出てきた課題をリスト化して管理する「課題一覧」などももちろん必要です。ただ、こちらはいずれ「プロジェクト管理」について紹介する機会があれば、その時に説明させていただくこととし、「開発ドキュメント」という切り口では、「要件一覧」「機能一覧」についてクローズアップします。 要件一覧は
講義「ソフトウェア工学」
（東大理学部情報科学科） 以下2022年度の内容 講義概要等はシラバス参照・A1月曜4限・14:55-16:40 録画はLMSから利用可能です。毎週必ずしも資料番号通りに進まないことがあります。 講義資料 (0) イントロダクション (1) ドメイン分析・要求分析 (2) システム分析・設計 (3) 形式手法 (4) テスト (5) 保守・管理 (6-1) アジャイルソフトウェア開発 (6-2)様々なパラダイム (7) 先端研究トピック レポート課題 〆切：12/14 （最終講義回の1か月後） → 〆切についての相談は柔軟に受けるが事前に連絡（成績を出してしまう前に） 課題：ソフトウェア工学に関する論文あるいはガイドライン調査報告書などを読み，内容について簡潔に要約し，技術的および実用上の強みや限界，疑問点について考察せよ．結果はA4 2-3枚程度にまとめる（PDF形式）．提出先は講師メー
はじめに RDRA２.０についてまとめみた（前編）の続きになります。 前編ではRDRA２.0へ取り組むモチベーションや特徴、ざっくりした概要を説明しました。 後編ではもう一度RDRA２.0の特徴について理由を添えて説明したいと思います。 また、RDRA２.0で作成する各レイヤーの関係性や成果物についての説明を行いたいと思います。 目次 1.RDRA2.0の特徴について 2.各レイヤーの関係性について 3.各レイヤーの成果物についての説明 1.RDRA2.0の特徴について RDRA2.0の特徴として『RDRA２.0とはシステムの全体像を素早く、整合性を保ちながら明確にする』ことが挙げられています。この特徴について「全体像を素早く」と「整合性を保ちながら」という２つの観点に分けて理由を分析しまとめました。 RDRA２.0が素早く要件の全体像を把握できる理由 ポイント1. 作るモノが明確で、アイ
はじめに イオンスマートテクノロジー株式会社（通称AST）のCTO室TechLeadチームの@t0doroki_takaです。 本記事の内容は、上記の書籍で紹介されている手法を自分の解釈で整理・アレンジしたものです。 計画段階から完成形を定義して、全体の開発工数・工期を見積もって年単位で開発を進めるプロダクトは、アジャイルという考え方の無かったウォーターフォール・モデル時代の考え方なのかもしれません。とはいえ、業務システム開発においては、プロジェクト開始直後からアジャイル開発することは難しく、このような見積もりは欠かせないと思います。 なぜなら、多くの業務システムは、出来る限り早く市場に投入してフィードバックを得てピボットする性質のサービスではなく、予め要件・機能を定義してステークホルダーとの合意形成が不可欠です。アジャイル的な開発を導入するにしても、事前に全体規模の把握は必要です。その際
目次 はじめに 配属されたプロジェクトについて 心に刻んでおきたい言葉【要件定義編】 1.目的と手段がごっちゃになってない？ 2.業務フローは明確になってる？ 3.リリース後の運用のことも検討してある？ 4.制約と前提条件の区別できてる？ 5.プロジェクトが成功するかは要件定義にかかってる。 おわりに 参考資料 はじめに こんにちは。某スマホアプリのバックエンド開発をしているアラサーエンジニアです。 以前配属されていたプロジェクトに、かなりできるPLの方（Hさん）がいました。 当時の私はプレイングマネージャーとして、Hさんの下で開発チームのリーダーをやっていて、 Hさんからビシバシありがたいご指導をいただいていました。 そのおかげもあって、人間的にもエンジニアとしてもかなり成長できたと思うので、 その際に言われたことを忘れないように、つらつら書いていこうと思います。 今回は要件定義編となり
要件定義の始まりは要求事項の整理から 要件定義の項目 ・背景/目的/目標：開発の目的を明確にする ・成果物概要：第三者でも成果物がイメージできるものを図示する ・動作環境：アプリケーションの動作環境を記載する ・ユースケース：重要なユースケースを挙げる ・機能要求：要求事項を実現するための機能を検討する ・入力/出力要求：アプリケーションの入力、出力を明確にする ・接続性要求：連携するアプリケーションがあれば記載する ・ソフトウェア要求：保守性、信頼性、拡張性の目標とするレベルを定義する ・セキュリティ要求：セキュリティの側面からの対応内容を検討する ・スケジュール要求：要求されるスケジュールを記載する 要件定義書を書く時の注意点 機能要求の整理 要求の最小単位を明確にして構造的に記載することで、 下記のようなメリットが得られます。 ・要求全体の理解がしやすくなる ・石器フェーズでソフトウ
第１回 システムズエンジニアリング コラム 一般社団法人JCOSE（Japan Council on Systems Engineering）※では、「システムズエンジニアリング（SE）とは、システムを成功させるための、複数の専門分野にまたがるアプローチと手段のことを指します。」と定義しています。 ※一般社団法人JCOSE（https://www.jcose.org/）は、INCOSEの日本支部として、システムズエンジニアリングを日本に普及させることを目的としている団体です。 本コラムはシステムズエンジニアリングとは？の基礎的な内容を数回に分けてわかりやすく解説していきます。
探偵事務所に浮気調査を依頼するとき、絶対に複数社から見積もりをとるようにしましょう。 なぜなら、探偵事務所は無数にあり、料金の算定方法は探偵事務所によってまちまちだからです。 探偵に個人の事情を説明して回るのは恥ずかしいし億劫かもしれませんが、探偵事務所によって数十万円の差が出てくるケースもありますから、見積もりは複数社からとり、比較検討して納得がいく形で契約できるようにした方がよいでしょう。 今回は、探偵事務所に見積もりを出してもらったとき、チェックし、比較するポイントについて簡単に解説していきます。 探偵事務所に浮気調査の依頼をするのが初めてだという方や、見積もりを出してもらったけれど、どこをポイントに見ていけばいいかわからないという方は、本記事を探偵事務所選びの参考に役立てていただければと思います。 浮気調査の見積りでチェックしておきたいポイントとは？ 今回は、浮気調査の見積りでチェ
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 on Twitter: "おサイフケータイは日本のソフトウェア開発の数少ない「国際的にも評価が高い、輝かしい成功事例」なので、彼らがやった「VDM仕様に対する徹底的なテスト」がもっと多くの現場に広まって欲しい。そして、その技術をより高めて欲しい。まじで。こ… https://t.co/JCGlYUa7j1"
おサイフケータイは日本のソフトウェア開発の数少ない「国際的にも評価が高い、輝かしい成功事例」なので、彼らがやった「VDM仕様に対する徹底的なテスト」がもっと多くの現場に広まって欲しい。そして、その技術をより高めて欲しい。まじで。こ… https://t.co/JCGlYUa7j1
はじめに こんにちは、ヘルスケア開発部でバックエンドを担当している徐 一球(Seo Ilgu)です。 ヘルスケア開発部では主にLINEドクターというサービスを開発しています。 LINEドクターはサービスを立ち上げた当初からWaterfall開発を採用していましたが、市場の変化や顧客のニーズ、チーム内の課題に迅速に対応するため、開発プロセスをScrum開発へと切り替える決定をしました。 紆余曲折はありましたが導入の初期フェーズが完了したため、2つの記事に分けて紹介したいと思います。 きっかけ LINEドクターはサービスは「医療を最適な距離に近づける」ため生まれたOnline診療サービスです。 COVID-19のパンデミックによる需要の増加と、ユーザーに良い体験を届けると同時に更なる「ユーザー中心の設計」と「継続的な改善」を強化する必要がありました。 Waterfall開発モデルは明確なフェー
magnoliak🍧 on Twitter: "プロセスを厳密に決めてから取り掛かろうと言われても、そんな日は永遠にやって来ないのですよ 歩き始めることでしかゴールには近づかないんですよ でも時々立ち止まって、ちょっと戻れるくらいにはしておこうね"
プロセスを厳密に決めてから取り掛かろうと言われても、そんな日は永遠にやって来ないのですよ 歩き始めることでしかゴールには近づかないんですよ でも時々立ち止まって、ちょっと戻れるくらいにはしておこうね
「問題解決の科学シリーズ」は今回で12話目となった。1話から11話を通じて「こうすればこういう具合に失敗した（あるいはうまくいった）」という私の失敗体験と、問題を構成する要素の1～4をひも付けて、「問題解決」について探究してきた。 問題を構成する5つの要素 意思決定者（decision maker） 制御可能変数（controllable variables） 制御不能変数（uncontrollable variables） 制約条件（constraints） 結果（outcome） この1～5の要素の関係をひと言で表現するとこうなる。 『問題解決は、私たち「1.意思決定者」が、ある「4.制約条件」の下で、私たちの力が及ばない「3.制御不能変数」によって「2.制御可能変数」や「5.結果」が影響を受ける前提で、「2.制御可能変数」の最適な値を選択することによって因果関係を持つ「5.結果」を導
magnoliak🍧 on Twitter: "昔初めてPMBOKで「段階的詳細化」って用語を知った時、随分と当たり前のことにわざわざ名前がついてるんだなぁと思ったことが有るけど、案外ちゃんと名前をつけてあげないと最初から細部まで完璧な計画が(実際に有るかは別として)存在せねば… https://t.co/aRbIF0KJ5t"
昔初めてPMBOKで「段階的詳細化」って用語を知った時、随分と当たり前のことにわざわざ名前がついてるんだなぁと思ったことが有るけど、案外ちゃんと名前をつけてあげないと最初から細部まで完璧な計画が(実際に有るかは別として)存在せねば… https://t.co/aRbIF0KJ5t
地域のデザインプロデューサーを育成する「ふるさとデザインアカデミー」の報告書及び研修テキストを公開しました （METI/経済産業省）
経済産業省及び中小企業庁は、デザインと経営の両面を踏まえ、製品・サービス・事業・地域等のプロデュースができる地域人材の育成を支援する事業「ふるさとデザインアカデミー ichi」の報告書及び研修テキストを公開しました。 1.趣旨 経済産業省及び中小企業庁は、「令和元年度ローカルデザイナー育成支援に関する委託事業」として、中小企業・小規模事業者の支援者を主な対象とした人材育成支援事業「ふるさとデザインアカデミー ichi」（委託先：株式会社ジェイアール東日本企画）を実施しました。 本事業は、デザインと経営の両面を踏まえ、製品・サービス・事業・地域等のプロデュースができる人材（デザインプロデューサー）を各地域において育成することにより、地域の中小企業・小規模事業者等の「デザイン経営」※1を促進し、ひいては地域経済の活性化を図ることを目的としたものです。 本事業のプログラムは、講義を中心とした「短
「要件定義と基本設計の2つの言葉はよく目にするけど、詳しい違いが分からない」、「それぞれの作業で、どんなことを意識すればいいのだろう」など、要件定義と基本設計について不明瞭な点があるという方も多くいらっしゃるのではないでしょうか。この2つの言葉は明確に区別されており、それぞれで意識するポイントも違ってきます。 この記事では、要件定義と基本設計の違いから、設計の流れ、要件定義、基本設計の作成時の重要ポイントまでを解説していきます。 また、設計を効率的に進めるためのサービスの紹介も最後にしています。 ぜひ、最後までご一読ください。 「要件定義」と「基本設計」とは？ 要件定義と基本設計は、どちらもシステム開発の業務フローの一部です。 要件定義は、クライアントからの要求をもとに実装する機能を決める作業のことです。要件定義でクライアントへのヒアリングを通じ、要求機能一覧や業務フローなどを作成していき
卓驭科技-官方网站
深圳市卓驭科技有限公司专注于智能驾驶系统及其核心零部件的研发、生产、销售等业务，为汽车行业智能化提供灵活多样的解决方案。凭借多年积累的感知、机器学习、定位、决策、规划、控制技术研发与量产经验，与合作伙伴一道推动高阶智能驾驶的全面普及。 成行平台以 32 至 200TOPS 的灵活算力配置，7V/10V/12V 的简洁传感器配置，实现了包括高速领航、城市领航、城市记忆领航驾驶在内的高阶智能驾驶功能。成行平台基础版本提供了亲民普惠的高阶智能驾驶可用体验；支持灵活增加算力，拓展高精地图、激光雷达等传感器提升舒适性，增加安全冗余。并支持多样化的产品交付模式，满足不同定位、价格车型的市场需求。
Toby on Twitter: "【WBSの功罪】 世の中、WBSを少々信じすぎだと思います。 関係者の多い大きいプロジェクトにおいて、WBSで管理した結果、とにかく変更対応にずっと追われててものすごく時間が取られた、疲弊したという経験がある人も多いと思う。IT系のPJマネジメントで必ず出てくるので、"
【WBSの功罪】 世の中、WBSを少々信じすぎだと思います。 関係者の多い大きいプロジェクトにおいて、WBSで管理した結果、とにかく変更対応にずっと追われててものすごく時間が取られた、疲弊したという経験がある人も多いと思う。IT系のPJマネジメントで必ず出てくるので、
①日本経済は生産性が低いので、３０年間成長していない。 ②全ての産業がデータ×AI化されるので生産性が高まる。 ③AI人材が足りないので育てよう(提案)。 全ての産業がデータ×AI化されるという主張は、事例などで根拠を補強されています。いわゆるデジタルトランスフォーメーション（DX）と同じ文脈です。 では全産業のデータ×AI化に向けて、何が課題になっているのでしょうか。引用します。 人材の質に大いなる課題がある。大半がSIerにおける古典的なプログラマー、コードを書く人といった人材であり、研究と開発のギャップを乗り越えられる人が少ない。すなわち、自然言語処理や機械学習などの研究・実験環境を、堅牢で大規模かつリアルタイムの本番環境につなげられる人材が足りていない。 シン・二ホン p.104から引用 実験環境(研究)と本番環境(開発)のギャップを埋める人材が足りないことが、データ×AI化の壁に
要件定義書の作り方 - 要件定義の進め方
要件定義書の書き方がわからない、要件定義って何やればいいの？という方もいると思うので、発注側としての要件定義書の作り方をまとめておく。 要件定義書に書くべき内容の図による表現 手順①：[作業]あるべき姿の確認 手順②：[作業]現状の把握 手順③：[作業]問題(あるべき姿と現状の乖離)の中から、問題点を特定する 手順④：[会議]あるべき姿と現状と問題点の認識に関する合意をとる 手順⑤：[作業]問題点をどこまで解決するかの目標を決める 手順⑥：[作業]問題点の真因を分析する 手順⑦：[会議]目標と真因分析結果に関する合意をとる 手順⑧：[作業]真因に対する対策を検討する 手順⑨：[作業]対策の中から、システム化対象のものを明確化し、要件化しておく 手順⑩：[会議]対策、システム化対象課題、要件に関する合意をとる 手順⑫：[会議]要件定義書の内容に関して合意をとる 手順⑬：[作業]要件定義書に承
ほとんどの場合、組織に属しているデザイナーは「数字意識を持て」と言われて困ると思います。 それは「デザインをすること」が仕事だと思っているから。 世の中のため、お客様のため、ユーザのために素晴らしいクリエイティブを生み出すことが、デザイナーの存在意義。数字を追うのは、営業や経営者の仕事でしょ？と思っています。良いモノをつくることが一番の会社への貢献だと信じています。 実は、私も”数字意識を持たないデザイナー”でした。 そんな私が、数字意識を持つことが大事なのかに気づいた経緯をまとめました。 「デザイナーとしてかっこいいものを創ること」が正義だった 私が学生の頃からデザイン事務所に入って2年ほど働いていた間、一番興味のないことは数字でした。 逆に興味のあることは、デザインとクリエイティブな発想を活かした仕事。 恥ずかしい話ですが…社会人になったばかりで実務経験がないのに”自分はデザインができ
要求定義の進め方 ｜ 要件定義と何が違う？
要求定義と要件定義、似ている言葉ですが、その意味と役割は異なります。 端的に言えば、要求定義は「顧客がシステムに求める機能や目的を定める」工程で、基本的に発注側で実施・作成されるものです。 それに対して、要件定義は「顧客の求めるシステムを実現するために必要な要件やコストを明確にする」工程で、こちらは発注を受けたSIerやベンダー側で実施・作成されます。 どちらもシステム導入における上流工程に含まれており、これらに不備があると、その後の開発工程すべてに影響が及ぶため、細心の注意を払って取り組むべき工程と認識しておきましょう。 システム開発基本の流れ システム開発プロセス 業務改善や業務改革（BPR：ビジネス・プロセス・リエンジニアリング）、あるいはDX（デジタルトランスフォーメーション）に取り組む際のシステム導入は、ほとんどの場合でV字モデルに準じて進められます。 下記の図にあるとおり、ソフ
（仕様書を書いてと言われたが何をしたら良いかわからない…とりあえず書き方を調べよう…） 初めて仕様書を書くことになったとき、仕様書の書き方から調べる人は多い。私もそうだった。書きたいことがはっきりしている状態で、エンジニアやデザイナーに伝えるためのルールを学ぶなら、書き方を調べるのが正しい。 ただ、そもそも『仕様』がどういうものなのか理解できているだろうか。仕様書に書く内容は決まっているだろうか。フォーマットはわかったが、結局何を書いたらいいのかわからず、頭を抱えている人も多いのではないだろうか。 今回は、仕様書の書き方はわかったが何を書いたら良いかわからず手が止まってしまっているあなたへ、仕様の正体と、仕様の考え方についてお伝えしようと思う。ちなみにこの記事、書いた本人でも引くほど長いので、途中で飽きたらバイオハザードの部分は読み飛ばしてもらって良い。 仕様って何？ 仕様は、遊びや機能を
「成功する要求仕様 失敗する要求仕様」アラン・M・デービス 成功する要求仕様 失敗する要求仕様 作者:アラン・M・デービス日経BPAmazon 読んだ。いわゆる要件定義・要求定義に関する本。帯に「デマルコ絶賛！」とあり、表紙の感じからも「ピープルウェア」など一連のシリーズものの扱いなのかも。2006年初版ということでけっこう古いんだけれども、自分は最近知った。 原題は “Just Enough Requirements Management” ー ちょうど十分な、要求マネジメント。「ちょうど、十分な」というところがミソっぽい。 雑感 (雑な感想) いや、良くまとまってるなーと思った。この本では、要求を「導き出し」、「トリアージし」、「仕様化」、という流れからの「変更を管理せよ」となっている。 問題解決やビジネス成功のために大事なことは、 ユーザー視点を理解する 時間やリソースに都合のつく問
AeroVXR合同会社
About AeroVXR エアロブイエックスアールとは 航空機等の開発や飛行試験に精通したスタッフが 空飛ぶ乗り物に関する 研究、開発、認証をお手伝いする会社です。 安全・安心の向上と航空宇宙産業の発展に貢献できるよう、 空飛ぶ乗り物の研究・開発及び運航に携わる パートナーをサポートし共に航空宇宙産業の路を歩んでまいります。
RDRA - 要件定義の進め方
誰のため、何のため、システム化の目的が不明な要件定義 ゴールが不明確な、ひたすら思い付いた機能の議論をしている 議論が袋小路に入って先に進まない 思い付きの要望を並べただけの整合していない要件定義 誰が何のために、どのような状況で使うシステムなのかが明らかにされないままフォーマットを埋めるだけの要件定義から、計画的に素早く全体像をつかみ、論理的に要件を組み立てるための進め方を紹介する。 ※この進め方は数十回のRDRAを使った要件定義の経験をまとめたものである
2022.06.28追記 下記ヒアリングシート、数年経ち、頭の中で自然と出来るようになったので実際はあまり描いていないのですが 最近はこの要素に加えて ・相手の文脈や背景、歴史（なぜこのプロジェクト/場が相手に必要か？） ・ステークホルダー（相手の関係者がどんな人で、どんなことを意図しているか） などを考えています。 ーーーーーーーーーーーーーーーーーーーーーーーー こんにちは、アラワスの関美穂子＠sekimihokoです。 一対一の視覚化の可視カフェや、グラフィックレコーディングをお仕事にしている個人事業主です。 基本的に東京に暮らしながら、月1くらいで地元の鹿児島にも帰っています。 ▼詳しくはこちら。 プロフィール あぁ、なんて大それたタイトルをつけてしまったんでしょう。 本当はもっと慎ましやかなタイトルをつけようと思ったんです。 ただ今回は「グラフィックレコーディングを始めたばかりで
「要件定義」という言葉、耳にしたことがあるという人は多いと思います。では、要件定義とはそもそも何か、具体的にどうすればいいか答えられますか？ 本連載では、Webサイト制作の要ともいうべき要件定義について掘り下げていきます。LIGブログでは制作サイドの視点から解説します（発注サイドの視点でまとめた記事はつなweBで公開中）。 本記事の監修者 株式会社LIG Webディレクター 因幡 祐香（Yuka_Inaba） Webディレクター歴12年。システム開発を伴うプロジェクトの要件定義やディレクション、長期にわたる安定運用と事業展開を想定した情報管理や体制構築を得意とする。Webディレクター・PM向けのセミナーも実施するなど、メンバー教育にも力を入れている。 株式会社LIG Webディレクター 平山 梨佳（Rika_Hirayama） 1987年福岡県生まれ。2011年よりWeb業界のキャリアをス
視聴メモ: モジュラモノリス徹底解剖〜実践者から学ぶLunch LT〜｜いわまさ@ちいかわうさぎ系エンジニア
非モジュラーモノリスからモジュラーモノリスへのステップ株式会社ナレッジワーク 川中さん なぜモジュラーモノリスにするのか？チーム事情 マイクロサービスと比較したメリット バージョン整理整合容易性 インフラ引用容易性 どのように変更したか？トップレベルには意味ごとにモジュールが並び、その中がclean architectureのようになっている モジュールが公開するAPI以外はinternal packageへ まずはディレクトリ分けまずmodule単位で切って全部公開(ディレクトリだけ移動する) 他のmoduleから内部データが無造作に使われていたりするため、隠蔽は諦める 言語によってはpackage公開ルール周りで不自然な構成になるので、諦める 一部モジュールAPIの公開(隠蔽していく)容易なモジュールから着手 最終構成発表資料より拝借LTの発表内容になかった追加事項モジュール間のRDB
はじめに こんにちは、Product Division Division Headの吉田です。 2022年からプロダクト開発部はProduct Divisionという名前になりました。 ようやく新しい部署の名前にも慣れてきました。 昨年は開発体制について紹介させていただきましたが、今回はEmotion Techの開発プロセスについて紹介します。 10名程度の体制で開発手法について考えている方への参考情報になれば嬉しく思います。カンバンの導入プロセス、カンバン運用についても少し紹介させていただきます。 カンバン使う前はどうしていたのか Emotion Techの開発チームでは、カンバンを使う前はスクラム(Scrum)を使っていましたが、数ヶ月たってKPTの中でいくつかの課題が見えてきました。 当時の課題 開発メンバーが互いの開発領域について詳しくないため見積工程が難しい（ストーリーポイントを
はじめにソフトウェア開発の計画作りでは、各工程に要する時間を算出するために『見積もり』という行為が行われます。 見積もりが使われるのはソフトウェア開発だけではありませんが、ソフトウェア開発での見積もりは難易度が高く、たびたび問題が発生する工程の一つです。 この記事では、何回かに分けて、ソフトウェアにおける見積もりについて書きたいと思っています。 まず1回目は「見積もりがどんなものなのか？どういう特徴があるのか？」といった基本的な内容についてお伝えしていきます。 ◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆ ソフトウェア開発の見積もりとは ソフトウェア開発における見積もりとは、主に開発に関わる作業の時間や期間を指します。 ソフトウェア開発の多くの作業は人間が行ないます。 そのため単純な計算をすると 『ある人がその作業に費やす時間 × 作業の数 = 開発に必要な総作業時間』 とすることができます。 このう
日常生活の中で、ITエンジニアと非エンジニアの会話は、よくあるミスコミュニケーションの宝庫です。特に夫婦間では、この違いが顕著に現れることがあります。例えば、リビング用のDIY棚を作るシナリオを想像してみましょう。 夫（エンジニア）は、妻（非エンジニア）から「リビングに置く棚を作って！」というリクエストを受けます。エンジニアの夫は即座に詳細を求めます。「どのくらいのサイズ？棚は何段必要？どんな色がいい？」と。しかし、妻はこれらの質問に対して、「そんなに細かく決めなくて大丈夫でしょ、任せるわ！」と返答します。この「任せる」という言葉が、後の混乱の始まりなのです。 エンジニアである夫は「任された」と解釈し、自分なりのロジックで最適な棚を作成します。しかし、完成した棚を見た妻の反応は「これじゃない！色も大きさも全然イメージと違う！」というもの。夫は困惑し、妻は怒り心頭。ここで夫は気づきます。「任
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webサイトリニューアルにおける「要件定義」の勘所 vol.1
フリーランス向け！Web制作の単価の決め方と見積もり項目【WordPress対応】 | TERUBLOG
要件定義とは？全体の流れ、メリット、書き方まで、解説します - 企画書作成.COM
https://www.chusho.meti.go.jp/keiei/torihiki/2018/180416support1.pdf
RDRA２.０についてまとめみた（後編） - Qiita
見積りは科学であり、ソフトウェア開発は不確実性との戦い
過去にPLから言われた心に刻んでおきたい５つの言葉【要件定義編】 - Qiita
要件定義の情報収集したメモ - Qiita
第１回 システムズエンジニアリングとは？システムエンジニアとの違いについても解説。
探偵への依頼の見積りをとるとき、押さえておきたいチェックリスト
上流工程で効く、「テストの考え方」 記事一覧 | gihyo.jp
https://shiftasia.com/ja/column/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%A8%E3%81%AF/
LINEドクター Scrum 開発：Waterfall開発からScrum開発へ
「それで売り上げ落ちたら、責任取ってくれますね？」――問題解決の科学（12）
「要件定義」と「基本設計」の違いとは？基本の流れとポイントを解説
デジタル化(DX)の要求定義できる人材いますか : 新規事業のつくり方
数字を知るデザイナー、デザインしかしないデザイナー | 株式会社商藝舎ブログ
仕様書の書き方を調べる前に知っておきたい『ゲームの仕様の考え方』
読んだ「成功する要求仕様 失敗する要求仕様」 - モノラルログ
「お仕事としてグラフィックレコーディングを信頼して任せられます！」とよく言われる私の愛用ヒアリングシート 【DL資料付】
要件定義って何をやるの？制作側が気をつけるべきポイント | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
小さな開発チームでカンバンを使ってみた - EmotionTechテックブログ
ソフトウェア開発の見積もり① 「見積もりの基礎知識」｜ソフトウェア開発ブートキャンプ
事例3：要件定義ドキュメントの漏れや 曖昧性の低減-IPA.pdf
DIY大作戦: エンジニア夫と妻の「任せる！」の行方：エンジニア同盟：エンジニアライフ