学習方法 = 遊ぼう、人に教えよう、習慣にしよう、できたことを振り返ろう
以前紹介した書籍
SOFT SKILLS ソフトウェア開発者の人生マニュアル [ ジョン・Z.ソンメズ ]
今年読了した最高の書籍 SOFT SKILLS ソフトウェア開発者の人生マニュアル [ ジョン・Z.ソンメズ ] - moke039のログ
で、書ききれなかった学習について、実践するために整理する。(28-30章) 結局、本をもう一度読み返すのが一番確実なのかもしれないけれど。
まずは、目標、目的、最も重要な点を見極める。全体像をつかむ。 遊んでみる。参考書から遊んでみて引っかかった点を学ぶ。人に教える。 目標を達成するまで、上記を繰り返す。
全部完璧に学び取るのは無理だ。必要なだけ学ぶのがいい。
抵抗感なく始めるには、遊び感覚が必要だ。集中しつつ、創造する。失敗してもゲームが終わるだけ。切り替えよう。
実践を通じた学びは記憶に刻まれやすい。人に説明することでより体系的に理解できる。
世の中はノイズだらけだ。どうしようもないことを思い悩んでも仕方がない。
自分にできることを少しづつ、懸命にやるだけだ。そして自分をいたわり励まし、楽しもう。
計画は悲観的に、バッファをもたせて最悪値で見積もろう。実行は楽観的に諦めずに取り組もう。
大きすぎるToDoに押しつぶされないようにしよう。それはノイズでしかない。
タイムボックスを使用したToDoをカレンダに記入しよう。1日10ポモドーロもできれば上出来だ。大きめ1、中くらい3、小さい5タスクを目標にする人、1日5タスクを目標にする人、いろいろだけど、欲張りすぎて無力感にとらわれないようにしよう。
報連相、雑相で、うまく周りにシェアして、モブプロ、スウォーミングでこなそう。
学びの成果は YWT で振り返ろう。
経験学習モデル「具体的経験」「内省的観察」「抽象的概念化」「能動的実験」も有効だ。
ポモドーロテクニックや習慣化を駆使して、少しづつ前進しよう。
日々の積み重ねが自己肯定感にもつながるはずだと信じて。
以下、印象に残った箇所の引用。
ざっと流し読みしてその世界に飛び込み、すぐに遊んでみよう。 何をしているかわからなくても気にしなくていい。 そして、実験し、探りを入れているうちにどのような疑問が浮かんでくるかを観察するのだ。 さんざん遊んでありとあらゆる疑問が浮かんだら、初めて本に戻って文藻を読む。 このサイクルを繰り返し、プレーしながら見つけた問題を解決するという目的のために 知識を少しずつ蓄えていこう。 最後に、自分が学んだことを誰かほかの人に教えて知識をセメントで封印しておこう。
どうすれば始められるか - 学び始めるための基本的な知識は何か。 テーマの幅 - 学ぼうとしているものの規模はどれくらいで、何ができるのか。 基礎 - 使い始めたあと、基本的なユースケースは何か、その技術を使うために知って いなければならない最も基本的なことは何か。 日常の用途の80%をカバーするためには、どの20%を学べばいいか。
全体像をつかむ スコープを決める 物理学をすべて学ぼうとしても、人生を全部かけても無理だ。 使える時間を考慮する。 成功の基準を決める 参考資料を見つける 学習プランを作る 目次を参考にどういう順で学ぶかを確認する。 リソースをフィルタにかける 全部詰め込もうと思わない。
使い始められるようにする方法を学ぶ 遊び回る 役に立つことができるところまで学ぶ 教える
書籍:エッセンシャル思考でも同じような点に触れている。
ノイズ──大多数のものは無価値である 万物の大半はほとんど価値がなく、 ほとんど成果を生まない。 少数のものだけが非常に役立ち、大きな影響力を持つ。 ──リチャード・コッチ(起業家、コンサルタント) 努力の量を増やしても、いつか限界がやってくる。それ以上努力しても成果が増 えないどころか、逆に成果が減ってしまう。「努力した分だけ報われる」というのは、 ただの幻想だ。残念ながら、世の中はそこまで単純ではない。 80対20の法則(パレートの法則)」という言葉を聞いたことがあるだろうか。 19世紀末に経済学者のヴィルフレド・パレートが提唱した法則で、成果の80%は 20%の努力に起因するという説だ。 リーダーシップ論の権威ジョン・c・マクスウェルもこう述べている。 「ほとんどあらゆるものは、徹底的に無価値である(9)」 努力の量と成果が比例する という考え方を捨てたとき、エッセンシャル思考の大切さが見えてくる。 よく遊び ストレス軽減、集中、多様性、創造 よく眠る 90点以外は捨てる。うまく断る。集中する。 読む、書く、 推敲=削除 凝縮 修整 抑制 アリストテレスは、仕事には3つの種類があると考えた。 1つは「テオリア(理論)」、すなわち真理の追究を目的とする仕事。 2つめは「プラクシス(実践)」で、実用的な行動を指す。そして忘れられがちなのが 3つめの「ポイエーシス(制作)」、仕事のやり方自体を指す言葉だ(2)。 ハイデガーは蛹が蝶になる喩えを用い、ポイエーシスとは今ある形を捨てて新たな形で 生成することであると述べている(3)。 計画 バッファ 仕事のスキル 道具を磨く 小さい始める 続ける
YWT Y:やったこと W:わかったこと T:(わかったことを活かして)次にやること(の候補)
自分で疑問を投げかけ、自分に教える。経験的学習モデルを回す。 「具体的経験」「内省的観察」「抽象的概念化」「能動的実験」
ToDo List を作らない。習慣にする。
タレント、プロダクトマネージャ、フルスタックエンジニア、スペシャリスト、プロフェッショナル
VUCAが溢れている現代、リーン生産方式が当たり前にできて、さらにリーン開発方式(=トヨタの主査制度)ができなくてはグローバルな市場で勝ち残れない。
- Volatility – 変動性
- Uncertainty – 不確実性
- Complexity – 複雑性
- Ambiguity – 曖昧性
医者、弁護士などのスペシャリスト・プロフェッショナルでも、定型的な作業、価値創造しかできないようでは生き残れなくなっている。 NTT研究所のニーズのない要素研究に巨額の投資が行われ、それなりの成果もあったようだが利益につながっていない例など、スペシャリスト・プロフェッショナルなだけでは市場に貢献できない。
タレント=変な人=主査には、独特の 目的、利益志向、付加価値創造 が行える、スペシャリスト・プロフェッショナルが求められている。
①一つの専門分野に詳しいエンジニアは普通のエンジニア ②二つの専門分野に詳しいエンジニアは立派なエンジニア ③三つ以上の専門分野に詳しいエンジニアは天下のエンジニア
と言うらしいが、専門分野が1つでも、スペシャリスト・プロフェッショナルからうまくエッセンスを引き出し、素早く目的を達成し価値創造できる 人材なんじゃないかと思う。 スペシャリスト・プロフェッショナルからエッセンスを引き出しているうちに、スペシャリスト・プロフェッショナルと対等に語れるようになり、専門分野も広がっていくのだろう。逆に広がっていかなければ、エッセンスを引き出せていない、自分のものにできていないということか。
第十条 主査に必要な資質── ①知識、技術力、経験、②判断力、決断力、③度量、 ④感情的でないこと、冷静であること、⑤活力、ねばり、 ⑥集中力、⑦統率力、⑧表現力、説得力、⑨柔軟性、 ⑩無欲という欲。要するに総合能力が必要。それは「人格」。
この中には可愛げというか人懐っこさというか、懐に飛び込まれても不快にさせない力がある気がする。それが⑩なんだろうか。
主査を活かす組織、仕組は、主査を中心に各分野のスペシャリスト・プロフェッショナルがフォローし、その周りをフォローするエンジニア・マネージャがいる。 主査はスペシャリスト・プロフェッショナルと、スペシャリスト・プロフェッショナルはエンジニア・マネージャとの共同作業を通じて、暗黙知を広げ、共感、刺激しあい、周囲のの反応や市場を見ながら、コスト、価値を見極め、市場から求められる技術を磨いていく。
このような組織を効果的に回していくための、評価・処遇をどのように行っているかの答えが読み取れなかった。
ソフトウェアエンジニアの育成、デザイナー、サイエンティスト、アーティスト
ソフトウェアエンジニアとして成長していくためには何を学ぶ必要があるんだろう。
どのように学べば効率的に知識、スキルの幅を広げていけるのだろうか。
それを明確にすることで後進を育て社会の継続的な発展に 貢献できないか。
そんな思いで自分の経験を思い返してみる。
良いコードがどんなものか、わかりやすさとはなにかをずっとモヤモヤとしていたけど、 コードコンプリートでのPPP(Pseudocode Programming Process)の解説などを通して、高凝集、疎結合とか防御的プログラミングとかモジュール境界について自信を持てるようになった。
またオブジェクト指向によるデータと処理のまとめ方、カプセル化、ポリモーフィズムなどを知り、 UMLで表現することでより大きなモジュールを扱えるようになった。
UML だけでコーディングができるようにはならないだろうし、集約記号は単なる気休め薬にしかならないと言うような興味深いコメントと共にスケッチとして素早く意図を共有するために、優れたUML表現を身につけることには意味があると感じる。設計も、設計図通りに作らせるデザインから、現場での交流を大事にするデザインに変わってきた。ここでUMLがなす役割は少なくないはずだ。
システム全体を UML で俯瞰しながら、モジュール、クラス、メソッドが高凝集疎結合になるよう、デザインパターンに近づけたり、デザインパターンから離れるようなリファクタリングを繰り返した。スペックアウトで要求、仕様を見つめ直した。
リファクタリングを支えるテスト駆動な考え方も重要だ。
そして簡潔なコードを書くための原則、SOLID原則やDRY、KISS、YAGNIなどでコードを磨き上げるプロセス、文化について思いをはせるようになった。
ソフトウェアエンジニアリング、デザイン、コンピュータ・サイエンスを学ぶうち、論理的には説明しきれない暗黙知の世界、歴史、哲学、文化、共感、美、職人技をソフトウェアにも感じるようになった。
https://v3.pubpub.org/pub/designandsciencej
ビジネスの限界はアートで超えろ! | GROVING BASE(グロービングベース)
サイエンス、エンジニアリングは論理的な課題解決。
定型的、因果的、再現性が高い。普遍。予測可能。
アート、デザインは感情的な課題解決・問題提起ねぇ……。
形式知はわかりやすさ故に軽んじられてしまうんだろうか。
非定型的、因縁的、再現性がない部分・予測できない部分が残り続ける。
エッセンスをうまくモデル化、可視化する力。80:20の法則からも少なくとも80%はノイズだと思っていい。
VUCAが溢れている現代、形式知化を待っていてはなにも始まらない。
- Volatility – 変動性
- Uncertainty – 不確実性
- Complexity – 複雑性
- Ambiguity – 曖昧性
形式知化されなくても何故かうまくいく機会をうまく捉えて行動していくしかない。AI、データサイエンスAgile/Leanの成功が、それを証明しているのではないか。
識者に聞く ソーシャルメディア進化論 | ダイヤモンド・オンライン
暗黙知を集団で共有し、形式知化して新たな形式知・暗黙知を生み出し成果を生み出す。知識創造のプロセスを素早く回すには、みんなで行動、共感するしかない。ただそれだと形式知化はあまり促進されないんだよね。暗黙知は失われやすいから形式知化して、どうにかしないといけないはずなんだけど。
こんな感じで、わかってるんだかわかってないんだかもわからないのに、生産性向上とか、イノベーションとかって狙ってできるもんじゃないな、なんて思い知らされるところもある。無駄なあがきかもしれないけれど少しでもこの社会がよくなればいいなって、楽しみながら頑張るしかないかなーって、お話でおしまい。
エンジニア、デザイナー、サイエンティスト、アーティストってレオナルド・ダ・ビンチにはなれないけど、憧れちゃうなー。
ボトムアップな設計ではだめなのか
清水吉男さんのもっとも素晴らしいところは、スペックアウトという言葉を生み出し、ボトムアップで設計を良くしていくことを肯定したところではないかと思う。リファクタリングという言葉もそうだが、今までの経験を活かしてトップダウンで設計を進めるとともに、ボトムアップで設計を進化させる・適応させる行為ももっと肯定されていくべきではないか。
個人的には第一版の方を持っているので、こちらの表紙のほうが思い入れがある。
(^-^)
USDMにそって仕様を書くと、How(実装) What(仕様) Why(要求) が関連付けて近くにきちんと書いてあるのはいいけど、仕様を全体的に読み解くのは結構しんどかったり、トレーサビリティマトリクス的にコードと対応させるのも難しくて、なんでこの本がそれほど評価されているのだろうかと思う。でもこの本の中で言われている通り、スペックアウトで実装を仕様に、仕様を要求に昇華させることで、設計、実装を改善することができるのではないか。
実装・仕様をうまく昇華できないままの なんちゃってスペックアウト では、ボトムアップで設計を改善するには至らず、ボトムキープのまま迷走しているのが悪いんじゃないかな。そういう点ではリファクタリングも闇雲にパターンを適用したり、コードをいじくり回して時間を浪費するだけなのは良くなくて、上位概念に昇華させて適用する必要があるんだろう。
Agileなプラクティス、XP のオンサイト顧客やモブプログラミングで暗黙知が暗黙知のまま共有しやすくなった。 Git のプルリクエストにWhat/Why(仕様/要求)を書くことで How(実装)と結びつけやすくなった。 チャットが普及し、単発的な事実を並べているうちにそれを昇華させて 文脈を読み取ることで、演繹的に説明する力がなくても帰納的に文脈を理解することが可能になった。
コミュニケーションのスピードとしてはこれらのほうが効率がいいんだろうけど、これらだけに頼りすぎると風化して忘れ去られるのが早かったり、体系的に伝えられず効率が悪いこともある。演繹的に伝える方法も学ばなければならない。
小さなスタートアップから始めて派生開発で育てていくのがセオリーになりつつある時代。影響範囲を考慮しながら仕様の統廃合を進めていく。そのためにはスペックアウト、リファクタリングのスキルが重要になっていくだろう。
サイエンスとしての公式・パターンが見つけられる前に、AIがデータサイエンスとして、公式・パターンが不明確なままの演繹的な予測も得られるようになっているから、どんな技術が重要になっていくかはよくわからないけど。
4K ディスプレイ最高
☆☆☆ FullHD ディスプレイ 4枚分は快適すぎる☆☆☆
今年、一番良かったと思っている買い物がこれ。
たしか2月ごろに買ったときには 46000 ぐらいだった気がするけど、半年で1万も安くなってる……。
まあ壊れても、次のが買いやすくて安心と考えようか。
最近、スマフォで読書したあと遠くを見たり、夕方ぐらいに目が疲れてきたりするとピントが合わず、ぼんやりとしか見えないことも増えてきたけど、老眼の兆しもなく視力1.2over を保ちづづけている自分にとっては、愛用のMacBookPro 2012 Retina を Display Menuというアプリで Dot by Dot で表示する環境が作業スペースが広く使えて快適だ。
MacBook Pro (13-inch, Mid 2012) - 技術仕様13inch ディスプレイで 2560 x 1600 = 232dpi 程度らしい。(https://testpage.jp/tool/ppi_dpi.php)
人間の目で識別できるのが300dpi 程度らしいから 15.6inch 4K 3840 x 2160 = 282dpi なら
もっと快適なのではということで、MBP2012では 4K 出力ができないこともあり、以下も購入。
(^-^)
Inspiron 15 7000ノートパソコン | Dell 日本
結局282dpi は見えないことはないけど、Windows10のデフォルトフォント 游ゴシック体が見づらいのもあって快適とはならず。ディスプレイ設定の[拡大縮小とレイアウト] - [表示スケールの詳細設定] で 115% を設定し、デフォルトフォントも変えるなどしてようやく快適な環境になった。 でもMBP2012 の Dot by Dot の見やすさにはちょっと劣るんだよな……。さすがApple というか、win10……。
# MBP 15inch は 2880 x 1800 = 226dpi 程度だからそれより広い環境を手軽に持ち出せると言い聞かせて高値のMBPを買わなかった自分を納得させている……。
# 120% 設定にすると、3840 x 2160 が 3200 x 1800 相当になり、MBP 15inch と短辺の解像度がおなじになるので、115% にこだわっている……。
で、話を最初のディスプレイに戻すと、28inch 4K は、FullHD(1920 x 1080) 14inch を4枚並べてるようなイメージなんだよね。FullHD 縦置きのマルチディスプレイを使っている人もいるけど、同じようなサイズは 4K ディスプレイ環境だと手軽に手に入ることになる。(実際にはベゼルの幅の違いとかでもう少し小さな画面になるかも……)。だからFullHD 12〜13inch のノートPC Dot by Dot 表示で快適な人には絶対おすすめできるんじゃないかな。机の奥行きとか、目線の移動量とかを考えても 40inch 4K って結構辛くて、28inch あたりが正解だと思う。視力悪い人だとそれでも辛いかもしれないけど……。
ってことで 28inch 4K ディスプレイが快適でよかったってお話でした。
参考:本文中に出てきたディスプレイサイズ値
Width | Height | dpi | |
---|---|---|---|
MBP 13.3inch | 2560 | 1600 | 232dpi |
MBP 15.6inch | 2880 | 1800 | 226dpi |
28inch 4K | 3840 | 2160 | 157dpi |
14inch FullHD | 1920 | 1080 | 157dpi |
15inch 4K | 3840 | 2160 | 282dpi |
15inch 4K 115% | 3339 | 1878 | 246dpi |
15inch 4K 120% | 3200 | 1800 | 235dpi |
スマフォも ASUS Zenfone2 Laser 6inch FullHD にしてるけど、こちらは 367dpi でDot by Dot 表示にする方法がなさそう……。できたとしてもやっぱり見づらいのかな……。
今年読了した最高の書籍 SOFT SKILLS ソフトウェア開発者の人生マニュアル [ ジョン・Z.ソンメズ ]
久しぶりに目頭が熱くなる良書だ。ソフトウェア開発を生業にしている人全員に勧める。
ソフトウェア開発者としての成功とはなんだろうか。それを手に入れるにはなにをすべきなのだろうか。
この本にはそれが全て書かれているっていうのはちょっと大げさだけど、そのぐらい惚れ込んでしまった。
自分のキャリアを見直し、市場価値を高める方法。新しい技術の効率的な学び方、生産性の高め方。
お金、健康を手に入れ、心を整える方法。 彼が数多くの失敗を乗り越え手にした成功の秘訣、習慣を惜しげもなく伝えようとしている。 暖かな気持ちでテンポよく読めるのは翻訳も素晴らしいからだろう。
これらの方法が唯一の手段ではないし、絶対成功すると約束するものでもないけれど、 彼と同じような失敗を、未然に防いだり、乗り越えたりするのに役に立ちそうと思えるものばかりだ。
私がこれまで読んだ書籍で最高のものを1冊上げるとすれば、 スティーブ・マコネルさんのコードコンプリートだ。 10年ほどこの業界で経験を積んできたからこそ共感できる思いもあれば、もっと早く読んでいれば苦しまずに済んだと思えるような示唆に富んだ内容ばかりだった。共感のあまり熱いものがあふれたこともあったかと思う。半年以上かけて上下巻を読了したときには、名著を見抜く目や、読書の習慣が身についたように感じた。
これを上回る良書だと言いたいところだが、ジョンさんによるともっとも優れていて最も影響を受けた本のリストとして、コードコンプリート、Clean Code、Head First デザインパターンを上げているので、コードコンプリートの偉大さは変わらないということだろう。 (^-^)
ジョンさんのいうとおり、優れたコードを書き、非常に低いレベルでコードを構造化するための包括的なガイドブックになっている。下巻最後の章、さらに情報を得るには に記載された書籍も、優れたものばかりだ。
ジョンさんいわく、Clean Codeは、コードコンプリートの知識を磨くとともに、その知識をコードベースと設計全体に活かす方法を理解するために役立つらしい。
Clean Codeはまだ読みかけだけど、アジャイルマニフェストの署名者の一人で、SOLID原則の提唱者、ボブおじさんの書籍はどれも素晴らしい。 私はデザインパターンを覚える前にSOLID原則をきちんと体得してほしいと思っている。
そしてデザインパターン。私はデザインパターンが有効に使用されているおかげで読みやすくなっているコードをまだ見かけたことがないから、デザインパターンがあまり好きではない。パターンを使う必要がない場面にまでパターンを無理やり使用して、可読性、メンテナンス性を落としているコードが多すぎると感じている。
必要に応じてパターンに近づく、パターンから離れることも考えてほしいと思うのだが、私自身もなかなかできていないように思う。
勝ちにこだわる。負けにもこだわる。
出口治明 (著) 仕事は“6勝4敗"でいい 「最強の会社員」の行動原則50
どれも未読だけど、なかなか興味深い。勝ち組と思われる著者たちだが、負けることの中でなにかを見出してきたから、
こんなタイトルの本を書いたのだろう。
勝ちにこだわる、負けず嫌い、完璧主義。結局負けることを恐れてなにもできていない。逃げて、休んで、言い訳ばかり。
負けたときこそ品格を保とう。大人として知っておきたい、負けても冷静でいられる方法 | ライフハッカー[日本版]
負けたときは素直に負けを認め、勝者を称え、自分の行動を振り返る。
人生の締切を迎えるまでは、何回でも勝負に臨めるはずだ。
たくさん敗戦を積んできたつもりだけど、まだまだ負けないといけないな。
変な勝ちにこだわりすぎてる気がする。