エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

Linuxコマンドの基礎の基礎

基本のコマンド

man

manコマンド。
manualの意味。
わからないことは、とりあえず、調べる。
調べ方がわからないと、学習できないからな。
思春期の子には、ちょっと刺激の強い言葉。

使い方

man コマンド

manの利用方法自体もman manで調べられる。
なんとも不思議な感じ。

less

画面表示制御のコマンドです。
ファイルの中身を確認するのに利用できる。

ls

listの略。
ディレクトリのファイル・フォルダのリストを表示する。

大抵、オプションの-lを組み合わせた、llを作っているところがある。
あとは、ジョークとして、slコマンドがあったりする。
タイピングミスした時にslが走るだけのコマンドだが、気休め程度にはいいかもしれない。

cd

change directoryの略。
ディレクトリを移動する際に利用する。

mkdir

make directoriesの略。
複数のディレクトリを作成できる。

cp

copyの略。
ディレクトリやファイルをコピーする。
ファイル日付を変更したい場合は、touchを使う。

mv

moveの略。
ディレクトリやファイルを移動する際に使う。

mv 移動前のパス 移動後のパス

rm

はremoveの略。
ディレクトリやファイルを削除する。
一度消すと復元できないので、十分に注意する。
windowsは、ごみ箱に行く習慣があるが、あれは悪習慣だと思うね。
消したつもりでも、実際消えてないのは、どうかと思う。

cat

concatenateの略
ファイルの内容を閲覧するコマンド。
lessと違って、すべての内容を出力する。

とりあえず

知らないわけではないが、とりあえず、基本的なコマンドだけ列挙。
lessよりもcat派。
たまにless使うけど、便利なので使うように心がけたいところ。

【SE稼業は忘己利他(もうこりた)】第11回 ヘタレのモチベーション 感想

gihyo.jp

きっかけ

よく見るようになって、共感することが多かった。
思ったことを書き留めておきたいがために、メモする。

内容と感想

はじめにのメモ

やる気やモチベーションは,自分が出すものであって誰かに出してもらうものではないでしょう。

同意。外的要因で下がることがあるかもしれないが、上がるのは内的要因に依存すると思う。
それに、何がきっかけでやる気が上がるか、本人ですらわかっていないことが多い。
それを理解せずに振り回される管理職は、結構いると思う。

インセンティブ(褒美)で人は動くか

他人に言われたり,迫られたりしただけで本気が出ることはまずない。
...
自分自身に火の粉が降りかかってきて初めて人は動く。

子どもを見ればわかる。
強制しても、進んでやることはない。
身の危険を覚えなければ、進んでやることがない。
海馬瀬人が海馬剛三郎の元で生きるために、過酷な教育を受け続けたのと一緒。

水を飲みたくない馬
馬を水飲み場まで連れて行くことはできるが,飲みたくない馬に水を飲ませることはできない。
イギリスの諺

無理やり言うことを聞かせるために、そういう環境に追いやっても、意図したとおり動くことはない。
イギリスにもいい諺がある。

木を見て森を見ず

要するに、目の前の作業に従事するばかり、最終的な目標を見失う。
よくあることだよね。
目的を見失わないように行動しても、いつの間にか五里霧中の状態にあるのは、ざらにある。

グランドデザインって書いてあると、某都知事を思い出してしまうが、書いてあることは、的を射ている。
何ができて目標達成か、そこまでの道のりとチェックポイントをしっかり立てることが重要だと思う。

個人戦が好きなあなたへ~個人戦と組織戦

昔にあった、別会社に委託した開発者の話を思い出した。

【海外:アメリカ】ソフトウエア開発者、仕事を中国企業に丸ごと業務委託したのがバレてクビに!仕事中はネットで時間つぶし | 日刊テラフォー

つまり、内部に知見やノウハウをためなかったためにそうなった。
解雇するのはいいが、組織も体制を考え直す必要があるということだ。
学習を怠った組織は、個人の裁量に任されるので、組織戦ではなく個人戦になる。
本当に組織戦をしたいなら、ノウハウをためることを組織側で考える必要がある。

信頼関係の修復

信頼関係は、簡単にできるものではない。
不条理と思える態度や行動を指摘しても、火に油を注ぐのは、容易に分かるはずだけど、意外と人はできない。
やるなら、必ず自省が先。

「なぜ?」の問いかけの先に本質が見えてくる

「なぜ?」と思うのは大切。
なぜがなければ、本質は見えずに場当たり的対処になる。
それには、同意だが、付け加えると、方向性の問題もある気がする。
頓珍漢な方向に「なぜ?」を進ませることがたまにあるから。

「なぜ?」の回数が少なくなったら、自分の想像力・開発力が衰退し始めたと感じるという考えが、自分にはなく、面白い考えだと思った。

もの柔らかな返答は怒りをそらす

仁義礼智信」の5つの徳性が、大切であることを説いている。
これを実現したのは、歴史上だと三国志劉備な気がする。
現に、今でも劉備は、信仰を集めている。
いかに大切かがよくわかると思う。
最近、D.カーネギーの本を読むようになって、劉備の評価がとてつもなく上がっている。
ちなみに、読んでるのは、以下の本

人を動かす 文庫版

人を動かす 文庫版

失敗に学ぶ効用

野球はミスをするスポーツです。ミスをなくそうとムダな努力をするよりも,ミスから学ぶことのできる選手のほうが,成長が早い。それなのに,ミスをした選手を怒鳴りつけたり,罰練習をさせたりするのは野球というスポーツがわかっていない証拠です。ミスをすると,どうして失敗したのか考えるチャンスになります。次にミスを減らすための練習に熱が入ります。
桑田真澄

桑田真澄の文言が、非常に心に沁みる。
これは、野球選手に限らず、開発者としても持つべきマインドな気がする。
ソフトウェア開発もミスするもの。
ミスから学ぶ体制を作ることが大切やね。

感想

最後の一文にあった言葉が、大切だと思った。

「一緒に考えよう」の一言が言える人間でありたいものです。

一緒に取り込める開発者が欲しいのは、だれしも同じだと思う。
独りぼっちは寂しいもんな
佐倉杏子は、これを意図して言ったのだろうか?
一人にさせず、親身になって問題に取り込んでやることが大切だと思った。
子育てにおいても、開発においても。

子育ては、したことないんですけどね!
そう考えると、親は偉大だと思う。

設計書からコードを自動生成して起こることメモ

問題

分業できない

自動生成にロックインしてしまい、自動生成の仕組みを理解してないとレビューができない。
設計書にどう書くかが問題になり、なかなか話が前に進まない。
大機能単位で、別々の会社に分割すると、設計がやりづらくなるだけで終わる。

問題が先送りされる

設計ばかりに注目され、問題がなかなか現出しない。
単体レベルの問題が出せない。
さらに、自動生成するツールができていない場合、製造に落とす作業ができず、暗中模索してしまう。
いざ、製造になって、根本的問題が発症する可能性が高い。

開発者が軽視される

製造の問題点を指摘しても、自動生成でどうにかなるからで終わる。
こうあるべき論を述べても、どうにもできない。
コードが成長しても、ずっと同じ構成を続ける。
リファクタリングが受け入れられず、設計の改良ができても、コードへの改善が行えない。

