http://anond.hatelabo.jp/20170414101838 わかる。すごく正しいことを言ってる。でもこの人、出来ない人がどう生み出されていくかがよくわかってない。 出来ない人間って、とにかく自分の考えを否定され続けて、 しかもどう考えたらいいのかを示されないままただひたすら否定され続けるうちに 指示待ちになってしまう。自分で考えなくなってしまうもんなんだよ。 とにかく上司が短期で、待てなくて、ちょっとでも自分の思ったことと違っていたら すぐ口出しして直させるような職場に勤めてたら、人間誰でもそうなるよ。 前の会社で無能無能って言われて自信なくしてた人が、 考えを尊重されるようになって、半年くらいしたら実はすごく優秀な人でした、みたいな例をよく見てきたから間違いない。 だから、上みたいなことをいくら説明されても 自分なりに工夫しようとしたりすること自体を否定される環境にい
Creating the possibilities of humans and society, Like sports. CEO Dai Tamesue 人間と社会の可能性を拓く、 スポーツのように。 タイムというはっきりとした結果が出る競技を追求しながら、人間の限界はどこにあるのだろうかと考え続けてきました。伸び悩んだり、重圧に苦しんだりする中で、限界は自分自身の思い込みが作っているのではないかと、そう思うようになりました。 社会を見渡せばそんな出来事が溢れています。思い込みによって制約がかかり可能性が狭まっている。自分がスポーツと向き合ってきた方法が、人間と社会の可能性を拓く上で活かせるのではないかと思い、会社を始めました。 私は「スポーツとは身体と環境の間で遊ぶこと」だと定義しています。遊びには計画も、義務もありません。面白いから行われる自由な活動です。そんな「遊ぶ」という感覚が
アメリカにNeal Whittenという著名なプロジェクト・マネジメントのコンサルタントがいる。何年か前に、ボストンで彼の講演を聴いたことがあった。彼はその中で、プロジェクトが失敗する三つの主な原因を挙げていたのだが、それがずっと頭にひっかかって残っている。彼のいうプロジェクトの三つの失敗理由とは、以下のようなものだ： (1) プロマネのハード・スキル不足 (2) プロマネのソフト・スキル不足 (3) プロジェクト・スポンサーシップの不足 プロジェクトの失敗の理由がプロマネに帰されるのは、ある意味、当然のことだ。Whittenはプロマネの能力を、ハード・スキルとソフト・スキルとに分解する。ハード・スキルとは、知識や技法など、いわゆる座学で習得できる種類のものである。WBSだとか、PERT/CPMだとか、パラメトリック見積法だとかいった事柄で、これらは技術として移転可能なものである。わたしの
海外の外注先とトラブルが発生した。発注書で決めていた納期が守れそうもないというのだ。我々から彼らにインプットすべき仕様情報が不正確だったし、予定より遅くなったせいだ、と彼らは、いう。こちらから見ると、彼らが出してきた設計承認図や仕様書の品質が低く、かなりコメントをつけてやり直しさせる必要があった。おまけに、両者共通の悩みとして、われらがエンドユーザーである顧客がぐずぐずとなかなか決めず、リサイクル的コメントをつけてくる問題があった。だが、まだ設計の中盤なのに、じりじりとスケジュールが遅れていった。このままだと、下流工程の仕事にも影響が出かねない。 担当者は、プロマネに相談にいくつもりだった。だが、彼のチームのベテランは、それを制した。そのベテランは別プロジェクトに従事していたが、担当者のことはよく面倒を見ていた。 「いったい何を相談に行くんだ？」 －－このままだと2ヶ月近く遅れそうです。下
すぐに効果が出る 企業の採用面接では、自然な会話の流れから相手の強み（または弱み）を見極めたり、奇をてらった質問をして相手の反応を観察しようとする面接官が少なくない。 そんなのは全然ダメだと、グーグルのラズロ・ボック上級副社長（人事担当）は新著『Work Rules!』で語っている。 重要なのは、職種に合わせて体系的な質問をすることだとボックは言う。そして、このルールは、会社の規模や業種にかかわらず当てはまるという。 ボックは著書の中で、1998年のある研究論文を引用している。過去85年間のアメリカ企業の雇用データに基づき、どんな選抜方法が最も適切な人材の採用につながるかを数値化したものだ。 それによると、一番効果的なのは、知能テストと実際の業務テストの組み合わせ。そして2番目に効果的なのは、知能テストと体系的な面接の組み合わせだった。逆に体系的な質問をしない面接で採用された者は、その後の
売り上げがゼロのときもあった 岡島悦子氏（以下、岡島）：川鍋さんにも伺っていきたいんですが、今おっしゃっていた長く続く会社という意味では、まさに86年やっている会社の家業を継がれた。日本交通さんでの修羅場と、ご自身の成長みたいな話をお願いします。 川鍋一朗氏（以下、川鍋）：いちおうIVSなんですけどね（笑）。お2人の話を伺っていて、やっぱりすごくベンチャーだなと思ったんですよ。自分はあんまりそこに苦しみを感じてないというか（笑）。 私の場合は三代目なので、生まれて物心がついてから「継ぐぞ！」と決めて、それから逆算してどうしたらいいかって一生懸命考えたんですよね。 アメリカに行ってビジネススクールでMBA取らなきゃいけないし、その後はコンサルティング会社で働くのが一番良さそうだと。で、レジュメ的には絵を描いたので、小学校から慶応に行ったボンボンの中では、一応一生懸命やったつもりなんですね。
——B2Bの受注ビジネスにとって、顧客満足とはいったい何を意味しているのでしょう？ わたしは、久しぶりにお会いしたR先生にたずねた。R先生は半ば引退した経営コンサルタントで、人生の大先輩である。R先生が不思議そうな顔をされたので、わたしは続けた。 ——ご存知の通り、わたしの勤務先はエンジニアリング会社で、製造業向けに工場やプラントを建てるプロジェクトが主な商売です。仕事を受注してから、工場が最初の製品を作れるような状態になるまで何年もかかります。大勢の人間がかかわり、お客様だってずいぶんいろいろな部門の方が関わります。工務、設計、製造、保全、製品開発、購買、法務、セールス・・。このうちメインの担当部門は工務部門と購買部門ですが、工務部門はさらに機械・建築・土木・化工・電気・制御・ITという風に専門分化しています。とくかく、一口に『顧客』といっても、関係者が非常に多いんですね。 「結構じゃな
モバイルファースト室の山下(@tomorrowkey)です。 Androidアプリを開発していて、ふとした時に不具合を見つけたりしませんか。 クラッシュであればDeploygateやCrashlyticsなどでクラッシュレポートを送ることができますが、表示崩れを報告をするにはスクリーンキャプチャを撮ってメールアプリを開き、画像を添付して、送信する、といった手順が必要でなかなか面倒です 。 アプリを開発する側は不具合のあったスクリーンショットがほしい、不具合を報告する人は報告する手順がめんどうといったギャップを解決するためのライブラリを作りましたので、紹介します。 不具合報告する機能を作りました 冒頭のアニメーションgifで一通りの挙動を見ることができます。 このライブラリを使っているアプリを開くと通知領域に「不具合を報告する」という項目が増えます。 不具合を見つけた時にこの通知を選択すると
また、今回の対談のモデレータを、倉貫氏、鈴木氏とも交流の深い株式会社SyncThoughtの橋本吉治氏が務めました。 顧客企業と受託開発スタイル 橋本 ► 倉貫義人さんは、近著『「納品」をなくせばうまくいく～ソフトウェア業界の“常識”を変えるビジネスモデル』（日本実業出版社刊）で「納品のない受託開発」を提示し、話題を集めています。個人的には、この書籍は倉貫さんの試みの集大成で、開発者の幸せが顧客の幸せにつながる、1つの方法論を示しているのではないかと思っています。 この書籍に対し、ブログで「「納品」をなくさなくてもうまくいく」と反論的な感想を寄せたのが鈴木雄介さんです。お二人の考えの違いを突き詰めると、個別の開発現場でより幸せな開発を模索するヒントが得られるのではないかと思います。 では、まずお二人の会社と代表的な事例について紹介していただきましょう。 納品がなく成果で契約、IT部門がなく
IT Leaders トップ ＞ 経営課題一覧 ＞ CIOコンピタンス ＞ 市場動向 ＞ 『CMOはCIOの敵か』─プロトコルの違いを乗り越えよ CIOコンピタンス CIOコンピタンス記事一覧へ [市場動向] 『CMOはCIOの敵か』─プロトコルの違いを乗り越えよ 2013年11月26日(火)山口 邦成 リスト オムニチャネル対応を含め、自社ビジネスへのデジタル活用の巧拙が企業の業績を左右する時代が訪れた。そこでは、CMO（Chief Marketing Officer：最高マーケティング責任者）とCIO（Chief Information Officer：最高情報責任者）は、いかに連携すべきか。本稿では、その視点や方向性について解説する。 （山口邦成 アクセンチュア 製造・流通本部 シニア・マネジャー） 少々誤解を招きかねないタイトルではあるが、そもそもCMO（Chief Marketi
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
わたしが以前から所属している「生産革新フォーラム」（Manufacturing Innovation Forum、通称「MIF研」）は、中小企業診断士を中心とした生産系コンサルタントの集まりである。毎年2回、工場見学を実施することをモットーとしており、昨年夏には慶応大学管理工学科の学生さんたちと合同見学会を実施したりした。製造現場をほとんど全く知らない学生と、それなりに経験を積んだ診断士では当然、同じ工場を見ても目をつけるポイントが違う。しかし学生さんにも素人ならではの意表を突く着眼点があり、交流してみるとなかなか楽しい。 そのMIF研で、もうけっこう前になるが、九州までの工場見学旅行があった。二日がかりでトヨタと日産の工場を一日ずつ回って見学し比較する、という興味深い企画で、わたしも行きたかったのだが、諸事情で参加できなかった。ただ、行ってきた仲間の報告が、とても面白い。トヨタと日産の生
住居が決まっているので久しぶりにのんびりした週末。3週間ぶりにコーヒーを入れてみたり。 午前中にアリさんマークの引越社が見積書を持ってきてもらうという話だったので、待つ間荷造り。マンガの多さに心が折れそう。一般書籍も500冊あったが、マンガもそれくらいあると思われる。マンガも裁断・スキャンしたいのだが、これはどう見ても引っ越しまでに終わらないので断念。 結局見積書を最終的に持ってきてくれたのは18時過ぎ。まあ、おかげで荷造りが多少捗ったけど……。なにが問題だったかというと、複写式の見積書なのだが、お客様控えを担当の方が持って帰って行き、自分のところに残っているのが本来向こうにないといけなかった書類だったという。自分もこういうミスやりそうだし、担当の方にちょっと同情。 404 Blog Not Found で紹介されていた「ハカセといふ生き物」を買って読んでみる。 研究者マンガ「ハカセといふ
子供のころに身に着けておきたかった技術。 ①計画力 おおよそ、その仕事をやれそうな２倍くらいの時間を取る。 で、期限までの進捗の測り方なんだけど。 「期限の２０％の時間で 総量の３０％を終わらせる」 ←スタートが巧くきれているかをチェック 「期限の５０％の時間で 総量の６０％を終わらせる」 ←うまく運べているかをチェック 「期限の８０％の時間で 総量の１００％を終わらせる」 ←期限に余裕を持てるかをチェック と、３段階のチェックを入れる感じにしたほうがいい。 ②計画力２ 計画を立てる場合、１月、週ごと、１日～３日ごと と３階層くらいで計画を立てる人が多いと思う。 「今月これだけ仕事する」 「今週こんだけしごとする」ってのは、決めるのは簡単だと思う。 で、ここに加えて、 「１月あとのことを６０％決めておく」とか、「１週間後を６０％決めておく」ってことをしたほうがいい。 っていうのも、先の予定
Merry Christmas! ５年前から、大学でプロジェクト・マネジメントを教えるようになった。今年の前期は東大の大学院で、また後期は法政の学部3年生に教えてきた。それ以外にも、単発的に依頼されて話した事もある。個別のエピソードについては、すでに何度か書いたと思う。しかし全体として、何をどんな風に教えるべきか、いつも悩ましい。 悩む最大の理由は、大学生・院生が実務の経験をほとんど持たない事だ。共同で事に当たることがなければ、プロジェクト・マネジメントの必要性がピンと来ない。また、授業で例題を考えるにしても、ビジネスに関わるケースを採り上げづらい。だからいきおい、「たとえば、あなたが同期30人の集まるパーティの幹事になったとしよう」といった例になってしまう。 それでも、講義を数回聴いた学生は、しだいにその意義が分かる者が出てくる。アンケート用紙にも、「もっと早くからこういう話が聞きたかっ
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。 いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。 1. 基本設計 （推定所要期間＝20日） 2.1 ハード調達 （推定所要期間＝35日） 先行作業：基本設計 2.2 設置調整 （推定所要期間＝ 5日） 先行作業：ハード調達 3.1 詳細設計 （推定所要期間＝10日） 先行作業：基本設計 3.2 ソフト開発 （推定所要期間＝20日） 先行作業：詳細設計 4. 総合テスト （推定所要期間＝15日） 先行作業：設置調整、ソフト開発 さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネッ
Liquidated damagesという英語をご存じだろうか。地震による「液状化の損害」、ではない。Damageはダメージ、被害だが、複数形でdamagesになると、損害賠償を表す契約用語になる。これは主に納期や性能など、請負側が保証すべき義務を果たせなかった際の損害賠償金のことで、あらかじめ契約で規定しておく。とくに納期遅れに対して科せられることが多く、商社やエンジ会社など、海外との契約を多く取り交わす企業では、略して『リキダメ』などと隠語風に呼ばれる。もし英文の契約書にこの言葉を見つけたら要注意だ。 納期遅れに対するLiquidated damagesは、日数に比例して計算する。1日10万円とか100万円で、遅れた日数分をかけて精算する。ただし、一定の上限を定めるのが普通である（たとえば受注金額の8%まで、等）。大型のプラント建設プロジェクトでは1日1億円近いケースもある。厳しい条件
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
