「菊と刀」という本を読みました

「菊と刀」。有名な本ですよね。

第二次世界大戦中に、アメリカの文化人類学者が日本を研究した研究結果の本です。

「日本人の特徴」みたいなものがあるなら知りたいなと思ってます。

しかし、この本についてはそれだけではなく、高校生のころから読みたかったんですよね。

というのも、当時同級生の友人(女子)が、読書感想文にこの本を選んだというのを聞いて、

「どひゃー なんて硬派なんだ!しびれるなあー」

と思っていたからです。

それから何十年とたって、やっと読みました(笑)

いや、実にすごい本です。

「なるほど、そういうことか」

と何度も思わされました。著者のルース・ベネディクトさんは日本に来たことがなかったそうですが、よくこれほどまでに日本のことを理解されたなと思います。

以下、気になったところを抜粋しておきます。


①日本人はめちゃくちゃ束縛されている

これはこの本で初めて知ったことなんですが、アメリカでは赤ちゃんを厳しくしつけるらしいです。

「え?赤ちゃんってしつけるものじゃないでしょ??」

というのが日本人の一般的な感覚な気がします。

日本では赤ちゃんが泣いていれば駆けつけるのがよい母親ということになってますよね。

しかし、アメリカでは赤ちゃんは一人の部屋に置かれ、決まった時間に授乳し、寝かしつけさせられ、母親が出かければ独りぼっちになるらしい。

これ、あんまり日本で知られていることではないですよね。アメリカ人って赤ちゃんや幼児をめちゃくちゃ甘やかしているイメージあったので驚きました。

で、この本曰く日本人は赤ちゃんと老人に甘く、青年から壮年にかけて非常な束縛が課される。

アメリカではその反対で、赤ちゃんと老人に非常な束縛が与えられるが、青年から壮年にかけてはその力をいかんなく発揮することができる、らしいです。

以下本からですが

「日本人の性格の矛盾を、子どものしつけを見れば納得がいく。それは日本人の人生観に二元性を生み出す。
幼児のころに特権があり、気楽に生きていた記憶のために、自分の言い分をどこまでも主張する傾向を与えるが、6,7歳以降に次第に用心深く振る舞い、「恥を知る」責任が課せられ、甚だしい拘束を甘んじて受け入れさせられる。
子どもによその〇〇ちゃんはもうそんな馬鹿な真似はしない、とかあなたはもういらないとか、そういう手段でいうことを聞かせようとするのが、嘲笑とつまはじきに対する恐怖心を養うことになる。
小学校の最初の三年は「困った事態」に陥ることをさけるように教えられる。
他人と違ったことをすれば、世間の笑いものになる、といって聞かされる。
また、自分が取るべき行動が規定されている。
日本では、年齢、階級と立場でふさわしい行動が求められる。自由な領域とそうでない領域が厳しく分けられている。
他人が期待することをやる、自分がやりたいことをやってはいけないという束縛が青年期に一番強く課される。

自重という言葉の意味は、「自分を重んじる」ことではなく、自分がやりたいことをしないという意味。
自分がやりたいことをやって、結果失敗したら恥ずかしい、恥辱は最も避けるべきこととして刷り込まれる。」。

令和の時代でも一緒で、最近も「40代でパーカーがダメ」とかそういうのに現れている気がしますね。

以下本からですが

「商人は階級制度の破壊者。なので、家康は彼らを一番下にした。
階級制度はとても細かく定義してあった。
それは秩序と保証の拠り所。日本人は詳密な行動の地図を必要とする
人が規則に従う限り保証をあたえた。
日本人は改革を毛嫌いする。
ふさわしい地位というのにこだわる。成金が嫌われる。
友好的態度は、あなたまかせの態度をとることが安全な道。」

 

②恥辱の文化

以下本からですが

「日本人は罪の重大さより、恥の重大さを気にする。
恥を基調とした文化なのか、罪を基調とした文化なのかは大きな区別。
日本人は恥辱感が原動力。恥というのは、あらかじめ避けられる危険を察知しないとか。
日本人の問題は、彼らは一定の掟を守って行動しさえすれば、誰か他人が褒めてくれるに違いないという安心感をたよりに生活するように育てられてきたこと。

日本人に主義はない。日本人は悪の問題に正面から向き合わない。」

うーん。耳が痛い。

でも、最後のわかりますね。

「他人と同じようにしたい、なぜなら失敗したときに笑われたくないから。」

そういう人が圧倒的に多い気がします。

つまり、失敗したとしても、他の人も失敗しているから笑われないので安心、という話なのです。

主義がない話については、第二次世界大戦で日本が敗戦した後、連合国軍を笑顔で迎えたことに世界が衝撃を受けたそうです。

それまで、日本人は断固として降伏しない、という勢いで戦ってきたわけですから。それも、そういわれればという感じですね。

③名と義理、恩

以下、本から。
「日本人は失敗、誹謗、擯斥にあまりに傷つきやすく、自分を悩ませる。ニホンの小説には、教養ある日本人がしばし我を忘れて怒りを爆発させた後、極端な憂鬱におちいるという話が繰り返し出てくる。
擯斥の恐怖に何もできなくなる。」
④競争について
以下、本から。
「日本人は競争があると効率が落ちる。競争があると成績がよくなるというのはアメリカの場合だけ。
競争でやると、負けるのではないかという危険に心を奪われる。
競争という機会は日本の教育では最低限におかれている。」
そうなんすね…。

