投稿

「ソフトウェアそのもの」を売るビジネスをしているか、「ソフトウェアが使えること」を売るビジネスをしているか。モノとコトの違い。この違いが品質の考え方を変えるし、それはテストの仕方を変えることになる。

研修なんかで勉強だけしてると、本当に役に立つのかわからないし、理解するのにもリアリティが足りない。一方で、現場で実践しかしてないと、新しいことを知ることもないし、もっと勉強しとけば良かったと悔やむことも多い。学びながら前に進むのが良いんだろう。

一歩ずつ少しずつでも前に進めていけば、着実に進む。まわりの変化の速さに焦ることもあるけど、出来ることをコツコツとでもやっていくので良い。外から見ると急に変わったように見えても、中にいるとじっくりと進んでることが多い。種を蒔かねば芽が出ることはなく、水をやらねば育つこともないのだ。

経営の施策を考えるときに、一つ一つに納得できる理屈を求めてから判断してる。とても面倒だし時間がかかるけど、それがうちの社風。たぶん経営者である私たちは心がプログラマなので、綺麗なコードを書くように、そんな風に会社を作っていってる。大きな目標だけ立てて、中身が汚いのは好きじゃない。

社員の採用を決めるときは、その人だけでなく、その人の家族も預かることになるし、その人の大事な人生の時間を預かることになるので、選考を決めるときは、何度やっても恐ろしいし、腹も括らないといけなくてしんどいのだけど、いつまで経っても、その気持ちは忘れないでいた方が良いんだと思う。

品質は犠牲にしてはいけない。スピード出したり詰めこんだりしたら、そのときは喜ばれるかもしれないけど、結局はお客様のためにならない。だから”後で直す”なんてコメントで妥協してはいけないし、テストコードもさぼらない。

属人性の排除って言うけど、属人性の高い仕事の方が報酬は高くなる傾向があるように思うし、その人ならではという指名で仕事がもらえるというところを目指した方が、やりがいはあるのではないか。

若い人たちの前で、なんだか偉そうに話してしまったけれども、本当は若い人たちが自分の感性で自分の信じることを進めることの方が、新しい世界を作れるんだと思うし、私もそうしてきたつもりなので、常識なんかに囚われずに自分の思う通りに頑張って欲しいと思います。

良いコードとは何かを語りあったり、お互いにコードレビューをしてくれるような仲間のいる環境を作ること、DRYでなかったり読みにくいコードを書いたら恥ずかしいと思う文化を作ることが出来たら、アジャイルなんて言わなくても、保守性の高いソフトウェアは作れる。

起きた問題そのものについて悩み嘆くよりも、問題の解決方法について悩む方が生産的だしエネルギーに無駄がないと思いますね。

一社だけでは業界を変えられないこと、受託開発のマーケットはなくならないことと、ゼロからビジネスモデルを作るのは大変なことを考えて、ソニックガーデンのビジネスモデルを採用したいという会社やこれから起業したいという方々をサポートするようなコミュニティか仕組みを作ったら、どうだろうか。

今日は、社内でやってるふりかえりにオブザーバー的に参加させてもらって、とても多くの学びを得たので、またブログにしたいと思う。人は人を育てて、自らも育つ。育てることで育てられる、ということなんだと感じた。

小さな会社だけど、知恵と工夫で大きなことをしようとするときのお手伝いが楽しい。どちらがどれだけ沢山のお金と人を使うか、という勝負はあまりしたくない。

ブログやプレゼン資料の骨子を考えるときや、会社の経営戦略を考えるとき、頭で考えてメモやマインドマップに吐き出してるんだけど、成果としてはなにも生産してないので、時間を使ってしまうと焦るんだけど、実際は静かに考えるまとまった時間がないと良いものは出来ないので、焦らないこと。

良いコードを書けるようになるには、ソースコードレビューが一番効く気がする、というか、コードレビューしかないんじゃないかと思う。ソフトウェア開発をアートだと考えれば、いくら勉強だけ続けても、作って見てもらって指摘してもらわないと、良いコードとは何かを腹落ちしないんだと思う。

経営者の仕事のひとつは同じことを何度も言い続けることであり、それが出来ることこそが優れた経営者の資質ではないか。チームが目指すビジョンを何度も、同じ言葉で、そして色々な言葉で言い換えて。伝え続けることが大事。

人月のビジネスで嫌な思いをして、それを嫌って独立してフリーランスになるのは、自分一人の責任だから良いと思うけど、人月や派遣のビジネスを嫌っていたのに、会社を作って社員を雇うようになって、同じビジネスモデルを採用するの、どうだろうか。社員を雇うなら、しっかり経営をしてほしいと思う。

店頭販売など人手のかかる事業においては、労働力としての人は必要で、管理する人たちも必要だろう。しかし、ソフトウェア開発のビジネスにおいては、労働力たる人は必要なくて、コンピュータこそが労働力になる。そう考えると、管理する人たちだけでよくて、そんな人たちに管理は最小限で十分な筈だ。