プロジェクトマネジメントで大切な一つのこと - プロマネブログ
ほうほうと思って内容見ていたのですが。。。ちょっとだけ。 プロジェクトマネジメントで大切な一つのこと まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。 PMBOKでは、以下の様なことを管理しろとあります。 総合管理 スコープ管理 タイム管理 コスト管理 品質管理 人的資源管理 コミュニケーション管理 リスク管理 調達管理 ステークホルダ管理 教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。 オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。 要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと
バッチ処理のあれこれと、SLA - プロマネブログ
風邪引いてしばらくブログ更新サボってました。 上記記事について、気になったので。ブコメで言及ももらったし。 ウィキペディアのバッチの利点って若干記載が古い 多くのユーザーがコンピュータのリソースを共有できる。 処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。 バッチ処理 - Wikipedia バッチをリソース目的だけで使うってずいぶん古い話だなあ、と思って編集履歴をたどってみたら、2006年の記載でしたか。 記載をたどってみると分かるんですけど、上記の内容って「メインフレーム」のバッチ処理に対する利点なんですよね。 そういった意味では、現在のバッチの設計とはちょっと概念が違うんじゃないかな
クラウドではなく、ダメな営業がSIerをダメにする理由のような。。。 - プロマネブログ
クラウドでSIがダメになる本当の理由 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 別にアジャイルもDevOpsもオンプレでもやっているし。。。ホスト、オープン系、Webとシステム開発の姿は代わり続けたけど、システム開発自体を続けてきた事実を考えれば、その中堅会社が言ってることも間違いじゃないよ 正直、全体的に内容が発散しており、「言いたいことはわかるが何を言っているのかよくわからない」典型的な文章となっているので、感想を書きづらいのですが、部分ごとにコメント欄で書ききれなかった感想を書きます。 クラウド技術でSIerの仕事は減るのか？ 開発や運用に関わる工数を大幅に減るでしょう。また、求められるスキルやテクノロジーも変わります。予算についての常識もかわるでしょう。開発・テスト・本番以降のワークフローやライフサイクルも変わります。 個人的な予
詳細設計書も問題だけど、それ以上に成果物定義が問題 - プロマネブログ
詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た
WEBサービス会社のはてながSIerからシステムを買ったこと - プロマネブログ
getlife - 『ミロク情報サービス×はてな、CFO対談 「上場の意義」…』 へのコメント 2014/10/22 08:59 にブックマーク へー、はてなってミロクさんの会計パッケージ使ってたんだ。 知らなかった。 「WEBサービス会社」のはてながSIerからサービスを買った理由 SIerで働いている人ならあまり違和感ないんですけど、業務システムに詳しくない人だと「はてなって内製でサービス作っているのに、なぜSIerからサービス買うの？」と思った人もいるんじゃないかと思ったので、ちょっとだけ。 企業の業務システムは、色々な分析方法がありますが、一般的なのは顧客との距離ごとに「フロントオフィス」「ミドルオフィス」「バックオフィス」に分けて機能分析を行うことが多いです。 フロントオフィス 顧客との直接的な営業活動を行う機能に対して働きかけるシステム。CRMやコールセンタシステム等。WEBサ
米国IT業界に過去あった多重下請構造、それが破壊された理由 - プロマネブログ
日本のIT業界を「SIガラパゴス」と言う前に知っておきたい海外ベンダ事情 - プロマネブログ 前回の記事を書いたあと、うっかりしていたことに気づいたので、追記です。 ユーザ企業とベンダ企業との関係については、他国との比較を色々書いたのですが、多重構造について深堀り書くのを忘れてました。 米国の事情についてもうちょい書きます。 下請構造が崩壊したアメリカ 端的にいうと、米国にも日本と同様の下請構造は過去ありました。 日本と同様に、元請けが大規模な案件を受注し、それを２次３次請けにシステム開発再委託するという構造です。 政府調達元請けの平均60.4％が下請け及び補給品に再投資され、それらのさらに平均83.2％が3次へ再投資、さらにその83.2％が再々投資、と繰り返される事により、初期調達額$369M（元請けのみ）は、上記再投資の構造より算出される係数2.06を乗ずる事により、$759Mと推計さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
