ウォーターフォールモデル (Waterfall Model)とは まず、ウォーターフォールモデルについて。 これは読んで字のごとし、滝の流れ (ウォーターフォール) のように流れに従って開発する手法のこと。 Wikipedaには以下のように定義されていました。 プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、「要求定義」「外部設計（概要設計）」「内部設計（詳細設計）」「開発（プログラミング）」「テスト」「運用」などの作業工程（局面、フェーズ）にトップダウンで分割する。線表（ガントチャート）を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にする。ウォーターフォール・モデルの利点
ドメイン駆動設計によるシステム開発 生産ラインのイノベーション
116 知的資産創造／2020年9月号 I T S O L U T I O N S 題が大きいと考える。現在のシス テム開発生産ラインを簡単に説明 すると、次のようなステップとな る。 ①要求定義や画面・帳票のUI、 ビジネスエンジンなど外部設計 を担当する業務アプリケーショ ンの専門家、基盤・ネットワー クや運用の方式設計するエンジ ニアなどがウォーターフォール モデルの上流工程を担当する。 ②次に、データベース構成・項目 やトランザクションなどを具体 的に設計するアプリケーション エンジニア、基盤・ネットワー IT構築コスト・期間の増加 「システム構築はどうしてこれほ どお金と時間がかかるのだろう」 システム開発にかかわる人は誰し も思っていることである。実際、 大手損害保険会社が第 2 次総合オ ンラインといわれている1980年代 に基幹システムを構築した費用は およそ300億円程度
12月といえば Advent Calendarの季節です。 ※Advent Calendarとは、Qiitaの毎年恒例のイベントです。 特定のテーマや企業内でチームを作り、一か月間記事を投稿し続けます。 本記事では、 ・私が読んでいるAdventCalendar ・12月14日までの大量の記事のなかで、個人的におすすめの記事 を紹介します。 15日以降の続きは、（19年12月後半編）の記事にて紹介します。 それでは以下。 機械学習入門系 カレンダー 機械学習をどう学んだか by 日経 xTECH 機械学習ツールを掘り下げる おすすめ記事 失敗から学ぶ機械学習応用～Another Story～ SlideShareで人気の資料「失敗から学ぶ機械学習応用」 の増田さんの資料あとがき的な位置づけの記事です。 どのように機械学習を勉強されたのか、その流れと使用した書籍などが紹介されています。 また
こんにちは、プロダクトデザイン本部（旧サービスデザイン本部）の若林です。 2020年2月18日に開催するMeetUPイベントにて、リクルートのUX組織が実践している「ナレッジシェアの仕組み」と「具体的な案件のナレッジ」を社外初公開いたします。 このブログでは、イベントに先立ちましてリクルートのUX組織の特徴をご紹介します。 リクルートのUX組織の特徴 リクルートは、多種多様なマーケットで数多くのネットプロダクトを運営しています。 リクルートテクノロジーズのプロダクトデザイン本部では、各プロダクトの「ユーザ体験価値（UX）」と「ビジネス価値」を高める案件を企画・設計しています。 シゴトの一例 どのような案件を実施しているか、SUUMOの例をご紹介します。 このようなユーザビリティ改善や新機能開発について、日々、企画・設計しています。 その際は、定性的な声や定量的なデータといった根拠を集めなが
請求管理ロボのエンジニアリングマネージャーの白坂です。最近カジュアル面談などでご質問をいただく機会の多い請求管理ロボの開発の進め方についてすこし突っ込んでご紹介します。 当社で公開している資料「3分でわかるROBOT PAYMENT」のP12をベースに紹介します。 機能を実装してリリースする際には上記資料の右図の通りで1〜8のプロセスを実施しています。 要望確認 プランニング 要件定義 開発 テスト レビュー ドキュメント整備 リリース 要望確認 担当ロール：プロダクトマネージャー、デザイナー 請求管理ロボではユーザーの声はもちろん、今話題のインボイス制度などの社会的な法制度の変化に合わせたプロダクトのアップデートを行っています。本プロセスでは、主にプロダクトマネージャーがユーザーインタビューや法制度解釈の確認などを通し、本質的な課題が何かを検査します。そして解決するためのユースケースや機
はじめに 2019/07/18に、BizReach QA Meetupというイベントに参加しました。 （イベントの参加レポートはこちら） そのイベントで、ブロッコリーさんという方が、自分が開催した新人向け研修の内容を発表しており、それを聞いて私は「この研修、自分も受けてみたい！」と思いました。 受けてみたいと思ったポイントは、2日間でテストに関する知識を体系的に学べそうだなと思った点です。しかし実際にその研修を受けるわけにもいかない。じゃあ自分で調べてみるか！と思い立って書いたのがこの記事です。 基本的にはブロッコリーさんのスライドに書いてあるカリキュラムに沿っていろいろ調べています。しかし、私はあくまでテストについて知りたかったので、以下については割愛しています。 ・モブワーク ・ソフトスキル ・見やすいコード ・クラス設計 ・読みやすいコード ・テストケース名の大切さ ・レガシーコード
皆さん、こんにちは。リンプレスの石津です。 IT企画や上流工程に関して、様々なお客様の支援に取り組んでいると、「上流工程」や「要求定義」、「要件定義」という言葉の指す範囲が、企業や個人によって異なることが気になります。 組織によって、工程の呼び方や範囲が異なるのは許容できますが、検討すべきことが検討されずに、開発工程で仕様のモレが発見されたり、ユーザに満足されないシステムが作られてしまうような事態が発生するトラブルは見過ごせません。 この記事では、一般に「要求定義」「要件定義」という工程がどう違うのか？それぞれで何を抑えるべきなのか？を考察します。 「要求定義」「要件定義」とは、何を扱う工程か？要求定義が変更されると要件定義の変更が必要となります。それぞれ定義が異なるため、しっかり区別しましょう。 「要求定義」とは ビジネスで何を実現したいか？ユーザの希望を扱う工程 「要件定義」とは 要求
YouTube埋め込みって、するだけでLighthouseスコアが低下して悲しい気持ちになりますよね。なので研究としてLighthouseスコアを低下させない対策を調べたり試しました。最終的に、特定のケースでのみ低下不可避という結論に至りました。 結論 YouTube埋め込みがファーストビューにあり、スマホ対応も必須な場合、Lighthouseスコアの低下は避けられない ※もし回避する方法を見つけている方がいれば教えてください 検証結果 以下のサイトとGitHub Repoに公開済みです。サイト内、コード内に説明は特に無いので本記事の内容と合わせて見ていただければと思います。 前提知識 YouTubeをiframeで埋め込んだだけで、Lighthouseのスコアは大幅に低下する Playerに関するJavaScriptがダウンロードされ、LCPに影響するため しかもファイル数も多く、1ファ
「Google Things to do」連携リリース - アソビューでの機能開発の流れ - asoview! Tech Blog
こんにちは! アソビューでバックエンド アプリケーションエンジニアをしている山野です。 アソビューは7月にGoogleとの連携機能「Google Things to do」のリリースをしました。 今回はこの機能開発について紹介したいと思います。 Google Things to doとは Googleがアクティビティやアトラクション分野で導入した予約検索表示機能です。 これにより世界中のゲストが世界中のアクティビティやアトラクションを見つけ、 Google上で価格を比較することができます。 またゲストは体験したいアクティビティ・プランを見つけた場合は、 Google上からサービス事業者のWEBサイトへのダイレクトにアクセスでき、予約に進むことが出来ます。 google things to do 開発体制 プロダクトオーナー・プロダクトマネージャーとエンジニア(私)の３人体制で開発を行いまし
このWhite Boardの謎解きをしてくれたのは、連載688回でも名前が出てきたRan Berenson氏(VP&GM, Core and Client Development Group)である。氏曰く、「これは、私やチームのメンバーが(USに居た)Jim Kellerの所に行ってプレゼンテーションしたときのものだ。このミーティングでは(Alder Lakeの)重要となるコンポーネントに対しての判断を行なった。右側に×がついているというのは、当初ヘテロなCPU構成やグラフィック統合、AI H/Wの搭載などがいずれも不要と(Jim Keller氏が)判断したという記録だ」という。 ちなみに氏はそこから2～3ヵ月かけて最高経営責任者に対して、効率的なプロセッサーを作るためにはヘテロ構成にするしかないと説得をした結果として、Alder Lake(やRaptor Lake)のP-CoreとE-
【要件定義】いきなり内容説明しない！業務フローを説明するまでの「長い道のり」をまとめました。 - Qiita
要件定義をしているときに、お客さんに資料を説明することがあります。ITを専門にしていないお客さんにどのように説明するのがよいのでしょうか。まずは、資料の中身を説明する前に、前提を話す必要があります。資料の作り方は書籍やネットの記事でよく目にしますが、資料説明の仕方はあまりないようにみえます。ので、資料を丁寧に説明する流れを検討し、自分なりの言葉でまとめました。 本記事では、 ①紙媒体で行っていた業務をシステム化するプロジェクト ②「要件定義フェーズ」 ③「業務フロー」を「お客さん（ITを専門にしない方）」に説明する と仮定して、セリフと解説を記載してきます。 説明の流れ 1.ウォーターフォールモデルにおける要件定義の解説 2.使用する資料の概要説明 3.近々のスケジュールの確認 4.資料の見方と説明の流れの提示 5.資料の説明開始！
ソフトウェア開発をめぐる品質やコスト、納期にかかわる要求がますます高度化している。その一方では、開発プロダクトが、ますます大規模化、複雑化を遂げているという状況もある。そうした要請に応えるアプローチとして、大きくクローズアップされているのがMBSE（Model Based Systems Engineering）による開発アプローチだ。そうした中、去る2019年10月23日、富士ソフト アキバプラザにおいて、UMLやBPMN、SysMLなどさまざまな表記方法に対応したモデリングツール「Enterprise Architect」の提供元であるスパークスシステムズ ジャパン主催により、今回で第3回となる「Enterprise Architect 事例紹介セミナー」が実施された。ここでは、当日実施された小松製作所（コマツ）によるセッションの模様をレポートしたい。 株式会社小松製作所 開発本部 シ
UML2.0クイックリファレンス 作者:Dan Pilone,Neil PitmanオライリージャパンAmazon 目次 目次 はじめに シーケンス図とは 設計プロセスにおけるシーケンス図の立ち位置 シーケンス図の描き方についてのヒント ヒント1 ヒント2 シーケンス図を構成する要素 メッセージ 自己メッセージ 外部とのメッセージのやり取り ライフライン 実行仕様(イベント)の表現 シーケンス図の例: ログイン 複合フラグメント alt 分岐処理の表現例 ref 相互作用使用 別参照 opt 条件による実行の表現 delay 非同期の遅延処理 par 並列処理 loop 繰り返し処理 break 中断処理 critical 排他制御処理 グループ化 作成と消滅 上下でメッセージ間でスペースを空ける 分離線 ボックス ノート メッセージのノート GitHub 参考資料 はじめに ソフトウェア
要件定義書と要求仕様書の違いを解説！誰が作るのか、進め方も解説
要件定義書と要求仕様書の違いとは？システム開発プロジェクトに加わると、「要件定義書」や「要求定義書」、時には「要求仕様書」といった言葉を聞く機会が増えます。では、「要件定義書」や「要求仕様書」は何の目的で作成され、両者にはどういった違いがあるのでしょうか？ システムエンジニアを目指す方は、それらの目的や意味、違いをしっかり押さえておく必要があります。ここでは「要件定義書」と「要求仕様書」の違いを題材として、システム開発の基本について解説していきます。
この記事は個人開発Advent Calendar 2022 24日目の記事です。 はじめに 初めての個人開発ということもあり、開発に用いた技術スタックに目新しいものは全くありません。なのでそれを紹介するだけなら面白みがないと思うので、非情報系の学部＆プログラミング未経験の状態からサービス作ってみるかと思い、実際に作るに至った経緯をメインに書こうと思います！ 個人開発は大学3年の春頃から始めて、出来上がったのは約1年後です。単純な技術不足を含む様々なことが理由で、かなり時間がかかってしまいました。なのでリリースした頃には、既に大学を卒業していました。 ちなみに個人開発に没頭していたこともあり、卒業時点では就職先が決まっていませんでした。決してダメ人間が故に、「働く先がなかった訳ではないよ」と自分には強く言い聞かせてます！ その辺りの経緯に関しては余談で書かせて頂きます。 作ったサービスの概要
ひと昔前のシステム開発では「どのように開発を行うか（How）」に重点を置き進められていましたが、その進め方では不備や失敗が多く、ひととおり経験したのちに、現代のシステム開発の関心事は「どんなシステムが必要か（What）」に変わりました。 このように、よいシステムを開発するには、考え方や進め方、成果物の書き方に至るまで、目的や環境に合わせて常に変化していく必要があります。しかし、ただ一つ変わらないことがあります。品質は顧客が決めるということ、つまり「品質＝顧客満足度」という図式です。 今回は、システム開発の超上流工程の要求定義と品質をテーマに、要求定義の進め方や書き方、要件定義書やRFPとの違いに至るまで網羅的に解説していきます。どうぞ最後までお付き合いください。
リンクは載せておくが有料記事だ。内容は https://www.nikkei.com/article/DGXMZO49404950U9A900C1000000/ （同内容が日経コンピュータ2019年8 ... 私はシステム屋で働いているが、ウォーターフォール型のプロジェクト開発をしている。アジャイル開発のニーズが有るというのは分かる。ただね、ウォーターフォール型開発が悪、アジャイル開発が正義みたいな論調は如何なものかと思っている。 フォトジョーSzczepanskaにUnsplash プロジェクトの基本はウォーターフォール開発であるはず。例えば2019年10月1日から始まった消費税対応。法制度に照らしあわあせてどんな要件なのか、どんな機能が必要なのか？きっちり決めてスケジュール通りに納品する。こんな案件でアジャイル開発スタイル取る必要がある？ウォーターフォール開発はプロジェクト運営の基本形
オープンソース開発におけるソフトウェア工学的側面
Software Engineering オープンソース開発におけるソフトウェアの工学的側面 Paul Vixie ポール・ヴィクシー Translation by Akira Kurahone 「プログラムを書く」ことだけがソフトウェア開発ではない。にもかかわらず、オープンソースプロジェクトでは多くの場合、プログラムは単に書かれ、単に配布されている。とはいえ、ソフトウェア工学的に作成されなければ、幅広いユーザに受け入れてもらえないわけでもない。これが事実であることを示す例はいままでにもたくさんある。そこで、本章では、通常のソフトウェア開発で実践される工学的工程をまず検討し、そのうえで、それらの工程がオープンソースのコミュニティでどのように実践されているかについて考察してみたい。そして最後に、そこに現われた違いの意味について考えてみることにする。 ソフトウェア開発の工程 ソフトウェアの開発
仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方｜kakomoe
仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方 💡このnoteはなに？ プロダクトに関するドキュメントの種類呼称別の整理と、どうしたら現在のチームにドキュメントに関する目線合わせのアイデアを書いたものです 💡誰のためのnote？ プロダクト開発に必要なドキュメントについて日々心を悩ませている人 ドキュメントの話に着地をつけたい 誰かが言い出すアレ今までの経験上、どこに配属されても、プロダクトに関するドキュメントとして誰が何を書き、そして運用するのか、という議論が起きないことは1度もない。 プロダクトに関するドキュメントは、PRD・要件定義書・仕様書・Design Docなど、さまざまな呼称があり、会社や部門によってさまざまな使われ方をしている。 そしてそれぞれの言葉には単一の定義があるわけではない。 そもそもドキュメン
はじめに この記事はこちらの素晴らしい記事を拝見し、私も書こうと思った記事となります。 筋肥大目的で筋トレを始めて約6年程度の体験＆健康に関する学習で得た知見を元に書いています。筋トレ3年目頃から、筋肥大よりも健康志向になったので記事の内容は健康に重きを置いた内容となっております。 エンジニアリングにも全く関係ないので、皆様暇な時に読んでください。と言いたい所ですが、 日常的に運動をしていない不健康なエンジニアは必ず読んでください。 また、私が仕事よりも本気で取り組んでいるジム勧誘活動によって、弊社社員のジム加入率は80%を超えています。熱心で粘着質な勧誘、そしてプロテイン服用の強制によって、運動経験がなく将棋一筋の弊社CTOですら1年以上筋トレを続けております。 ですので、筋トレエンジニアの方で社内に筋トレ民を増やしたい！と思っている方にもお役に立てる記事となっております。 なぜ運動不足
![[筋トレのすゝめ] プログラミングばっかりしていて、運動不足のエンジニアを撲滅したい](https://cdn-ak-scissors.b.st-hatena.com/image/square/38c18292e99f00e01ed51c17ac54b1f985c39a2e/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--L8KyRHbr--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255B%2525E7%2525AD%25258B%2525E3%252583%252588%2525E3%252583%2525AC%2525E3%252581%2525AE%2525E3%252581%252599%2525E3%252582%25259D%2525E3%252582%252581%25255D%252520%2525E3%252583%252597%2525E3%252583%2525AD%2525E3%252582%2525B0%2525E3%252583%2525A9%2525E3%252583%25259F%2525E3%252583%2525B3%2525E3%252582%2525B0%2525E3%252581%2525B0%2525E3%252581%2525A3%2525E3%252581%25258B%2525E3%252582%25258A%2525E3%252581%252597%2525E3%252581%2525A6%2525E3%252581%252584%2525E3%252581%2525A6%2525E3%252580%252581%2525E9%252581%25258B%2525E5%25258B%252595%2525E4%2525B8%25258D%2525E8%2525B6%2525B3%2525E3%252581%2525AE%2525E3%252582%2525A8%2525E3%252583%2525B3%2525E3%252582%2525B8%2525E3%252583%25258B%2525E3%252582%2525A2%2525E3%252582%252592%2525E6%252592%2525B2%2525E6%2525BB%252585%2525E3%252581%252597%2525E3%252581%25259F%2525E3%252581%252584%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_34%3A%2525E3%252581%25259F%2525E3%252581%252591%2525E3%252581%252597%252Cx_220%252Cy_108%2Fbo_3px_solid_rgb%3Ad6e3ed%252Cg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2FmZjliMGZlZjIuanBlZw%3D%3D%252Cr_20%252Cw_90%252Cx_92%252Cy_102%2Fco_rgb%3A6e7b85%252Cg_south_west%252Cl_text%3Anotosansjp-medium.otf_30%3A%2525E3%252583%25259E%2525E3%252583%25258A%2525E3%252583%2525AA%2525E3%252583%2525B3%2525E3%252582%2525AF%252520Tech%252520Blog%252Cx_220%252Cy_160%2Fbo_4px_solid_white%252Cg_south_west%252Ch_50%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzJlNjEyMTI5ZDQuanBlZw%3D%3D%252Cr_max%252Cw_50%252Cx_139%252Cy_84%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
技術力を見える化する！オブジェクト指向コードレビューの実践 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちは akihiyo76 です。現在、私のチームではレビューガイドラインを明文化して、レビュアーはガイドラインに従ってコードレビューを行なっています。このガイドラインは、チームで運用を開始して２年になりますが、チームでも浸透しレビュー時に必ず利用するようになりました。 はじめに コードレビューの課題感 課題改善に向けて 採用したコードレビュー観点 1. Design（設計） 定義 具体例 2. Simplicity（理解容易性） 定義 具体例 3. Naming（命名） 定義 具体例 4. Style（コードスタイル） 定義 具体例 5. Functionality（機能要求） 定義 具体例 6. Test（テスト） 定義 具体例 7. Document（文章） 定義 具体例 指摘対応の要否 具体的な利用方法 指摘例 最後に コードレビューの課題感 私は現在モバイル開発チー
アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 チーム・組織にプラクティスを導入し、根付かせるために！ 116の手法を一冊にまとめた“実践”の手引き チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。 プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。 本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。 架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、
IPAデジタルスキル標準ver.1.0.pdf
All Rights Reserved Copyright© IPA 2023 デジタルスキル標準 ver.1.１ 2023年8月 All Rights Reserved Copyright© IPA 2023 1 目次 I. デジタルスキル標準の概要 ⚫ デジタルスキル標準策定の背景、ねらい ⚫ デジタルスキル標準 改訂の考え方 ⚫ デジタルスキル標準の構成 ⚫ デジタルスキル標準で対象とする人材 ⚫ デジタルスキル標準の汎用性 ⚫ デジタルスキル標準の活用イメージ II. DXリテラシー標準 1. DXリテラシー標準策定のねらい、策定方針 2. DXリテラシー標準の構成 3. スキル・学習項目 a. 概要 b. 詳細 4. DXリテラシー標準の活用イメージ III. DX推進スキル標準 1. DX推進スキル標準策定のねらい、策定方針 2. DX推進スキル標準の構成 3. 人材類型・ロー
要求定義とは？要件定義との違い、進め方のポイント
要求定義はシステム開発の用語で登場しますが、要件定義と混同したり、中身を決めるときの方法や内容が違ったりして、さまざまな失敗やトラブルを引き起こします。 システム開発をベンダーに依頼する場合には、システム開発を依頼する担当者も要求定義や要件定義の違いを理解した上で、要求定義や要件定義を進めていく必要があります。 本記事では、要求定義と要件定義の違いをわかりやすく解説した上で、要求定義の重要性や陥りやすい失敗事例、進め方のポイントについて解説していきます。 要求定義・要件定義の違いは？ システム開発会社ごとやシステム開発に関わる企業担当者によって「要求定義」と「要件定義」の言葉の指す範囲や意味が異なる場合があります。しかし、両者の定義を不明瞭に開発を進めることは、後述するようにさまざまな問題を引き起こします。本章では、要求定義と要件定義の違いについて、わかりやすく解説していきます。 要求定義
“DXの本質”から考える ワークフローと人材育成のベストプラクティスとは？：「地に足の着いた」DX推進の人材育成を DX推進を主導する「DX人材」の獲得や育成に多くの企業が取り組んでいるが、そもそもDX人材とはどのような人物を指すのだろうか。国内企業が抱くDXに関する“誤解”を正し、その本質と適切な人材育成方針を探る。 デジタルトランスフォーメーション（DX）推進は国内企業の必須課題だが、経済産業省が「DXレポート2（中間とりまとめ）」で指摘した通り、全体としてその進捗（しんちょく）は思わしくない。 これが進まない理由としてよく聞かれるのが「DXを主導する人材が社内にいない」というものだ。そもそもDX実現の明確な道筋が立っておらず必要な人材が分からなかったり、採用後に人材のミスマッチが起きたりするケースが多い。社外から人材を招く手段もあるが、人材に限りがある以上どの企業でも容易に獲得できる
何のため？ たまたま「予定通り進まないプロジェクトの進め方」を読んでいたら、レストランの注文をうまくユーザーの要望・要求・仕様に例えていて分かりやすく、もう少し掘り下げて整理したいと思ったのと、システム開発の上流工程周辺（企画とか詳細設計含める）は工程やドキュメントの種類が多く自分自身よく混乱するので、改めて勉強して、まとめておくためです。 主観も混ざっていますので、参考程度にしていただければと思います。 そもそもなぜ混乱しやすい？ 概ね下記のような理由だと考えています。 同じような言葉が多い 要望/要求/要件 設計/仕様 仕様書/定義書 各組織の文化的な要素もあり、会社、メンバー、業務委託構造によって、各工程やドキュメントの呼び方が若干異なることがある。 要求仕様書なのか、要求定義書なのか、要件仕様書なのか、要件定義書なのか、など 機能仕様書、機能要件定義書、など レストランの注文例 ち
プロダクトマネージャーが成果を出すためには、ユーザーの課題解決や価値提供に加え、プロダクトチームやステークホルダーを動かす必要がある。ところが、常に合理的で正当な行動を取っていたからといって、必ずしも周囲の人が動くわけではない。Product People株式会社代表でプロダクトコーチの横道稔氏は「ProductZine Day 2024 Winter」の特別講演に登壇し、プロダクトリーダーシップにおける信頼獲得やマネージングアップ、パーソナルブランドの重要性について語った。 ProductZine Day 2024 Winter 横道氏の講演スライド（Speaker Deck） プロダクト組織を率いるには、組織内での信頼を得ることが重要 横道氏はLINEやサイバーエージェントでプロダクトマネージャー、エンジニアリングマネージャー、エンジニア、アジャイルコーチ、人事といった、プロダクト制作
私はソフテックに入社して15年超の社員で、主に組込みソフトの開発に携わっています。最近、関わった仕事で、内部設計フェーズにおいてどういった資料を作成すべきかを見直す機会がありました。 今回のソフテックだよりでは、組込みソフト開発において内部設計書に書くべき内容について、まとめてみたいと思います。ソフテックで実際に作成している資料など、できるだけ具体的な例をあげて、ご説明していきます。 内部設計書とは、一般的に、ユーザーの目に見えないシステム内部の設計を記述したドキュメントを指します。詳細設計書と呼ばれる場合もあり、ソフトウェアのプログラミングを行うために必要な資料になります。 ソフトウェアの開発プロセスは一般的に下図のようなV字モデルで示されますが、その中で、内部設計書を作成する段階は、要件定義と基本設計（外部設計）が完了した後、プログラミング（コーディング）を行う前の作業になります。 図
顧客を成功へ導くCS(Customer Success)がやってしまった、失敗。顧客の失敗（Customer Failure）を繰り返さないよう参考にしていただけたら幸いです。 産業保健×SaaSの特徴僕は働くひとと組織の健康という「産業保健」の分野で、企業の人事労務や産業医(働くひとの健康管理を専門にする医師)の業務を効率化するクラウドサービス「Carely」のカスタマーサクセス(CS)チームのマネジメントをしていました。産業保健分野のSaaSには以下のような特徴があります。 【産業保健SaaSの特徴】 ・法律で義務づけられていることが多いが微妙なルールが会社ごとに異なる。 ・医療機関や健康保険組合にて、紙の文化、FAXの文化が根強い。 ・健康診断の予約やデータ入力といったアナログ業務に工数をとられすぎていて、本来やるべき働くひとの健康に貢献する仕事に集中できていない ・専門性が高く、産
HOME » Blog » 自律型（ティール・アジャイル）組織・複雑系 » 「エンタープライズ・アジャイル」LeSSとSAFeどちらを選択すべきか。その違いと比較。 エンタープライズ・アジャイルのフレームワークがなぜ必要か？ いわゆる「エンタープライズ・アジャイル」、大規模なアジャイル開発のフレームワークとして、LeSS（Large Scale Scrum）やSAFe（Scaled Agile Framework）が知られています。 多くのアジャイルの本に書いてある手法は、XPやスクラムあるいはカンバンでも、一つのチームで製品をつくることが前提で描かれています。 しかし、ある程度の規模になると、複数のチームに分かれて製品開発を行うのが普通です。そうした場合、アジャイルではどのようにすすめていけばいいのかという問題にぶつかります。 またアジャイルの課題として、ウォーターフォール開発ではおなじ
はじめに こんにちは！今年4月にLITALICOに新卒入社した@mihotoyamaと申します。 LITALICO Engineers Advent Calendar 2021を盛り上げたい気持ちから、 勢い余って1日目に記事を書かせていただくことになりました。 今回は、エンジニア人生を踏み出したばかりの私がこの1年間に読んだ(+積ん読した)技術書を紹介したいと思います✨ 前提 私のバックグラウンド 医学系大学院で6年ほど研究していました。 RやPythonによるライブラリを利用したデータ解析や、シェルスクリプトでの作業の自動化はよく行っていましたが、 チームでプロダクト/サービスを開発するという経験はありませんでした。 そのため『自力で調べてなんとかする』のは慣れていても、 プログラミングの基本やセオリー、開発の工程、また情報工学についての知識がほとんどなかったため、 そのあたりは本を読
ITエンジニア（SE・社内SE・情シス）として何から勉強したらいいか分からない 現場で認められる実力を伸ばしたい！ どんな本が社内SEの勉強にオススメか知りたい といった疑問に答えます。 SE＋社内SE歴15年の経験で学んできた経験をもとに、社内SE初心者が体系的にシステム開発を学ぶのにおすすめの書籍を整理しました。システム開発の工程に沿っておすすめの本を紹介していきます。 こんな人におすすめ ・社内SE/SE初心者 ・ITエンジニアスキルを基礎から体系立てて勉強したい ・上司が何も教えてくれない ・ライバルに勝ちたい 本記事でご紹介する社内SEにおすすめ本一覧 社内SEの基礎を学ぶ 1冊目 社内SE 1年目から貢献！情シス 企画・開発・運用 107のルール 2冊目 小さな会社のIT担当者になったら読む本 3冊目 エンジニアとしての生き方 4冊目 漫画で学ぶITの基礎 5冊目 ソフトウェア
企業活動や社会全体のデジタル化に伴い、専門人材の不足が深刻になっている。デジタル人材は現状で100万人程度といわれるものの、政府は26年度までに230万人が不足すると見込む。230万人の不足は日本の労働人口6800万人を土台とし、最低限のデジタルスキルを広げていくためにいくつかの仮説に基づき推計した。 今年40歳を迎える筆者が対外的にどう見えているのか、たまにキャリアに関する相談を頂きます。が、毎回「オレに聞くな」と返します。なぜなら、筆者が抱える最大のコンプレックスは「キャリア」だからです。 部署移動が多かったのと、転職活動も職種・業界に拘っていないので、一貫性がありません。17年間の肩書を振り返ると、営業 ⇒ 開発 ⇒ データサイエンティスト ⇒ 経営企画 ⇒ R&D 兼 リサーチャー ⇒ マーケター ⇒ 事業開発 ⇒ マーケター ⇒ 現職（執行役員）…カタカナと伸ばし棒が多いのです。
はじめに こんにちは。kouです。 昨年8月1日、株式会社NoSchool に入社し、オンライン家庭教師サービス『マナリンク』の開発に本格的に携わり始めてちょうど1年が経過しました。 この1年間、マナリンクの開発に携わる中で様々な学びがありました。 今回、入社1年という区切りにこの1年間の学びを、簡単にですが並べてみようと思います。 この1年間で学んだことは多くありますが、それらを全て挙げるのはキリがない上に、記事としても読みにくいものになってしまうため、中でも学びが大きかった部分に絞って紹介します（今回は主に設計とテスト周りについて取り上げています）。 自己紹介 本題に入る前に軽めの自己紹介をしておきます。 kouという名前で活動しています。 2021年の7月からエンジニアとして働き始め、現在でエンジニア歴2年程度です。 昨年8月、NoSchool入社時点での設計・テスト周りに関するレベ
IPAデジタルスキル標準.pdf
All Rights Reserved Copyright© IPA 2023 デジタルスキル標準 ver.1.１ 2023年8月 All Rights Reserved Copyright© IPA 2023 1 目次 I. デジタルスキル標準の概要 ⚫ デジタルスキル標準策定の背景、ねらい ⚫ デジタルスキル標準 改訂の考え方 ⚫ デジタルスキル標準の構成 ⚫ デジタルスキル標準で対象とする人材 ⚫ デジタルスキル標準の汎用性 ⚫ デジタルスキル標準の活用イメージ II. DXリテラシー標準 1. DXリテラシー標準策定のねらい、策定方針 2. DXリテラシー標準の構成 3. スキル・学習項目 a. 概要 b. 詳細 4. DXリテラシー標準の活用イメージ III. DX推進スキル標準 1. DX推進スキル標準策定のねらい、策定方針 2. DX推進スキル標準の構成 3. 人材類型・ロー
背景 事業規模の拡大に伴いオフィスの移転がありました。それに伴い社内ネットワークインフラの構築を行いました。 中小ベンチャーのネットワーク構築の記事は5年前の@wadapさんの記事が詳しいです。まぁ、5年前なので細かいアップデートが色々あるので記事にしておきます。 要求定義 ゲスト用ネットワークの分離（インターネット回線、LAN回線） 将来のシステム監査で指摘されるであろうことなので。 トラフィックのQoS制御のため。 役割（部署）毎にLANの分離 ウィルス感染した場合に被害を減らすため。 重要情報を扱うエンジニアのネットワークを守るため。 安定 ストリーミングを扱うプロダクトを扱っているので安定性を高める。 特にWiFiは安定してほしい。 WiFiと有線を用意してL1レイヤの冗長性を確保しておく。 低レイテンシー 初期費用、固定費は安く。 20人ぐらい (平均3台/人で計算して60端末同
はじめに イオンスマートテクノロジー株式会社（通称AST）のCTO室TechLeadチームの@t0doroki_takaです。 本記事の内容は、上記の書籍で紹介されている手法を自分の解釈で整理・アレンジしたものです。 計画段階から完成形を定義して、全体の開発工数・工期を見積もって年単位で開発を進めるプロダクトは、アジャイルという考え方の無かったウォーターフォール・モデル時代の考え方なのかもしれません。とはいえ、業務システム開発においては、プロジェクト開始直後からアジャイル開発することは難しく、このような見積もりは欠かせないと思います。 なぜなら、多くの業務システムは、出来る限り早く市場に投入してフィードバックを得てピボットする性質のサービスではなく、予め要件・機能を定義してステークホルダーとの合意形成が不可欠です。アジャイル的な開発を導入するにしても、事前に全体規模の把握は必要です。その際
DXの具体的実務：AI活用に向けたデータ基盤の構築
コンサルティング会社やスタートアップのIT系事業会社を経て、2022年12月に株式会社cross-X（https://crossx-10-tf.com/）を創業し、現職。コンサルティング会社在籍時にはパートナーとしてデータ・AI戦略プロジェクトの統括を担い、日系大手企業を中心にデジタル・DX戦略を推進。IT系事業会社在籍時には執行役員・本部長等として経営・事業マネジメントや東証マザーズ上場、資金調達を経験。現在は創業したcross-Xで、大企業のDX推進アドバイザリーやDX人材の育成支援等を担う。京都大学法学部卒業。著書に『DXの実務――戦略と技術をつなぐノウハウと企画から実装までのロードマップ』（英治出版、2022年） DXの進化 【DXの進化】 DX（デジタルトランスフォーメーション）、すなわち、「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニー
新人Webディレクター必見！要件定義とは
更新日: 2017年3月21日公開日: 2016年10月27日新人Webディレクター必見！要件定義とは Web ディレクターにとって必須工程となる要件定義。 なんだか面倒くさそう、難しそう、と思って後回しにされていませんか？ 自己防衛の意味でも 要件定義 は重要なファクターとなりますので、頑張って基礎知識だけでも習得しておきましょう！ 新人Webディレクター必見！要件定義とは要件定義とは img:IPA 要件定義とは、Web サイトやアプリケーションなどの開発初期段階において、発注者と受注者の情報共有のために、実装すべき機能や満たずべき性能を第３者でも分かるように明確化しておく作業のことです。 要件定義は、Web サイトやアプリ開発において非常に重要な役割を担っていて、要件定義のでき次第で開発の成功が左右されるとも言われています。 一般的に要件定義の主導権は受注側（開発側）のディレクターが
課題 開発中に生じるエラーメッセージや命名のために英単語を調べたい時に、わざわざブラウザで翻訳するのが面倒くさい。 解決方法 PhpStormのプラグインであるTranslationを用いて、DeepL APIと接続することでエディタ上から翻訳が可能になります。ちなみに無料です。 Translationプラグインをインストールする。 再起動すると、環境設定→ツール→翻訳を開く。そして、翻訳エンジンにDeepL翻訳を選択する。そして、構成から③で取得する認証キーを入力する。 3.DeepL API FREEにアカウント登録をして、認証キーを取得する。登録後、アカウントタブにDeepL APIで使用できる認証キーが表示されます。 ※私はアカウント作成後、認証キーが機能するまで少しタイムラグがありました。５分程経過してから、PhpStormと接続するのがおすすめです。 4.右上に文Aのアイコンが
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BD, UT, IT, ST, UATとは？ウォーターフォールモデル型のシステム開発における各工程・各段階の用語の意味
【AI&システム開発系】おすすめAdventCalendarと記事まとめ（19年12月前半編） - Qiita
リクルートのUX組織の特徴（ナレシェア近日公開！） | Recruit Tech Blog
請求管理ロボにおける開発の進め方 - ROBOT PAYMENT TECH-BLOG
ソフトウェアテストについていろいろ調べたことを書いた記事 - Qiita
IT化の上流工程における「要求定義と要件定義の違い」とは？
ReactでYouTube埋め込むとLighthouseスコア低下する問題の改善手法まとめ
Raptor Lakeの開発を半年短縮できたのはイスラエルチームのおかげ？ インテルCPUロードマップ (1/3)
MBSE、プロダクトライン開発を実践し要求を正しく満たすソフトウェアをスピード感をもって実装できる体制を整備 | gihyo.jp
PlantUMLを通じてシーケンス図の描き方を学ぶ - EurekaMoments
初めての個人開発に没頭していたら、リリースした頃には大学を卒業していました
要求定義│要件定義との違いや品質を高める進め方・書き方まで網羅的に解説
SIerがAgile開発を始めるための課題と対策 - ビジネス中学
[筋トレのすゝめ] プログラミングばっかりしていて、運動不足のエンジニアを撲滅したい
【2024年】ITエンジニア本大賞まとめ - Qiita
“DXの本質”から考える ワークフローと人材育成のベストプラクティスとは？
要望、要求、要件の違いとか、基本設計、詳細設計の違いで迷わないようにするためのまとめ - Qiita
プロダクトリーダーが周囲から信頼を得て成果を出すための6つの問題領域と解消法
技術レポート「内部設計書に書くべきこと～組込みソフト開発の場合～」｜ソフテックだより｜株式会社ソフテック
とあるカスタマーサクセスの失敗目録【Customer Failure】｜やすまさ🎨パパゲーノ
「エンタープライズ・アジャイル」LeSSとSAFeどちらを選択すべきか。その違いと比較。 – BlueLogic
今年入社の新卒エンジニアがこの一年間に読んだ技術書15冊を紹介する - Qiita
社内SEの勉強におすすめ！システム開発が学べる本22冊【厳選】
1年がかりでMOpsなチームに変わったので、やったこと・気付いたことを書く｜松本健太郎
【振り返り】実務経験1年のエンジニアがスタートアップに入社して設計/テスト周りで伸びたこと
小規模（5〜20人）ベンチャーオフィスのネットワーク構築例
見積りは科学であり、ソフトウェア開発は不確実性との戦い
PhpStormを使ってるのに、わざわざ未だにブラウザでDeepL翻訳してるってマジ？