設計書が人のためではない

読む人のために作るような設計ができない。
すべてなんらかのフォーマットで書かないといけない。
柔軟な表現にかけるため、理解がしづらくなる。
表現の幅が減ると言ったほうが正しいかも?

どうあるべきだったか

定型的データ構造

適用するなら、定型的なデータ構造のコード生成だけだと思いました。
変更がすくない箇所への自動生成は有効。

仕様書は、変更が入ること前提なことがおおいので、自動生成の対象にすべきではない。
区分値とか、コード定義とかが有効なのかもしれない。

それ以外は

やったらダメだと思う。
知的創造の分野と、単純な繰り返し項目(自動化できる場所)は、きっちり分けるべきだと思います。
知的創造の分野を自動化した結果、人が分からなくなるでは意味がない。 知的創造の分野を自動生成するのは、早すぎる分野かとおもう。

JJUGナイトセミナー Java API訴訟問題を考える 参加報告

概要

イベント趣旨

2012年、OracleGoogleが「Android OSにおいてOracle著作権や特許を侵害している」として訴訟をおこしました。
その後、Googleによる著作権侵害が認めらえたあるとされたものの、2016年5月には「フェアユースの範囲である」とされました。
この件について考える勉強会を行いたいと思います。

内容

初のMS開催!

日本マイクロソフトで初開催。
久々に行ったけど、場所は案外覚えていて、方向音痴だけど迷わず行けた。
品川の人混みは、ちょっと吐き気を催す。

そこには。

寺田さんが元気に会場整備。
あまりに違和感がなく、最初は気づかなかった。
心なしか、元気そうであった。

Oracleが訴えるまでの経緯について~SunとOSSIBMAndroid

www.slideshare.net

Javaのエコシステム

  • 標準仕様と各社別の実装
    • ベンダーはJava標準APIを実装した製品を販売
    • 仕様標準によるロックイン回避
      ただし、ベンダーの差別化による追加実装はあった
  • 仕様の策定がオープン
    • 仕様はJCPを通じて作成
    • 標準認定にはSunによるテストが必須&お布施が必要

今のOpenJDKやOracle提供のJDKしか知らなかったが、昔はベンダー各社で提供がされていたのか。
アンチMSの考えが発端にあるのは、なんとなく理解できる。

OSSのエコシステム

Apache Software Foundation

1999年設立されたオープンソースを支援する任意団体
Apache Software Foundationの元、色々なOSSが開発された。
Struts, Tomcat...etc
また、基本的にAL2.0で商用利用可・非公開OKが魅力的だった。

IBMとASF

OSSを戦略的に活用して、IBMが飛躍
OSSで実装を共有し、標準化
実装ベースでの標準化に成功

コミュニティベースのイノベーションが起こり始める

JavaOSS

  • 2005年5月 Project Harmony提案
    • 目的は、AL2.0でJava5の実装提供
    • 賛同する企業が多数出現(BEM, IBM, Intel...etc) → 反MSの流れ?
  • 2006年10月 ApacheHarmony爆誕
  • 2006年11月 Sunが反抗してJ2SEOSS
    • のちのOpenJDK
    • ただしGPLv2(コード公開義務あり) → ベンダーの不満が溜まる
  • 2006年 Sum vs Harmony
    • Harmony:制限外せ!!
    • Sun:やだ!! → お布施が欲しい?企業の財政的に厳しかった裏がある?
  • 2007年8月 SunがTCK*1を公開
    • テスト対象がGPLv2である必要があり、実質OpenJDK専用
    • Apacheが抗議活動をし、JCPでのJSR承認に全て反対 → 似たような行動を日本のどこかの政党で見たことがある気が。。。

意外と子どもっぽい言い争いな気がしてきた。
牛歩戦術って単語が出てくるのでは?と期待してしまった。

AndroidJava

2005年頃からGoogleAndroid戦略として動き出す。

目的

  • 打倒MS
  • OSSによるキャリアとメーカーへの価値提供
  • ユーザの囲い込み

Androidの普及

  • 無料で使えるOSにベンダーが乗っかる
  • ソフトウェアの対価よりユーザ数が欲しいGoogle

両者の思惑が一致したために、普及した。

Android以後

Sun の OSS 戦略は失敗

  • 2009年4月20日に Oracle に買収
  • 2010年8月、OracleGoogle を提訴
  • 2010年10月、IBM が OpenJDK に参加
  • 2011年11月に Harmony は活動停止

個人的な考え

GoogleによるJavaの分断は、SunがJavaを完全OSS化しなかったための流れ。
本来はプラットフォームで分断化されるリスクは最小化すべきだと思いました。
※分断の意味があっているか、若干不安。。。

この流れを知ったうえで、裁判を起こしたOracleを見ると、
Androidへの嫉妬な気がしてならない。
(JavaMEより成功しているのが気に食わないのかな???)

AndroidをJavaMEにしちゃて、取り込んじゃえば?って思わなくもない。
そもそも趣向が違うので、無理な話かも知れんが。。。

歴史的な背景は、これにて終了!


Oracle vs Google訴訟の全貌と概要 ~API著作権で保護されるべきか~

www.slideshare.net

Oracle vs Google 裁判の論点

  1. 特許権侵害 → 解決済み
  2. Javaライブラリ実装コード本体の無断複製 → 解決済み
  3. JavaAPIの著作権侵害 → 論争中(本日のお題!)

APIの利用はフェアユース*2かどうかが論点。

法律議論の注意点

  • 解釈論
    法をどう捉えるか
  • 立法論
    どういう制度であるべきか

法律を語るには、両者を区別する必要がある。
今回は、解釈論について。

著作権とは

著作物の利用について、一定期間の独占権を認めることが、著作権の目的。

法律では、保護と利用のバランスを取ることが大切。

著作権の大原則

  • 申請しなくても創作したら自動的に生じる
  • 表現を保護するものであって、アイデアを保護するものではない

超そもそも論(立法論)

なぜプログラムは著作権で保護されるのか

本来は、芸術のための法律で、技術分野とは縁が薄かった。
1980年代にソフトウェア発展とともに、保護が急務になった。
なので、やっつけで芸術と一緒にされてしまった!!
日本は、別アプローチで法の保護をしようとしたが、米国のご威光で同じく一色単に!

日本と米国の裁判の違い(Break Time!!)

日本

法律を重視。 → 解釈論を優先する
裁判結果は予測しやすいが、技術変化への対応が遅い。

徳川200年の歴史を持つからなのか?
法を守ることに重きをおく。
法を作る人間が優秀で迅速に行動できる人である必要があるな~と、今更なが思う。

米国

公正さ(フェアユース)を重視 → 技術変化への対応が早いが、裁判はやってみないと分からない

さすが、自由の国!
自由競争が重視されたからこその考えかもしれん。
国民性がでるなと感じた。

米国のフェアユースの考え

社会にメリットがあると判断されればフェアユースとなる

同人誌を訴えたが、同人誌のおかげで売れるようになった → フェアユースが認められる
ベータマックス裁判でのタイムシフト録画 → 市場に害があるとみなされないためフェアユース
※日本だと法律に書いてあるので、合法

ベータマックスが、ベイゴマックスに聞こえてしょうがない!(余談)