以上ですが、単なる日本ディスみたいに聞こえたかもしれませんが、外国から見てこう、というのは大変参考になることだと思います。

分厚い本なので、勉強になった話を全部を紹介することは不可能なのですが、本の中ではアメリカとの対比だけではなく、太平洋諸島の文化の話や、西欧諸国とアメリカの違いなどにも言及されてます。

なので、いわゆる浅い

「出羽守」

的な話ではなく、かなり納得感の行く話になってます。

それは例えば「アメリカがイイ」とか「日本がイイ」とかそういう論点ではなく、戦時の

「日本をどうしたら攻略できるか」

という観点で書かれているからなんじゃないかと思います。敵を知ることが重要ですからね。

アメリカだってめちゃくちゃ問題を抱えた国だと思いますが、それとこれとは話が別なわけです。

 

皆さんはパラパラという踊りを知っていますか?

昔、ディスコやクラブではやっていたそうですが、知らない人のために言いますと、決まった踊りを覚えてきて踊る、というやつです。

日本人は自由にふるまっていい場所ですら

「自由にする」

ことができないことの一つの現れなんじゃないかと思います。

親や年長者の教育、古くからある物語、価値観の中に
「一定の掟を守って行動しさえすれば、誰か他人が褒めてくれるに違いないという安心感」
がめちゃくちゃ刷り込まれているということのようです。

 

最後に個人的な意見なんですけど、

「笑われたら恥ずかしい」

という考えは、現代日本人を苦しめている気がしますね。

つまり、「菊と刀」が描かれた1944年ぐらいの価値観であれば、戦争に行って戦死をとげることが日本人にとって名誉なことだったから
「笑われたくない」
という価値観はマッチしていたと思います。

ただ、現代においては戦死なんてとんでもないし、一回しかない人生、個人の幸福を追求していい、ということになりました。

日本人にとっては、誰かに何かを決めてもらわないと行動できないのに、「好きなことをやっていいよ」となったわけです。

そして、「好きなことをやる」となると、一人一人やりたいことは違うので、「他人と同じことをする」わけにはいかなくなります。

他人に期待されたこと、他人と同じことをやっていつの間にか老人になり、死に際しても誰も誉めてはくれない。

それぐらいなら、好きなことをやればよかった。

それに気が付いたときにはもう手遅れなのかもしれません。。。

もっと、好きなことをやって生きていけばいいんじゃないかと、私は常々思ってます。

MINDSET マインドセット という本を読みました 

どっかで紹介されていたので読んだんですが、よい本でした!

マインドセット

この本の主題は、たった一つ

「能力は伸ばせるものである。能力を生まれつきで変わらないものと思い込んでいると、それは伸びないし、人生に問題を与える。」

ということが繰り返し書かれています。

347ページありますが、ほとんどこれだけです。

ただ、確かに非常に重要なことだと思います。

 

この本曰く「人間は変わらないと思い込んでいるコチコチマインドセットの人間」は次のように考えてしまう。

①人間は生まれつき、頭の良い人間、悪い人間がいる

②努力してもそれは変わらない

③努力してうまくいくことは、能力の証明にはならない

④努力せずに成功することが自分が優れていることの証明である

⑤つまり、努力したのに失敗したとしたら自分は優れていないと証明されたことになってしまう

⑥そうなったら大変なので、少しでも失敗しそうなことはやらないし、もちろん努力をしない

⑦結果 努力しないので何も成果が上がらない

⑧失敗したら自分が優秀ではないということになってしまうので、すぐに他人のせいにする

⑨自己反省しないしやり方も変えないので、何もよくならない

⑥~⑨の繰り返し

 

恐ろしいですね…。

「コチコチマインドセット」の逆は「しなかやマインドセット」です。

しなやかマインドセットの人は、失敗しても、そこから何かを学び取ろうと思い、自分が優秀だとか優秀じゃないとかに結び付けないので、成長できるし、成果もあげられるんです。

 

何度となく、ハッとさせられました。

私も仕事をしてきて25年ぐらいになるんですが、仕事のできない人って「思い込み」が強い人が多いな、と思います。

ちょっとした人の行動を見て

「あの人は箸の持ち方がなっていないから、育ちが悪い。ロクな人間じゃないに決まってる。」

みたいなことを言う人です。

そういう人って他人のことをずーっと見てるんですよね。

それで

「あの人のああいうところがよくない」

と他人を断罪することに時間を使ってしまいます。

そんな時間があるなら、別のことをしたらいいのにな~ って思うんですが、つまりそれって

「人間は変わらない」

「自分は優秀 ○○さんは無能」

という考えの裏返しなんですね。

 

人間関係、恋愛・友人関係もそうで、

「相性がいいから」

「運命の相手だから」

ということで相手も変わらないし自分も変わらないと考えていると、何かやっていけない問題が立ち上がった時に、相手と話し合わず、相手がどうしようもない人間だと決めつけてしまうようです。

