ブログ村

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業務用の書類、例えば契約書とか領収書はときめかなくても捨てられない。 漫画や小説や映画やアニメや音楽はCharlie的には飽きることがないので、いつでもときめいてしまうし(そしてこれが部屋の半分くらいを占めている)。

コレクターにとっての部屋には「状態」があって、そのステータスは3種類あるのだ。

1. 汚い：ゴミがある状態
2. 乱雑：モノが定位置に無い状態
3. モノが多い：コレクターにとっての片付けられた状態

コレクターの「部屋の片付け術」は、視点が違う @ Caq’s Blog

つまり、同じ体重でも「脂肪の多いブクブク状態」と「均整のとれた筋肉の美!」を一緒にしてはいけない、ということですね。

非常によくまとまっていると感心した。論の整理が上手だということは、おそらく片付けも上手くいっているに違いない。それに比べてうちは…

• ゴミを捨てたいが紙リサイクルの日に雨が降っていたり、不燃ゴミは2週に一度だったりで、その間に溢れることが。
  これを解決するには24時間ゴミ出しokな建物に引っ越すくらいしか思いつかないが、片付かないと引っ越せないので実現困難。
• 「定位置」を定めようにも絶対的に容量が不足してきている。 近く(歩いて10分の距離)にトランクルームを借りたが、持ち運びが容易なDVD BOXとか季節ものの衣類が少々動いただけで、書籍類は滞ったまま。
  自炊が鍵になるのだが、前に書いた通り、オートシートフィードスキャンは嫌なので進んでいない。
  (パラメータ調整にこだわる悪い癖はエンコも同様)
  書籍の電子流通化は全然期待できないし、困った困った。

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

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