公式発表はコチラ↓です。

https://onlineconsultant.jp/close-2/

 

齊藤君は2013年に入社し、もう11年も勤めてくれているのと、多大な功績を評して、取締役になってもらうことにしました。

仕事で実績があるというだけでなく、逆風が吹いたときも、他の社員さんを励ましたりする姿勢があり、そういう方にもっと権限とリーダーシップを持ってもらいたいからです。

 

齊藤君に初めて会った時のことを思い出すと、彼は新卒の時に不動産屋の営業をやっていて、それで24歳ぐらいの時に転職でうちの会社を受けてくれたんですよ。

自筆の履歴書が送られてきて、すごく字がキレイで丁寧なことに驚きました。

経歴でよいなと思ったことは、

「ソフトテニスを中学・高校・大学と続けていて、神奈川県で2位、部活ではキャプテンだった」

というところです。

チームスポーツでよい成績を納めた方、キャプテンやリーダー経験のある方は仕事ができる傾向にあるからです。

ただ、面接してみると、話がわかりにくい…。

それで、面接支援をしてくださるコンサルタントの方がいるんですが、その人が

「この方はダメ。NGですよ。」

とおっしゃいました。

が、私は何か光るものを感じたので採用しました。

 

未経験からプログラマーとしての入社でしたので、最初は私が一から教えました。

が、進捗が思わしくなく、私は齊藤君に毎日怒ってました（笑）。

まー、本人にも当時から言ってたんですが、野球の野村監督の有名な言葉で

「一流の人間にしか怒らない」

というのがあります。

私も当時から、齊藤君には一流になってほしいと思って怒ってました。

 

業務に入ると、要領がよいとは言えないが、がむしゃらにがんばってなんとかしてくれるようになりました。

後、齊藤君が作ったところはお客さんに評判がいいんですよね。

お客さんが感じる細かい使い勝手って、些細な気遣いなんですが、プログラム的には

「その些細な気遣いが難しいんだよぉぉ~」

ということがよくあります。

そこを齊藤君は非常にがんばってくれるんですよね。

大きなお客さんに、ちょっと無理難題なことを言われた時も、彼は一人でその仕事を回して連日夜まで頑張ってなんとか実装にこぎつけてくれたことがあります。

そうやって獲得した大きなお客さんの仕事で、うちの会社は大きな利益を得ていたことがありますから、齊藤君の実績が多大というのはそういう部分です。

最近では結婚もし、子供もできて少し重みが増したかなと思います。

忙しいのにプライベートでもよく勉強をしていて、そういうところは本当に見上げたものです。( ˊᵕˋ )

 

齊藤君と相対すると、話がわかりにくんですよね（笑）。

文章もわかりにくい。

ただ、弁舌巧みで文章がうまく書けてという人間が仕事ができる、というのは浅い仕事だと思います。

本当に大きな仕事や会社にインパクトを与える仕事というのは、それだけではできないんですよね。

お客さんから信頼をもらえないと、任せてもらえない。

齊藤君にはそれがあるわけです。

仕事というのは、突き詰めれば信頼なんだなと思います。

 

誰も完璧ではないし、個性もあります。

会社というのはチームでお互いの足りないところを補完して進めていくのが大切だと思います。

そういう意味では、私と齊藤君は結構いい補完関係にある気がしています。

 

では、最後に齊藤君のOCヒストリーを見ていきましょう★

 

これからもいろんな世界の海で齊藤君を埋められるといいな！⊂(^-^)⊃

 

新体制でこれからも「日本にGoogleのような会社を作る」ことを目標にがんばっていきますので、よろしくお願いいたします。

 

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

うちのプログラマー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とは別で「デメテルの法則」というのが紹介されていて、すごい重要と思わないですが、これに名前がついてたのか！というのを知らなかったのでメモしておきます。

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

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

 

みたいなやつ。

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

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

 

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

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

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

 

④アジャイル開発

 

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

私の師みたいな人がよく

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

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

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

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

---

 

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

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

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

 

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

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

イチから教えます！(`･ω･´)

応募はコチラから！