実務能力というのは段取りのうまさなんだと思うんだ - やまもといちろうBLOG（ブログ）
取りまとめなど一人でやる仕事って、土曜日が一番はかどる。連絡をすることもされることもなく、考えることに没頭できるから。 仕事を進める上で、とりわけ多くの人が関わる事案というのは、仕切る際に結構進め方にコツのようなものがある。これが分からないと厳しいと思うのだが、実際にはあまりそういうのに無頓着で、ただ単に金が儲かればいいとか、サービスが期日どおりリリースできればいいと考えるマネージャーも多くて困る。自分のことを棚に上げていうけどさ。 でも、立場も役割も機能も違う人たちを集めて、何がしかの結果を出さなければならない仕事というのは実に多い。取りまとめる際に、利害は対立するし、共通の認識は違うし、問題に対する考え方も違う。これはしょうがないのだけれども、そこにプロジェクトがあって、人が集うからには方法論をある程度ノウハウ化しておかないと話を進められないと思うんだけどね。 ちなみに、私がそういう事
今のデザイナーに必要な10のスキル
見た目だけを考える仕事をしているわけではないという意味も含めて、「デザインする人」という肩書きのようなものを名刺に入れています。デザイナーと書くと、『外側』を作るというイメージのほうが強いかもしれないので、わざとそう書いています。両方とも意味は同じのはずですが、日本語で書くとちょっと印象が違うような気がします。どちらでも良いと思いますが、こう書くことで私自身は意味を重く受け止め、足りないことが多いですが、日々精進するきっかけになります。 最近デザインという言葉は考え方や仕事の仕方などあらゆるシーンで使われるようになってきました。ではデザイナーはどうでしょう。デザインと同じように意味が広がってきているのでしょうか。 Fast Company の「Beyond Design, 10 Skills Designers Need to Succeed Now」という記事でこれからのデザイナーに必要
分裂勘違い君劇場 - 「努力すればスキルが向上して上に昇れる」というのは幻想
なんですよ。 まさか、面白い仕事とおいしい年収をもらえるポジションにいる人たちが、豊かな才能と地道な努力によってそれを獲得したなんていうインチキを信じている人なんて、まずいないと思いますけど、念のため補足しておきます。 夢のない話なんですが、実際には、どんなに努力しても、人が育ってポジションにふさわしい人材になるということはほとんどないんですよ。現実はその逆で、「ポジションが人を育てている」というのが実態です。 プロジェクトリーダーの能力を身につけるには、実際にプロジェクトリーダーというポジションにつけられ、プロジェクトリーダーの権限と義務と責任を持ち、それに適応するために悪戦苦闘するのが、圧倒的に能率がいい。 平社員というポジションのまま、プロジェクトリーダーの能力を身につけようと努力する場合の数十分の一の努力と、数十分の一の時間で、プロジェクトリーダーの能力を身につけられるんです。下積
１４個の身も蓋もない仕事の法則 - 分裂勘違い君劇場
「単なる知り合い」と「人脈」は全くの別物である。人脈とは、自分のことを高く評価してくれる権力者のことである。 20代の時にあちこちに恩を売りまくっておけ。そいつらはいろんな組織で成長して権力を握り、30代半ばには、強力な人脈になる。 自分とは違うタイプの優秀さを持った人間を「無能だ」と決めつけて切り捨てるのは、致命的な機会損失である。 客観的なビジネスプランはたいてい役に立たない。自分の熱い主観を企画書にぶち込め。 みんなの良い意見を集めても魅力的な企画にはならない。優れた企画は、たいてい誰かの個人作品である。 目下の人間にも、上司に対するのと同じだけ敬意を払い、「さん」付けで呼んでおけ。自分の部下を「君」付けで呼んでいると、そいつが抜擢されて自分の上司になったとき、「さん」で呼ばなければならなくなるという屈辱を味わうことになる。 ほとんどの人は、建前ばかり並べて会議をするので、思考力が失
未来の転職が、過去にさかのぼって現在の自分を有能にする - 分裂勘違い君劇場
転職、すなわち中途採用の面接では、自分が過去に取り組んだ仕事について質問されます。 しかも、ごまかしがきかないよう、具体的な行動内容を、細かく聞かれます。 広く浅く訊くのではなく、何カ所か適当に選んで、狭く深く訊いていきます。 たとえば、エンジニアなら、過去に自分が開発したシステムにおいて、 なぜ、そのフレームワーク、ツール、ライブラリ、DBを使ったのか？ 他に、どのようなフレームワーク、ツール、ライブラリ、DBが候補として 上げられたのか？ 他の選択肢と比べて、どの様な短所と長所があるのか？ なぜ、他の選択肢ではなく、それを選んだのか？ 使う前に、どのように性能評価・検証したのか？ なぜ、ある部分を汎用的に作り、別の部分をハードコーディングしたのか？ なぜ、その設計だと、生産性が高く、トラブルのリスクやメンテナンスコストが低くなるのか？ もっと低くできる余地として、どのようなものが考えら
「プログラミング言語を理解するにはどうしたらいい？」という話を聞いて思うこと - 西尾泰和のはてなダイアリー
「プログラミングとか特定のプログラミング言語とかを習得したくて色々勉強したけど、いまいち理解できた感じがしない、何がいけないのだろう、何を学べばいいんだろう」という話を聞いて思ったこと。 それって、目的が曖昧だから達成感が得られないというだけじゃないのか？ 僕の今までの人生の中には「プログラミングを習得した！」と思える瞬間も「Pythonを理解した！」と思える瞬間もなかった。具体的な「Pythonで継続のある言語を実装できた！」とかならある。でも「継続の概念を完全にマスターしましたか」と言われるとそんな気はまったくしない。まだまだ先は長い。しかし僕よりはるかに継続に詳しい人たちが集まって継続に関する議論をしてたりするのを見ると、この道に明確なゴールはないことがわかる。どこまで行っても「まだ先がある」という感じが残るに違いない。 手段が間違っているのではなく、目的が間違っているんだ。「○○を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
