IT業界でありがちな説明下手について - 文系プログラマによるTIPSブログ
横着しちゃいかんのです。 IT業界に限った話しではありませんが、説明下手な人っていますよね。 私がIT業界でよく日頃から感じている説明下手（質問下手とも言う）なエピソードについて書いてみます。 例 この話から私が理解できた部分 この話から私が理解できなかった部分 どうして話が伝わらないか どうすれば伝わったか こういう質問が返ってきたら説明下手かも！？ 雑感 例 やらないおさん、落ちちゃうんですけど、getHoge()のこの部分があれで、多分ああなんじゃないかと思うんですけど、どうすればいいですか？ ？？？？ え？ごめん。何の話？いきなりソースコードの具体的な箇所の話されても理解できないから、落ち着いて順を追って話してみようか ※ 以降、質問をする側を「やるお」、される側（私）を「やらないお」とします。 ※ getHoge() メソッドはやるおが自分で作った独自メソッド。当然やらないおは知
資料を何度も作り直させるのは三流以下の仕事 | サイボウズ式
【サイボウズ式編集部より】この「ブロガーズ・コラム」は、著名ブロガーをサイボウズ外部から招いて、チームワークに関するコラムを執筆いただいています。今回は「My Favorite, Addict and Rhetoric Lovers Only」のファーレンハイトさんが考える「成果につながる仕事の依頼の仕方」についてです。 チームで仕事をする際に避けられないのは「仕事の依頼」です。 自分が仕事の依頼をすることもあれば、誰かから仕事を依頼されることもあるでしょう。チームワークが難しいひとつの理由に、優秀なプレイヤーは、優秀なワン・オブ・チームメイトでは必ずしもないという点が挙げられるでしょう。それが顕著に出る一例になります。 同時にこれは、組織における「教育」という側面に密接に関わっています。日本企業の多くは小さいタスクを新人や後輩に任せることで、成長を促しながら実業務の負荷分散を行っていくと
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
「残業は上司の無能の象徴であって、本人の能力とは一切無関係」という認識が広まらないといけない: 不倒城
ちょっと今からシャドウボクシングを始めようと思うのだが。 言いたいことを最初に要約すると、以下のようになる。既出かどうかは知らない。 ・かつて「残業をたくさんする=真面目に仕事してる=仕事出来る」と評価する向き、というのはあったんだろう、と思う。もしかすると今でもあるのかも知れない。 ・それに対するカウンター的な議論、「残業は本来よくないこと」という認識も、最近はある程度一般的になってきたような気がする。 ・残業をたくさんすることと、仕事が出来ることはイコールで結びついてはいけない。これは当然の前提だ。 ・一方、残業が多いからといって「仕事が出来ない」かというと、それも一概に言えることではない。残業容認へのカウンターとして「残業が多い人=仕事が出来ない人」というレッテリングを行うのも、端的に言ってやり過ぎだし、逆効果だと思う。 ・どんな形態の残業であれ、それが発生してしまっているのは単に上
5分でよく分かるロジカル・コミニュケーションのポイント - GoTheDistance
ロジカル・コミニュケーションを考えるのにとてもぴったりのエントリが２つ並んでいたので、便乗させて頂きます。 「AともいえるがBともいえる」とか言う人の役立たなさ - Chikirinの日記 「Aしかない」とか極論を言う人の役立たなさ - プロマネブログ このように全く反対のことを２つ並べて考えるのが、最も思考訓練になると思います。「Aは最高や！」と「Aはマジクソ」の本が２つ並んでいる書店って気が効くなぁと思う。 何かを主張するのなら断定的であるべき 特にインターネットで顕著なんですが、何かを意見表明して主張をしたいなら言い切るのがベストです。ネットの文章はタイトルが全てとはよく言われますが、言いたいことが簡潔でないと伝わりにくくなりますし、読まれるかどうかも怪しくなります。読まれないと始まらないという、鶏卵問題がありまして。 実は「AともいえるがBともいえる」言説は、読者のためにならないこ
エンジニアとして大成したいならやってはいけない48ヶ条 - レベルエンター山本大のブログ
いろんなエンジニアを見てきて、成功パターンはそれぞれだけれど 失敗パターンはだいたい決まっている。以下、アンチパターン。 成し遂げるのではなく、中途半端で満足する。 自分の責任と考えず、人のせいにする。 よりよくしようとせず、現状維持を良しとする。 仕事を中心においていない。 自分の特徴を構築していない。同世代と比べてさしたる特徴がない。 生活習慣を重視しない。日々の積み重ねに価値をおいていない。 与えられたチャンスに乗っからない。やる前から怖じ気づく。 アウトプットの質にこだわらない。 自分を分析していない。強み弱みを問われても答えられない。 刺激よりも、平穏を求める。変化に弱い。 行動よりも熟考を優先する。考えた末に行動しない。 現在の仕事の進め方に疑問を持たない。既存踏襲が正しいと思っている。 チームへの貢献よりも、自分の仕事の進捗を優先する。 焼き畑農業的な人間関係。信頼の構築では
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
「ちゃんと」できる人なんていない - レジデント初期研修用資料
あってはならない「確実に」という作業指示 – プリウスに見るゴムホースの「組み付け基準」 という記事が興味深かった。 「適切」は難しい 「適切に」判断したり、「正しく」組み付けたりすることは、特にそれが100% に近い再現を求められた場合には、とんでもなく難しい。 詳細なマニュアルを作成して、現場にそれを徹底したところで、大きく「適切に判断を行う」と書かれた項目が残っていたら、かならず誰かが間違える。 「適切」な判断や「正しい」組み付けを現場に実現しようと思ったら、マニュアル本から「適切」や「正しく」といった言葉を追放すればいい。便利な言葉が禁止されれば不便になって、マニュアルを書く人は頭を抱える。抱えた頭で手順を見直すと、「正しく」やらなくても正しい結果にしかなりようがない、本来そうあるべき手順が見つかる。 困っている人は「正しく」やらない 最近部屋を整理していたら、棚の奥から研修医時代
マネージャになりたくないプログラマのキャリアパス
金曜日、KLab元CTOの仙石さんからありがたい話をいただきました。 話は、開発者の採用、教育、評価あるいは開発者の心構えなど多岐に渡りました。いくつも興味深い話がありましたが、個人的に一番聞いて良かったと思える話を紹介します。表題の件です。 若いプログラマの中には年をとってもマネージャになりたくないと言う人がいます。他人事ではなく自分もそのひとりでした。若い時にマネージャ志望のキャリアパスに語ることは、プログラマとしての自分の誇りを傷つける気がしていました。マネージャを偉いと見なす風潮が、技術に対する裏切りのような気分がしていました。技術者をマネージャより低いと位置づけるのが許せませんでした。 たぶんピュアだったのでしょう。そんな経験があるので、今でもピュアな若者は好きです。本物のプログラマになるには、技術だけに一心に向き合うピュアな期間が必要だと信じています。そして、技術に真摯に向き合
ネットワーク図の書き方 - Akio's Log
先月から出稼ぎで東京に来てます。毎年、プロジェクトの特性上、３〜４月に空きが出てしまうので、仕方のないことなんですが。 で、最近ネットワーク図を書く仕事をしているのですが、ちゃんとしたネットワーク図を仕事で書くのは初めてのことでしたので、「コツ」をつかむまでだいぶ時間がかかってしまいました。 その過程で、いろいろと参考にしたサイトをまとめてみます。 書籍 ネットワーク現場の教科書 改訂版 （マイコミムック） (MYCOMムック) 作者: IDG出版社/メーカー: 毎日コミュニケーションズ発売日: 2011/03/31メディア: ムック購入: 1人 クリック: 9回この商品を含むブログ (2件) を見るこれはネットワークの教科書 改訂版 （マイコミムック） (MYCOMムック)の実践編的な内容ですが、本当に役に立ちました。ネットワーク図を書く際には、物理構成図と論理構成図をきちんと分けて書か
ウェブ業界で起業したいならMarcoを目指そう | quipped
Marco Armentという人をご存知だろうか？ Instapaperという「ブックマークして後で読む」アプリの作者として知られており、アメリカで大人気のブログサービスTumblrの共同創業者でもある。彼は2010年にTumblrを離れ、今はInstapaper一本にしぼって仕事をしている。主な収入源は$4.99のiOS用Instapaperアプリで1、アプリのダウンロード数が常時ランクインしていることを考えると、十分生活できるだけの額だろう。 今日のお話は至極単純なもので、ウェブ業界で起業したい人たちは、Mark ZuckerbergでもSteve JobsでもなくてMarco Armentをお手本にするべきだという話だ。ここですでに納得なら、残りを読む必要はない。 ぼくがMarcoをお手本とするべきだというには、3つの理由がある。 Marcoがウェブプロダクト制作に関して平均的に能力
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
Page d'accueil
Dans ce témoignage captivant, plongez dans le monde d'un bénévole passionné par la solidarité. Découvrez comment son engagement envers l'entraide façonne un monde plus solidaire, où chaque geste compte. À travers des récits personnels et des expériences enrichissantes, explorez le pouvoir transformateur de l'entraide dans la construction d'une société plus juste et plus unie.
RFIとRFPの違い：ナレッジ！？情報共有・・・永遠の課題への挑戦：ITmedia オルタナティブ・ブログ
このところ提案書や企画書を書いたり、書かせたり、評価したりという仕事がいくつか続いている。その中で後輩からRFIとRFPの違いについて聞かれたのでそのときに自分なりに答えた事をここに整理しておく。 RFI（Requset For Informattion）とは、入札や調達の事前準備として、ベンダーに保有製品や提供可能なサービスの概要、あるいはその組合せや実績などの情報を提供してもらうための情報提供依頼書。したがってRFIへの回答は基本的にはできあいの製品カタログやパンフレット、事例集といったもので構成され、価格も精緻な見積もりではなく標準価格や参考価格。だからRFIの場合回答期限は１～２週間と短めになる。 そしてRFP（Requset For Proposal）は、ベンダーにシステムの提案を作成してもらうための提案依頼書。したがってRFPの場合は、提案の範囲や提案に骨子となる要件、そしてな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
まとめよう、あつまろう - Togetter
http://bukupe.com/summary/4855
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
Good night, Posterous