米国は、裁判の結果が法律化するので、技術変化への対応が早くなる仕組み。

フェアユースの両者の言い分

Oracle

  • Javaを使って金儲けしすぎじゃ!(俺に分前をよこせ!)
  • フェアユースは報道、教育、研究に適用されるもの
  • スマホでの出遅れを卍解するためにJavaの資産を使った

Google

  • API の再利用はイノベーションの源泉
  • Javaは、みんなが使えるオープンなもの(空気のような存在?)
  • Oracleはライセンス料が欲しい小銭稼ぎ

訴訟戦略

陪審員が技術系のトーシローなので、感情に訴えて勝つのが、戦略としてあるらしい。
ここは、日本の水戸黄門のライターの出番な気がしてならない。

Googleは、そういう点だと、非常に有利かな~と思った。
Google検索は便利だし、利便性の良いサービスをフリーで提供してくれるし。
FinTechでますます世間の印象がいい。
Oracleがかなり不利な気がする。
ただし、日本では感情論に訴えても意味が無い。法が絶対だから。

Q&Aであった面白い考えや意見

今後のスケジュールは?早くて何年に終わる?

早ければ2、3年で決着
それまでの間、Javaが停滞しないか、ちょっと心配。

コミュニティから裁判するなという働きかけはなかったのか?

Oracle の人気がなさすぎて『何やってるの Oracle』という考えが主流だった

API著作権を認めることでAPIヤクザがでるのでは?

何がいいたいかというと、APIを広めて、広まったタイミングで訴訟を起こす。

さそがにそれは止められるだろうという考えだった。

個人の考え

Googleがかなり有利だし、勝って欲しい。
感情論かもしれないが。
Javaをプラットフォームとして普及されるなら、もっと普及させる努力をOracleにはして欲しい思いが強い。
できれば早期解決を願う。

*1:Java認定のためのテストキット

*2:公正な利用であれば、その利用行為は著作権の侵害にあたらないという考え

【書評】SOFT SKILLS

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

Soft Skills: The Software Developer's Life Manual

Soft Skills: The Software Developer's Life Manual

きっかけ

プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blog

↑の記事を読んで、前から読みたいと思っていたが、手が出せていなかった。
日本語訳が出たのをきっかけに、日本語訳版を購入して読んだ。

内容

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

キャリアを築こう

スタートから派手に行こう!:誰もがするようなことはするな

事業者のマインドセット

ソフトウェア開発者のキャリア → ビジネスとして扱う
スキルは、個人の資産で、大切なもの。
事業主として考えて、資産を増やす必要がある。
事業主のマインドを持つと、スキルの棚卸しと必要なスキルの判断をするようになり、プラスに働くから。
(俺は、クリアマインドが欲しいッ!!)

どのようにして自分を事業と考えるか

事業として売るもの = ソフトウェア開発スキル
多くいる開発者の中で独自製品(特殊スキル)を持ち、差別化を図る必要がある。
そして、スキルは持っているだけでは意味が無いので、価値を伝える必要がある。

未来について考える:あなたの目標は何?

事業として考えぬいたら、次はビジネス目標を考える番。
何に力を注ぐべきか十分に考える必要がある。
特に、人間は何に力を注ぐべきか考えずに行動することがある。
何も考えずにポストに飛びつき、来るか来ないか分からないチャンスを待つ。
(「果報は寝て待て」を都合よく考えるやつが多いのもそれかと思う。寝て待つのはやることをやって、準備万端になってから。それをせずに寝たら、ただの時間の浪費だろうと思う。)

早く目標を決めて動く。
そうしないと、時代や周囲の人間に流されて無駄足を踏む人生を歩むことになる。

目標の設定方法

  1. 大きな目標を決める
    細かく決めなくていい。近づいたら細かく目標を立てる。
    重要なので時間をかけて考える。
  2. 途中にある小さな目標を決める
    大きな目標から現状に至るマイルストーンを考えてみる。
    そこから小さな目標を持つことで小さな達成感を得て、目標へ向けての動きを加速させる。

社交術:考えている以上のものが必要だ

放っといてくれ、私はただコードが書きたいだけなんだ!

優れたソフトウェア開発者 = 人と接するのが上手い
仕事の大部分は、人相手。コードを書くのが仕事であるとの考えは、間違え。
人と接することが大前提。

「大切にされている」と誰もが感じたい

人は、大切にされたいと根底で思っている。
(同意。大切にされたい。誰かもっと俺を甘やかしてぇ~!!!)

人と接するときは、基本的欲求を意識して、自分の行動がどう影響するか考えるべき。
(今のメディアはできていないことが多い気がする。)

何らかの形で存在を貶める → 限度を超えると凶暴な反応を見せる。
さらに、その反応をからかうのはNG。
余計エスカレートしていく。
(残虐な事件は、大部分がコレな気がしてならない。周囲の人間が無自覚でからかってえいる可能性もある。)

人に自分を認めて欲しいのなら、まずは自分から他人に礼を尽くす。
プライドを傷つけては、人心は絶対に掴めない。
(劉備もそうしただろう!三顧の礼は社交術の基本)

批判 → 行動意欲を削ぐ。
罰するよりも褒めることが重要。
人への批判は絶対にやめるべきだが、コードへの批判は積極的にする。
ただし、コードへの批判が、人への批判の隠れ蓑にならないようにする。
例えば、「だれこのウンコード書いたの?この開発者クソじゃね?」って言うとか。
(この例は、知り合いの知り合いの話だから!)

他人が望んでいることを考える

相手が望んでいることを考える。
そうすることで、人への批判が減り、好意と尊敬の眼差しを得られる。
会話も自然と相手中心で敬うものにハズ!

議論は避ける

人は、感情的な生き物。
必ず理解してもらえるわけではない。
大人は感情をコントロールできるようになっただけで、中身は子ども。
(大人がケンカしているところを見ると、子どもだということがよく分かる)

話が平行線になる場合は、自分の意見を諦める機会を待つ。
本当に大切な事を見極めて、許容できるのであれば、許容する。
貸しになり、次に自分が意見を通しやすくなる。

面接をハッキングするコツ

面接で合格するための手っ取り早い方法

気に入られるのが一番早い。
※最低限の技術力があればの話。

常識に囚われずに親密な関係を築く

採用 → 個人推薦があると有利
推薦してくれた人の社会的信用を借りることができるため、スタートから高く評価してもらえる。
(これを代理証明してくれるのは、ビジネスになるのではなかろうか?)

面接に必要なもの
  • 常識に囚われない考え
  • 社内の接点となるべき人との関係構築
    →何かのユーザグループに参加して発表すれば、ある程度コネが作れる。

本物の面接ではどうすればいいのか?

技術的に優れているのは、当然。
次に、求められていることを理解し、実行できることが求められる。

雇用者にとって、雇うのは投資。
仕事を頼まなくても終わらせる人が優遇される。
何事も進んでやる積極性が重要。

今すぐできることは何か?

  1. 技術スキルを磨く
  2. 人脈作り
  3. 面接練習

雇用形態:3つの選択肢を理解する

会社の従業員

メリット
  • 安定性
  • 責任範囲の限定
デメリット
  • 時間の大半を雇用主に捧げる必要がある(つまり、奴隷である)
  • 仕事が選べない
  • 収入の頭打ち

