ぶくま殿 extern

「ともに半径だから」と「言葉を与えられる」生徒と、(略) 「半径」という言葉が出てこない生徒とがいる。
(略)

言語化能力を磨くには言語化を徹底的に行うしかないと思う。問題を解くだけでも、読書をしてもダメである。書かないとダメ。
(略)

数学なら問題を解く際（計算を除く）、必ず思考プロセスを書かせる。自分で「解説」を作る感じ。 (略) 模試などで間違えた問題について「なぜ間違えたのか」を記す復習ノートを作成させる。

(comment) 元記事で使われている抽象化とは、上位語化、上位概念化のことではなかろうか。
牛⇒哺乳類、コーラ⇒飲み物みたいな。

思考を言語化する @ gen-uine

ネクサス7(nexus7)で開発者オプションを表示させてUSBデバッグにチェックを入れる方法 @ WEB HORIC.

現場のプロに聞く！ITエンジニアが生き残るために身に付けておくといい7つのスキル @ Layer8

Charlieが常々(自分も含む)自社のスタッフに望んでいるスキルと重なる項目が多いです。
根底は「他人を動かすコミュニケーション能力」ですかね。
挙げられている7つのうち「英語」は入力と出力両方に関わることで、その他は出力スキルと言えるのではないでしょうか。

• 英語
• 図解力
• わかりやすい文章が書ける
• 技術をお金に換算して話す技術
• お客様の悩みや課題に寄り添うスキル
• 人を巻き込むための4W1H
• スキルの掛け算

• 基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（前編） @ Publickey
• （後編）

• 知識ならば座学で学べ、ペーパーテストで測れる。
• スキルならば師匠について繰り返し練習することで身につき（上で述べたように座学で促進できる部分はある）、ポイントをしぼった実技テストで測れる。
• 資質だと持って生まれるしかなく、パフォーマンス全体の結果から想像するしかない。

それは知識ですか、スキルですか、資質ですか？ @ タイム・コンサルタントの日誌から

スキルの習得には師匠(対話性?)と反復が必要、とするとITエンジニアの育成の、何と難しい(環境である)ことよ。

「答えられない質問」への建設的な対処法4つ@ lifehacker.jp

「聴衆に助けを求める」は、少人数だとうまくいかない。
コンペとか全国支店長会議のように聴衆がライバルな状態でもうまくいかなそう。
技術研究会だったらよいかもね。

Charlieが院生時代に教授に教わったのは、全く答えられないわけではないけれど回答に厚みが足りないと感じたら「それには3つの考え方があります」と答えるワザ。
まず思いついた通りの回答を述べて、 次に全く逆のことを述べる。で、その比較を論じている間に3つ目の斬新な回答を考える、という。

• いち早く70%～80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話 @ "肉とご飯と甘いもの @ sotarok"
• 「まず仕上げる」という話 @ やまもといちろうBLOG（ブログ） (2012-01-06 00:53 added)

開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？ @ 達人プログラマーを目指して