人間関係というのは常に努力が必要だと私も思ってますが、コチコチマインドセットの人は人間関係に努力が必要とは思ってないんですね。

 

少し話が広がるんですが、生きづらい世の中 と言われて久しいですが、上記のような思考に世間が取りつかれている気もします。

「完璧な人は生まれながらに完璧である」

という幻想です。

大谷翔平は努力しているからすごい人なわけですが、完璧なところに皆さん目が行きがちなんだと思います。

ご本人はインタビューなどで、

「僕に才能はない」

と話しているのも

「またまた~ 謙虚ぶっちゃって」

となるわけです。本人が

「とにかく練習した。」

と話しているのでそれを素直に受け止めたらいいんじゃないでしょうか。

そして、誰か何か悪いことをすると、いきなり悪い人というレッテルを貼り、すべてを否定するのはよくない気がします。

誰にでも悪いところはあるし、失敗することもあるし、人は変われるので。

 

この前街を歩いていたらワイルドという詩人の詩が書いてありました。

「人を一目で判断してはいけない。

どんな聖人にも過去があり、どんな罪人にも未来がある。」

 

自分がコチコチマインドセットにならないように気を付けていきたいです。

 

 

どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか(プログラミング)

若手プログラマーの疑問に答えていくシリーズ第2弾を書きました!

よかったら読んでみてください。⊂(^-^)⊃

対象者は下記のような方です。

-プログラミングを始めて2,3年以上
-オブジェクト指向でプログラミングをしている
-オブジェクト指向のプログラミングを理解はできるし、自分で書いているが、うまく書けているか自信がない

 

 

前回はこちら↓

若手プログラマーの疑問に答えていく

「はじめの一歩を踏み出そう」という本を読みました

まず、最初に言いたいことはこの本にもっと早く出会いたかった…。

3,4回読みました。

それぐらい感銘を受けた本です。

「はじめの一歩を踏み出そう」

https://amzn.to/47FbmRm

はじめの一歩をふみだそう

会社をやっている、これからやる、会社経営に携わる、小さい会社にいる人にはぜひ読んでほしい本です!

 

会社をやろうという人が

「起業家タイプ」「マネージャータイプ」「職人タイプ」

に大体分けられるが、それは「職人タイプ」は100%職人なわけではなく、起業家の側面も持っている。

逆に、起業家も100%起業家なだけではやっていけず、マネージャーの側面も持っていないといけない。

職人として、目の前の仕事に没頭してしまう人が多いが、会社を成功させるために必要なのは、「システム化」である。

個人の能力に依存しないことが肝心。

システム化、マニュアル化というと血が通っていない冷たいイメージを受けるかもしれないが、それは違う。
ロボットのように永久的に同じやり方をやるのではなく、イノベーション+数値化に継続的に取り組むことで個人を成長させられる。

一流企業は名もない会社だったころから一流企業のように経営されていた。

製品やサービスは、一貫したもので提供されないといけない。顧客の期待を裏切ってはいけない。

例えば、床屋で最初はコーヒーが出てきたのに、次に行った時は出てこなかったとかのサービスの品質が一定でないことで、顧客の足は遠のいてしまう。

 

 

スマホアプリで配送ルートの配送の順番が入れ替えできるようになりました!

なんとなんと。

ODIN リアルタイム配送システムのスマホアプリ(2024/09/15時点 Android版のみ)で、配送計画の順番入れ替え機能が付きました!

パチパチパチパチ。

下記のような配送計画をドライバーさんのアプリで見る画面があるんですが、これをドラッグアンドドロップで動かしたり、消したりできるようになったんですよ( ˊᵕˋ )

動画とかないとわかりづらいとは思いますが、動画はそのうち撮ります!

配送計画入れ替えの画面

配送計画入れ替えの画面 ドラッグアンドドロップとかで入れ替えできます

 

また、マイナーな修正ではありますが、

「配送先が多い計画を見る時に、配送計画の一覧画面を開くと、一番上の配送先が一番上に表示されるのが見づらい!なんとかして!」

というお客様のご要望を頂いていたので、配送してない配送先を一番上に来るようにしました!

これも、配送先に到着したかどうかがわかるODINならではの機能だと思います。

 

しかし、こういうのはお客様の環境でお客様が使ってみて初めて得られる知見ですよね。

現場で使ってみて、初めて細かい使い勝手がわかるというか。

こういうお客様の声を大切にしております。

 