独立系コンサルタント

メリット
  • 自分で自由に時間を使える
  • 収入が増える可能性がある
デメリット
  • 仕事探しは自分で。
  • 負荷が大きい
  • 上司が増えるだけで、会社員と変わらないかも

アントレプレナー

ギャンブルに近い。時間と将来の可能性を利益と交換している。

メリット
  • 完全な自由
  • 大儲けができるかも
  • やりたいことができる
  • 上司がいない
デメリット
  • 完全自己責任
  • ソフトウェア開発以外のスキルが必要

あなたはどのタイプのソフトウェア開発者か

専門性はとても大事

専門分野を持つ = 多くのチャンスが得られる。
枠が小さくなる可能性もあるが、欲しい人から見ると魅力的に見える。
プログラミング言語は専門性とは言えない。ただ使う道具がそれですというだけ。

ソフトウェア開発者の専門分野

何を作るかはっきりさせておく必要がある。
特定分野に特化する → 高時給が得られる

専門分野の選択方法

どこまでやるか、できるだけ限定する。
そうすることで、限定的な市場での価値が高くなる。

多言語プログラマーはどうか

複数のスキル持ち → 貴重な存在だが、スキルが浅いと売り込みにいく。
多言語を極める前に、一つの言語を極める。
多才になるのは、その後。

どの会社も同じではない

小さな会社とスタートアップ

一人一人の会社への貢献度が大きい。
安定性に劣るものの、求められるスキルは広い。
早いペースで何かを作りたい・成長したい人が選ぶべき

中規模の会社

安定している。もしかしたら、大企業よりも安定しているかもしれない。
小企業よりリスクが負えず、変化のペースが遅い。
最先端テクノロジーが支持されるわけではない。

大企業

深い企業文化が存在している。
多数の手続きがあり、形式的で、確立されたやり方で仕事をする必要がある。
与えられるチャンスが多いが、成功しても貢献度が低い。
政治操作の餌食になる可能性がある。

ソフトウェア開発会社かソフトウェア開発者がいる会社か

アジャイルプロセスが適用されているかで見極める。
開発者主導で仕事ができることが、重要

出世階段の昇り方

責任を引き受ける

地位を引き上げることとは、責任を引き受けることである。
責任を求められたら引き受けるべき。
責任を負わせてもらえない場合、外に出て誰も関与しない場所を探す。
不毛な沼地を肥沃な大地に変える → 一番評価されて、真価が発揮できる
(なぜかMTGを思い浮かべた)

間接的に責任を引き受ける

チームメンバーの指導者、助言者になる。
他人の問題を解決することで、多くを学べる。

責任の重い仕事が回ってくるためにできること

  • チームメンバーの支援
  • プロセスのドキュメント作成・メンテ
  • 作業の自動化

(自動化は同意。楽なことをしてくれる人は、重宝されるし、アレコレ依頼される)

自分の存在を主張する

達成したことを誰も知らない → 何をしても意味は無い。

主張するためにできること
  • 仕事内容を記録して、要約した内容を報告する
  • 発表や講師
  • 声を上げる
  • 定期ミーティングへ必ず出席

勉強する

スキルと知識を磨く → 昇進昇格に有利
キャリア向上への真剣度を見せることができる。
ソフトウェア開発以外の知識を習得しておくこと。
視野が広がり、将来的に必要になる。

学習している事を知ってもらう → 自分の価値を高く見せる

プロであること

プロとは何か

責任を取り、キャリアを真剣に考え、あえて茨の道を選択する人。
重要なのは、首尾一貫とした考えを持ち、高品質を当たり前に考えて、基準を持っている人。

プロとアマチュアの違い

プロ
  • 原則に従う
  • 仕事を正しく終わらせる
  • 間違いと無知を認める
  • 責任を取る
  • 首尾一貫。言動がブレない。
    (リーダーで言葉と行動がブレブレの奴を最近見た気がする。ハゲとは言わないけど)
アマチュア
  • 仕事を終らせることに集中
  • 間違い・無知を認めない
  • 責任は取らない
  • 言動が変わる。

いい習慣を身につけてプロになる

プロ → 習慣から始まる
習慣は、安定性を築き、信頼性を養う。
継続的な自己研鑽は、高い品質と技術を得られる。

自由を得る:仕事の辞め方

上手な辞め方

上司に伝えるのは、賢いやり方ではない。
貯金があったとしても、すぐに火の車になる。
やめる前に現実的なプランニングが必要。
副業を初めて、生活を支えるレベルのことができるようになってから、そちらにシフトする。
考え無しで辞職 = 生活が苦しくなるだけ

独立して働くための準備

新しいことを始めるために辞職 → 辞めた方がいい。
なぜなら、必要な仕事を把握しておらず、辞めた時には遅い。
始める前に、ある程度成功させる必要がある。

新事業 = 必ず失敗する 成功させるために多くの失敗が必要になる。

フリーランサー:外に出て独立する

クライアントを獲得するための最良の方法

ブログを始めること。
コンテンツから自身の判断をしてもらう。 料金は、適当に決め手はならない。
生活に支障がない額を掲示する必要がある。
そのためには、競争力を持っていることが前提

初めての製品開発

クライアントの候補を見つける

顧客が見える製品を作る。
顧客なしの状態では、成功せず、売り込めない。
有名人は、名声を使って製品を売り込む。
できない人は、ブログで買い手を作らなければならない。

市場をテストする

買ってくれる人が少ない = 問題の定義がおかしい
前進しても大丈夫か判断したら進むと、上手くいけば顧客グループができるはず。

小さく始める

ものごとの最初 → 必ず失敗する
最初から大きく賭けても、失敗の可能性が大きいので、最初は小さくしてリスクを小さくする。

スタートアップを起業したい場合

スタートアップの基礎

規模の拡大と利益増大を狙う

大きく潰れるか

スタートアップの目標 → 大企業になること
リスクが大きいことをしなければいけないので、失敗の可能性が大きい。
(日本でスタートアップ企業がないのは、リスクを犯せない人間性から)

典型的なスタートアップ

知的財産を基礎にしている場合が多い。
一般的な方法 → 既に大企業が実践済み
大規模な潜在的価値の獲得が必須になる。

アクセラレータ

企業を成長させる人(ラノベに出てくる反射させる人ではない)
狂想は過酷だが、採用できればメリットが多い。

遠隔勤務サバイバル戦略

隠遁の課題

在宅勤務 = 課題が多い

  1. 時間管理
    誘惑が多く、計画立てないと時間だけが過ぎる可能性大
  2. 内発的やる気
  3. 孤独感

うまくやり遂げるまでは、できたふりをしよう

取り掛かる前からやり遂げたかのように行動する。
嘘をついて行動しろと言うことではない。
行動することが前提で、自身がないことで行動を制限しなさんなという意味。
難しい問題に挑み、やり方を覚えることが重要。
(少し、ポジティブ思考が強い気が。。。考えなしにやり始めては行けないと思うが。)

ダメな履歴書を良くする方法

プロのライターを雇う。
ただ、プロのライターなら誰でもいいわけではない。
慎重に選ぶ必要がある。

