私は新卒のときから10年ほどIT業界、ときには会社を移りながらエンタープライズのSI（System Integration）のさまざまな現場で働いてきましたが、システム開発のチーム編成として「アプリケーション担当」と「インフラ担当」に分かれていることが長らく当たり前でした。 最近はAWSをはじめとするパブリッククラウドの台頭、特に抽象度の高いマネージドサービスの普及によって従来型の分業モデルが理に叶わなくなってきたのでは？と感じることが増えたので、ポエムを書いてみます。 みなさんの案件はどんなチーム分けですか？ 私がよくいた「エンタープライズの業務システム開発」はこんなフォーメーションが多かったです。 とある社内向けWebシステムの開発体制 ユーザー企業（発注元の会社スタッフ） アプリケーション担当：通称「業務」。要求定義と仕様調整。事業会社だとコードレビューまではしないところが多い印象
ソフトウェアの開発者・テスト技術者・品質管理／品質保証の担当者の方へJSTQBからの情報を届ける「JSTQB カンファレンス in 2022 Autumn」。ここで五味氏が「DXに求められるソフトウェア品質とその計測」をテーマに登壇。ここからは、組み込みシステム産業・IoT産業のDXに関する動向変化について話します。前回はこちらから。 1,108社に聞いたDXの取り組みの経年変化 五味弘氏：ということで1番目が終わりました。3番目は軽くしようと思っているので、次に2番目のネタです。 （スライドを示して）ここは分野が組込み動向調査、つまり組込みソフトウェア、組込みシステムに特化しています。IoT産業も含んでいますが、そこにおけるDX・ソフトウェア開発の関係を、これも統計を使って調べたので報告したいと思っています。 下に書いてありますもので検索してもらえれば私たちのものが見つかるので、ぜひやっ
DXも業務改革も、まずは企画を作り、社内の承認を得る必要があります。しかし、企画を作る・社内に通すこと自体が難しく、そもそも変革を始められない、無理に通して変革を始めたが社内が大混乱して中止になったというケースも。そこでケンブリッジ・テクノロジー・パートナーズ株式会社が、企画の作り方・通し方のノウハウをまとめたセミナーを開催しました。決裁者に怒られる、プロジェクトが「浅い」と一蹴される……といった、企画書づくりでつまずきがちなNGパターンを解説します。 DXプロジェクトを始める「最初の一歩」をどう作るか 榊巻亮氏（以下、榊巻）：みなさん、こんにちは。今日は「企画の作り方、通し方」というセミナーを行っていきます。始める前に、声のトーンが大丈夫かとか、できればチャットに書き込みしていただけるととてもありがたいです。「いいね」を飛ばしてくださるの、非常に助かります。ありがとうございます。 感想も
Devin を含むAIソフトウェアエンジニアと周辺技術のざっくり紹介 - Algomatic Tech Blog
こんにちは。LLM STUDIO 機械学習エンジニアの宮脇（@catshun_）です。 本記事では最近注目を集めている AI ソフトウェアエンジニアに関するプロダクトについてざっくりと紹介します。 社内勉強会に向けたキャッチアップ資料として作成しており、加筆修正する可能性がありますが、本記事を読んだ方の議論のネタ程度になってくれれば幸いです。 おことわり 本記事では AI ソフトウェアエンジニアに関する 詳細な解説は含みません。 Devin を参考に AI ソフトウェアエンジニアと呼称していますが、主語が大きく曖昧性の高い表現を使用しています。詳細については 参照元をご確認ください。 不十分また不適切な言及内容がございましたらご指摘いただけますと幸いです。 プロダクト等の利用時は 必ずライセンスや利用規約を参照して下さい。 本記事の目次 プログラム生成を伴う推論 Self-Refine (
スクラムマスターを兼任して見えてきた、シフトレフトのための立ち回りとやってきたQAの活動 - freee Developers Hub
こんにちは。決済プロダクトでQA兼スクラムマスターをしているbarusです。 本日はfreee QA Advent Calendar2023 7日目です。 adventar.org 今回は「スクラムマスターを兼任して見えてきた、シフトレフトのための立ち回りとやってきたQAの活動」と題してお話させていただきます。 freeeカードUnlimitedの立ち上げ期から現在に至るまで、各チームを転々としながら、いずれもスクラムチームの一員としてアジャイルQAを行ってきました。 今年の9月からスクラムマスターを兼任しながら、日々品質とスピードの両立に取り組んでいます。 本記事ではスクラムマスターを兼任して見えてきた視点を交えながら、より早期にシフトレフトをしていくためにQAがどのように立ち回るべきか、そして実際に自分たちのチームがやってきたことをお話しようと思います。 ここではQAプロセスの最適化と
アソビュー！初のネイティブアプリリリース。機能設計でデザイナーが取り組んだ4つのこと - asoview! Tech Blog
こんにちは！デザインリードを担当している山中です。 ついにアソビュー！のネイティブアプリがリリースされました！ 私が入社（2019年の夏ごろ）してから、アプリをつくりましょう、という話は何度もでて、途中まで開発しいたもののコロナの影響で業績が低迷、アプリの開発どころではなくなり、他の開発の優先度が高くなり、アプリの開発がずっと止まっていましたが、業績がV字回復し資金調達により採用に力を入れたことで開発メンバーも増え、やれることが増えてきたので、アプリ開発が再開でき、ついにファーストリリース！ ようやくです！私もだいぶ待ちましたが、アソビュー！をご利用の皆さん、お待たせしました！そして、週末なにしよう！？と考えてしまう前に、ぜひダウンロードしておでかけ先を探してみてください！ アプリダウンロードURL iOS アソビュー！:遊び先の検索・予約 on the App Store Andr
近年、機械学習（ML）やディープラーニング（DL）といったAI関連技術をプロダクトへ応用し、新たな価値を生みだそうという動きが加速しています。その中で、従来の「DevOps」の考え方を、機械学習向けに発展させた「MLOps」という新しい概念が生まれ、注目を浴びています。MLOpsが注目される背景には、どのような課題があるのか。そして、実際に現場でMLOpsに携わる人々は、何を目指し、どんな取り組みを行っているのか。ヤフーとLaunchableで、それぞれMLOpsをリードしている2人のエンジニアに語っていただきました。 機械学習システムの普及を契機に関心が高まる「MLOps」 黒松：ヤフーの黒松です。私は大学時代に、ビッグデータを研究テーマにしており、OSSとして当時注目されていたHadoopなどを扱っていました。卒業後は富士通研究所に入り、基盤研究の一環として、機械学習のための基盤を作り
はじめに HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしている輿水です。 私たちのチームには、プロダクト開発を進める上で次のような課題がありました。 プロダクトオーナー（以下、PO）の業務が多岐にわたり、ドキュメントの更新が大きな負担となっていた 要件や仕様について最新の情報を把握することが難しく、ステークホルダー間でのコミュニケーションコストが増大していた これらを解決するため、私たちのチームは「エピック主管」という仕組みを導入しました。これは、エンジニアがリードしてドキュメント管理を行い、プロジェクトマネジメントの役割も果たすことで、POやエンジニアリングマネージャー（以下、EM）の業務負担を削減するものです。 本記事では、エピック主管とは何か、そしてその役割や成果について深く掘り下げて紹介します。 この記事では、プロダクト開発において
「運用でカバー」を増やさないための対策 向井毅男氏（以下、向井）：というところで、運用でカバー（すること）はよくある話です。カウシェさんでも、やはり運用でカバー（すること）を前提に仕様を決められたアンチパターンがあったと聞いています。池松さんにそのあたりを紹介してもらってもよいですかね。 近藤優輝氏（以下、近藤）：池松さんが固まってしまったかもしれない。 向井：固まっちゃいましたね。まぁ、オンラインあるあるですね。 見ている方、なんでもけっこうです。気になること、些細なことでもけっこうなので、ぜひ質問とかコメントとかもらえればと。あっ、池松さん動きましたかね。たぶんミュートになっているので。 池松恭平氏（以下、池松）：すみません。聞こえていますか（笑）？ 向井：大丈夫です。じゃあ、あるあるパターンの、運用でカバーのアンチパターンをお願いします。 池松：わかりました。「運用でカバーできれば良
本当に｢上流階級｣が民主主義を支配しているのか
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
チームでやっている ZenHub x Scrapbox を使ったフルリモートなアジャイル開発の紹介 - Money Forward Developers Blog
こんにちは！ マネーフォワード クラウド横断本部のWebエンジニアの はるやま (@linnefromice) です。 現在クラウド横断本部で行っている既存サービスのリプレイスプロジェクトにおける開発チームでの開発プロセスの紹介をさせていただきたいと思います！ 背景 プロジェクト発足当時は2人だったのですが、現在5人にまでメンバーが増え、そのうちの1人は海外居住者なので現在入国できておらずフルリモートで参画しています。海外居住者でないメンバーに関しては最低週1出社としていて、チームとしてはほとんどがリモートでの勤務がベースになっています。 (当たり前なことではあるのですが、)途中参画したメンバーはそれまでの経緯や意思決定をキャッチアップも必要ですし、初期メンバーはそれに対するフォローだったり、メンバー同士の相談などもなるべく低コストでスムーズにしたいです。 上記のような背景があり、仮にフル
これから実例マッピングを使おうと思っている人へお伝えしたい日本語情報のリンク集 - ブロッコリーのブログ
はじめに〜本記事の目的〜 2020年の4月に実例マッピングを日本語訳で紹介してから3年弱で、色々な人が実例マッピングを試しています。 本記事では、これから実例マッピングを試そうとしている人向けに、実例マッピングに関する日本語情報を提供することを目的としています。 目次 はじめに〜本記事の目的〜 目次 実例マッピングとは何か 考案者による実例マッピングの説明記事 実例マッピングの説明スライド 実例マッピングの説明記事 実例マッピングについて言及している書籍 The BDD Books - Discovery Agile Testing Condensed 実例マッピングの実践報告 アルプ株式会社様 実践報告スライド 株式会社リンクアンドモチベーション様 伊藤忠テクノソリューションズ株式会社様 株式会社サーバーワークス様 aki.mさん 株式会社永和システムマネジメント様 実例マッピングを利用
はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 要件定義フェーズの新しい案件に入る予定です。過去何回か対応したものの、対応手順や内容、要件定義に関わる用語について上手く言語化出来ない箇所があったため、振り返り兼ねて整理してみました。 要件定義とは 要件定義は、システム開発の初期段階で、ユーザーの要求やニーズを具体的な開発内容に落とし込む工程です。要求定義がユーザー視点で 「何を必要とするか」 を定義するのに対し、要件定義は開発者の視点から 「どのように実現するか」 を明確にします。このプロセスでは、システムの機能や性能、利用する技術などを具体的に定め、ステークホルダーと合意形成を行います。 プロジェクトの目的やゴールを明確にし、開発範囲や実装すべき機能を確定するため
Tebiki社でQAエンジニアをしている中西です。 多くのテストエンジニアやQAエンジニアは、ユーザー目線でのテスト経験があるかと思います。プロダクトのユーザーとプロダクトの使われ方を想定して、テスト対象がユーザーのニーズにマッチしているかを確認しているのではないでしょうか。 Tebiki社では、「ユーザの行動が全て」というValueがあり、開発チームはプロダクトライフサイクルを通して、このバリューを体現することが求められています。つまり、ユーザー目線でテストすることに加えて、ユーザー行動に基づきテストすることが求められているのです。 本記事では、ユーザー目線でのテストとユーザー行動に基づくテストの違いを明らかにし、それらのテストを行うための取り組みを紹介します。この記事がユーザー行動にフォーカスしたテストプロセスの改善のきっかけになれば幸いです。 ユーザー目線でのテストとは本記事では、「
お客様のビジネスは、かつてないスピード感で変革を続けていくことが求められています。同様に品質に対する要求も大きくなり、その一方で技術要素は常に新しいものに対応していかなければならないなど、三重苦に陥っているお客様も非常に多くなっています。そのような状況だからこそ、コスト・工期を抑えつつ、品質を確保することができれば、「Speed To Market」も実現でき、他社への差別化を図ることができます。我々はそのような変革への支援・実現を担っています。 また、QE&Aはお客様に変革をもたらすだけでなく、アクセンチュア全体の品質向上の実現を推進しています。様々な領域に特化したエンジニア、アーキテクト、システムコンサルタント、そして多くのグローバルタレントがコラボレーションし、最大限活躍できる場を提供していきたいと考えています。 組織概要 品質の作りこみ(Quality Engineering)
CTOが聞く Vol.5 fluct 笹本 & 尾池「顧客から圧倒的に信頼されるプロダクトをつくるために取り組んでいるfluctのエンジニアに話を聞いてみた」 - CARTA TECH BLOG
CARTA HOLDINGSで働くエンジニアたちにCTOが「最近なにやってるの？」をざっくばらんに聞いていくシリーズです。今回はCARTA HOLDINGS CTOのすずけんが、事業子会社の一つであるfluctのCREチームの話を聞きました。「fluct」についてはこちら インタビュアー：鈴木健太 Twitter ID @suzu_v（写真右） 株式会社CARTA HOLDINGS 執行役員CTO / 株式会社fluct取締役CTO。社内では「すずけん」と呼ばれる。「みんなのGo言語」「データ分析基盤入門」共著者。ウェブ技術全般に明るい。ポッドキャスト「ajitofm」をやっています。 インタビュイー：笹本将平（写真中央） 株式会社CARTA HOLDINGS / 株式会社fluctCREチームリーダー社内だと「さっさー(saxsir)」とか「さっさーさん」と呼ばれている。2016年に新卒
生成AI（人工知能）をシステム構築に活用する取り組みが進んできた。ソースコードの自動生成やテストの効率化、運用自動化などカバー範囲は広く、省力化や品質向上といった成果を上げている。今回はNTTデータの取り組みを見よう。 前回の記事 AWS・MS・Googleが生成AIでシステム構築支援、ソフト開発全般で効率化競う 「長年にわたって生成AIを研究しており、AIガバナンスを徹底しながら、積極的に活用を推進していく」。NTTデータグループ 技術革新統括本部システム技術本部ADM技術部ADM担当EGMグループの村上功修部長は、NTTデータの生成AIへの取り組み姿勢をこう述べる。 同社が生成AIをシステム構築へ適用するに当たって指針は大きく2つある。1つは開発者が不足している領域への適用、もう1つはソフトウエア開発領域全般への拡大である。要求定義から設計、開発、テストなどの工程について、「Azure
CTOの名人です。 マナリンクでのPAY.JPの活用を題材に、クレジットカードによるサブスク実装をするときの全体感について解説します。 これまでサブスク課金を実装したことがなかったけど、これから実装することがあるかもといった方や、サブスク課金特有の罠について知りたい方に読んで頂きたいです。 主に以下のテーマについて説明していきます。 カード情報をトークン化して決済処理 2回目以降の課金成功をWebhookで検知して通知処理 2回目以降の課金での失敗をWebhookで検知して通知処理 ユーザーがいつでもサブスクを停止、再開できる機能 カード情報をトークン化して決済処理 大前提として、クレジットカードによる決済処理を実装する際は、自社のサーバーをユーザーのクレジットカード番号が通過しないように実装する必要があります。 上記記事から、以下のように、カード番号を非通過にすることが求められていること
事業組織全体で取り組むドメインモデリングのすすめ
sumirenです。 経営管理（事業計画作成、財務Modeling）SaaS「Zaimo.ai」を開発するZaimo株式会社で、技術顧問としてドメインモデリングや組織設計のアドバイザリを行っています。 Zaimo.aiでは、スケール後もドメインモデリングを事業全体で活用できるよう、創業間もないフェーズからドメインモデリングを組織的に活用するカルチャーづくりに励んでいます。 ドメインモデリングというと、DDDのような重厚なプロセスを想像される方が多いかと思います。同時に、技術が目的と化している熱狂的DDDファンも少なくないことから、ドメインモデルというワード自体に拒否反応を覚える方もいると思います。 しかし、ドメインモデリングはもっと手軽に使えるものであり、エンジニアリングのみならず、事業全体にインパクトをもたらしうるものと筆者は考えています。この記事では、そうしたドメインモデリングに関する
これこそ「三度目の正直」だと思うぞ。何の話かというと、生成AI（人工知能）がもたらすIT業界のディスラプション（破壊）の件だ。「ははーん、木村はまた人月商売のIT業界をディスるつもりだな」と思う読者もいるかと思うが、まさにその通りだ。少なくとも人月商売のIT業界の下請けITベンダーは、せいぜいあと3年から5年の命だ。人月商売の親玉であるSIerも大規模なリストラに追われることになるだろう。ただし、その破壊的な影響はもっと広範なものだ。全く想定外の悪夢が現実になるかもしれない。 生成AIがもたらすIT業界のディスラプションは、技術者なら誰もが先刻ご承知のはずだ。要するに、生成AIはいわゆる「知的労働者」の仕事を片っ端から奪っていくが、生成AIが「死に神」よろしく最初にその鎌を振るうのが人月商売のIT業界の技術者である、との予測だ。いや予測というよりも、確定した近未来の惨劇と言ったほうがよいな
システム開発などの現場で必須となる要件定義。当たり前のように使っている言葉ではあるものの、要件定義書の記載事項や具体的な要件定義の進め方についてあらためて問われると、返答に困ってしまうという人も多いのではないでしょうか。 今回は、要件定義の概要や要件定義書に記載すべき項目、要件定義を進める際の基本的な流れについて解説します。要件定義を適切に行うために必要なスキルにも触れていますので、ぜひ参考にしてください。 はじめに、要件定義に関する基本的な知識を整理しておきましょう。「要件」と「要求」の違いや、要件定義と仕様書の違いを押さえておくことが大切です。 要件定義の位置づけ 要件定義とは、開発者の視点で発注者の要求をまとめ、解決するための具体的な方法を決めることを指します。何をどうシステム化するのか、ドキュメント形式で可視化することが要件定義のゴールと捉えてください。 さまざまな開発プロジェクト
はじめにTIG DXユニット 1 真野です。元々バックエンド開発を中心にしていますが、ここ3,4年でいくつかのユーザーストーリーマッピング作成に関わるなど、プロダクトオーナー的な視点も求められることが増えてきました。 アジャイルで仮説検証を繰り返しながらソフトウェア開発を行っていると、全体感が見えにくくなることが多々あるかと思います。特に開発タスクをプロダクトバックログのチケットで管理していると、そのチケットの背景にあたる、その機能が、「だれが」「どういったユースケースで使用して」「何を解決するか」といった認識が薄くなりがちです。 そんな時にユーザーストーリーマップがあると、全体像の認識をチーム全体で共有できて便利です。ユーザーストーリーマップは視覚的にわかりやすく、特殊な構造もしていないため共通理解しやすいことがポイントです。 また、ユーザーストーリーマップはこれから何を作ろうかという要
前提として、カミナシが目指しているエンジニアリング組織の形について、CTOとして以下の三つの原則をブログ記事で明示しました。 すべてはオーナーシップ 開発チーム自身がシステムを運用する SRE、QA、プラットフォームの類を安易にチーム化しない この三つの原則は、価値ある製品を顧客に届けるためには開発チーム自身のオーナーシップが不可欠であり、そのためには各チームが自らのシステムを運用する重要性、そしてSREやQAなどを単独のチームに分けないことを示しています。 チーム化の理想としては、以下の三点が挙げられます。 フォーカスによる専門領域のExecution Level 深化 チームごとの役割分担による組織全体のExecution Level 深化 希少な人的リソースの「基盤」化 各個人が専門領域にフォーカスすることでExecution Levelを高め、チームが役割を分担することで組織全体の
![[t_wada氏×カミナシTori氏]ソフトウェアエンジニアと品質保証 SRE、QAの枠にとらわれない新しい視点 | Offers Magazine](https://cdn-ak-scissors.b.st-hatena.com/image/square/22d449c58c1eb5d9e28ee9350a10c50da3956732/height=288;version=1;width=512/https%3A%2F%2Fs3-ap-northeast-1.amazonaws.com%2Fassets.offers.jp%2Fmedia%2Fwp-content%2Fuploads%2F2023%2F12%2F27105156%2Freport_quality_assurance.png)
1on1の面談では何を重視しているか 広木大地（以下、広木）：それでは、会場の質問です。評価の話は今していただいたんですが、「1on1って何を話しますか」という質問が来ていますが、EMのほうで1on1の話ってしていましたっけ。 曾川景介氏（以下、曾川）：EMの人がたまにエンジニアとしたりしますが、私はそれなりにしています。ときに私がやりたいことや好きなことを話しているときもありますね、事実として（笑）。 （会場笑） でも、結局その人が解決できない問題があるときに、それを一緒に解決するための時間だと思うので。そういうイシューなど、もちろんそれは会社のイシューでもいいし、個人として「こういうことに悩んでますよ」というのがあるんだったらそれを目標にします。とはいえ毎回毎回、そんなにきれいに悩みがあるわけでもないので「こういうもの作りたいよね」といった話をしているときもあります（笑）。 広木：なる
バルテス・ホールディングス株式会社の小島氏は、自身が社内キャリアカウンセラーとして受けてきた相談から、年代別キャリアのよくある悩みと、その悩みを解決するための対策と、キャリア開発の基本ステップについて紹介します。全2回。 自律的・主体的なキャリア形成ができている人は50パーセント 小島友美氏：キャリアに関する悩みがわかったところで、次にキャリア開発の考え方について紹介していきたいと思います。 昨今では“自律的キャリア”と言われますが、2004年ぐらいに文科省から、キャリア教育の推進に関わる報告書が出されました。 それに基づいて小学校、中学校でもキャリア教育が本格的に始動し始めたので、若手は意外と中学、高校、大学でキャリア教育を受けてきているわけですね。なので、自律的・主体的なキャリア形成の意識はわりと醸成されてきているのかなと思います。 ただ一方で、自律的・主体的なキャリア形成ができている
Railsでサービス立ち上げる際の相棒にChatGPT ChatGPTがウェブサービスを開発する上で有用な点をまとめてみました。 全てにおいて共通する考え方ですが あのGemを使って、こんなカラムを持ってるテーブルだから、こうしてああすれば、完成する これ、汚いコードで本当はもっと綺麗に書けるよなー という ”理想” を描く必要はあります しかし、今までは Google検索 で知識を補完し、自分でその状態に持っていっていましたが Google検索 より ChatGPT の方がより早く理想の状態に持っていけるというのが体感値です。 ChatGPTの回答がベストプラクティスかどうかを判断するのは個人の責任です そのプロジェクト、クラス、メソッドにおいてそれが”良い”かどうかを判断する必要はありそうです。 AIが作ったコードを本採用するの？ よければそのまま採用してます しかし、AIが作ったコー
【UXデザイン】「構造化シナリオ」手法による要求／要件定義の進め方 #uxtryout - log4ketancho
サービスデザインをする際に、「不の調査結果」を「ソリューション」に落とし込んでいく必要があります。要求定義から要件定義へのフェーズです。このフェーズのアウトプットを出す際に「構造化シナリオ」という手法があるそうです。今回はその勉強会に「ブログ書く枠」で参加させていただいたので、レポートしていきたいと思います。 www.street-academy.com 座学 構造化シナリオとは何か シナリオ手法の一種で、理想シナリオを「短編小説風」に記載したもの。*1 価値シナリオ そのプロダクトを使って得られる価値を、簡潔に記載する 行動シナリオ 操作シナリオ 取扱説明書のような文章の粒度 の３つから構成され、徐々に詳細化していく。 構造化シナリオのメリット プロダクト／サービスのイメージをチーム全員で共有できる 短期間に作成し、そのレビューによって、妥当性の評価を行うことができる 構造化されることに
21世紀の格差社会には「上流社会」がない...19世紀ウィーン富裕層の研究から現代が学べること
＜先進国における所得格差は20世紀には大幅に縮小したが、今世紀になって再拡大していることは周知のとおり。私たちが過去から学べることは何か＞ 人類の歴史上つねに存在してきた所得格差は、20世紀の先進国で驚くほど縮小した。 自由主義や資本主義に基づく経済成長と、民主的な福祉国家による所得再配分によって、社会全体が共に豊かになるという理想が、一時は実現するかに見えていたのだ。 だが以前ピケティの著書『21世紀の資本』で広く知られたように、経済成長の鈍化･停滞や新自由主義を背景に、21世紀に入る頃から格差は再拡大しつつある。 今までの先達の努力は何だったのか。彼らの敷いてきた路線をどう継承すべきか。このままでは世界はどんな様相を呈するか。あるいは再び過去に逆戻りか。 このように私たちは経済史上の現在地を測り直し、将来像を描き直す必要にいま迫られている。 前近代から続く格差が縮小し始めたのは第一次大
ソフトウェア設計とは何か - Qiita
はじめに 本稿の目的と構成 ソフトウェアの設計に悩んでいる駆け出しエンジニア〜中堅エンジニアを対象に、世の中にある様々な設計手法をまとめ、それらをどう活用したらよいかを伝えたいと思って書き始めましたが、思った以上に長文になってしまいました。 本稿は以下の構成となっています。 設計の定義 様々な設計モデル ジャストインタイムの設計活動 誰のための、何のための設計か 参考文献 長文はすっ飛ばして、参考文献に挙げた書籍やWebページの中で興味のあるものを読んで頂くのもよいです。いずれも良書ばかりです。 筆者のバックグラウンド いわゆるSIerに勤めています。 以前は中〜大規模の受託SI案件にアーキテクトとして参画し、アーキテクチャ設計や開発標準化などを主に担当していました。もちろんウォーターフォール開発です。 現在は自社パッケージ製品の開発をリードする立場です。アジャイル開発をベースとしています
「【SmartHR/カケハシ/リクルート】複雑化する開発体制におけるエンジニアの社内巻き込み術 ‐プロダクト成長をリードするエンジニアたちの試行錯誤‐」は、成長プロダクトの開発をリードするエンジニアたちの試行錯誤に触れ、社内巻き込み術や改善のステップなどのノウハウを紹介するイベントです。ここで株式会社SmartHRの大谷氏が登壇。チーム人数の増加によって生まれた課題と、その課題にどう対処したかを紹介します。 みなさんはこういった経験をしたことがありますか？ 大谷洋生氏：では僕の発表を始めようかなと思います。「エンジニア主導の仕様検討：はじめの一歩を踏み出す」というタイトルで、話をさせていただきたいと思います。よろしくお願いします。 まず自己紹介ですね。SmartHRから来ました。エンジニアをしています。大谷と言います。ふだんはRailsを書いたりReactを書いたり、あとはFlutterを
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
図解入門 よくわかる最新システム開発者のための仕様書の基本と仕組み[第3版] | 智明, 増田 |本 | 通販 | Amazon より、要点、キーワードをメモしたもの。 システム開発全体の流れ とは プロジェクトの流れ 時間軸 要求定義 要件定義 設計工程 外部設計 内部設計 検証 実装工程 試験工程 納入 マイルストーン 成果物の流れ 要件定義での成果物 設計工程・検証での成果物 実装工程での成果物 試験工程での成果物 それぞれの工程を結びつける成果物 情報の流れ 要求定義・提案書 要件定義 基本設計 外部設計 内部設計 実装工程 試験工程 サンプル Markdownで表現すると以下のようになる。 ## はじめに 要求定義の前置きを書く。 ## システム構築の目的 - システム構築をする際の目的 ## システム構築の制限事項 - システム構築をする際の制限事項を記述する。 - 移行プロジ
ビビッドガーデンとベルフェイスのコラボイベント「脱ビルドトラップ toB/toCそれぞれのプロダクトマネジメント」。事例発表とパネルディスカッションを通して、各社が取り組むプロダクトマネジメントの手法と、いわゆるビルドトラップ状態を脱したプロセスなどの実例を話しました。ベルフェイス株式会社より登壇したのは、プロダクトマネージャーの吉本氏。同社が脱ビルドトラップのために取り組んだ施策について話しました。 ビジネスサイド出身のプロダクトマネージャー 吉本猛氏：では、私から発表します。よろしくお願いします。「ベルフェイスが脱ビルドトラップのためにやってきた3つのこと」というタイトルで話します。 （スライドを示して）簡単に自己紹介します。吉本と申します。今、Product GroupのSales Communications Product Divisionの商談アプリケーションのTeam Man
技術広報のyayawowoです。 突然ですが、システム開発を行う中で お客様からの要求/要件漏れが発生し、スケジュール遅延が発生した経験はございますか？ （私は過去、苦労した経験があります…。） システム開発を着実に成功させるためには、お客様の要求/要件をしっかりと引き出した上で分かりやすく成果物としてまとめることが大切です。 その大事な工程となるのが要件定義です。 本記事では、要件定義の概要・進め方だけでなく、重要ワード/ポイント、求められるスキルについてご紹介します。 要件定義とは？ 要件定義の進め方 1. ユーザー要求をヒアリング 2. 要求の深堀 3. 要件定義書の作成 重要ワードとポイント 業務要件 システム要件 機能要件 非機能要件 求められる4つのスキル コミュニケーションスキル 資料作成スキル 分析スキル スケジュール管理スキル おすすめ書籍をご紹介！ 要件定義 まとめ ◆
開発のサイクルタイム分析機能のリリース&活用方法
現状、大きくはこの3つの機能で現状は構成されています。 「開発組織の生産性を最大化する」と一言で言っても、どのレイヤーの視点で見るかによって得られるインサイトが異なります。このレイヤー・プロセスの現状を把握し、解決すべき課題・ボトルネックを発見、その後のアクションに繋げられるように機能を整えていっています。 サイクルタイム分析とは何か サイクルタイムの定義 サイクルタイムとは、開発プロセスにおいて、特定の段階から次の段階までの所要時間のことを指します。 この時間は、作業が実際に開始されてから完了するまでの期間を示し、効率性と生産性の指標として使用されます。 Offers MGRにおける開発プロセスのサイクルタイムの計算方法・表示 Offers MGRにおいて、サイクルタイムはいくつかの開発プロセスの主要なフェーズに分けて測定することができます。（要求定義、デザインなどを含めた開発のフルファ
要件定義とは？進め方やポイント、必要なスキルをわかりやすく解説 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
要件定義とはプロジェクト開始前に必要な機能などをまとめる作業です。要求・要件定義、そしてプログラミングからテストを経てようやくシステム運用に至ります。今回は要件定義の基礎知識から決定までの流れ、要件定義を成功させるポイントを分かりやすく解説します。 要求をまとめ、進め方を決める システム開発を行う上で「何をどうシステム化するのか」を決めるのが要件定義です。 まずはクライアントの要求を細かくヒアリングし、その要求を実現するために実装する機能や性能を決め、具体的な開発工程を設計するのがプロジェクトにおける一番最初のフェーズです。 ゴール設定と方向性の決定は、プロジェクトの成功を左右する大きな要因です。 要件定義はシステム開発における上流工程に位置します。 要件定義と要求定義の違い 要求定義は、要件定義のベースとなるクライアントの要求をまとめたものです。 クライアントにとってシステムによって実現
ウォーターフォールモデル (Waterfall Model)とは まず、ウォーターフォールモデルについて。 これは読んで字のごとし、滝の流れ (ウォーターフォール) のように流れに従って開発する手法のこと。 Wikipedaには以下のように定義されていました。 プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、「要求定義」「外部設計（概要設計）」「内部設計（詳細設計）」「開発（プログラミング）」「テスト」「運用」などの作業工程（局面、フェーズ）にトップダウンで分割する。線表（ガントチャート）を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にする。ウォーターフォール・モデルの利点
こんにちは、プロダクトデザイン本部（旧サービスデザイン本部）の若林です。 2020年2月18日に開催するMeetUPイベントにて、リクルートのUX組織が実践している「ナレッジシェアの仕組み」と「具体的な案件のナレッジ」を社外初公開いたします。 このブログでは、イベントに先立ちましてリクルートのUX組織の特徴をご紹介します。 リクルートのUX組織の特徴 リクルートは、多種多様なマーケットで数多くのネットプロダクトを運営しています。 リクルートテクノロジーズのプロダクトデザイン本部では、各プロダクトの「ユーザ体験価値（UX）」と「ビジネス価値」を高める案件を企画・設計しています。 シゴトの一例 どのような案件を実施しているか、SUUMOの例をご紹介します。 このようなユーザビリティ改善や新機能開発について、日々、企画・設計しています。 その際は、定性的な声や定量的なデータといった根拠を集めなが
ドメイン駆動設計によるシステム開発 生産ラインのイノベーション
116 知的資産創造／2020年9月号 I T S O L U T I O N S 題が大きいと考える。現在のシス テム開発生産ラインを簡単に説明 すると、次のようなステップとな る。 ①要求定義や画面・帳票のUI、 ビジネスエンジンなど外部設計 を担当する業務アプリケーショ ンの専門家、基盤・ネットワー クや運用の方式設計するエンジ ニアなどがウォーターフォール モデルの上流工程を担当する。 ②次に、データベース構成・項目 やトランザクションなどを具体 的に設計するアプリケーション エンジニア、基盤・ネットワー IT構築コスト・期間の増加 「システム構築はどうしてこれほ どお金と時間がかかるのだろう」 システム開発にかかわる人は誰し も思っていることである。実際、 大手損害保険会社が第 2 次総合オ ンラインといわれている1980年代 に基幹システムを構築した費用は およそ300億円程度
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラウド時代も「アプリ」と「基盤」のチーム分けで本当にいいの？ - Qiita
DXに取り組んでいる会社の典型的特徴とは IPAが調査した、組み込みシステム産業・IoT産業の動向把握
https://www.meti.go.jp/meti_lib/report/2022FY/000249.pdf
PMが各部署から忙殺され、プロジェクトが炎上気味に…… “人をアサインしておしまい”から脱却する企画の進め方
AIシステムが成熟する今「MLOps」が必要とされる理由とは？ MLOpsを推進するために大切なこと
メンバー全員が開発リードになれる、「エピック主管」という仕組み
「運用でカバー」を増やさないために カウシェが実践する「小さく出し、小さく失敗する」
要件定義について言語化できる様に整理してみた - Qiita
ユーザー行動を使い、ユーザー目線でのテストを洗練させる
Quality Engineering & Assurance(QE&A) Careers
NTTデータが「生成AIありき」のSI、コード変換の作業工数を7割削減の効果も
クレジットカードによるサブスク実装をするときの全体感【PAYJP】
人月商売のIT業界を滅ぼす「死に神」、想定以上だった生成AIの猛威とは
要件定義とは？仕様書との違いや記載すべき項目、作成の進め方を解説 | Backlogブログ
ユーザーストーリーマッピングで始める要求整理 | フューチャー技術ブログ
[t_wada氏×カミナシTori氏]ソフトウェアエンジニアと品質保証 SRE、QAの枠にとらわれない新しい視点 | Offers Magazine
メルカリ・メルペイCTOが語る、エンジニアリングマネージャーに求めるもの Part.3
将来のキャリアに漠然とした不安はあるけれど、自分ではうまく考えられない人へ キャリア開発のための基本ステップ
【ChatGPT活用法】Railsで新規サービス立ち上げる際の活用術 - Qiita
「仕様検討のボトルネック化」「技術的な手戻り」にどう対処する？ ポジティブな変化とうれしい誤算を生み出した、はじめの1歩
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
敢えていま読む「仕様書の基本と仕組み」とシステム開発全体の流れ markdownサンプル - Qiita
ビジネスドリブン&トップダウンで陥ったビルドトラップ 「アウトプット偏重」からの脱出を実現した3つの施策
要件定義 とは【まとめ】 - RAKUS Developers Blog | ラクス エンジニアブログ
BD, UT, IT, ST, UATとは？ウォーターフォールモデル型のシステム開発における各工程・各段階の用語の意味
リクルートのUX組織の特徴（ナレシェア近日公開！） | Recruit Tech Blog