今回はですね、不詳私がこの修正をやらせていただきました!(`・ω・´)

おりしも、実はAndroidのターゲットSDKをアップデートするというタスクもやらねばならず、やることが多めではあったんですが、チームの皆さんの助けがあり、なんとかできました。( ˊᵕˋ )

ODIN リアルタイム配送システムのAndroidアプリも10年前から存在しているので、古い部分もまだあります。

古い部分はJava、新しい部分はKotlin、サーバー側の処理(大部分はS君が書いてくれましたが)はPHPとTS & JS で、5言語を同時に書いたり読んだりするのがだいぶ脳トレでしたね!(笑)

ODIN リアルタイム配送システムはお客様の使い勝手向上のため、どんどん便利になっていきます!

お問い合わせはコチラからお気軽にどうぞ!( ˊᵕˋ )

 

 

 

 

 

若手プログラマーの疑問に答えていく

実はもう16年間ぐらいプログラマーをしています。

まー、本業は社長なので、全部の時間をプログラミングに費やせるわけではないので、実際に16年間プログラミングをしている方と比べたらどうかわかりませんが。

会社に新入社員か未経験の中途さんが入ってくると、私が教えることもあります。

で、大体似たようなことを似たようなタイミングで聞かれるので、まとめてみようと思ってます。

第一弾は、

「スーパークラスかインターフェースか 」

です。

「共通する機能ってスーパークラスに実装するのと、インターフェースにするの、どっちがいいんですか?」

と聞かれることが多いんですよね。

答えはぜひ、リンク先のスライドを見てみてください。(o_ _)o))

 

ちょいちょい書いていることですが、プログラマーはエンジニアかと言ったら、ちょっと違うと思います。

 

難しいことをやろうとしたら、アーティスト的な能力の方が必要になってくるんですよ。

問題を解くのではなく、作品を作るってことなんですよね。

なので、プログラマーとしての良し悪しは、「何を作ったか」につきると思います。

採用の場面で、

「こういうことを勉強してきました」

とか

「前の職場ではこういう仕事をしてきました」

とズラーっと職歴を並べて頂けることもあるんですが、自分の代表作だと思うものを見せてもらったほうがずっと説得力があります。

 

弊社では新卒・中途のプログラマーを募集中です!

ぜひ、コチラからご応募ください。( ˊᵕˋ )

 

 

 

『ハーバード流交渉術 必ず「望む結果を引き出せる!」』 という本を読みました

この本、めちゃくちゃいい本で、実のところ3回読みました。

ハーバード流交渉術 必ず「望む結果を引き出せる!」

必ず望む結果を引き出せる!ハーバード流交渉術

ぜひ、みなさんに読んでほしいです!!!

が、どうですか?このタイトル。

「とっつきにくいな~」

とか

「なんか営業マンとかが読む本でしょ?自分には関係ないわ。」

とか

「難しい理論とか駆け引きとかのテクニックなんでしょ?」

と思いませんでした?

私は思いました。ビジュアルもちょっととっつきにくいですしね。

でも全然違う中身です。

めっちゃ平たく言うと、そういう駆け引きとかではなく、お互いに利益のある方法でゴールを見つけようという話です。

これは、あらゆる利害が衝突する人間関係で有効な話です。

職場の顧客や取引関係はもちろんのこと、上司・同僚・部下、家庭、恋人、友人、サークルの仲間、近所、大家、などなどです。

 

で、もう一度書きますが、本当に全大人に読んでほしい。(ゼン・ターレンではなく、大人全員という意味です)

それは、この本のある部分が私は一つの生きていくヒントになる気がするからです。

あなたは、「わからずや」に出会ったことはありませんか?

「この人、話が通じないな…。」

と。

この本では、自尊心について多くのページが割かれています。

自尊心を傷つけられた時、人は「わからずや」になってしまう。

うーん。わかりみが深い…。

そして、実は自分のほうも「わからずや」になっている危険性があるんですね。

ケンカになった時、相手が「わからずや」になってるなと思う場合がほとんどかもしれませんが、まずは自分が「わからずや」になってないか、自分が「自分のメンツ」「傷つけられたという思い」にとらわれていないか自問するのもいいと思います。

 

特に本書の中で覚えておきたいな~ と思うことをメモします。

・問題と人を分ける。人を非難するような話し方をすると、相手は守りに入ってこちらの言うことを聞いてくれなくなる

・相手は一人の人間。それがたとえ国対国や、裁判などだったとしても、個人の意識・考えなどはかなり判断や行動に影響を与える

・人間なので、感情が大事。例えば、メンツが立たないとかそういう理由でハードな交渉を仕掛けてくる場合がある

・関連して、自分を軽んじられていると思ってハードな交渉をしかけてくる相手もいる
自分たちを対等の相手として扱ってほしいという感情に目を向けるべき

・相手を重んじるために、相手の話をよく聞くことが大事。

・何かを取り決めるプロセスに、あらかじめ反対派を入れておくと、反対が少ない

・相手にこちらの利益を認識してもらうには、その利益が正当なものだと納得してもらうこと

・お互いが相手をやりこめることや、今まで抱いてきたイメージの補強材料としてしか話し合ってこないことも多い

・大体の議論をしている人たちが
「向こうの態度は許せない。私をコケにしたらどういう目にあうか、思い知らせてやる。」
ということしか頭になかったりする。

・昨日の行動のいい・悪いを問い詰めるより、明日、誰が何をできるかを考えよう

・問題を探そうという批判意識ほど、アイデアの邪魔になるものはない

・相手の問題は相手が解決すべきだというのは思い込み

・物事にたいする判断は自由な発想の邪魔

・パイを分け合うのではなく、パイを増やすことを考える
その場合に、複数人でブレーンストーミングするのがよい
ブレーンストーミングをする際に誰が何を言ったかなどの責任を問わないほうがよい

・交渉では例外なく共通の利益が存在している

・交渉が決裂したときにとれるベストな行動を決めておく

・どこが問題かを相手に聞いてみる


ちょっと話は「わからずや」に戻ります。

こじれるケンカというのは、一方が「何に怒っているか」「何が得たいのか」をはっきり言わないことのケースが多い気がします。

これも自尊心の問題で、自分を守りたい、プライドの高い人は何に怒っているのか言わないんですよ。

相手に自分が怒っていることを言うと、

「そんなことに怒っているのか。小さい人だな。」

と思われるのがイヤで第三者にも言わなかったりします。

 

こじれる喧嘩で多いのが

「どうして察してくれないの??」

とどっちかが憤慨していて、どっちかが

「そんなこと言ってくれなきゃわかんないよ!」

ということが多い気がします。

 

これって一番始まりが、自分のことを察してくれてないのはつまり自分を重く受け止めてくれていないのだと思って自尊心が傷つけられて始まっているので、そこがまず「わからずや」化してるんですよね。

 

でも、これは怒っている理由をズバッと早めに言った方がいいと私は思ってます。

人間には、相手の感情を全部わかる能力はありませんから。それを他人に求めるのは結局自分がむなしくなるだけです…。

そして、ちゃんと理由を言わないと、結局的外れな議論に終始して、生産性がなく、決裂して終わりになるか、嫌な感じをひきずってお互い歩んでいくのどっちかになっちゃいますからね。

 

 

「ちょうぜつソフトウェア設計入門」という本を読みました

ちょうぜつソフトウェア設計入門」。

うちのプログラマーS君が

「おススメですよ!」

と言ってくれたので、読んでみました。

結論→よい本です!

かわいい絵がついていますが、中身は本格派!

普通に技術的なとっつきにくい話が展開されていますが、かわいい絵がついていることにより、とっつきやすい感じになっているのがすごい。

プログラマーの初心者向けというよりは、中級者、2年目とか3年目の方が読むとちょうどよさそうです!

 

ソフトウェアの設計って本当に大事ですよ。

この前、XにPostしたんですけど、一番大事なのはDBの設計ですが、次に大事なのは、クラス設計だと思ってます。

ただ、クラス設計についてまったくわからずにプログラミングをしている方も多くいると思います。

別にわからなくてもできるし、ソフトウェアは動くからです。

しかし、設計についてわかってやっている方が、他の人の開発が早くなるし、バグも少なくなります。

その逆も真です。

また、クリーンアーキテクチャーの一番内側に近い部分の設計がダメだと、技術的負債が膨れ上がります。

外側に近いほうはダメでもまだなんとかなるのですが。

 

この本は、いろんな手法をある程度の深さまで紹介してくれる点で優秀だと思います。

ぜひ、設計をちゃんとやってみたいという志がある方は、この本を読んでみてください!( ˊᵕˋ )

 

以下、私が読んでよかったなとか知らなかったことなどをメモしておきます。

①パッケージ原則

ちゃんとパッケージに分けましょう。

②オブジェクト指向とかSOLIDとか

オブジェクト指向の紹介と、SOLIDというソフトウェア設計の原則について紹介されています。

SOLIDは次の原則たちの頭文字です。

・Single Responsibility Principle 単一責任原則

・Open Closed Principle 拡張に対してオープン、変更に対してクローズドであるべき
この本の中で
「洋服をいっぱい着てというのはいいけど、痩せろとか胸を大きくとかは難しい、というのに似ている」
と紹介されていて、このたとえはわかりやすいな!と思いました。

・Liskov Substitution Principle リスコフの置換原則

・Interface Separation Principle  単一責任原則のインターフェース版

・Dependency Inversion Principle 依存関係逆転原則

 

ちなみに、SOLIDとは別で「デメテルの法則」というのが紹介されていて、すごい重要と思わないですが、これに名前がついてたのか!というのを知らなかったのでメモしておきます。

詳しくは下記を読んでいただきたいですが、
デメテルの法則を厳密に守るにはどうすればいいの?

現場ではこうなってるプログラムっていっぱいありますよね。

$this->car->getEngine()->start();
$this->car->getEngine()->getheat();
$this->car->getEngine()->getVoilder->getId();

 

みたいなやつ。

いや、もうEngineクラスに書きなさいよって。でも、書いてる時は夢中で書いちゃうから気が付かないんでしょうね。

③テスト駆動開発やデザインパターン

 

スタブとかモックとかをあんまり使い分けていなかったので、大変参考になりました。

・スタブはテスト用の疑似オブジェクト 仮に期待通りの答えを得たとしたら、を仮定するダミーオブジェクト

・モックは使われ方を検証するための疑似オブジェクト(呼び出し回数とかをちゃんとチェックする)

 

④アジャイル開発

 

アジャイル開発とは何か、というだけではなく、ソフトウェア開発の歴史が書いてあって、非常に参考になりました。

私の師みたいな人がよく

「歴史を知ったほうがいい」

ってよく言ってるんですが、その意味がよくわかります。

ウォーターフォールについて、一般に誤解があることもわかりました。

ドキュメント偏重とか、SIの歴史なども勉強になりました。(o_ _)o))


 

それにしても、ソフトウェア開発って苦労することばっかりですよね。

世に目を向ければ、ソフトウェア開発の失敗のニュースがよく飛び込んできます。

日本のシステム開発が少しでもよい方向に行ったらいいなと思います!

 

さて、弊社でも新卒・中途でプログラマーを募集しています!(営業も募集中)

ソフトウェア開発、設計とか考えてやりたいと思っている方がいれば、ぜひ弊社に応募してください。

イチから教えます!(`・ω・´)