必要な情報は、きちんと揃えてプロに渡す。
ゴミを渡してもゴミしか生まれないので、注意!
(残飯にキャビアぶっかけても、残飯なのが変わらないのと一緒!!)

プロを雇わない場合、ユーモアと仕事の結果を書くしかない。

テクノロジーに対して頑なな態度を取る。

テクノロジーに対して宗教的になっている

自分がやっていること = 熱狂的になってしまう。
知っているというだけでテクノロジーを崇めるのは危険!
数あるテクノロジーの中から、最良なものを取捨選択できることが必須。
最新のテクノロジー以外が、劣っているという考えは持たないようにする。

すべてがいいもの

テクノロジー → 歴史のある時点では「いいもの」だった。
時間とともに状況が変わり、求められるものが変わっただけ。
存在を認めて、広く受け入れる必要がある。

選択肢を制限するな

自分が選んだテクノロジーが最高だと思ってはいけない。
他のテクノロジーの過小評価 = 最終的には自分を傷つける。

自分を売り込め

コードモンキーのためのマーケティング基礎構造

自分のマーケティングとは?

無意識にしていることが多い。
自分のメッセージと届く範囲がコントロールできるようになれば、売り込み方を調整できる。
積極的に自分の意見を言うように心がける。

自分のマーケティングの大切さ

エキスパートになっても、他社との競争に負けては意味が無い。
自分を売り込む手法を知ることで、相手よりも優位に立てるようにする。

自分のマーケティングはどのようにすべきか?

個人ブランドの設立から始める。
ブランドを作ることで、どう進めて行くかを考えて、首尾一貫した行動できるようになる。
一番簡単なブランドの作り方は、ブログを作ること

自分だと気づいてもらえるブランドを確立しよう

ブランド

製品・サービスについて思い浮かぶ期待感。
視覚を通して予想を起こす。

ブランドを構成するもの

  • メッセージ
  • ビジュアル
  • 一貫性
  • 反復的な接触

独自ブランドを作る

  1. メッセージを決める
  2. 市場を選ぶ
  3. キャッチフレーズを決める
  4. エレベーターピッチ
  5. ビジュアルを作る

作って満足せずに、拡散まで行う!

成功するブログの作り方

ブログの重要性

  • 技術分析による宝物庫(ゲート・オブ・バビロンの作成!!)
  • 力量の向上
  • チャンスがくる可能性の向上
  • 考えの言語化
  • 専門知識の最新化

成功のためのポイント

たくさん書くこと。
投稿の頻度が重要。
最低でも週一がいい。記事が多ければ多いほど、トラフィックが増える。
(同意。ブログ分割したら、アクセス数が激減した。。。orz)

質の高いコンテンツを作ることを忘れてはならない。
質の高いコンテンツは、読む人が増え、成功の可能性が増える。
そして、リンクが貼られるようになれば、アクセス数が増える。

ちなみに、最初から高すぎるモノを求めてはいけない。
いいコンテンツを作るには努力が必要。
イメージを中心に作る。

ブログ継続のためには、アイディアのストックと質の高さを意識しないようにする。

アクセス数を増やすには

他人のブログにコメントを残す。
ただし、スパム的メールはNG

最大の目標:他人のために価値を生み出せ!

人が欲しがっているものを作れ

人が欲しているものを知ることは、難しい。
なぜなら、人は嘘を言う可能性が高いから。
※意図して嘘を言っているわけではない。

兆候を掴み、ものごとを見極めることが重要。

自分がしていることの90%は、無料化

ハードワークの対価を得ることは、間違いではないが、大成しない。
なぜなら、シェアしにくいため評判が広まらない。
将来への投資が必要。評価は値段が付けられない。

講演、プレゼンテーション、講師

ライブで話す力は必須

講演を始める

人前で話す → 上達するまで時間が掛かる。

職場でのプレゼンテーションが最適。

社員が発表することは歓迎されることが多い。
仕事に直結していれば、なおさら。

チームで役立ちそうなことの講習会をやる。

エキスパートである必要がなく、プレゼンの必要もない。
学んだことをシェアすること、人の役立つ情報が大切。

ユーザグループでの講演

新たに発表してくれる人を求めている。
小規模で前提条件が厳しくなく、マーケティングにもなる。

フォロワーを惹きつけるような本・記事を執筆する

本や記事が重要な理由

本を書く = 一定の信用が生まれる
専門家として見られたいなら必須。
(大学の教授とかよくやる。中身があるかは別だか。)

書籍・雑誌は利益にならない

本から多額の収入を得るのは、奇跡に近い。
(同人出版したことがある人は分かるはず!俺は分からない!)

収入が得られないだけで、メリットがないわけではない。
広く流通すれば、得られる信頼の量が違う。

惹きつける記事を書くなら

Amazonとかで、ベストセラーを見るようにする。
そうすることで、興味があるトレンドや問題が分かるようになる。

バカにされるのを恐れるな

あらゆることは、最初が気まずい

最初は、誰でも居心地が悪い。
時間を掛けないと、居心地の悪さは消えない。

バカに見えても構わない

他人にどう思われようが気にしないこと。
プレゼンで失敗しても、死ぬわけではないし、肉体的被害はない。
失敗したプレゼンは、頭に残っていないもの。

プライドを捨てて外に出ることが重要
(サイヤ人の王子には無理だろうけど!)

ベストを尽くしつづけ、結果が出るのを待つ。
何かをやり続ける = 上手くならないと行けないから続ける

小さなステップを踏む

成長する方法
  • 自身を追い込む(獅子の子落とし??外国にそういった諺はないのだろうか?)
  • ゆっくりステップを踏む

学ぶことを学ぼう

学び方の方法を学ぶ

学習のプロセスを解剖する

興味を持ったこと → 無意識に学ぶ
学んだことを実践する → 覚える可能性が高い
学んだことを他人に教える → 学習効果が高い

学習スタイルは、人である以上、同じになる。
人毎に違うのは、間違え。

人生の大きな目的は、知識ではなく行動である。
ハーバード・スペンサー

本を買って読むだけでは学んだとは言えない。
実践までやる。
(バカの壁で言いたかったことに近い気がする。)

独学の方法

何かを学ぶ → 出来る限り早く試せるポイントに到達し、行動を起こす。
遊べるだけの知識がつけば、好奇心という強力な武器を手に入れられる。
好奇心を武器に、能動的に学習が可能になる。
(作者はMTGを例に出していた。俺は遊戯王だ!!!)

メンターを探す:あなたのヨーダを探す

(外人のヨーダ信仰は異常)
(師匠といえば、日本人なら東方不敗やろうがッ!)

メンターの資質

メンターには様々な種類がいる。
もっとも優れたメンターになるには、もっとも落し穴にハマった人であることが多い。

メンターをどこで探すか

ベストは、個人のネットワーク内から探す。
個人のネットワークが狭い場合、近くのイベントに出て探すことがいい。

仮想メンター

メンターが見つからない場合、本を仮想のメンターにする。
※なるべく本物のメンターがいい
(自分は、だいたい本がメンターになることが多い)

メンターを見つけたとしても、そのメンターが積極的だとは限らない。
その人になりきって、仮想メンターを想像するのもあり。

