00:03
はい、5月18日、木曜日ですね。 遅刻は昨日11分になりました。
毎回9時10分ぐらいに始めているので、もういい加減
コンスタントに9時10分に始められてるなら、ちゃんと9時スタートしろよっていう感じなんですけど、
なかなか癖がなおらんって感じですね。
はい、まあ、さておき、おはようございます。 夢見のkeethことくわはらです。
はい、ではでは、本日も朝から始めていきたいと思います。
本日はですけども、まあ、テクノロジーではないんで、全然ないんで、いわゆるフィロソフィー的なお話ですね。
社内スラックでですね、あの、共有いただいたものがあって、
まあ、こういう10項目とか10箇条ってね、結構やっぱり読みやすいっていうのがあるんですけど、まあ、その辺、
なんか面白そうだったので、今日見てみたいと思います。
はい、で、まあ、これ1本1本の記事自体はそんな長くないんで、
引用されている別の記事のリンクも、ついでに読みながらやっていきたいと思います。
というとこですね。では早速いきたいと思いますが、見えてないですね、やっぱり。
スーさんですね。おはようございます。ご参加いただきありがとうございます。はい、いつも通りダラダラやっていきたいと思います。
じゃあ、いきましょう。我がままのプログラマーにならないための10のルールっていうことです。
えっと、エゴレスプログラミングって言葉がありますと、はい、もうこれだかんだいぶ前に聞いたことあるんですけど、
アメリカのコンピュータ科学者、ジェラルド・ワインバーグ氏によって、プログラミングの心理学っていうものがあって、
こちらに取り上げられた思想になりますと。ちなみにプログラミングの心理学っていう書籍がありまして、
アマゾンで出てますので、興味ある人は読んでみてください。ただ、本、
1994年の書籍なのでだいぶ古いっていうのもあってですね。
でも、367ページ、技術評論者から出てるんで、しっかりした書籍なんでしょうね。
というところで、興味ある人は読んでみてくださいと。
昔になればなるほど、本当、マインドとかフィロソフィー的な話なので、
なんだかんだ今も通用する書籍が結構多いんですよね。というところで、読んでみてもいいかもですね。
で、戻りますけど、そのプログラミングの心理学っていうところで取り上げられた
エゴイレスプログラミングという言葉がありますと。
で、プログラマー同士が協調することで、最終的なコードの品質が向上するという思想ですよと。
で、プログラマーが協調できていないムードだと、
コードの品質が下がると言い換えても、なんだか思い当たり不思議のある感じです。
1970年代からある考え方ですけど、ちょうどちょっと話題になってきましたと。
さて、そのエゴイレスプログラミングのための10回ということですね。
はい、10個の回律の話ですね。10回ですけども。
これをまあ、じゃあ今から10個カット読んでいきたいと思いますね。はい。
ごぞうごふさんですね。おはようございます。ご参加いただきありがとうございます。今日もダラダラ読んでいきたいと思います。
じゃあそのエゴイレスプログラミングのための10回ですけど、
1つ目が自分が失敗をすることをまず認めるっていうところです。
2つ目、コードは自分自身ではないと。はい、これ結構大事ですね。
他者に対してコードレビューするときも大事ですね。他者もコードを書いたけど、別にそれはその人ではないので、
あくまでコードの指摘をするだけで、その人自身の指摘をするというわけではないよってところですね。
まあこれはでも、言う側もそうですし、受け取る側も、これはあくまでコードに対する指摘で、僕自身の否定ではないよみたいな。
03:04
受け取り手のマインドも結構大事ですよね。
3つ目、どれだけ空手を知っているかは重要ではない。
他にもっと知っている人がいると。はいはい。空手っていうものを出されてますけど、要はその専門分野の話が
専門分野についてどれだけ知っているかってのは重要ではない。上には上がいるよということですね。
4つ目、相談なしにコードを書き換えないと。はい、これはもうそのままですね。
5つ目、自分よりも知識がない人に対して尊敬と敬意と認体をもって接すると。
いいですね。尊敬、敬意、リスペクトは大事ですけど、認体ってところも本当に大事ですよね。
ジュニアの方は今から成長するってところがあるので、自分たちも歩んできた道なので、
先輩側としてはそれを認体も徹底しましょうと。6つ目、唯一不変なことは世界は変わるということ。
言葉的には矛盾してるけど、確かにその通りですよね。
はい、で、続いて7つ目。7つ目かな?次が6つ目かもしれない。
はい、敬意は立場からではなく知識から生まれると。へー、そうなんですね。
敬意は立場からではないんだ。
はい、で、続いて7つ目。自分が信じるもののために戦え、ただし敗北は礼儀正しく認めようと。
はいはいはい、これも結構大事ですね。
敗北を礼儀正しく認めるって結構、交渉な
マインドなんですけど、すごく大事ですよね。はい、続いて9つ目ですね。
オフィスでコードを書くだけの人になるなと。
あー、これはいわゆる職業プログラマーになるなっていう話かな?
で、10個目、ラストですね。人物ではなくコードを批評する。人には親切に、
コードには遠慮しないと。はい、いいですね、これ。
さっき読んだその2つ目と結構似た、
快律な気がしますけど、まあいい、そんな感じですね。
はい、このルールは1971年に作られたものですけど、
これらのルールの逆をいく人物を想像してみると、確かに同じチームになるのは遠慮したい感じですよね。
で、考えさせられる内容なので、原文もぜひご覧ください。
残念ながら日本語の書籍は手に入れづらい状況のようですけど、
英語のKindle版はすぐに手に入れることができるので、
頑張って英語の本を読んでみてください。
タイトル、サイコロジーオブコンピュータープログラミングっていう書籍ですね。
はい、まあちょっと英語でかつ長そうなので、ただまあ、
えっと、9.99ドルなので結構安いので、読もうと思ったらサクッと読めそうですね。
はい、というところでした。
で、あと補足としてワインバーグ氏が現在投票中だと。
あ、Twitterにて現在の様子をお伺いすることができるので、
書籍も多く読まれている人物が多数ですよということですね。
はい、で、本記事はこれで締まっちゃうんですけど、
そうすると短すぎるので、続いて参考として、
濃縮還元、オレンジジュース、なんちゃらかんちゃら、
脳洗顔で読めますかっていう記事ですね。
というのと、あとプログラミングの6大10項目リストっていうのがあるので、
その辺も見ていきたいなと思っております。
はい、まあ分かりやすく先に、6大10項目リストからいきましょうかね。
はい、では行きましょう。
以下に私の選ぶプログラミングの6大10項目リストというのを挙げておく。
つまり60個ですね。
06:00
取り上げた順序には特に意味はない。
このエントリーを簡潔なものにしておきたいので、
それぞれの項目は短い要約を引用するに留める。
興味を引くものがあれば、ぜひリンクをたどって、
オリジナルの作者の考えについてもっと詳しく読むことをお勧めします。
はい、要約だけで意味を取りにくいものも簡単に攻めつけてみたよということです。
はい、では行きますかね。
一つ目です。
一つ目はジェラルド・ワインバーグのエゴレスプログラミングの10回なので、
これはさっき読んだことですね。
はい、さっき読んだやつですのでこれは飛ばしますと。
じゃあ二つ目。
二つ目はデア・オバサンジョのソフトウェアプロジェクト失敗の10の兆候というものですね。
ははは。
もうタイトル的に読みたいですけども。
まあとりあえずじゃあ10項目行きましょう。
一つ目は最初のバージョンであまりに多くのことをやろうとするというのが一つ目です。
はあ。
なるほどね。
スモールスタートで行きましょうとかそういうMVP決めてちゃんとやりましょうということですかね。
二つ目、確立されていないテクノロジーに大きく依存している。
はあ、はいはい。
これはもうなんかその通りですね。
次で三つ目、稼ぎ頭だったり強力な後ろ盾を持っていたりする別の社内プロジェクトと競合していると。
これはなんか普通にその組織でのビジネス戦略の話じゃない気がしますけど、
競合しちゃっている時点でもうなんかそれは大変ですよね。
次で四つ目、チームが人員不足だと。
まあこれもその通りですね。
これは人の数もそうですし、そもそも人の能力とかスキルがない人がそこのチームにいるっていうのも全然あるかもしれないですね。
はい。
まあでもそれはその人が悪いわけではなくて、そういう疎覚をした組織が悪い気がしますけどね。
はい、まあどんな組織とかチームにも体力ってものがあって、その体力に耐えうるプロジェクトなのかどうかってのは結構大事ですよね。
ちょっと背伸びして頑張れば届くぐらいがやっぱりちょうどいいと思います。
ほんとに。
はい、じゃあ続いて五つ目、複雑な問題には複雑な解放が必要。
はい、複雑さ自体がプロジェクトのゴールになっちゃうよっていうところですね。
なるほどね。
複雑な問題をまあうまいことシンプルにして解決していこうっていうのがよくは言われる話なんですけど、結果解放は複雑になってしまうってことですね。
ってことはそもそものスタートする問題を切り分けて小さくしてから問題と取り組みましょうっていうのがやっぱほんと大事なんだろうなと思いました。
じゃあ続いて六つ目、スケジュールチキンと。
スケジュールチキンってなんだ?
はいはい、いやそうか、英語なんですね。
ちょっと英語なんで軽くサマリーだけ翻訳してスケジュールチキン読んでみますと、
ある理由からチームメンバーはプロジェクトの遅延を示す悪い知らせを安心して報告できなくなったと。
誰もその責任を取ろうとしないので生産ラインの下に責任が添加される。
この時点で責任のなつり付け合いが始まっているのです。
はあはあ、なるほどね、そういうお話なのね、スケジュールチキンだと。
報告しないのはよくないけどでも結果責任まで問われるので報告したくなくなるというので、まあほんとそういうことですね。
はい、いわゆる悪いニュースを伝えることを恐れるってことですね。
はい、続いて7つ目、スコープクリープってことです。
私知らないワードですけど、こちらはですね、スケジュールは変わらずに要件がどんどん膨らんでいくっていう、まあそういう話ですね。
ああ、だからスコープか、はいはい、スコープのクリープってことですね、そのままだと。
まあこれもさっきのMVPと一緒なんですけど、これの10箇所1つ目の最初のバージョンであまりに多くのことをやろうとすると、
09:04
割とシンクする内容だなと思いましたね。
まあとにかくできることを最小限でスタートしていくのはすごく大事だという話ですね。
続いて8つ目、第2のシステムシンドロームと、比較的小さい成功したシステムの後継システムっていうのが、機能満載の肥大化したシステムになる傾向があると。
はははは、なるほどね、スモールスタートで前回成功しちゃってるので、後継はじゃあどんどんどんどん詰め込んでいきましょうということですね。
いやー、なるほどね、後継システムを作るのは別にいろんな事情があるんでしょうけど、
成功した小さいシステムがあるんだ、それを育てていけばいいのにと思いますけどね。
それをベースにまた新しく作り直して肥大化したシステムを作るのはどういうことなんだろうという気はしますけど。
はい、まあいいや。
で9つ目、参入戦略がないと、勢いだけ参入したっていう。
そもそもプロジェクトというか、これはビジネス戦略がないまま参入したということですね。
はい、でラスト10個目、解き方を知らない問題に取り組んでいると。
えー、10個目は失敗する傾向があるだけで、別にこれはなんか悪い意味ではない気がしますね。
別に、まだないものを作ろうとするとか、新しいことに挑戦するときは、基本的には解き方っていうのは別に前例がない場合もよくある話なので、
これはこれで何でしょうね、まあ10の超高にはもちろんあると思います。
失敗する確率はかなり上がるんだろうと思いますけど、まあでもだから挑戦しないというのはちょっと別な話な気はします。
まあ単純に10箇条の中に入れたという話ですね、これは。
はい、今のがデアオーバー参上のソフトウェアプロジェクト失敗の10の超高という10項目でした。
では続いて、次の10項目は、オマルシャヒンっていう方のマイクロソフトで、あるいはその他のどこであれ、働くための10のヒントっていうとですね。
この人はじゃあマイクロソフトで働いてたのかな、ということです。
はい、では行きましょう。
1つ目、プロセスは思考の代用にはならないということですね。
ちゃんと意識しないとプロセスは思考の代用になると思っている、もしくは思い込んで行動していることはあるかもありますよね。
というので、これ大事なのはプロセスは思考の代用にはならないと。
はい、2つ目、オフィスにばかりいないこと。
もっと言ったらパソコンから離れたらいいって感じかもしれない。
で、3つ目、自分の製品を使うこと。
まああなたの顧客が使うようにあなたも自分たちの製品を使うことと。
これはまさにMSのいいマインドだって感じですね。
事業会社みんながこのマインドを持つのがいいかもしれないですね。
次で4つ目、何かが壊れていたら不平を垂れるのではなく直すこと。
行動は不平よりも有便だと。
ああ、いい言葉ですねこれ。
ほんとそうですね。
不平は直してから言うのがむしろいいかもしれないですね。
はい、5つ目、難しい問題を簡単に見えるようにすること。
簡単な問題を難しく見えるようにしないことということですね。
これはさっき言った言葉と結構似てますね。
次で6つ目、仕事や相手に応じて適切なコミュニケーション手段を使うことです。
はいはいはい。
ツールとかやり方とかタイミングとかいろんなアクセスの仕方があるけど、
12:00
これは本当にその通りだと思いますね。
あと僕らプログラマーとかエンジニアって仲間がいつ話しかけていいかなんて
僕らですらわからないですからね。
隣にいるけどスラックで今話していいって話しかける。
昔やってましたけど、本当にその通りだと思ってて。
まあそういうことですよね。
あとはセールスの人とかだとスラックとかメールよりも
電話で直接喋ってくれた方がやりやすいって人もいらっしゃると思うんで。
本当人によってやり方とか全然違うのでそれを使いましょうってことですね。
もちろん一言で例えばスラックだけで閉じれるんだったらそれは一番ですけど、
まあ人はそうじゃないよってことですね。
続いて7つ目、誤りから学ぶことってことです。
これはそのままですね。
続いて8つ目、物事をシンプルに保つこと。
これもそのままですね。
さっきの5番目の簡単な問題を難しく見えるようにしないことと似てると思いますけど。
シンプルなものごとはシンプルにしましょうということですね。
これをちょっと僕は思ったのはシンプルと単純ってやっぱり違うものなので、
シンプルっていうのは削ぎ落としてって結果残ったものっていうのがシンプルだと思っているので、
単純にするのとシンプルに保つことってちょっと違うよなっていうのが一つだと思いました。
続いて9つ目、常に価値を付け加えることだと。
淡々とやるんじゃなくてそれにプラスアルファを付けながら行動しましょうと。
ラスト10個目、他の人の製品も使ってみることだそうです。
競合のあるなし関係なしに使ってみましょうということですね。
これはいわゆる外の世界をしっかり見てみましょうってことに他ならんなって思いました。
オマール社員のマイクロソフトで働くための10のヒントでした。
続いて、マイケル・マクドナーっていう方のデザイン学校では決して教えてくれない10のことだそうです。
この人たちはデザイナーの方なんでしょうね。
ではこちらも行きましょう。
1つ目ですけど、才能が成功に占めるのは3分の1でしかない。
うわーこれいいですね。
デザイン領域の人がこの言葉を発せるってすごく説得力がありますね。
デザイン領域って結構、僕はちゃんと学んだことはないんですけど、
ものすごく才能っていうところを意識せざるを得ない領域というか世界なんだろうなって勝手に思ってて。
でも何人かのデザイナーさんに聞いたけど、確かにみんな一度はこの才能に打ち開かれるみたいなのは通りますし、
なんだかんだ仕事してるとこいつ才能あるなっていうのを思うなっていうのはちょいちょいやっぱ話は聞くんですよね。
でもこの人が言うには才能が成功に占めるのは3分の1でしかないっていうのはすごくいい話だと思いましたね。
はい、残り3分の2はなんだっていうのはちょっと気になりますけど。
じゃあ続いて2つ目ですね。
どんなクリエイティブな仕事でも95%はクソみたいな作業だと。
言葉はあれですけど、これもなんかある意味で励みになるじゃないですけど、
なんか頑張ればなんとかなるんだなっていう気はしますね。
でも95%って結構大変だな。
はい、じゃあ次で3つ目。
全てが同じように重要であるというのはすごく重要なものがないっていうことですね。
はいはいはいはい。いやそれもそうですね。最優先な事項がないってことだよね。
全て同じで重要ってことは。
15:01
これなんかでもいろんなあるいはステークホルダーだったりお客さんだったりとか、
まあ顧客の人が言うようなことですね。
全て最優先みたいな言い方してどんどんチケット回されることとかたまにありますけども。
つまりそれじゃあどれも重要じゃないってことだよねっていう風に僕ら受け取っちゃいますしそういうことだよなってあるので。
はい、これは結構マインドとして覚えておいていいかもしれないですね。
続いて4つ目。
一つの問題について考えすぎないことだそうです。
デザイナーっていうのは偏りがちというかそれに固執しがちだと。
で、十分なものになっているところで先に進みましょうってことですね。
はい、はいはいはい。
なんか満たされているところが十分満たされているんだったら次に進みましょうと。
それをさらにブラッシュアップとか洗練したいっていうのは確かにデザイナー同士はよくある話だし、
クリエイティブな仕事ではあるのでやりたいのはわかるけど次に行きましょうってことですね。
続いて5つ目。
わかることから始めてわからない部分を潰していくことだと。
まあこれはなんかちょっとコンテキストによってはなんか批判されそうな言葉な気がしますけど、
まあ言いたいことはわかるって感じですね。
続いて6つ目。
目標を見失わないことだそうです。
これはあれですね、定期的にちゃんと向き直りをしましょうとか振り返りをちゃんとしましょうってことですねこれは。
はい、続いて7つ目。
幅を利かせすぎるとバランスを失いますと。
自信を持ちすぎるのは自信がないのと同様に有害である。
問題には謙虚に対することだと。
はあね。
そう、デザイン領域にはそんな自信を持ちすぎる方って結構いらっしゃるんですね。
わかんないけど。
でもこういう言葉が出るぐらいには自信を持っている方って結構いらっしゃるんだろうなと思いましたね。
やっぱりそう、領域が違うなっていうのはツクツク思いましたね。
なんか、デザイナーの方って結構なんでもできるできるというか、
宣言してガンガンやっちゃうタイプの方が多いっていうのは僕は、まあ僕の知り合いのデザイナーがおっしゃってました。
逆にエンジニアはできないスタートで喋ることがかなり多いと。
これもまあ仕方ない感はありますね。
リスクヘッジをするのがエンジニアって感はあるので。
ちょっと世界観が違うんだろうなっていうところでこういう言葉が生まれたっていうので、まあ見てて面白いですね。
続いて8つ目。
地獄への道は善意で舗装されている。あるいは異形を罰せられずに進めることはできない。
まあ補足ありますけど、世界は平均的で予測可能なものでできており、素晴らしいアイディアは挑戦を受けることになる。
まあ何か新しいこととか異形を指すにはやっぱり茨の道だっていうのはその通りだってことで、
世界の物事は大体平均的で予測可能なものという、みんなが善意で作られたものでできていると。
なので最初の方の地獄への道っていうタイトルですけど、地獄っていう言い方はまあまあさておきですけど、
まあ大変だ、茨の道だってことですね。
はいじゃあ続いて9つ目。アウトプットが全てだと。
いやでもある種そうですよね。クリエイティブな仕事をしている人って本当アウトプットが全てですよ。
その人が内部でどんだけいろんなものを思考したり考えたりプロセスに時間を使ったところで、他者はその人をアウトプットでしか評価しないので。
それは本当そうなんですよね。そのプロセス自体もアウトプットしているって結構でも大事かもしれないですね。
完成してないけど今こういうことを考えているとか、こんなやり方をしているっていうプロセスをアウトプットしている方とか結構、
最近そういうでも波多いですよね。YouTuberとかもそうですしTikTokとかもそうですけど、
18:00
途中段階の作業とかも垂れ流しで公開している方もいらっしゃいますけど、
この人こんな風にやってるんだっていうのを見るのは、それ自体は結構実はコンテンツになりうるんですよ。
じゃあラスト10個目ですね。世界の残りの部分が重要だと。
自分の仕事が意味を持つもの、持つのも他の人たちにあってのことだそうですと。
そうですよね。自分の仕事自体が確かに価値はあるかもしれないですけど、意味を持つのは他の人があって初めて意味が生まれるってことですね。
いやーこれ本当重要だなと思いました。
次でラストですね。6大項目の6個のうちのラスト。
Andre Steylerの10年のソフトウェア開発が教えてくれた10のことだと。
はい。いいですね。僕もこの業界ちょうど10年経ったんですよね。今年11年目ですね。
確かにソフトウェア開発10年間やってきたので、10箇所なんとなく僕もこれ大事だよなってまとめてみるのは、改めてまとめるのはいいかもしれないですね。
偉大な方々の言葉と結局似通る気はしますけど。
まあいいやさておき。Andre Steylerの10年のソフトウェア開発が教えてくれた10のことです。
オブジェクト思考は思っているより難しいと。
やっぱりやってる人はみんな同じことを思っているだろうし、
去年か一昨年か、著名な方々がオブジェクト思考などないみたいな発言をしていて、
その人はオブジェクト思考で2,30年やった結果を思ったっていうので、それはすごく面白い話ですよね。
面白いというか興味深いなと思いました。
はいじゃあ次で2つ目。ソフトウェア開発で難しい部分はコミュニケーションである。
いやもうこれ完全に同意です。
問題はコミュニケーションですよね。
いやーすごくわかります。
プロジェクト開発で一番お金かかるのも人件費とコミュニケーションですよ。
最初にコミュニケーションパスとか仕組みとか、
誰にどういう話をすればいいかっていうのをしっかり定義してからプロジェクトをやっておくと、
意外と物事早く進むんですよね。
アプリケーションとかの仕様だったりとか情報とかっていうのをガッチガチに最初に固めるというより要件定義ですね。
設計をするっていうのはすごく大事な話ではあるんですけど、
なんだかんだシステムとかアプリっていうのは物事が変わっていったりするし、
仕様って後から僕らが考えてなかったことが生まれるのはよくある話なので、
そこは多少の余白というか多少の雑差を残しつつ物事を早く進めるというのがすごく大事なことで、
最初にガチガチに決めるのはちゃんとチームというかコミュニケーションパスというところだと思います。
はい続いて3つ目。
ノートを言えるようになろうと。はいこれはその通りですね。
これはビジネスマン全員に言えることですね。
別にプログラマーとかソフトウェア開発だけではないと思います。とにかくノーが言えることってすごく大事ですね。
できないっていうキャノットではなくてノーですね。
これ結構違うに似てるんですけど違うんですよね。これはすごく大事なことだと思いました。
で続いて4つ目。全てが同じように重要なら重要なものはないということですと。
これは他の方もさっきおっしゃってましたね。はいはい。
それで5つ目。一つの問題を考えすぎないこと。
これももう先ほどのデザインの方が言ってたことやっぱり似てますね。
悪夢は細部に宿るが悪夢払いの方法は理論ではなく実装することだと。
21:00
面白いですね。神は細部に宿るって言うけど
そういう一つにこだわっちゃうっていう悪夢も細部に宿るってことですね。
いやこれ面白い言葉ですね。なるほどちょっと今後使っていこうと思います。
悪魔払いの方法は理論ではなくて実装することだよということですね。
はい。それで6つ目。何かに本当に深く潜り込むこと。
ただし時間を取られすぎないことだと。はい。
深淵で興味深いことがあっても実際に使うことがないことも結構多いってことですね。
それは本当そうですよね。これはなんか僕よく言う言葉なんですけど
技術を使うのは何のためだって話がよくあって、その技術が使われないんだったら
それは単なる自分がゲームで遊んでるのと他の一緒ですよねって話になるので
そういう価値を提供したりとか技術で何か世の中を良くするみたいな
そういう話になるときに本当の技術力ってのはその深さなんですかってのは
改めて見直すのはいいかもしれないですね。では続いて7個目ですね。
ソフトウェア開発組織の別な部分について学ぶことだと。
やっぱりソフトウェアって結局僕らの開発だけで物事は進むわけではないし
いろんなものが重なって最後にアウトプットとして僕らがプログラミングして
作ったものを最後デプロイしてっていうところになってくるので
大事なのはその開発だけではないのでその別の部分について学ぶことってのが
すごく大事だと思いました。で続いて8つ目。同僚は
最良の教師だと言ってます。同僚を競争相手としてではなくて資産として
見ましょうと。これでもよく言われる心理学
フィロソフィー的な話ですけど他者とか僕以外の人全員が先生だって
言い方する人もいてそれ良い言葉だと思いますね。何事からも学ぶことはある
ということですね。はい続いて9つ目。動くソフトウェアが
全てだと。極論そういうことですよね。
動かないソフトウェアには価値がないので。じゃあラスト10個目。どうしようもない奴らもいると
いろんな人がいるってことですね。これをもうマインドとして一回インストールしておくと
対処というかそういう人たちと接する時の態度が変えられるよね
って話だと思います。はいというところで
一応10個。あともう1個ありますね。6大項目10個のうちの最後は
偉大なる10冊って書籍ですね。書籍が10冊バーと並べられてますけど
これはちょっと長いし全部リンクなので皆さんの方で
見てみてください。まあ結構読んだことあるなとか知ってるなってものもありますけど
だいぶ古い書籍もありますね。リスプとかC言語とかの書籍もあったりするので
まあこれを読みたいかどうかちょっと人に任せますけどっていうところですね。じゃあちょっと続いて
以上まあ明らかにプログラマーでなくデザイナーである人物の10項目リストを
含めているっていうことを妙に思っている人もいるかもしれません。私は次の
上位デビュラーの考えと同意見ですと。ソフトウェア開発っていうのは
エンジニアリングの近い親戚であり、エンジニアリングの原則自体はそうでないにしても
数学や科学にクリエイティビティをブレンドしたようなものですと。それが
クリエイティブな人たちのアドバイスの多くがソフトウェア開発にも適用できる理由なんですよって
言ってます。で一応それから私の推薦著書リストとスティーブ家記の
リストと比較してみると面白いかもしれません。私のリストにリファクタリングと
デザインパターンが入っていないのには理由がある。そしてスティーブのリストにコード
コンプリートが入っていないのにもきっと理由があるでしょう。結構名著ですよね
24:00
リファクタリングとデザインパターン、そしてコードコンプリートですよね。かなり名著な
書籍ですけどこれらが10項目に入っていないっていうのには理由があると。
でもその理由は語らないですね。分かりました。というところで、後ほど
この記事もシェアするので皆さんも見てみてくださいと。でラストですね
時間ちょっと押してますけども、ラストほんと一瞬なので
読んで終わりにしたいと思いますけど、もう一つですね。ゲラルド・M・ワーゲンバーグさんの
ガンで余命はずかっていうところの記事ですね。これを多分
日本語訳してるのかな?というので、これは短いのでサクッと読んで終わりにしたいと思います。
ライトついてますか?問題発見の人間学という書籍がありますね。
などシステム開発に関する書籍を数多く執筆している
ゲラルド・M・ワーゲンバーグ氏っていうのが、自身のウェブサイトにいて
末期がなることを打ち明けました。自身のツイッターでも報告したことからこの悲しい
知らせは瞬く間に広がってしまいました。彼がかかっているのは狂戦癌で
1年の生存率が25%という極めた深刻なものです。常に
治療は不可能な状態であり、科学療法を用いたとしても最長で3年しかもたないようです。
全身の痛みや極度の疲労、視力や
聴力の低下など様々な症状が出ており、執筆を始めとする
仕事はすでに行えなくなっている状況です。ただ完全に諦めているわけではなく
現在も専門医としていくつかの治療法を検討します。ワーゲンバーグ氏の体調や
治療結果はサイト内の日記にして知ることができます。また、サイトに設置されている
ゲストブックにはワーゲンバーグ氏のエッセンスが書き継がれており、
ケントベック氏だったりとか、日本のアジャイル開発の有名な平辺賢治さん
という方の著名人の名前も挙げられています。
平辺氏はワーゲンバーグ氏との出会いや思い出を自身のブログでも
語っているので、興味ある人は読んでみてください。
本記事は資料にも締められておりました。ワーゲンバーグ氏の紹介というか
今の状況をサクッとまとめた感じですね。
では、今日の朝勝はここで以上にしたいと思います。
なかなか興味深いお話がたくさんで、やっぱり10項目でまとめられているんですけど
1個1個の詳細なところ、なんでそういう風に考えたのかという背景まで
読んでみたくなりました。というので、皆さんの方でも
見ていただければなと思います。ではでは、朝勝はここで締めたいと思います。
今日は改めまして、5造国さんとケイさんと
市中郵船さんと、たぶんオンラインのスーさんですね。はい、ご参加いただきありがとうございました。
いつもダラダラやって本当に申し訳ないですけど、明日もなんかゆるーく読んでいきたいと思いますので
興味ある方は参加してみてください。じゃあ、木曜日ですね。
今日も一日頑張っていけたらなと思います。それでは終了したいと思います。お疲れ様でした。