応募はコチラから!

ちょうぜつソフトウェア開発設計入門を手に持つS君

 

「ハッカーと画家」という本を読みました

この本はどっかで読んだ本に紹介されていたのと、タイトルにいつも私が考えていることに共通することがあったので、手に取りました。

多分、プログラマーをしている人には普通に面白い本ですが、私にとって衝撃を与える、思い出に残る一冊になりました。

ハッカーと画家 コンピューター時代の創造者たち

ハッカーと画家

「普通のやつらの上を行け」という帯が若干恥ずかしい(笑)

 

まず、ハッカーという言葉に「物騒だな」と思われたかもしれませんが、これはここでは「優れたプログラマー」という意味で使われています。
「エンジニア」という広い意味ではなくて、「プログラマー」ですね。
著者のポール・グレアムさんという方は、後のYahoo!Storeとなるソフトウェアを作り、ベンチャー創業者として大きな成功を収めたことで知られる方、だそうです。

 

①アメリカ人はどうしていいプログラムを書くのか

 

冒頭の「メイド・イン・USA」という章にのっけから衝撃を受けました。
「アメリカ人はどうしていいプログラムを書くのだろう。」

どひゃー。これは、私もずっと考えてきたことなんですよね。私も日本人ですから、よく言われる
「日本ってさー 何かを改善するのはうまいけど、クリエイティブなものを作るのは苦手だよね~」
ってやつ、ほんとムカつきますよ。(アニメとかゲームとかはクリエイティブなもの作れてると思いますしね)