積極的ではないメンターに教えてもらうには、熱意と無償の労働が必須。
(師弟関係で、弟子が雑務をやるのは無償労働な気がする。。。)
(ハウツーを読んでもできないことがある。それを知らないで大声上げる奴は、バカの壁を超えられない)

弟子をとる:ヨーダになる

メンターになること

開発者は、自分がメンターになれるとは思っていない。
しかし、教える人は、1歩先に進んでいるだけで、メンターの資格がある。

メンターになることは、正しいこと知っていることではない。
他人の問題を客観的に見て解決方法を示すことが、メンターの役割。
知恵や経験を教えてはならない。他人の成功には部外者の視点だけでいい。
(この考えはちょっと懐疑的。知恵の継承は必要だと思うのだが。。。)

メンタリングのメリット

「なぜ」の問にさらされ続けるので、深い知識と考え方が得られる。
成長を助けることで、立場逆転しても助けになってくれるかも知れない。
(恩をきせなかった場合、仇討的な倍返しを食らうだろう!)

教える:学びたいなら教えろ

(「えろ」で終わると、くださいを付けたくなる。)

自分は教師ではない

教えることは、誰にでもできる。
しかし、できないと思っている人が多い。
それは、能力の問題ではなく、自身に影響されるから。

完璧にマスターした → 教えられる 朧気なから覚えた → 恐ろしさを感じる

教えることは、知識をシェアすること。
教師になることは、エキスパートである必要はない。
教わる人より一歩先にいることが重要。
(今の教師は学位にこだわりすぎているからダメな気がする。)
(人生学も含めて、人間として一歩先に行く必要があると思う。)
(そして、先生と呼ばせるのではなく、呼ばれる存在になる必要がある。)

教えると何が起こるのか

深く理解できていない事実に直面することができる。
問題にぶち当たる事によって、情報の断片が再構築されて概念を手に入れる。
(理解、分解、再構築??錬金術の流れがここに出てくるのかッ)

始める

教える場合、謙虚な視点で権威的なトーンで話す。
知識のひけらかしではなく、自身を持ってしっかり話すことが重要。
自信なさげに話すと、信頼は得られない。
教える方も、教わる方もバカにされたくないと思うので注意する。
お互いにリスペクトできるような教え方をする。

正しく教えるには、練習あるのみ(Go!プリンセスプリキュアのシャット風)
自分の優位性の証明や、承認欲求を満たすことをしてはいけない。
(今の人には、かなり厳しい気が。。。)

今まであった中で、最も優れている先生を思い浮かべて、アプローチを真似る。
(残念なことに、学校の教師で尊敬する人にほとんどあったことはない。やっぱり職場で一緒に働いた人になる。) (一番印象に残るのは、話が面白い人ですね。)
(あとは、仕事への取り組み方が、真似できないくらい厳格な人とか)

学位は必要か、なしで済ませられるか

成功するために学位は必要か

成功には不要。
しかし、学位がないと求人と昇進に影響する。

大企業ほど学位を気にする。
理由は、教育レベルで求人をフィルタリングかけるため。
(果たして、それは適切なのだろうか?結局、学位だけでは優秀な人を逃す気がするのだが。)
(働く事に重きを置いた人は、学位がないのに優秀であることが多いと思うが。) (自分が学位ない(大学出てない)ので、懐疑的になる)
(優秀な人を取りたいのであれば、きちんと人を見るべきだと思う。人事の怠慢では?)

能力を証明できれば、教育済みの証明は不要。
つまり、ベンダー系の資格があることが重要。

学位がなければどうすればいいか

経験と能力の証明が必要。
学位は、能力の証明。
学位がない場合、能力の証明をする必要がある。

証明するためには、自分の作品集を持つ必要がある。
GitHubOSSに貢献することが、一番の近道。

知識のなかの隙間を見つける

(そこにサンタナがいるはずだ!!)

なぜ隙間が残るのか

知識の隙間は、放置されやすい。
隙間があることで、何が問題なるのか理解できなかったり、理解できないことの気持ち悪さの回避に走る。

隙間の見つけ方

知識の隙間 → 見つけるのが難しく、無視されやすい(まるで俺みたい!)
単純な見つけ方は、作業する上で時間が掛ているところ。
知らないことがあるせいで、無駄な事をしている可能性が高い。

分からないことや調べれなければいけないことは、リスト化して知識の隙間があることを理解する。

隙間の埋め方

隙間を認識すること。
認識できていれば、解決に向けて動けるので、隙間を埋めることができる。

生産性を高める

全ては集中から始まる

集中

意識が1点に集まること。
現実世界では注意を逸らすものが多く、日常生活で集中状態は出現しない。

集中している時間を増やす

集中状態にコツ
  • 一つの作業に専念する
  • 最初の苦痛に耐える

上記をこなすと、知らない内にゾーン*1に入る。 入るには、無理矢理、自分がそのことだけを考えるように仕向ける。

自分自身に対して責任を取る

責任の大切さ

会社に出社するのは、雇用主に対する責任のため。
責任の自覚が薄い環境 → 怠ける。人間の性なのでしょうがない。

監視している人がいない時に生産性を向上させるには、自分に対する責任感を育てることが重要。
つまり、品位・高潔さが必要になる。
(騎士であれってこと??)

品位と高潔さを持たない場合、外的要因に左右されることになる。
責任感がある人間とは、自制心を持っている。

燃え尽き症候群の治し方

燃え尽き症候群に陥る仕組み

新しいもの → 最初は熱狂するが、時間とともに冷める
(一時プリキュア熱が強かったけど、時間とともに冷めて閉まったのと同じかッ?)

冷めるのは自然のサイクル
一生懸命にやればやるほど、燃え尽きるペースが早くなる。
(密閉空間の焔と同じ。強く激しく燃えれば、自身が出した二酸化炭素で早く消える。)

生産性が高くなる → 生産性の向上が鈍化するので、生産的ではないように感じる。

実際には単に壁にぶつかっているだけ

燃え尽きる ≠ 終わり
本当は壁にあたっているだけ。
それを超えると大きな成果になる。

その壁の向こう側

壁を超える → 人が少なく、競争がゆるい。
だから、燃え尽きても無視してやり続けることが重要。
(なぜだろう、アイマスを思い浮かべてしまう。)

壁を推して通り抜ける

壁は、押し続ければ抜けられる。
忍耐と同じことをやり続ける地味さが必要。
(押し通る!邪魔するな!アシタカ風)

時間浪費のメカニズム

もっとも大きな時間の浪費

テレビを見ること。
何も得られなければ、無駄である。
(無駄無駄無駄無駄!!)

テレビの問題点

  • 時間の浪費
  • お金の浪費
  • マインドコントロール

テレビ以外の浪費

  • SNS
  • ニュースサイト
  • 会議
  • 料理
  • ゲーム

全部無駄とは言わないが、浪費していると感じたら、見直したほうがいい。

習慣を持つこと

習慣が人を作る

目標のための習慣 → 目標達成しやすくなる
無意識に何かすることが習慣になれば、その道のプロになれる。

習慣の作り方

目標を決めて時間を捻出し、毎日続ける。
それだけ。

習慣にこだわりすぎない

習慣は、守れないこともある。
守れない時は無理にするのではなく、代償行為等で冷静に対処する。
そうしないと、やっかいな人間になるか、人間性が壊れる。

