トップ  > メモ一覧  > カテゴリ「マネジメント」の絞り込み結果 : 3件

3件中 1 〜 3 表示  1 

No.4498【引用】ITエンジニアの力をフルに引き出してくれる会社の見分け方



ITエンジニアの力をフルに引き出してくれる会社の見分け方

会社全体の技術力は、その会社のCTO個人の技術水準で頭打ちになりがちだ。
なぜなら、 人間は、自分以上の人間を理解できない 生き物だからだ。
CTO以上に優秀なエンジニアが応募してきても、CTOがその価値を理解できずに、希望年収を割高だと感じて逃してしまうことがよくあるのだ。
また、CTO以上に優秀なエンジニアは、やがてはCTOの地位を脅かすことにもなりかねない。
そのため、CTOは自分以上に優秀なエンジニアの採用を割高...

引用元

更新:2012/06/17 02:20 カテゴリ: web開発  > マネジメント ▲トップ

No.1637 "自分がやったほうが早い"はダメ!マネージャがやってはいけない5つのミス

"自分がやったほうが早い"はダメ! マネージャがやってはいけない5つのミス

2009/10/16

 

マネージャの仕事の中でも重要なものに、部下に適切に仕事を任せる、というものがある。英語では"delegating(権限の委譲)"という。仕 事を丸投げしたり、介入しすぎたりしては部下も思い通りの仕事ができないことは容易に想像がつく。U.S.News & WORLD REPORTに「部下に仕事を任せる際の5つの間違い(原題: 5 Ways Managers Fail at Delegating)」という記事が載っているので紹介しよう。

1. 共通の認識を持たない

仕事が成功裏に終了した時のゴールは何かということを事前に部下と確認しなかったため、最後に出てきたものがあなたの期待したものと違っていたということはよく起こる。

2. 進捗管理をしない

プロジェクトの最初に話をするだけで、計画通りに仕事が進む……なんてことはない! プロジェクトに関与し続け、チェックすることはマネージャの有効な武器だ。進捗管理により、予定通りに仕事を進め、問題を早期に把握し、必要ならば計画を修正することができる。

3. 自分が出しゃばる

ときどき、マネージャが神経質になりすぎて、部下に与えた仕事を自分でやろうとすることがあるが、これは誰がその仕事の責任者かという点に混乱を生じさせ、部下のパーフォーマンスも低下する結果となる。

4. 自分でできることは自分ですべきだと思う

これは自然な感情だが、部下を十分に活用できなくなり、あなたの仕事があふれかえることになる。結果として、あなたがマネージャとして本来すべき仕事に時間をかけられなくなる。マネージングとは他人に仕事をさせることなので、あなたはその方法を学ばなければならない。

5. 不適切な人に仕事を任せる

仕事を任せる際には、地位に照らし合わせて誰にその仕事を任せるべきかではなく、誰がその仕事をできる才能やスキルを持っているかを考えよう。もちろん、その仕事を任せるべき人に、仕事を任せるのがいつも乗り気がしないならば、その人の職務が適切かを再検討しよう。

仕事を任せ、適切に介入することは、マネージメントの縮図と言える。やるべきことを考え、適切な人を選び、やってほしいことを正しく伝え、結果がでるようにフォローする、これがマネージメントというものだ。

引用元

更新:2009/10/17 21:45 カテゴリ: web開発  > マネジメント ▲トップ

No.1034 サイトリニューアル

リニューアルには気遣いと愛着を

6月9日というロックな日にブログを書くというめぐり合わせをうれしく思うモバイル班のロックマンです。

livedoorに入社して10ヶ月ほど経ったのですが、振り返ってみるといろんなコンテンツのリニューアルばかりやっていたことに気付き、今回はその私の考える「リニューアル」について書いてみることにします。

なぜリニューアルするのか


これはサイトによっていろいろ変わってくるのかも知れませんが、私がこれまでやってきたサイトリニューアルは、「これからこのコンテンツの停滞したPVや UUを伸ばすぞ!」という掛け声のもと、その第1番目の施策として「ユーザビリティの向上」を目的として行うリニューアルです。

その中身は
(1) デザイン・見た目のリニューアル
(2) 機能改善(使いやすくする)とか
(3) 新機能追加 とか

という表と裏の総見直しといったところです。

(1)と(3)について……これは次のいつかの機会にとっておきまして……今回は (2) 機能改善 (使いやすくする) についての考えを書きたいと思います。

「慣れ」をもつユーザーの行動パターンに沿って
無理なく機能改善


全面的に機能改善しようとするときに私が一番意識しているのは「ユーザーの今までの行動パターンに沿って、無理なくリニューアルして使い勝手のいいほうに誘導する」ということです。

いくら「使いにくい」と評判のサイトでも、その「使いにくい」機能や遷移で利用してきたユーザにはその中にも「慣れ」というものも発生していて、「初めて 使う人には使いやすいだろう」というような中途半端な改善は、「慣れ」ているユーザーにとっては「逆に使いにくくなった」という結果になりかねません。

なので、いくら使いにくいと評判の遷移や機能や見た目でも、リニューアルだからといって無闇に激変させるのは良くないと思ってます。

それがリニューアルの一番難しいところであって、重要な部分だと思います。「やるべき」か「そのままにするべきか」の判断に妥協なく時間をかけます。

それぞれの機能の挙動や遷移に一貫性がなかったり、無駄な部分があったとしても、「いままで利用してきてくれたユーザーの"慣れ"という利便性」を損なわ ない形で、「あれ、なんか使いやすくなった」と、ある意味では気付かれないくらいスマートに機能改善を私は図ろうと意識してます。

そこの手を抜くと結局は時間だけ使った「無駄なリニューアル」になりかねない気がするからです。

