原因追求型のフィードバックをされると、気がめいる
原因追求型のフィードバックをされると、気がめいる：仕事が「つまんない」ままでいいの？（57）（1/3 ページ） 部下や同僚にネガティブなフィードバックをしなければならないことがありますが、伝え方に気を付けないと、相手のやる気を削いだり人間関係を崩したりします。本来、どのようなコミュニケーションをとるべきなのかをエンジニア視点で考えてみました。 何かしらの問題が起こって、部下や同僚にネガティブなフィードバックをしなければならないことがあります。 例えば部下が作ってきた報告書の品質があまり良くないとき。「この報告書の書き方は良くないよ」「○○を、□□に書き換えてくれる？」のように問題点を指摘し、改善するよう促すことがあるでしょう。 けれども、ストレートに指摘し過ぎると相手のやる気を削いでしまいますし、人間関係も悪くなりかねません。指摘される方も嫌なものです。ネガティブなフィードバックが続くと、
熟練者しか操作できない残念な社内システムが生き残る、もっと残念な理由
どこをどう操作したらよいか分からない。用語が意味不明。何度申請しても差し戻される――。 レガシー大企業の社内システムの残念さがたびたび話題になる。笑い話で済むならよいが、社員の生産性やモチベーション、ひいては維持運用する情報システム部門のプレゼンスにもかかわる由々しき問題である。今回は「残念な社内システム」の問題地図をひも解いてみよう。 「一見さんお断り！」の難解社内システム 決裁システム、経費精算システム、購買システム、人事システム。いざ利用しようと思い画面を開くも瞬く間に思考停止。差し当たって何をしたらよいかすら分からない。ユーザーフレンドリーとは程遠く、前時代感が満載のお世辞にもスマートとはいえない古臭い画面。直感的に操作できない。「歴史館かよ！」と叫びたくなる。 大企業に勤務した経験のある人であれば共感いただけるであろう。とにかく、とっつきにくく使いづらいのである。 パソコンの前で
ITベンダーの皆さん、それは「奴隷の満足感」「奴隷の成功体験」です
いつまで経っても、「うちは絶対に逃げないことで、お客さんから信頼されている」と自慢げに話す人が後を絶たない。誰のことかと言うと、大手SIerなどの経営幹部たちだ。客から「システム開発を何とか完遂できたのは、あなた方の踏ん張りのお陰だ」と“感謝”されて、たわいなく喜び満足感に浸る。その挙句には、そんなもの価値でも何でもないのだが、絶対に逃げないことを自分たちのブランド価値と勘違いする。 もちろん、客のIT部門がしっかりしていて、果敢に最新技術の導入などにチャレンジしたような案件なら話は別だ。客が様々な困難に直面した際に、SIerが全力で支えて乗り越えたというのなら、SIerの経営幹部はそれを誇ってよいだろう。しかし現実には、客の大企業や官公庁のデタラメな管理体制、とんでもない変更要求などで大炎上したプロジェクトでも、逃げなかったことを誇っているのだ。 本当に困った人たちだ。というわけで、私は
デジタルデフレーションに全部飲み込まれるニッポン
認証技術の標準化団体OpenIDファウンデーション理事長を務めている野村総合研究所（NRI）上席研究員の崎村夏彦君に話を聞きました。話題は去る6月21日に開催されたOECD閣僚級会合の労働組合諮問委員会のパネルディスカッション。インターネット技術諮問委員会（ITAC）委員でもある彼が出席したのです。 ディスカッションのテーマは「デジタルデフレーション」。デジタル革命による生産性の向上が、労働者の職を奪い、デフレーションにつながっているという考え方です。OECDの委員会で、そんな危機感を持って議論されているのに驚きました。 デジタル革命が労働者の職を奪いデフレーションにつながる 「デジタル革命」という言葉はよく耳にしますが、｢デジタルデフレーション｣は私も崎村君から初めて聞きました。すぐにネットで調べてみると、このところ徐々に話題に上ってきているキーワードの一つのようです。例えば、アメリカの
事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance
言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア
「技術のプロ」でも「業務のプロ」でもない、IT部門って何？
IT部門の存在感が薄れている――。そんな声を取材で耳にする機会が増えている。先日も、大手ユーザー企業のシステム構築を支援するITコンサルタントからこんな話を聞いた。「今、IT部門はサンドバッグ状態です。最近支援に入ったユーザー企業でも、IT部門は社内の利用部門からもITベンダーからも叩かれてしまっています」。 なぜサンドバッグ状態になっているのか。前出のITコンサルタントは、「IT部門が何のプロなのか」が問われていると指摘する。IT部門は一般に、社内の利用部門からは「技術のプロ」を、ITベンダーからは「業務のプロ」を期待されやすい。ところが最近は、どちらの面でも難しくなっている。 まず、技術の側面についていえば、ユーザー企業のIT部門はITベンダーに比べるとどうしても後れを取りやすい。しかも最近は、経営支援やマーケティングなどを開発対象にしたシステムが増えてきた影響もあって、利用部門のほう
ハンズラボ情シス、長谷川さんの「“情シス”不要論」 その真意は？
ハンズラボ情シス、長谷川さんの「“情シス”不要論」 その真意は？：情シス“ニュータイプ“の時代（1/2 ページ） 「一般論としては“情シスは衰退していくのがいい”と思ってるんです」――。そんな刺激的な言葉を口にしたのがハンズラボの情シス、長谷川さんだ。情シス自らが“情シス不要論”を唱える真意とは。 連載：情シス“ニュータイプ“の時代 「情シス」と聞くと、「上から降ってきた無茶振りを粛々とこなす人」「安定した社内環境を維持するための縁の下の力持ち」といった、受け身で地味なイメージがついて回ります。しかし、本来、ITで会社を支える情報システム部門はスーパースター的な存在であり、米トップ企業の情報システム部門は「攻める」「改革する」という旗印のもと活躍しています。 日本にもっと、“攻める情シス”を――。そんな思いから生まれたのが、新たなアプローチで企業を変えようとしている「情シス“ニュータイプ“
最低3年は会社にいなさいと言われ、3年毎に転職して行ったら40歳になったらオファーが無くなった件：吉政忠志の考える。行動する。改善する。：エンジニアライフ
23歳で大学を卒業し、某社に入社しました。良いオファーがあったので、転職しようとしたら課長から「お前、3年はこの会社で働け、石の上にも3年というだろうが」と説得され、4年いました。この言葉が心に響いたのですが、結果として違う理解で私は人生を歩いてきてしまったようです。 その後、3年くらいたつとヘッドハンターが来て「兄さん、いいのあるよ」と英語で言われ、ふふふこれでまた年収も役職もアップだ！と、釣られてほぼ3年おきに転職してました。 ちなみに、転職時に●百万円の契約金が積まれたりしたことも何回かありますし、基本的にはベース金額の増額で転職してきたので、実力で転職してきたと勘違いしていたんですよね、私。若くて目立ってたからゆえの高額オファーだったんです。サラリーマン時代は当時の社長から伝説的な給料と言われたりして、結構イイ気になってました。そして、6回の転職をし、いよいよ7回目になった時、突然
ITエンジニアとして2020年に向けて活躍するための3つの「習慣」
＠ITは2014年9月、日本のITエンジニアの現状や課題、技術への「思い」などを知るための読者調査を実施した。2000人近い読者から回答を得て、その結果の一部を記事としてすでに公開している。 このアンケート結果を元に、「IT投資が増加していくとされる2020年に向けて、エンジニアが技術との関わりを楽しみ社会でその能力を存分に発揮するために何ができるのか」について、現役エンジニアによる座談会が行われた。本稿では、座談会から見えてきた誰でもすぐに試せるスキルアップサイクルを紹介したい。スキルアップサイクルは下記の3つの要素で構成されている。 出席者は、日本マイクロソフトでエバンジェリストを務める井上章氏。デジタルアドバンテージ代表取締役の小川誉久氏。そして、co-meeting取締役CTOであり、「パブリッククラウドエバンジェリスト」としての活動も意欲的に行っている吉田雄哉氏である（以下、敬称
元ソニーCIOと対決前夜！ -【第2回】劣化の進んだIT部門の再建は不可能
今週は、通常の「極言暴論」とは趣向を変えた「極言暴論スペシャル」を4回に分けてお届けしている。日経コンピュータ誌上で、元ソニーCIO（最高情報責任者）で、現在ガートナー ジャパンのエグゼクティブパートナーを務める長谷島眞時さんとバトルを演じることになったので、それを事前に盛り上げるための企画だ。 長谷島さんはソニーのCIOとしてIT部門改革を成し遂げた人だ。その長谷島さんと誌上バトルを行うことになった経緯は、この極言暴論スペシャルの1回目の記事を参照してほしいが、話を丸めて書くと、長谷島さんはどんなIT部門でも改革できると信じているし、私は大半のIT部門は劣化が進み改革は不可能と断じている。そんなわけなので、一度ガチンコ対決をしてみようという話になったのである。 日経コンピュータでの誌上バトルは、10月2日号から「IT部門への“暴論”を斬る」と題する連載として掲載する。毎回、私の極言暴論を
CTOとか役員とかに関する基本的な知識 - UNIX的なアレ
CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ 先日のCTOエントリが結構反響あったので続きを書いてみます。いろいろな方のリアクションみていると、CTOとか役員とかそのあたりをもう少し理解してもらいたいなと思ったのが理由です。 役員って何？ これ結構勘違いされていますが、会社法における役員というのは取締役のことです。そのため、CTOだから会社法上の役員というわけではありません。 またそれと同様に、執行役員も会社法上の役員ではありません。取締役と執行役員を兼任しているケースは多いですが、これは社内におけるそれぞれの役割を分けているためです。 それでは取締役の役目は？ まず、重要なのは以下の点です。 取締役は単独で職務執行権限を持たず、取締役会の一員に過ぎなくなった 取締役 - Wikipedia 取締役という立場自体はそれだけで職務上の何らかの権
ITが奪う仕事、創る仕事：日経ビジネスオンライン
このコラムについて 機械が人間の雇用を奪っている――。19世紀の英国で起きたラッダイト運動以来、労働者と機械との“競争”は続いている。そして現在、各国で実際に雇用が機械に奪われる状況が現実のものとなってきた。このコラムは3回のシリーズでこの問題を取り上げる。1回目では海外の実証研究を紹介し、2回目で日本の現状について分析する。さらに3回目では、機械との競争の中で、これからの仕事の姿について考える。 記事一覧 池永 肇恵（いけなが・としえ） 法政大学大学院政策創造研究科教授 東京大学教養学部卒業。経済企画庁に入庁し、同調査局、内閣府国民生活局、男女共同参画局、厚生労働省、一橋大学経済研究所准教授などを経て現職。労働市場の二極化、地域の雇用と産業を中心に研究している。 プロフィール詳細
第28回 システム子会社が自主性を失って迷走
親会社から独立した情報システム子会社が増えている。しかし経営的に成功しているケースは少ない。うまくいかない理由のほとんどは，親会社が安易な発想で，子会社に仕事を任せていることにある。情報システム子会社には，社内の業務だけに対応するのか，それとも社外のビジネスも受注して成長を狙うのか，明確な戦略が必要である。その上で子会社に移った社員のモラルを維持し向上していくことが不可欠だ。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 金融サービス業のS社は管理会計システムの再構築に着手した。この仕事の責任者になった情報システム部のB部長は，業界でも画期的なシステムにしようと計画段階からはりきっていた。ところがいざ具体的な作業が始まってみると，システム要件の
【第15回】埋まらないシステムと業務の溝（1）～ITをすぐ「システム構築」から考えない
【第15回】埋まらないシステムと業務の溝（1）～ITをすぐ「システム構築」から考えない：三方一両得のIT論 IT部門がもう一度「力」をつける時（1/2 ページ） 企業に情報システムを導入する目的は、ユーザー部門の仕事が便利になるからでもなければ、IT部門の自己満足のためでもない。企業が最大限の利益を上げるためだ。本質を見極めずにやみくもにシステムを入れても失敗する。 わたしは、前職の製造業で入社以来システム開発や運用、企画、教育などに携わってきた。なかでも開発や運用の標準化に10年以上携わった経験が、わたし独自のあるべきシステム論の源になっている。本当に現場で役に立ち、しかも急激な事業環境の変化にも柔軟に対応できるシステム化とはどういうものか。 導入しても使われないシステム システムの標準化の目的は、システム開発の生産性と品質向上の双方を実現するものだ。だから、わたしは要領よく仕事を進める
エンドユーザーの要求は間違っている？
ムラウチドットコムの橋本昌巳氏（取締役システム担当）は，自社のECサイトの構築で，かつて次のような経験をした。 ある業務担当者に新機能が欲しいと言われて開発した。しかし，その機能を使うのはその人だけで，他の人は使わない。業務改善に寄与したかどうかも結局，分からなかった。担当者が異動すると，また「違うものを作ってくれ」という要求が出てきた。要求通りの機能を追加するうちにシステムはどんどん複雑化し，保守性が悪くなった。改修のコストも徐々にかさむようになってしまった…。 。 現場を取材していると，こうした要求定義（注1）にまつわる話は事欠かない（図1）。IPA（情報処理推進機構）のアンケート調査（注2）によると，9割の企業が「失敗プロジェクトの原因は要求定義にある」と考えている。野村総合研究所の堀崎修一氏（ITアーキテクチャーコンサルティング部 主任テクニカルエンジニア）は「業務要件の詰めの甘さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
世界で最も人材不足が深刻な国は日本（調査結果）
利来w66app-利来w66官网下载-首页