システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
マネージメントに必要なことは全てゲームから学んだ
この投稿は毎年恒例、pyspa Advent Calendar 2020の1日目の投稿になります。 どうもご無沙汰しております、akisuteです。すっかり年に1回アドベントカレンダーのときにだけ顔を見せる人になっておりますが、おかげさまで無事平穏に過ごしております。 さて突然ですが私はプログラマーを引退しました。 なぜなら今年で36歳だからです。プログラマーは35歳になったら定年ですね。 実際のところ、このぐらいの年になると、よほど何らかの意志が働かない限り、技術に対する情熱みたいなものが失われてくると思います。もちろん本当に技術とプログラミングが好きな人は間違いなく35歳なんかで情熱を失ったりはしないと断言しますが、残念ながら私はそうではなく、もはやiPhoneには大した興味が湧いておりませんし、最近はJavaだのGoだのTypescriptだのVue.jsだのといったものを必要に応じ
「OpenProject 11.0.0」がリリース、作業分解図ボードなどを追加
ProductZine Day＆オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine（プロダクトジン）」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。
BASEの長期間プロジェクトでのチーム開発について - BASEプロダクトチームブログ
ServiceDev所属、サーバサイドエンジニアの栗田です。 現在私は、ServiceDevのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。 BASEでは主にQ毎にプロジェクトチームを編成し、チームで主体となって機能開発を行っていきます。 チームメンバー構成はプロジェクトの特性や規模により様々ですが、多くの場合、同じグループから1〜2名がプロジェクトにアサインされます。 今回はとある長期間プロジェクトで感じた事や・実際にこのように進めたよというところをサーバサイドエンジニアの視点から紹介したいと思います。 どんなプロジェクトだったか 今回紹介するプロジェクトは「BASE」の拡張機能である「BASE Apps」の1つである「商品オプション App」を開発するプロジェクトでした。 「商品オプション App」は商品にギフトラッ
計画の科学 - hitode909の日記
三点見積もりでもやってみるか、という話になって、id:onkさんにおすすめされたので読んだ。PERT、Program Evaluation and Review Techniqueについて教えてくれる本。1965年の初版が電子書籍化されていておもしろい。 読んでたら、こんなの大学の授業でやったなってだんだん思い出してきた。 PERTは各タスクの依存関係をグラフにしたもので、見積もり時間を持っているもの。ガントチャートと違って、各タスクの依存関係や、遅れたときに全体に影響がある箇所や、余裕がある工程がどこなのかを可視化できる。 ja.wikipedia.org 以下は読書メモ ネットワークは関係者が集まって描く。お互いの意見を出し合って最高のプランがネットワークとしてまとまるのが良い点 見積もりトータルフロートが0であるパスがクリティカルパス。そのパス以外はフロートがあり、早くやっても仕方な
約9カ月でリリース、目標の2倍の成果――“品質”と“納期”を両立させる新規プロダクト開発でチームを崩壊させない方法
約9カ月でリリース、目標の2倍の成果――“品質”と“納期”を両立させる新規プロダクト開発でチームを崩壊させない方法：リクルート事例に見るエンジニアとしての価値の高め方（1） 変化が速くなる一方の市場環境において、エンジニアとしてビジネスに貢献するにはどうすればいいのか。本連載では、リクルートでの新規プロダクト開発事例からエンジニアとしての価値の高め方を明かす。初回は、本連載で事例として扱うプロダクトの概要やスケジュール、開発の進め方について。 エンジニアとしてビジネスに貢献するにはどういうアプローチをしていけばよいか 近年、ビジネス市場の変化は速くなる一方です。FinTech、MaaS（Mobility as a Service）、HRTechなどに代表されるように、ほぼ全てのビジネスにデジタル技術が欠かせなくなっているため、エンジニアである私たちにも、市場変化の速さは“脅威”といえると思
プロジェクト管理を自動化してみたけど思うようにはいかなかった話 - dely Tech Blog
こんにちは。delyでAndroidエンジニアをしているkenzoです。 今回はAndroidの話ではなく、担当している別のプロジェクトの管理をいい感じにしようと思っていろいろやったけど、そんなにうまくいかなかった。という感じの内容です。 どんな話 「他部署の依頼でコンテンツを作成するプロジェクト」の管理を自動化した結果、うまくいったこと、失敗したことについてのお話です。 なんで自動化したの 今回のお話の背景 弊社では開発部が他の部署から依頼を受けてLP等のWebページを作成しています。 私は他の部署と開発部内の実装者とのやりとりの間に入って管理する取りまとめのようなことをしてきました。 やっていたことをざっくり言うと、依頼を受け、実装者に依頼して、配信の準備をする。という簡単なお仕事で、元々はスプレッドシートで管理をしていました。 発生した問題 新たに高い頻度でコンテンツを作る施策の開始
マネジメントって何すればいいの〜？1年間マネジメントに向き合ったのでまとめを書きます - Qiita
はじめに こんにちは！Supershipの永田ゆにこです！「Supership株式会社 Advent Calendar 2016」の20日目を担当します（^o^）今年は会社のやつに参加するぞ〜！ これからマネジメントやらなきゃいけない人や、同じように困ってる人にぜひ読んでほしい！めちゃくちゃ長いです。 前置きと振り返り さて、これまでは二年連続でGitに関することを書いてきました。Gitが使えるデザイナーブランディングをしていたんですね〜。いまやデザイナーの人がGit使うのは普通になってきた印象です。便利すよねえ。 去年の書いたのはこれ Gitとわたしとデザイナーと 〜2015年Gitの思い出〜 その前書いたのはこれ デザイナーがこうやってGit覚えて大好きになったよ♡ てな感じで少し前はデザイナー&ディレクターをしていたのですが、最近はだんだんプロデューサー&マネージャーぽい感じに変わっ
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
プロジェクトにおけるスケジュールと費用のトレードオフを考える | タイム・コンサルタントの日誌から
9月にスケジューリング学会で「プロジェクトにおけるスケジュールと費用のトレードオフを考える」というタイトルの講演発表を行った。わたしがこの何年間か個人的に続けている『リスク基準プロジェクト価値』（Risk-based project value = RPV）分析の手法を用いて、スケジュール・リスクのコスト化という問題に初めてくさびを打ち込んだ研究の発表である。サイトに書くにはやや理屈っぽい話であるが、小さな学会でもあったので、ここにその要旨を（数式は極力飛ばして）再録する。 =================== 日揮株式会社の佐藤です。本日は「プロジェクトにおけるスケジュールと費用のトレードオフを考える」というタイトルで発表させていただきます。 皆さん、ちょっとこういう問題を考えてみてください。皆さんはあるプロジェクトのプロマネです。このプロジェクトは全体納期に対して、1日10万円の遅延
第10回 膨れ上がる要件の量をマネジメントする
前回は、要件の量と確度を定量化しユーザーとベンダーが一緒になってマネジメントする必要性について触れました。見積もりが終わった後も、見積時に合意したシステム要件と開発の実態がかい離しないようにマネジメントしなければ、プロジェクトを成功に導くことはできません。 今回は、要件量をマネジメントする方法として、NTTデータのスコープマネジメント手法を紹介します。 スコープマネジメントの背景 システム開発プロジェクトでは、ビジネス環境の変化に合わせてシステムに対する要求が日々変化する一方で、コストに対する制約は厳しいものです。そのため、要件の変化を適切に管理できなければ、見積もりより実際のコストが膨らんでしまいます。 システム要件の変化には様々な原因がありますが、ユーザーとベンダーが要件量の増減にうまく対応できないと、状況はさらに悪化しマネジメント不能に陥ります。スコープマネジメントはこの対応の問題点
C88のこと - MEMOGRAPHIX
盆LTの話と時間的に前後するけど、コミックマーケット88お疲れ様でした。我々のサークルは新刊でこういう本を出した。 【jadda+ C88新刊】チーム制作が苦手なアナタのための、一冊まるごと「チームで同人誌をつくる」を特集した『jadda+ Issue 2』【1日目・東フ-01a】毎回3日目に配置されるから、今回1日目（平日）はどんな感じか勝手が分からず若干不安だったけど、幸いにもなかなかの結果を出すことができた。うれしい感想もいくつかいただいた。後日、購入された方の感想を観察してみたところ、おおむね意図通りにこちらのやりたかったことが伝わっているようだった。 意図というのは、"どういう本として捉えてほしいか"と言い換えることができる。この本、いままでで一番か二番くらいに悩みながら作ったんだけど、多くの時間を本の立ち位置を決める作業に費やした。 立ち位置チームの本といっても、いろいろな切り
TechCrunch
In an attempt at damage control, the CEO of the equity management startup Carta, Henry Ward, today emailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundred blocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo
第4回：企業の「実行力」を担うキーマンは誰か
ここまで、せっかく練り上げた戦略が実行されない理由や、戦略を実行可能なものにするには「戦略」を「プロジェクト」「プロセス」「アクティビティ」と段階的に詳細化していく必要があることについて説明してきました。この詳細化のプロセスで最も重要な役割を果たすのが「プロジェクトマネジャー（PM）」です。 経営層から示された戦略や要求は、幹部層、管理職層を通じて、現場に伝えられます。この戦略や要求を「現場の言葉」に翻訳し、プロジェクトとして実行する役割を担うのがPMです。別の見方をすれば、経営層と現場の狭間に位置し、その橋渡しをする機会が最も多いのがPMであるといえます。企業の「実行力」の多くはPMが担っているのです。 ここでは、そうしたPMに求められる能力について考えてみましょう。PMに求められるのは、 要求を引き出し、議論を深める力 価値を設計する力 不確実性に対処しながら、やり切る力 と大きく三つ
プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から
1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ（ロンドン金融街）全体の投下コストは、総額5億ポンドに上っていた。証券取引所のＰ・ローリンズ理事長は、責任をとって辞任する。 「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
機械学習プロジェクトはなぜ失敗するのか | AI専門ニュースメディア AINOW
新規開発の不確実性を軽減する「仮説検証型アジャイル開発」の支援サービスを提供 Relicとレッドジャーニー
サル先生のプロジェクト管理入門