ケータイlivedoorニュースの場合


このような改善のわかりやすい例の一つとして、これは私が去年リニューアルしたケータイlivedoorニュースもそうですし、ケータイサイトでは定番になった次のようなフローがあります。

◎こんな既存のフロー
「記事ページに"コメントをする"のリンク」
↓↓
「コメント入力画面」
↓↓
「コメント確認画面」
↓↓
「コメント完了画面」

◎これを簡易化
「記事ページに設置されたコメント入力ボックスに
コメントを入力後、送信(書込)ボタン」
↓↓
「コメント一覧へリダイレクト」

気軽にストレスなく書き込めて、確認画面や完了画面があったことに慣れていた"既存ユーザー"でも、[削除] ボタンも見やすく設けてあげればフローを変えても不安は最小限にスムーズに対応できます。

ケータイlivedoorニュースのコメント欄の場合はログインしているかしていないかによってコメントできる、できないがあるため大きな効果はありませんが、サイト全体が成長傾向にある中で、コメント数も増加しました。

ケースはさまざま


上記の形はもはやケータイサイトでは定番なのですが、この場合の考えるべきは、記事ページ自体に入力ボックスがある関係でほかの項目も多くある関係上行数はとれません。基本的に最低限の枠、1行だけが自然でしょう。

この1行入力ボックスを利用する場合、50文字〜100文字くらいの場合が妥当です。

ケータイlivedoorニュースではヒトコト程度で気軽に書き込んでもらってサイトが活性化したらよいなあというスタンスでこのような形をとっていますが、同じコメントでも文字数を多く入力させたい場合はこの形は向かないかもしれません。

ボックスからユーザーに見える (視覚的に確認できる) 文字が少なすぎますし、入力した文字数が多い場合、しっかりと確認してから書込みたいため、気軽に「書込ボタン」を押せる必要がなく、むしろ、別ページ (入力画面) と確認画面も必要だったりします。

そうなると、書き込み・編集・削除系のフローは単に簡易化するだけでなく、状況により、フローは長い遷移の既存ままにせざるを得ないときもあります。

この場合は、完了画面での誘導 (リンク) をわかり易くするという対応も考えます。

書き込み・編集・削除系のフローに決まった判断方法はなく、新しい遷移が「"新規ユーザー"にはあきらかに使いやすいもの」であっても、"既存のユー ザー"にはどうか、遷移を変えても戸惑わないか、使われなくなってしまわないか、いろんなケースを考えて判断しなくてはなりません。

モバイルサイトはどうしても画面遷移のスピードが遅かったり、遷移が多くなってしまうことも多いため、ここには全神経を注いである程度時間をかけてあらゆる角度から慎重に決めます。

効果は未知数


ユーザー側だけでなく運営側への効果


また、これはちょっと違った視点なのですが、例えば新しくそのサイトを任され、リニューアルをして、リニューアル後も自分がそのサイトを運営していくので あれば、「妥協なき機能改善」は「ユーザーのための機能改善」だけでなく、「このサイトに愛着をもてるにする」ためにも大事なことかなと思います。

既存のサイトですと、すぐに愛着を持ってモチベーション高く運営することがどうしても難しいので、「隅々まで理解し、手を加える」という作業をすることで自然を愛着が沸いてきますし、「どんどん良くしていこう」というモチベーションを作ることができます。

小さなことですがこんなリンクの追加でも大事↓
画像

これはケータイならではの特徴で、検索流入の多い (初めて来る人の多い) ニュース記事ページではとても重要な考え方になります。

だいたいのプロジェクトは限られたリソースの中でやるわけで、開発の関わらない部分、簡単だけどめんどくさい部分もトライ&エラーでどんどんやっていかないとサイト自体成長しません。

ただ、こういった細かいことは"愛着"をもってないともしかしたら思いつかないかもしれません。

最低限死守すること


たぶん上記以外にも違った視点で見ることが出来ると思うのですが、リニューアルにはいろんな方面に効果を与えられる可能性があって、それは、ユーザーに対 してだったり、自分も含む運営側に対してだったり、さらには社内のほかのプロジェクトに対してだったり……その可能性を引き出すためには「手抜きしない」 ことが最低限、第1に死守するところかと思います。

実際に、リニューアルそれ自体一発で直後にPVやUUが激増するということは稀だけに、その「妥協なきリニューアル」をきっかけに"愛着とモチベーショ ン"を持ち、継続的に細かくユーザビリティを見直し続けることが、すぐにではなく、のちに「あのリニューアルは成功だった」といえる「すばらしいリニュー アル」が実現できるのではないかと考えています。
更新:2009/06/10 09:31 カテゴリ: web開発  > マネジメント ▲トップ
3件中 1 〜 3 表示  1 

FuelPHP

Mac

フロントエンド開発

web開発

プロマネ

マネタイズ

プレゼン

webサービス運用

webサービス

Linux

サーバ管理

MySQL

ソース・開発

svn・git

PHP

HTML・CSS

JavaScript

ツール, ライブラリ

ビジネス

テンプレート

負荷・チューニング

Windows

メール

メール・手紙文例

CodeIgniter

オブジェクト指向

UI・フロントエンド

cloud

マークアップ・テキスト

Flash

デザイン

DBその他

Ruby

PostgreSQL

ユーティリティ・ソフト

Firefox

ハードウェア

Google

symfony

OpenPNE全般

OpenPNE2

Hack(賢コツ)

OpenPNE3

リンク

個人開発

その他

未確認

KVS

ubuntu

Android

負荷試験

オープンソース

社会

便利ツール

マネー

Twig

食品宅配

WEB設計

オーディオ

一般常識

アプリ開発

Python

サイトマップ

うずら技術ブログ

たませんSNS

rss2.0