5分で分かる、「スクラム」の基本まとめ:開発チームを改善するためのスクラムTips(8)(1/2 ページ) 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み(フレームワーク)」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
本ガイドラインは、バーンワークス株式会社が行う Web サイト制作全般においての品質を保持するために定めたものである。当社は本ガイドラインに基づいた制作を行い、クライアントに対して常に安定した品質のサービス、及び納品物を提供する。 Last modified 2023-10-18 ディレクターはクライアントから指定の Web サイト要件を満たし、Web サイトのビジネスゴールを達成するため、適切な情報提供、提案を行う、また Web サイトの情報設計からプロジェクトの進行管理、プロジェクトメンバーの業務管理、納品物の品質管理を適切に行うものとする。 ディレクターはクライアントを含めプロジェクトメンバー間でのコミュニケーションを積極的に取ることで円滑なプロジェクト進行を心がける。また、クライアントに対しては進捗の報告、情報共有を適時、および明確に行い、信頼関係の構築に努める。 新規 Web サ
TL;DR テスト環境、本番と同じ環境にサイトを置いたときに確認しておきたいことってなんだろう。公開後のクレームやトラブルを防いだり、サイト公開・納品前にサイトの品質を上げるためにチェックしておきたいことをまとめました。大切だけど意外とチェックし忘れそうな内容を知りたいとき、過去の失敗をもとに作成したシートを公開します。 機能 要件定義をもとに指定の機能が実装済か確認します。 項目 解説
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
こんにちは。安達です。今年も引き続き、張り切って行きたいと思います。 さて、突然ですがみなさんは「プロジェクトマネージャー」を目指してますか? もちろん、ひと口にプロジェクトマネージャーと言ってもさまざまな方がいます。 大規模な業務システム構築のプロジェクトもあれば、ECサイトやWebサービス構築プロジェクトもあります。LSIのチップ制御ソフトウェア開発もあれば、スマートフォンのゲームアプリ開発もあります。 ただ、共通して必要とされるスキルが、「プロジェクトマネジメント」だということは、みなさんも意見が一致するのではないでしょうか。 しかしそうはいっても、プロジェクトマネージャーになってから独学でプロジェクトマネジメントをゼロから学ぶのはとても非効率です。もちろん会社でOJTをするなり、体系的なプロジェクトマネジメントのマニュアルがあるならば、さしあたっての問題はないでしょう。 でも、ある
会社で士気の低下に困っているとしたら、それがすべての人材にはびこる前に何か手を打つ必要があります。有能なプロは、恵まれない環境に長く留まりません。これは驚くようなことではありせんが、士気の低下は時々起こるものであり、悪影響を及ぼす前に対処すべきなのです。士気の低下を治す特効薬はありません。従業員に積極性がないとすれば、おそらくさまざまな物事のやり方が間違っている状態なのでしょう。 『A Culture of Purpose: How to Choose the Right People and Make the Right People Choose You』の著者、Christoph Lueneburger氏はHarvard Business Reviewの記事で、従業員を引き込むために、戦略から戦略へ飛び移るのは有効ではないと論じています。彼が有効性を実証したのは、会社を目的に向けて調
「ユーザエクスペリエンス(UX)」のデザインや、その手段としての「人間中心設計(HCD)」という単語を、このところよく見かけるようになりました。 その多くは、「ユーザーを正しく理解しよう」というものです。それ自体はすばらしいことで、価値があることに疑いはありません。 でも、UXの対象者は、実はエンドユーザーだけではないと言うと、あなたは驚くでしょうか。 というのも、UXを大きな視点で見ると、サービスや製品がエンドユーザーに届くまでのあいだに、そこにたずさわる、すべての人が、その対象であると考えられるのです。 その1つに、自社の「チームのUX」のデザインという考え方があります。 「チームの信頼感を生むための、組織のUXデザイン」について、ワークショップ設計の専門家でもある、株式会社Gaji-Labo(ガジラボ)の山岸ひとみさん(HCD-Net認定 人間中心設計専門家)に伺いました。 社員やパ
デベロッパなら誰しも、自分の将来を決断すべき時が来ます。このままデベロッパ、またはシニアデベロッパのキャリアに留まってコードに専念するか、チームの管理を担うリードデベロッパや開発マネージャといった管理職の世界に飛び込むかの選択です。 ディルバート:プログラマからスーパーバイザへ 私自身も2011年に同じような決断をしました。ある大手インターネット銀行のシニアデベロッパだった私は、直属の部下はいなかったものの、数人をメンタリングしていました。当時私は、大学生に職場を世話して1年間のトレーニングを提供するアカデミーのプログラムに携わっていました。最初はメンターを担っていたのですが、最終的には、通常のシニアデベロッパの職と並行しつつ、そのアカデミーの管理を任されるようになりました。厳密な意味で、私が複数の人たちを直接管理したのは、この時が初めてで、私はその仕事を心から楽しみました。その後、私は消
SQuBOK Guide について SQuBOK とは、ソフトウェア品質知識体系を指します。このガイドを日本科学技術連盟(日科技連)さんにてとりまとめして、ガイドとしてオーム社より書籍として提供されています。 ソフトウェア品質に関心のある方ならば、一度は耳にしたか、目を通したガイドではないでしょうか。 詳しくは、日科技連さんのページをご覧ください。 ソフトウェア品質知識体系ガイド―SQuBOK® Guide― 第1版は、中国語版や電子書籍版も提供されているようです。 SQuBOK Guide 第2版 第1版から7年の月日がたち、ソフトウェアを取り巻く環境も変化していく中で、2011年でしたか、第2版の話が本格化してきました。モバイルやサービスのソフトウェア品質、開発領域でのソフトウェア品質、ソフトウェア品質の定義の変化などを含めて、第1版を踏まえて、第2版として、検討できる知識体系へとプロ
ガバナンスの項で見たとおり、営利企業の究極目的は株主価値増大であり、その他の目的は全てこれに従属します。(何度でも繰り返しますが、社会のルールに従い品格のある行動をとることは「目的」以前の基本前提です)。 株主から委託された資金は、借入で調達された資金と併せて事業に投下され、そこから生み出される利潤が、株主価値の増殖部分ということになります。この一連の資金の流れを司るのが財務機能です。 財務機能は次の2つの部分から構成されます。 適切に財務機能が運営されないと、必要な資金がショートして破綻したり、投資利益が金利と逆ざやになりどんどん持ち出しがかさむといった株主価値の破壊につながります。 このような事態を回避すること、更にはより積極的に調達・運用の吟味を通じて株主価値を最大化/最適化することが財務戦略の使命です。 したがって財務戦略はガバナンスプロセスを支える重要な支柱ということが
ほうほうと思って内容見ていたのですが。。。ちょっとだけ。 プロジェクトマネジメントで大切な一つのこと まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。 PMBOKでは、以下の様なことを管理しろとあります。 総合管理 スコープ管理 タイム管理 コスト管理 品質管理 人的資源管理 コミュニケーション管理 リスク管理 調達管理 ステークホルダ管理 教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。 オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。 要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと
トヨタが考案した「かんばん方式」は、生産計画に応じて必要なものを必要なときに必要なだけ供給でき生産効率が向上するため自動車の製造に限らず製造業一般に普及し、現在ではプログラムマネジメントの手法の一つとして広く採り入れられています。そのかんばん方式を使って複数人で取り組むプロジェクトをオンライン上でマネジメントできるサービスが「Taiga」です。 Taiga.Io | Agile, Open Source, Free Project Management System https://taiga.io/ ◆アカウント登録 上記サイトページの下にある「SIGN UP」をクリック。 TAIGAのアカウント登録画面になるので、ユーザーネーム・公開ネーム・メールアドレス・パスワードを入力したら「SIGN UP」をクリック。 無事、サインアップが終わるとこのようなサインイン画面になります。なお、複数の
9. ● 常に文書による指示を要求せよ。 ● 準備を十分行い完全に準備ができているまで実行に移すな。 ● 些細なことにも高い完成度を要求せよ。わずかな間違いも繰り返し修正させ小さな 間違いも見つけ出せ。 ● 重要な決定を行う際には会議を開け。 ● もっともらしくペーパーワークを増大させよ。 ● すべての規則を隅々まで厳格に適用せよ。 ● 何事をするにも「通常のルート」を通して行うように主張せよ。決断を早めるため のショートカットを認めるな。 ● 可能な限りの事象を委員会に持ち込み「さらなる調査と熟考」を求めよ。委員会の メンバーはできるだけ多く(少なくとも5人以上)すること。 ● 議事録や連絡用文書、決議書などにおいて細かい言葉遣いについて議論せよ。 ● 以前の会議で決まったことを再び持ち出し、その妥当性について改めて問い直せ。 10. ● 常に文書による指示を要求せよ。 ● 準備を十分行
職場での不正行為は組織を蝕み、巨額の損失を招きかねない。これを食い止めるためには、「仕事の能力と倫理観は相関しない」ことをマネジャーが認識し、倫理観の醸成に組織的に取り組む必要がある。その6つの要諦を経営心理学の権威が示す。 マネジメントに関するあらゆる課題のうち、最も取り上げられることが少ないのは、間違いなく次の問題だろう。非倫理的な行動が目立つ従業員に、どう対処すべきか。特に、その人物が有能で替えがきかない場合には? このテーマが多かれ少なかれタブーとされているのは、3つの理由による。第1に、倫理・道徳は定義が難しく、往々にして哲学的な議論に入りこまざるをえないが、マネジメント論の著者は形而上学にアレルギー反応を示す向きが多い。第2に、人を不道徳であると見なすのは物議をかもす行為である(もっとも、「節操のない」「不正直な」「腐敗した」といった言葉を替わりに用いてもけっして遠回しな言い方
乗員に期待されていることは何か? 日々の学びを通じて、より優れたサブマリナーになることを期待している。日々の野外演習、メンテナンス活動、訓練演習、モニターの観察、航海、配備を学ぶ機会としてとらえ、人として成長することを望む。 米国の攻撃型原子力潜水艦サンタフェのマルケ艦長が、乗員の「信条」として示した文書の一文だ。 「人として成長することを望む」 このひと言に、マルケ艦長が実践した「権限を委譲するリーダーシップ」の本質がある。 彼が就任する前のサンタフェは米国海軍の中でジョークのネタにされるほど、悪い見本として使われていた。乗員の士気は低く、予定通り出航できない、乗員の残留率も低く、昇進率も平均以下という艦にマルケ艦長が就任して、米海軍で最も成績のよい艦へと変身させた。そのときの体験を語った「最強組織の作り方」は、組織のリーダーや経営者、あるいは、プロジェクトを任されているPMなどに一読を
この記事面白かったです! 「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の9割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。 私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。 実装可能と実現可能は別問題 前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。 技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた
シビアに見積もった工数をdとした時の計算式: d + d(( r1 [ + r2 … + rn] ) * x1 [* x2] ) 例 例)1, 3, 5歳の子供がいて、夫婦で看護を半々にシェアできるエンジニアの当初の見積工数が30人/日、時期は1月~2月の場合 30 + 30 * (( 0.04 + 0.04 + 0.02 ) * 1.2 * 0.5 ) = 31.8 ということで計算後の見積工数は32人/日ということになります。 さいごに 半分ネタで半分本気です Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWh
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く