悪い習慣に気づいて変える

悪い習慣を見つけたら、発動条件と達成の褒美が何かを考える。
代価の習慣を考えて切替を行っていく。

ハードワーク

ハードワークがクソなワケ

ハードワークには、苦になる作業とならない作業がある。
仕事 → 辛い
遊び → 楽しい

ハードワークを楽しむ輩がたまにいるが、やりたいとは思わないハズ。
何かメリットがあるからやる。
利益のない仕事は、簡単。

さぁ、賢く働こう

賢い仕事はハードワークよりもいい結果が得られるわけではない。
成功するためには、一定の頑張りと忍耐が必要になる。

ハードワークは退屈だ

ハードワークから逃げるのは、退屈で人権が認められないから。
ハードワーク = 難しい作業 = 誰もやらない
やり遂げる人 → 楽な方に逃げる人よりは優秀
(そうだと信じたい!)

現実:簡単なものなどない

本物の成功を手に入れたいなら、ハードワークをするしかない。
ハードワークで得た仕事の仕方という種は、ゆっくり育ち、ある時期に収穫することができる。
蒔いてもいない種は、育ちもしないし、収穫もできない。
※ずっと楽できない意味ではない。成功ができないという意味。

成功は、次の成功の呼び水になる。
ただ、最初に成功する道のりが険しいだけ。
凡人は、回り道をして成功しようとするが、そんな道はどこにもないので、そのまま終わる。

どんなことでも、しないよりした方がマシ

なぜ行動することを拒否するのか

行動しないためにチャンスが消えることはよくある。
多くの人が行動しないのは、怖いから。
間違うこと、壊してしまうこと、合否を突き付けられることの全てが怖い。
(日本人は、嫌われることの恐怖がハンパない気がする。村八分とかあるし)

恐怖に縛られないでいることが、チャンスを掴むためには重要
最良の行動でなくても、何もしないがデフォルト選択にならないようにしなければいけない。

起き得る最悪のことは何か

正しい行動 → 何度か間違えたからこそできる
行動を起こすのが遅いと、正しい道を見つけるまで時間が掛かる。

選ばないことを選び、行動を先延ばしすると最悪の結果が出る。
(俺は誰も選ばない・特別扱いしなかったがゆえに独身なのだ)

動く車のハンドルは切りやすい

行動しない = 止まっている車
方向が間違っても、ハンドルは重くて切れない。

行動する = 動いている車
方向が間違っていても、ハンドルは切りやすい。

方向の間違いは、進んでみないと分からない。
間違うコストが低いなら、何かすることを選んだほうがいい。

お金に強くなろう

給料はどのように運用するか

目先のことだけを考えるな

目の前の金でやれることを考える → 稼げば稼ぐほど使う。
財力通りか、それ以上の事をしてしまうので、高給取りでも貧困になる。

資産と負債

資産 → 維持費 < 利用価値
負債 → 維持費 > 利用価値

給料だけでは

収入が増えることは金持ちではない。
億万長者になるためには、お金を生み出す資産へ投資する必要がある。
貯金しても、貯金したお金の働かせ方を知らなければ、金銭面で成功はできない。 (百万長者という言葉が書いてあった。)
(mirrioearの日本語直訳だろうか?)
(最初見た時は意味が分からなかった。理由を考えたら納得とニヤケ笑いが。。。)
(金に強いかどうか判断するための罠だろうか?)

給与交渉の方法

交渉は、応募する前から始まっている。

給与交渉は、評判に影響される。
ソフトウェア開発者としての名声は、ブランド力と積極的なマーケティングにかかっている。
(たまにブランド力だけの奴がいるのが腹立たしい。1回地獄に落ちてほしいね)

どのようにしてポストを獲得するか

役職に付く = 給与に影響する
交渉は、必要性が高いほうが不利になる。
職が欲しいから求人票を見て応募 → 不利な状況から交渉スタート
会社側が欲している → 交渉は有利に進められる。この状況になるには自己マーケティングするしかない。

数字を先に言ったほうが負け

先に数字を言う → 交渉では不利になる。
会社側が自分が思っているより低い額を掲示しそうな場合だけ、釘を打つために下限値を先に言う。
先に言ってくれと頼まれても、絶対に答えてはならない。
会社が先に答えられないのは、何か理由があるハズ。
どうしてもいう場合は、広い範囲を言う。
ただし、下限値は許容最低額より高めに設定する。

掲示を受けたとき

必ず数字を見ること。
最終的な掲示で数字がない場合、許諾してはならない。

借金の危険性

借金は悪いことである

借金を抱える = 利子分余計に払う
借金より大きな収益を上げるためでなければ、しないほうがいい。
借金は、時間とともに積み上がっていき、負担は重く、金に苦労しない生活から遠ざかる。

金をめぐるバカげたこと

不要な借金 → してはいけない
(むしろ、するやつなんているのか?)
借金をした場合、高い金利から返済すること。
購入はローンを組まずに購入したほうが得。
なぜなら、利子を払わなくてもいいから。

すべての借金が悪いわけではない

借金 < 収益 → 借金しても問題はない
利益が見込めない借金が一番不味い。

やっぱり体が大事

なぜ健康でいる必要があるのか

自身

自身があるように見える = 才能以上の成功を呼ぶ
健康と自信 → 健康的だと外見がよくなり、自信があるように見える

恐怖心の除去

不健康だと、病気になるリスクを抱える事になる。
手遅れになってからでは遅い。
健康的になり、次世代に繋ぎ、次の世界を長く見守らなければならない。
(死を求めていたが、考え方が少し変わった気がする)
(誰のために生きるか考えていたが、嫁もなくこどももいないためどうすればいいか悩んでいた)
(次の世代に繋ぐことや何かを残すという考えがあるのか)

負けない心を鍛えよう

心と体のつながり

心とは、体にはない部分のこと。
体と心は等価であり、優劣はない。

人生を操作したい場合、心の力・思考方法を使ってコントロールする必要がある。
(キングになりたいと思わなければ、キングにはなれないのだ!)

恋愛と人間関係

ゲームの性質を理解する

恋愛 = ゲーム
戦略的に挑む必要がある。
追うだけでは、相手は逃げてしまう。

自信を持つことが必要。
3秒ルールを適用して、3秒以内に行動する。
3秒以上の思考停止は、自信がないように見えて、ものごとが上手くいかない。

恋愛は数のゲーム

一人の人に固執する = チャンスが少なくなる
世の中は広いので、受け入れてくれる人は必ずいる。
失敗を恐れず、拒否される事を恐れないことが大切。

失敗に正面からぶつかれ

なぜ失敗を恐れるのか

失敗 = 本能的に嫌う。先天的なもの
失敗の恐怖 = 壊れやすい心を保つためには必要

失敗することは、孤島に送られるイメージに近い。
助けてもらえる希望が無く、抑圧される感覚が失敗することに近い。

失敗は敗北ではない

失敗 → 一時的なもの
敗北 → ずっと続く
(敗北したキングは、元キングとずっと言われる!)
(敗北を取り戻すためには、もとの位置まで這い上がる必要があり、最初の通った道より険しい)

成功するためには、何回か失敗する必要があることを覚えておく。
失敗を恐すぎると、成功がやってこない。

読み終えて

感想

