進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
ガントチャートの功罪 〜 新規事業で工程表を作ることに意味はあるか？ | Social Change!
「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
ScaleOut | Supership
「ミライリアルの幸せを、デジタルの力で創る」ことを目指すSupershipグループの社内報です。日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipグループの”Be Super”なストーリーをみんなでシェアしていきます。
「管理」を勘違いするPMが、メンバーに翻弄される理由
「管理」を勘違いするPMが、メンバーに翻弄される理由：新任PMがついやってしまうNG集（4）（1/3 ページ） 1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 こんなはずじゃなかったのに……ああ世知辛い、PMの嘆き プロジェクトを管理するプロジェクトマネージャ（PM）は、何かにつけ苦労する立場にあります。 「メンバーにガミガミ言うことに疲れた」「いくらチームに必要とはいえ、この役割はつらい」「ぶっちゃけプログラマの方が良かった」……このような声をPMからよく聞きます。 しかし、ここでいま一度思い出してみてください。形はさまざまあれど、PMは理想とする「管理」の姿を持っているはず。そして、それは決して「ガミガミ言うこと」ではなかったと思います。 「そんなこと言ったって、メンバーが
見えてきた危機対応での「やってはいけない」
プロジェクトで危機的な状況に直面したとき、やってはいけないことが少なからずある。日経SYSTEMS5月号（4月26日発行）の特集記事「プロジェクトの危機 その時どうする」の取材では、このように感じる指摘を、ベテランのプロジェクトマネジャー（PM）から受けることができた。 特集記事で取り上げた危機的な状況には、「震災の影響によってプロジェクトが進められない」といったものに加えて、コストオーバーや納期遅延、品質の低下というものを含む。このとき、どのように対応すればよいかを、「人が足りない」「時間がない」「タスクが山積み」といった状況ごとに紹介している。 記者はこの特集の事例取材で、コストオーバーや納期遅れ、品質の低下といった危機的状況での対応を、主に担当した。これらの危機的な状況は、PMやリーダーが「順調に進んでいる」と思っている中で、急に判明することが少なくない。このとき、プロジェクトはかな
プロジェクトを完遂させるための4つの原則 | ライフハッカー・ジャパン
おなじみの生産性向上ブログ「At Zen Habits」では、プロジェクトをやり遂げるための心がけとして、4つの原則を挙げています。 以下が4つの原則です。 プロジェクトの範囲はできるだけシンプルに すべてを完璧にやる必要はない。プロジェクト範囲をできるだけ限定し、シンプルにすること。 完璧を追求せず、成果は「これで十分」というレベルで 完璧を追求しはじめると、プロジェクトはけして終わらない。成果は「これで十分」というレベルでOK。 余分なものはそぎ落とす アレもコレもと欲張りすぎず、本来このプロジェクトでやるべきことに集中しよう。余分なものはいったんそぎ落とすこと。 成果はできるだけ早くリリースする 完璧なものでなくともよいので、できるだけシンプルに成果を上げ、早めにリリースしよう。 ポイントは、できるだけシンプル化し、完璧を求めすぎないことのようですね。「まずは最小限のものを作るところ
運用管理の「うっかりミス」はどうすればなくせる？
本連載のこれまでの内容を簡単におさらいすると、「システム運用管理とはサービス業である」という考え方を基に、日々の運用管理業務の可視化・平準化を行い、お客様とのヒアリングによってSLAを導入してきました。「ここまで来れば完ぺき！」と言いたいところですが……。 システム運用管理はリスクマネジメント抜きでは語れない システム運用管理に少しでも携わったことがある方なら容易に想像が付くと思いますが、運用管理業務には常に「リスク」が付いて回ります。どんなに理想的な運用メニューを構築したとしても、システム自体にも、運用管理にかかわるさまざまなプロセスの中にも、リスクは潜んでいます。 そもそも、「リスク」って何でしょう？ よく耳にする言葉なので何となくイメージはつかめるかと思いますが、ここであらためて説明すると、リスクとは「損害を受ける可能性」のことです。また、リスクを「脆弱性×脅威×影響範囲」という定義
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