一瞬話はそれますが、私が会社を作った目的は
「日本にGoogleみたいな会社を作る」
ということなんですが、それは
「なんで日本にはソフトウェアの世界的に有名な会社がないんだろう??」
と思ったことが理由です。

車や車の部品を作ることはうまいのに…。

本書の抜粋ですが、
「米国人は一度何かをしたいと思い立つと、それがうまくできないんじゃないかとか、世間的に角が立つんじゃないかとか、そういうことを気にしない。
何かしたくなったら、ナイキのコマーシャルみたいにするんだ。Just do it.というやつだ。」
映画やソフトウェアはこれでうまくいく、だそうです。

まだ抜粋が続くんですが
「「几帳面」なんて言葉は、優れたプログラマがソフトウェアを書く仕事ぶりからは最も無縁なものだ。
コードはピラミッドみたいに、慎重な計画をしてから苦労して組み立てていくものではない。
(どうして日本ではよい車が作れるのかという話で)日本人の文化に、デザインと職人の仕事を尊ぶところがあるのが重要なのだと思われる。…彼らは、ものをうまく作ることに取りつかれているんだ。」

うわー。
職人を尊ぶ文化は、よいソフトウェアを生み出すのには向いていない
と言い換えていいと思います。

さて、プログラマーとは、「職人」なのか。「芸術家」なのか。
日本では、「職人」に近いと思っている人が多いと思います。
きめ細やかな仕事、整理整頓されたコード、素晴らしいアーキテクチャー。

ここで、職人と芸術家を私なりに定義してみました。
・「職人」→ 過程にこだわり、例えば「裏側を見せてもキレイ」とか「細部もめちゃくちゃちゃんとやってある」にこだわる
・「芸術家」→ 成果物にこだわり、「裏側はぐっちゃぐちゃ」、「細部はメインの引きたて」

確かに、日本は「職人の手仕事」が大好きで尊ぶところがあると思います。
それがカッコイイと刷り込まれて生きています。
プログラマーは「芸術家」なのか、「職人」なのか。

非常に定義が難しいです。
そして、私が思う「職人」と「芸術家」の最大の違いは
・「職人」 → 他人が指定したもの、あるいは期待したものを作る
・「芸術家」 → 自分が作りたいものを作る
だと思います。

プログラマーと一口に言っても、仕事や会社によって全然変わってくると思います。
受託開発・SES・Sier・下請け企業のプログラマーさんは圧倒的に職人でいることを求められると思います。
自社開発でやってる会社さんでも、企画は企画部がやって、プログラマーは完全に職人でいることを求められていることがあります。
弊社は、プログラマーさんも仕様を考えて実装するので、芸術家の割合が高いです。
ちなみに、これは職人がいいとか悪いとか、職人さんをディスする話ではありません。
何より、「ご飯を食べていく」ことを考えれば、普通に芸術家は職人よりも貧乏であることが多いですからね(笑)。

でも、ポール・グレアムさんの主張に確かにそうなのかもな… と思ってしまいました。
「職人を尊ぶ文化は、よいソフトウェアを生み出すのには向いていない」
というのは私の会社を作った目的に対するヒントを与えてくれるものでした。

