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人のプログラマーがいる大企業が出している製品よりも、ガレージの二人組の方がいい製品を出している、ということは起こるわけです。
我々もガレージ側なので、得られたことを生かしてがんばらないとな!って改めて思いました。

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

 

 

「時間最短化、成果最大化」という本を読みました

これはたまたまアマゾンで目に入ってきて

「なぜ、あの人は私の150倍の成果が出せるのか」

という小見出しに興味を惹かれてしまいました。

そりゃ、150倍成果を出したいからね(笑)

この本は、要はスキルよりも考え方が大事という話が繰り返し出てくると思います。

いや~ ほぼ100%同意ですね。

スキルって大した違いじゃないんですよね。

皆さん、スキルさえあれば仕事がうまくいくって思っている人が多い気がしますが。

経験的に、仕事というフィールドにおいて、同じことに遭遇しても成果を上げられる人、上げられない人の差はスキルの差ではなくて、考え方の差なことが多いと思います。

最初に衝撃的な話があるんですが

「社会人になった最初の上司がどんな人だったか」

ということが、ビジネスパーソンとして成功しているかしないかの違いを最も作るらしいです。

それは、考え方というのをその人に刷り込まれるからだそうです。

へぇ。

これもよくわかりますね。

私は最初にサラリーマンとして働いていたときは外資系に勤めていたので、全員転職で入ってくるんですよ。

ただ、びっくりするんですけど、同じ会社から来た人って同じような考え方をしているんですよね( ゚Д゚)

そして、同じような不平不満を毎日言って、新しい職場になじめず、同じような期間で辞めちゃうんです。

 

さて、本自体は読みやすくてすぐ読めるし、たとえ話もあって腑に落ちながらも、非常に穿った内容なのでおススメです。

下記はメモです。


①後でゆっくり考えよう、を止める
打ち合わせは相手とのすり合わせ

②重要度と緊急度が一緒なら、早く終わる方を終わらせる

③10回やると1回成果が出る

④3歩歩けばチャンスがある

⑤面倒なことをやる。
面倒なことは他人はやらないから。

⑥宇宙でボールペンが使えないから、優秀な科学者が120億ぐらいつぎこんで宇宙で使えるボールペンを作った。しかし、ロシアは
鉛筆を作った。ボールペンを作ってないか、難しいことをやるのに悦に行ってないか考える。

⑦欠落的欠点は直したほうが良い。(仕事をしていくうえで致命的な欠点という意味です)
ケアレスミス
スケジュール管理ミス
タスク管理ミス

ケアレスミスが多い人には丁寧にチェックしてね、という

⑧会議では必ず発言しよう

⑨リアルな空間では自分の興味のあるなしに関わらず情報が飛び込んでくる。ネットでは、自分の興味あるものは深堀りできる
アマゾンは新しい発見に向いてない

⑩無理と思う問題をチームで話し合ってみよう

⑪「作る」までじゃなく、お客様に伝わるまでが仕事

空が高くなってきましたね