成功しているチームを分析すると金の卵もチームも失う - 室長のひとりごち
すっかりアジャイルもvsウォーターフォールから組織論に遷移しているので成熟度が上がってきたなとか、バズワードから実践に裾野が広がってきた感がありますね。 まあ、別にウォーターフォールは必ずしも失敗するシステム開発手法というわけでもなくて、プロジェクトに適したシステム開発手法を選び（ここ大事）、制約事項や前提条件を実現できるツールとテクニックを選定して、あとはチームのマインドセットをいかに維持するかチームの運営をすればいいのです。 すればね。 間違っていけないのは、プロジェクトの目的を達成するために適した手法や手段を選んでいるのか、というところです。そんなの単なる道具なのでチームが選択すれば良いです。 マネージャ、成功しているチームを見つける どこの組織でも1つくらいは上手にチームを運営して、立てたプロジェクトの計画を無理、無駄なく遂行しているチームはあるものです（そう信じたい）。10人いた
新人SEが同じ場所で常駐を続けると蝉になる - 室長のひとりごち
4月入社の新人システムエンジニアも、春のうちに配属になったり、夏のこの時期から現場に配属になったりと、組織の教育制度によりバラバラでその辺りは新人SEをどこまで教育できるかという組織の体力や現場のリソース不足が如実に現れますね。それよりこうして配属時期を思うと、入社してすぐにSEとして認められるなんてある意味すごい業界なような気がしますね…。 新卒の学生が企業を選択するのも、企業が新卒を採用するのもどちらも博打な訳ですが言い方を変えればエンゲージメントなのですよね。合うのか合わないのかはそれぞれの体質みたいなものですから。 新人SE、常駐先に配属になる ワタシもそうでしたが、新人教育というなのちょっとした教育期間後に、速攻で現場に常駐に出されるケースが多いです。現場の規模が大きければ大きいほど、顧客とSIerの双方の依存関係は深いですからワークロードの道幅も広く、業務も顧客よりエンジニアの
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
ソフトウェアプロセス技術がロストテクノロジーになっている - きしだのHatena
最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段
ついに公開、話題の無償PMツール - ツール開発者が活用法を解説：ITpro Active
大和田 裕＝情報処理推進機構（IPA） 技術本部 ソフトウェア・エンジニアリング・センター（SEC） エンタプライズ系プロジェクト 研究員 日々の進捗やメンバーの負荷などプロジェクトの状態を数値でつかむ。そんな定量的マネジメントの無償ツールが登場し、話題を呼んでいる。ツール開発者が活用法を解説する。 高い品質や新技術へのチャレンジを求められるが、予算も工期もギリギリで余裕はない。そんな難しいプロジェクトが増えるに伴い、プロジェクトマネジャー/プロジェクトリーダー（以下プロマネ）には、緻密なマネジメントが求められている。 利用部門からの仕様変更の要求を受け入れるかどうか、納期を守るために何人のメンバーを補充するか、どのサブチームを重点的にテコ入れするか――。そうした判断が不適切だったり遅れたりすると、プロジェクトの成功はおぼつかない。ITの現場を率いるプロマネの責任は重大である。 筆者は業務
芦屋広太一つ上のヒューマンマネジメント
評価を高める仕事術（最終回）「逃げ腰体質」の部下が逃げなくなった理由 この連載では、「ダメに見せないことで評価を高める」ための仕事術を扱ってきた。今回が、このシリーズの最終回である。これまで、11のネガティブ特性について、課題と対策を説明してきたが、最終回は、ネガティブ特性に関するエピソードを紹介する。この話は、ある企業で実際にあった話がベースになっている。 評価を高める仕事術（29）期を待つための「時間に関する三つの法則」 前回は、「期を待てない人がもったいない理由」や「期が待てない人」は残念な行動をしてしまうことを説明し、「残念ではない行動とはどういうものか」について簡単に説明した。今回もこの続きを説明する。筆者は、優秀な仕事をする人とそうでない人の違いは、特に説得や交渉の場面に顕著に出てくると考えている。だれでもできるような簡単な仕事をしていると、本当に優秀な人とそうでない人の区別
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 「派生開発」を成功させるプロセス改善の技術と極意: 清水吉男: 本
Amazon.co.jp: 標準テキスト オフショアプロジェクトマネジメント 【SE編】: 幸地司 (著), 霜田寛之 (著), 北島義弘 (読み手), 倉田克徳 (読み手), 北島義弘 (監修), 倉田克徳 (監修): 本
3年前の僕へ
Amazon CAPTCHA