たまに違和感を感じることが章があったが、それは文化的な違いだろうか?
文化的な違いを意識して読む必要がある。
あと、きちんと腹に落とし込んでやるまで、読み返したほうがいいと感じた。
いろいろな考えに触れたが、結構納得行くことが多い。
欧米や北欧のソフトウェア開発は進んでいる気がするが、そうでもないかとも感じた。

読むのに結構時間がかかった。
読書スピードが落ちたのだろうか?
読み返すことも結構あったのが、気にかかった。
ブログや自己マーケティングの方法は、結構参考になった。
自分が最近やり始めたことだからかも知れないが。

社内でプレゼンは良くするので、学習方法については概ね同意できた。
やはり、そとへのアピールは必須だと感じた。
いずれ、ユーザグループには公演したいものだ。

参考資料と合わせて読みたい本

人を動かす

人を動かす 文庫版

人を動かす 文庫版

まだ未読。
持ってはいるけど、まだ読んでない。
リーダー的立ち位置になったので、早めに読んで人心掌握の術を掴みたい

CODE COMPLETE 上下

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

読了済み。
古い本だが、やり方は今でも通じる。
若干読みづらく、腹に落としにくいが、効果的な手法が多く載っているので、時間を欠けて読み解くのをオススメする。

Clean Coder

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

未読。
プログラミングに関する書籍は結構読んだので、もういいかと思う気持ちが強い。

Head First デザインパターン

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

読了済み。
一番最初に買ったデザインパターン本。
読むだけだと理解しづらい。必ずコーディングして試すことが必須。

金持ち父さん貧乏父さん

金持ち父さん貧乏父さん

金持ち父さん貧乏父さん

未読。
金の考え方はソフトウェア開発者にとって大事だと思ったので、なるべく早めに読みたい。

バカの壁

バカの壁 (新潮新書)

バカの壁 (新潮新書)

読了済み。
学習方法や考え方の発展的な内容がこの本に書いてあった。
SOFT SKILLSを読み終えた人は、この本を読んで欲しい。
たぶん、考え方や学習に対する考え方が大きく変わるハズ!

*1:余計な思考感情が全てなくなりプレイに没頭する。ただの集中を超えた極限の集中状態。選手の持っている力を最大限引出す事ができる反面、トップアスリートでも偶発的にしか経験できない稀有な減少である。練習に練習を重ねたものだけが、その扉の前に立つことを許され、それでもおな、気まぐれにしか開くことはない。それは選ばれたモノしか入れない究極の領域 By 黒子のバスケ

管理職にコードの問題点を伝えても伝わっていない件

背景

新規プロジェクト開発に携わることになった。
何回かフェーズが別れており、段階的に開発する流れになっていた。
自分は第二フェーズから参加。
第一フェーズのコードを見たが、いろいろ不味いスパゲッティを作っており、指摘をした。
その結果、伝わっていなかったことが周囲の人から聴いて知った。

詳細

管理職との関係

ほとんど面識がない。
管理職は顧客に近いとこにいるため、作業場所が違っている。
顔は何度か合わせたことがあるけど、ほとんど覚えていない。
そのため、指摘は対面ではなく、メールベースでの指摘となってしまった。

知った経緯

歓迎会があり、管理職の近くにいる開発者から状況を教えてもらった。
一部の開発者からは絶賛されたけど、管理職に近い開発者からは全然理解を得られていなかった。

なぜなのか

簡単に言うと技術力の差。
理解ができていない管理職付近にいる開発者に話を聴いたが、どこがどう問題になるのか理解できていなかったらしい。
※管理職も含めて

自分は、文章で理論的に話したが、それが不味いという指摘を得た。
実際にどうなるのか想像ができていないため、指摘したことをやり続けることで、物理的にどういう問題になるのか分からないらしい。
つまり、内部的な構造は目に入っておらず、最終的なアウトプットが正しければ、内部構造はどうでもいいとういうことだ。

それは、不味い

内部構造を理解してないのは、非常に不味い。
カオスの予兆が分からないということだから。。。
その人の経歴を聴いたが、どうやら管理専門で教育を受けて今の立場にいるらしい。

管理職だからでは済まされない

「管理職だから内部構造を理解しなくてもいい」という理由にはならないと、自分は思うのです。
管理職でも、一定の開発スキルは必要だと思います。
なぜなら、改善はコードに対してするため、コーディングに対する知識がないと、改善が行えないから。
そして、今のコードの状況がわからないため、開発者に対して高負荷を意図せずにかける事態になる気がします。
そして、プロジェクトは炎上し、なぜなぜ分析をするのだが、そもそも自分に原因がない前提で分析するので、分析にならないことがある。
真因が求められない結果、開発者にしわ寄せが行って、「ダメだなコイツは」って考えになる。
そういった事を数度受けたことがあるので、どこの現場でもよくあることな気がしてならない。

開発者あがりの管理職が一番

管理職といえど、やっぱり開発スキルは最低限必要だと思いました。
説明能力がない自分にも問題あると思いましたが、自分が全て悪い気がしません!

最低でも原理・原則の基礎知識が欲しいと思いました。
実践はできずとも、理解はあることが重要だと思います。

そういう点では、開発者あがりの管理職は、結構強みがあるのではないかと感じました。
コーディングに理解があり、開発者との意思疎通ができて、それを顧客に説明できるので、強みだと思いました。

頼むから勉強してくれ

管理職も大変でしょうが、プログラミング理論・原理について一定の理解・勉強はして欲しいと感じました。
あと、開発者だけに勉強を強いている管理職をよく見ますが、それってどうなのと思います。
他人に強いる前に、自分がどうあるべきがちゃんと示してこそ、言葉に重みが出ると思うのです。

思うこと

自分が管理職ではないので、アンチ的な立ち位置で批判してしまいましたが、管理職が大きなプレッシャーと戦っている点は理解しているつもりです。
最終的に責任を取らなければいけない立場ですし、責任の重さは計り知れないと思います。
ですが、少し開発者の立場によって欲しいという思いがあります。
どうも、「お客様は神様です」思考が強すぎで、開発者軽視になっている気がしてならない。
開発者も悪いものを作ろうとしてやっているわけではないので、一定の理解が欲しいのです。

寄り添う努力を、もうちょっとしてくれてもいいのではないかと思う今日このごろです。。。

ブログ分けました

テクニカルとサブカル

テクニカル系のブログとサブカル系のブログに分けました。
このブログは、本来やりたかったテクニカル系のブログにします。
サブカル系の記事がみたいよ~って人は下記リンクのブログを見るようにしてもらえればと

エンターテイメント!!/サブカル

分けた理由

さっき書いたように、本来やりたかったテクニカル系のブログに専念するため。
ただし、息抜きも必要なので、サブカル系のブログに分ける。

あと、サブカル系の記事はPVがもの凄くて、調子乗っていっぱい書いちゃったから、本来やりたかったことのノイズになるので分けた。
ブログ見返す時に結構ノイズになったりするってのが大きな理由ですかね。

ブログの使い方は、ノートに近い事をしている。
現場で、ふとド忘れしたこととかを調べたいときに、即効でアクセスできるので、時短にもなるから助かっている。
エンジニアの人は、なるべくブログ書いたほうがいいと思います。