②常識を尊ぶ人はハッカーに向いていない

 

これもなんかわかるなって感じでした(笑)。
「ちょっと変人だな」
という人が優秀なプログラマーには多いものです。(その逆は真ではないけども)

他大多数の人と同じことがしたいと思っている人が、同時に革新的なことを生み出せるはずはないのです。
品行方正・成績優秀な優等生が優秀なプログラマーかというとそうではないんですよね。
「口にできないこと」「異端であること」には価値がある、「道徳には流行がある」なども考えさせられました。

優れたプログラマーは画家に近い

 

わかる~。本書の抜粋で
「優れたソフトウェア設計者は、建築家がエンジニアではないのと同じように、エンジニアではない。
ハッカーは、画家が絵具に関する科学を理解するのと同程度にコンピューターサイエンスを理解していればよい。」

そうなんですよ。よく、
「文系だからプログラマーとかなるのは無理です。」
みたいなことを言う人はいるんですが、それはおかしいんです。

なぜなら我々がやっている仕事のほとんどが、現実という複雑な事象から、何かを抽象化して抜き出すことだからです。
それが画家のスケッチに近いと言われれば、そうなのかもしれない。
何か絵を描くときに、いきなり細部から描けませんね。

「作家や画家や建築家が作りながら作品を理解していくのと同じで、プログラマはプログラムを書きながら理解していくべき」
わかる~。
だから、上流工程とか下流工程、とかが分かれているプロジェクトってうまく行かないことが多いんですよね。
そして、スケッチというのは、書く練習が必要なんですよ。
優れた芸術作品というのは才能ではなくて、膨大な書く練習の上に成り立ってます。

ピカソとか、15万作も作ったらしいですからね。
経験から言っても、プログラマーはいっぱい書いたほうがいいです。

私も、プログラマーの新人に、
「うまくコードを書いてくれ。」
と言いません。
「とにかくいっぱい書いてね。」
と言います。

そして、書いただけではダメで、できれば誰かに継続的に使ってもらうことが必要だと思います。芸術というのは他人に評価されてなんぼだからです。

「多くの企業はハッカーにエンジニアたれと強要する。それがよくない。」
確かに、プログラミングをしていて思うことは、プログラミングに必要な能力って、エンジニアに必要な能力とちょっと違うんですよ。

ただ、あんまりこんなことを言う人はおらず、大体
プログラマー=エンジニア
と世の中で理解されているように思います。

この話も、いずれ別のところで語りたいなと思います。

④サポートはプログラマーと密にやる

 

これはですね、弊社でも意識していることだったので、ポール・グレアムさんの会社でもそうだったのかと思って嬉しかったです。
抜粋&要約ですが
「大企業ではユーザーサポートはユーザーの機嫌を取るためのものだ。ユーザーから電話がかかってくると、サポート部門は決まった形式にそれを入力し、時間が経ってからそれをプログラマのやることリストに加える。
Viaweb(ポール・グレアム氏の会社)では、ユーザーからバグ報告があがってきて1分もたたないうちに、サポートスタッフはプログラマの横に立っていて、プログラマが
『あちゃー、これはバグだね』
というのを聞いている。」

