何でスキル不足のエンジニアをアサインしたからって訴えられるんですか
何でスキル不足のエンジニアをアサインしたからって訴えられるんですか：「訴えてやる！」の前に読む IT訴訟 徹底解説（112）（1/3 ページ） 顧客企業のプロジェクトのために下請け企業が用意したのは、プログラミングのいろはも知らないエンジニア。結局、契約期間途中で退場することになったが、責任は誰が取るべきなのか――。 連載目次 スキルの合わない要員アサイン 仕事を受注したが、メンバーのスキルが足りずにプロジェクトが失敗に終わった――。皆さまにはこんな経験はないだろうか。正直にいえば私にはある。 私の場合は幸いにしてそこまで大ごとにはならなかったが、こうしたことがあると自社に金銭的な損害を与える上、顧客に多大な迷惑を掛けるし、信頼も失墜する。スキル不足によってデスマーチ化したプロジェクトの中で、自信喪失したメンバーの心身が害されてしまうことが何より心配だ。スキルアンマッチは関係者を皆不幸に陥
ロードマップに機能を書くべからず｜小城久美子 / ozyozyo
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
分散型チームは成功の見込みが薄いプロジェクトにしがみつきやすい 失敗の効率をどうすれば上げられるのか | チームマネジメント｜DIAMOND ハーバード・ビジネス・レビュー
コロナ禍でリモートワークが浸透し、チームが分散して働く場面は珍しいものではなくなった。組織や地理的な境界を超えて、多様なメンバーがプロジェクトに取り組むことには、創造性やイノベーションを促進するという大きな利益がある。だがその一方で、分散しているゆえの調整コストが生じることも事実だ。筆者らの調査結果では、分散型チームは成功するプロジェクトには効率的に取り組めるものの、失敗するプロジェクトを見限ることができず、リソースを無駄に消費していることが明らかになった。本稿では、分散したチームがもたらす利益を活かしながら、マネジャーがコストに対処するための方法を紹介する。 この1年で、私たちは分散したチームで働くことに慣れた。しかし、オフィスに戻り、同僚と肩を並べて働くことができるようになりつつあるいま、実際にどれだけオフィスで仕事をすることになるのかと疑問を抱くのは自然なことだ。 分散型チームワーク
開発者を悩ます「ソフトウェアアーキテクチャ選定」 迷った時に使える3つの判断基準
近年、AndroidやiOSなどのモバイルアプリ開発で使用されるソフトウェアアーキテクチャにはさまざまな種類があり、「この開発プロジェクトに最適なアーキテクチャはどれか」と悩む開発者の方も多いのではないでしょうか。 そこで本連載（全5回）では、アプリ開発現場でよく使われる代表的なソフトウェアアーキテクチャ「MVC」「MVP」「MVVM」「Flux」「Clean Architecture」それぞれの基礎を解説するとともに、テストフェーズを見据えたアーキテクチャ選定のコツを紹介します。 著者紹介：石黒 邦宏 デジタル・マジック・ラボでインターネット経路制御運用に関わり、オープンソースウェアで経路制御を実現する「GNU Zebra」を開発。1999年IP Infusionを共同設立し、CTOに就任。2009年Access CTO、2015年アプリックス CTOを経て、2018年デジタルハーツホー
評価を高める仕事術（9）「思慮が浅い人」がプロジェクトを窮地に追い込む
前回までは11のネガティブ特性の2番目である「主体性がない、受け身である」について説明した。11のネガティブ特性は以下の通りである。 先を読まない、深読みしない、刹那主義 主体性がない、受け身である うっかりが多い、思慮が浅い 無責任、逃げ腰体質 本質が語れない、理解が浅い ひと言で語れない、話が冗長 抽象的、具体性がない、表面的 説得力がない、納得感が得られない 仕事が進まない、放置体質 言いたいことが不明、論点が絞れない、話が拡散 駆け引きできない、せっかち、期を待てない 今回は三つ目の「うっかりが多い、思慮が浅い」というネガティブ特性を説明する。これは 自分が行う発言や行動、そのほかの他人への働きかけが、どのような結果をもたらすかを考えることをしない。または考えることができない という行動特性を表す。「十分に考えつくし、熟考したうえで発言や行動をする」という行動特性の逆である。 こう
第1回 30年前の改善魂を取り戻せ
アジャイル開発が広まる機運が高まっている。アジャイル開発を経験したマネジャたちが「繰り返し開発と振り返りが本質」と気づいたからだ。「30年前の現場にあった改善の喜びを取り戻せる」と指摘するマネジャもいる。システムを開発する立場からアジャイル開発を取り巻く変化を追った。 短期間の「繰り返し開発」と開発した結果の「振り返り」。たった二つを実践するだけで、技術者も利用者も幸せになれる。2009年、登場から10年がたったアジャイルの価値がこの二つに集約されてきた（図1）。 「アジャイル開発はプログラマ寄りの技術で、ウォータフォール開発の対立軸と捉えていた。しかし実際にやってみるとその根本は繰り返し開発と振り返りであり、それは自分たちが30年前に開発現場で実践していたことと変わらないことがわかった」。富士通 文教ソリューション事業本部 文教第二ソリューション部の中尾保弘部長と、日立製作所 アプリケー
Case File：東邦チタニウム｜初のアジャイル開発プロジェクトを成功に導いた「リーダーの意志」 - CIO Online
ITシステムを、それも基幹業務システムを自社開発するということになれば、普通はベスト・プラクティスに学ぶかたちの、実績豊富な開発手法を選ぶものであろう。稼働開始時期を延期することが許されないうえに、メンバーの開発スキルも十分ではないとなれば、なおさらのことである。だが、チタン製造大手の東邦チタニウムは、主力製品の生産管理システムを構築するにあたって、一般的なウォーターフォール開発ではなく、アジャイル開発を採用し、そのプロジェクトを見事計画どおりに完遂させた。厳しい条件下でプロジェクトを成功に導いたリーダーは、そこにおいてどのようなプロジェクト・マネジメント手腕を発揮したのだろうか。本稿では、東邦チタニウムのアジャイル開発プロジェクトの軌跡をたどりながら、その手法や考え方について学んでみたい。 CIO Magazine編集部 ● text by CIO Magazine プロジェクト・マネジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
