目標管理制度で業績・モチベーションUP [労務管理] All About
人事労務コンサルタント・特定社会保険労務士。企業人時代を含め通算24年の人事コンサルを経験。一部上場企業から新設企業までを支援。セミナー講師、雑誌・書籍の執筆実績も多数。 成果主義人事賃金制度は、人事考課制度（短期的な評価）と役職・等級制度（中長期的評価）の2つの仕組みづくりがポイント。人事制度という箱物を作っても、「仏作って魂入れず」という状態では効果が出ません。前回の記事で後者の役職・等級制度の概要をお話ししましたので、今回は前者の人事考課制度を解説します。 短期的な評価制度の「人事考課制度」を運用して、給与・賞与処遇制度を納得できるものにしたいですね。効果的な制度とするために「目標管理制度」の導入をお勧めします。 目標管理制度は、Plan→Do→Seeで実施する ■成果を査定するのではなく、生み出す制度とする 人事考課制度は、従業員の成績評価です。給与や賞与は、年度ごと、期間ごとに決
![目標管理制度で業績・モチベーションUP [労務管理] All About](https://cdn-ak-scissors.b.st-hatena.com/image/square/3a713ecab6d4800da05c4504abbf5718b1613b04/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fimg.aacdn.jp%2Faa%2Fcommon%2Fogp300_300.png)
なぜかくも目標管理制度はうまくいかないのか｜日本総研
・成果主義人事制度の普及 １９９０年代の末ごろから、成果主義人事制度が一斉に普及した。それが日本企業にとって良かったのかどうかは今のところ評価が定まってない。景気拡大の局面に差しかかっている現状で改めて検証する必要があると思われる。 ところで、成果主義人事制度を導入するにあたって検討された主な人事テーマは、まず評価制度の改定があげられる。具体的には成し遂げた成果を納得性のある評価とするために目標管理制度を取り入れたこと、及び曖昧な能力評価に代わって行動ベースで評価が可能なコンピテンシー評価を取り入れることであった。次に検討された人事テーマは、短期決済的な色彩の濃い個人面での賃金・賞与制度の導入と降給・降格制度の導入にあたっと考えられる。この中でも、目標管理制度は評価制度に関して切り札のように取り入れられることとなった。しかし、現状では運用面で行きづまりを見せているのではないかと思われる。
第65回 ［図解］Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング：ITpro
今回は，Webサイト構築プロジェクトのワークフローを俯瞰してみたいと思います。実際にクライアントから声がかかる場面から納品，つまり開発案件の完了までを12の「ステージ」に分けて図解してみました。思考のプロセス/人的配置/タスク/ツールなども一緒に記しています。少し大きな図になってしまいましたが，ご参考になれば。 図は，一番上は「4つのステップ/3つのタスク/12の要素（第62回 持続可能なWebサイト開発を支える12の要素）」。その下は，人的配置をロール(役割)ごとに記述しています。その下は，大まかなタスクのレベルです。それぞれの期間内に処理すべき項目を列挙しています。その下が，「ステージ」。プロジェクト全体を12のステージに分類して作業内容を整理しています。基本的には，その流れの順で進んでいきます。その下は，それぞれのステージのアウトプットのイメージで，更にその下にはよく使うファイルアイ
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
プログラマの思索: Testlink設定メモ
TestLinkを運用する時の設定メモ。 TestLinkはRedmine以上に癖が多く、デフォルト機能のままではすごく使い辛い。 大人数でテストケースを厳格に管理しようとして、逆に使い辛くなっているから、基本は制限を緩めた方が使いやすいと思う。 #八朔さんへの援護射撃になるかな？ 【環境】 TestLink 1.7.4 【1】RedmineとTestLinkの連係 TestLinkテストケースが失敗になったら、バグ登録する。 この時、BTSと連携する重要な機能。 Mantis、Bugzilla、Trac、Redmineが連携可能だ。 BTSのURLを設定するだけでOK。 この機能を使うと、テスト実行画面で「失敗」ケースのバグアイコンからバグ管理IDを登録すれば、BTSのチケットへリンクできる。 更に、テスト結果画面にある「失敗したテストケース一覧」リンクから、NGケースとRedmineの
ASCII.jp：驚きのExcel 超早技ベスト15 これは便利！｜Excel達人の新定番テク60 知らないあなたは損してる！
マンネリ化した方法でExcelを使っていないでしょうか。実はもっと簡単で手早くできる技があるのです。使わないなんてもったいない。アナタの知らない「新」Excel技大特集！ 第1回は、手間を省いて操作をすばやく！ 今すぐ役立つ厳選早技15を紹介します。面倒な入力や編集作業をどんどん片づく！ 驚きのExcel 超早業ベスト15――インデックス 技1――表の早技 表の見出しを除いて列幅を自動調整 技2――入力の早技 支店名をいつも決まった順番でオートフィル入力 技3――入力の早技 「＝」の代わりに「＋」キーで式を入力 技4――入力の早技 セルを組み合わせて思いどおりに連続データを入力 技5――入力の早技 ながーい連番を一発入力 技6――編集の早技 ツールバーの［下線］ボタンで二重下線を引く 技7――表の早技 基本の行列入れ替えはボタンで 技8――表の早技 多様な罫線を使った複雑な表は「罫線なし」
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
第1回 テスト管理システムとは何か？ | gihyo.jp
はじめに TestLinkとは、オープンソースのテスト管理システムです。TestLinkは、Francisco Mancardi氏、Andreas Morsing氏、Martin Havlat氏を中心としたコミュニティで開発されています。元々は海外で作られていたソフトウェアでしたが、最近は日本でも徐々に浸透してきているようです。 本連載では、TestLinkの日本語化に携わっているTestLink日本語化部会の私たちが、このTestLinkの基本機能について順次ご紹介していきます。 今回はTestLinkのご紹介する前準備として、「テスト管理システムとは何か」「では、そもそもテスト管理とは？」といったことについて考えてみましょう。 テスト管理システムとは何か 「テスト管理システム」と言う言葉を聞いたことはありますか？ もしかしたら、「バージョン管理システムやバグ管理システムなら聞いた
プログラマーを採用する際に重視すべき10の資質
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます プログラマーが有するスキルには大きな幅があり、彼らの出身国や文化もさまざまであるため、プログラマーの素性や経歴というものはそれぞれ異なっているはずである。とは言うものの、プログラマーの優劣に大きな影響を与える資質というものも存在しているのだ。そこで本記事では、プログラマーを採用する際に重視すべき資質を10個選んで解説する。 ＃1：好奇心 優秀なプログラマーはものごとを「ありのままに」捉えるということをしない：彼らは、きちんと動作しているように見えるものに対しても、詳細を学ぼうとその中身に深く踏み込んでいくのである。そして彼らがそういった態度をとることで、存在すら明らかになっていなかった問題が解決されることも多々あり、それは通常、深刻な問
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
サービスインに間に合わなかった原因は何だったのか？
プロセスを改善するということ 開発プロジェクトの現場では、大なり小なり必ず問題が存在する。それらの問題は最終的に低品質、予算超過、納期遅延などプロジェクトの失敗につながることもある。この状況を打開しようとさまざまな手を打っている企業は多いが、その打ち手は必ずしも大きな成果を挙げているとはいえない。 よくある要因の1つに、問題が顕在化した際に安易に個人や組織・ツールを原因と特定し、対策を講じようとすることが挙げられる。個人を原因として対策を施した場合、問題は解決したとしても組織には何も蓄積されない。そればかりか、人格否定など別の問題を発生させることもある。また、ツールおよび組織についていえば、そもそもなすべきことを効率的に実行するために組織は編成され、ツールは選定されるべきだ。なすべきことをきちんと分析せずに、組織やツールに対症療法を施しても、成果が出ない場合が多い。 そこで、なすべきこと、
Mylyn＆Tracでリズムに乗ってタスクを大掃除♪
最小限の管理コストで最大の「見える化」を 近年「開発の見える化」が話題となっていますが、いざやろうとするとなかなか難しいものです。 模造紙を壁に張り付ける「タスク看板」などを利用してタスクの「見える化」を行っても、肝心のタスクの実行状況が見えなかったり……。そんなことはないでしょうか？ 本当にチームメンバーのタスクを把握できているでしょうか？ そもそも「タスク」とは、コーディングやテストといった純然たる作業や、故障処理、管理、仕様変更などの副次的な作業も含みます。開発を見える化する際に基本となる1つの単位です。 今回紹介するMylynとTracを利用すると、タスク取得→コミット、タスク取得→コミット、……というリズムに乗った開発で、作業履歴（ログ）を残しながら各開発担当者の作業内容を明確にできます。最小限の管理コストで最大の見える化を。世にも不思議なMylynマジック、とくとご覧ください。
「内部統制報告制度に関するＱ＆Ａ」の追加について：金融庁
平成20年６月24日 金融庁 「内部統制報告制度に関するＱ＆Ａ」の追加について 金融庁では、平成20年４月１日以後開始する事業年度から導入されている内部統制報告制度に関して、平成19年10月１日付で「内部統制報告制度に関するＱ＆Ａ」を公表しているところです。 その後に寄せられた照会等に対して行った回答例等を整理し、今般、「内部統制報告制度に関するＱ＆Ａ」に新たな質問・回答を追加しました。
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
InfoQ: 複数のアジャイルチームでのバージョン管理
複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント（イテレーション）だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図（壁張り用） この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
目標管理制度の問題点
Formation professionnelle en ligne
Access2007と相変わらずの毎黒ソフトっぷり：続きは自転車で…：SSブログ
Microsoft Access tips: Converting to Access 2007
PJ on Development