うちもですね、ODINの開発にあたり、同じような体制でやってます。(`・ω・´)

ODINのサイトに書いてあるんですが、
「サポート担当者と、システム開発者が机を並べ、緊密に連携を取って迅速にお客様へのご質問にお答えします。どうぞお気軽にご相談ください。」。
こうすることが、お客様の満足度を上げるだけでなく、よいソフトウェアを作ることにつながっていると感じています。

 

⑤ベンチャー企業について

 

「ベンチャーはほかのベンチャーと同じことをやっていてはいけない。ベンチャー企業の平均的な成長とは、すなわち、つぶれてしまうということだ。」
うう そのとーりで肝に銘じないといけないですね。

 

うわ、めっちゃ長くなっちゃった。

でも、この本についてまだ書ききれないぐらいです!

 

「人月の神話」という本を読みました

有名な本なので、タイトルを知っている人は多いと思います。
私もタイトルは知ってましたが、この度初めて読みました! Amazon: 人月の神話

なんと、1976年に書かれた本だそうです。
いや、時代を超えて語り継がれる名著ってやっぱり違いますね~。

何より驚くのは、ソフトウェア開発、つまりプログラミングというものにまつわる難しさの本質が、この48年前からほとんど変わっていないということです。
つまりは人間が何人か集まって、複雑なものを作ろうとすると発生する問題というのは同じなのかもしれませんね。

私が読もうと思ったきっかけは、弊社も少ない人数で開発していますから、
「いかに少数精鋭でよいソフトウェア製品を作るか」
ということを常に考えています。そんな時に、この本のことをAWSのセミナーで上げてらっしゃる方がいて、この機会に読んでみようと思いました。

下記に私が大事だなと思ったところを上げておきます。

①人月について

人月って言うのは、システム開発業界でよく言われる用語なんですが、「5人のプログラマーが5か月かかって作る」場合、5×5で25人月となります。

・人と月は交換可能ではない
コストは人と月に比例するけども
・人と月が比例するのは、作業者の間でコミュニケーションを図らなくても仕事が分担できる場合だけ
・コミュニケーションの労力は、人数が多いほどかかる。
・特に新しく追加した人は経験者から仕事に対する教育、訓練を受けないといけないので、それに3名が1ヶ月かかるとすると、3人月がもとの見積もりになかった人月がかかる。

→人員を投下しまくったり、後から開発に追加したりしても、なかなか成果が上がらないということです。
単純作業だったら、人を追加したらいいかもしれませんが、システム開発というのはコミュニケーションが大事だからです。
遅れているソフトウェアプロジェクトへの人員追加はさらにプロジェクトを遅らせるだけってよく言いますよね。

②スケジュール組について

ソフトウェア開発のスケジュールは
1/3 計画
1/6 コーディング
1/4 単体テストおよび初期システムテスト
1/4 すべてのコンポーネントを統合して行うシステムテスト
(あれ?この計算合ってます?(笑))

→計画が大事ってことですね!キモに命じます。

③コンセプトについて

少数精鋭チームは10人以内が理想的。
外科手術のチームように行う。
機能などで分担を分けるのではなく、執刀医と副執刀医はプログラムのすべてを把握し、判断する必要がある。

大勢で考えたほうがよいとか、そのほうが民主的とか、そういう問題もある。
が、重要なのはコンセプトの完全性なので、貴族政治の方がよいわけ。
アーキテクトとインプリメンテーションは違うタイプの創造的仕事。

ソフトウェア製品にとって、コンセプトの完全性がとても大事。
コンセプトの完全性は、デザインは一人または互いに意見が同じで共鳴するごく少数の頭脳から、考え出さないといけない。
重要な仕事は、製品を定義すること。

→これもわかる~×100。ですね。
昔、爆笑問題の太田さんがテレビで話していた逸話ですが、太田さんが映画を作ろうと思ったことがあったんですって。
で、映画を作っていると、太田さんは映画を作るのが初めてだから、美術監督は「これをこうしたほうがいい」、
照明さんは「あれをこうしたほうがいい」脚本家からは「こうしなきゃダメ」とか言われて、全員の言うことを聞いていたら、まったく面白くない作品になってしまったんですって。

これ、作品というか何か創造物というのは本当にこの側面があるんですよね。

④コミュニケーションについて

コミュニケーションの欠落が抗争、憎悪、嫉妬につながる。
そのうち内輪喧嘩するよりは一人でいたほうがいいと思い、バラバラになり始める。
マネージャーにとって重要なのは、全員を同じ方向に進ませること。
そして、組織の在り方というのは大事だし、組織にどんな人を追加するのかがとても重要。

→身につまされる話ですね。

⑤工数見積もりについて

プログラムを書く時間は、大体倍の時間かかる。
大体のプログラマーが、勤務時間の2分の1しかプログラムにかけられない。
機械が故障して使えないとか、ミーティングとか書類作成、社内事務、病気、私用など。

→わかる~。実際にそうですよね。

⑥スケジュールについて

1日毎の遅延
昨日はキーパーソンが病気
今日は機械の故障
顧客との緊急ミーティングなど、どんどんスケジュールは遅れていく。
が、3か月の納期とかってなってると、1日ぐらい遅れても、取り戻せるだろうと思っている。

しかし、結局1日の遅れを取り戻すことが難しい。
ハッスルプレイ、一生懸命になること、1日の遅れも取り返すために躍起になるべし。

→ううう その通りだと思います。

⑦ソフトウェアを作るということが、なぜこんなにも難しいのか

表現はプログラミングの本質。
仕様書や文書でコミュニケーションを図る必要がある。

何を構築するのかを決めるのが非常に難しい。
にも関わらず、後から変更するのがこれほど難しいものもない。

→弊社で、最近変えたことがあります。
それは、仕様書をもっと作っていく、ということです。今までは、テスト仕様書はあったんですが、プログラムの仕様書については、作ったり作らなかったりでした。
ソフトウェア製品の仕様書って難しいんですよ。すぐに仕様書が古くなってしまうからです。
コードが仕様書、テストコードが仕様書、という状態は多いと思います。

ただ、どうしてもそれじゃ表せない仕様がある。UMLもシーケンス図も足りないとい思うときが多いです。
図や絵じゃないと表せない仕様ってあるんですよ。
えてしてそういう仕様が複雑かつ大事なんですが、コードもテストコードもUMLもシーケンス図もそれを表すことができない時があります。
で、Outdateな仕様書だとしてもそういう絵や図を含むものが「ないよりマシ」という結論になりました。

また、表現はプログラミングの本質、という言葉にグサッときました。
私がいつも考えていることを一言で言い表してるなと思ったからです。

————————————

この本に出てきた言葉か忘れちゃいましたが、ソフトウェアって不思議なもので、1000人のプログラマーがいる大企業が出している製品よりも、ガレージの二人組の方がいい製品を出している、ということは起こるわけです。
我々もガレージ側なので、得られたことを生かしてがんばらないとな!って改めて思いました。

そして、弊社では現在、新卒・中途のプログラマー・新卒の営業を募集しています!
採用情報はこちら