読者です 読者をやめる 読者になる 読者になる

sakaharaのブログ

アプリ開発に関する話や日々の出来事など

島根にIT企業が集まるたった一つの理由

島根

島根といえばRubyの開発者・まつもとゆきひろ氏が住んでいることもあり、Rubyの聖地としてエンジニアにとっては有名な場所だと思います。 また県を挙げてIT企業を誘致していることもあり、島根に事業所を開設する企業も増えてきています。

Rubyのコミュニティの活動などやその支援はもちろん企業誘致に貢献していると思いますが、実は圧倒的に貢献しているのはこちらなんです。(たぶんね)

http://www.shimane-style.com/ss_shien/yugu/

↑のリンクを見れば一目瞭然だと思いますが、かなり太っ腹な立地起業の優遇制度です。

http://www.shimane-style.com/ss_shien/simulation/

例えば上記のシミュレーションだと例えば「8年間の家賃が0円」で家賃に対する補助だけで1,920万にもなります。 従業員の雇用についても一人あたり130万の補助と相当な額です。

その他にも松江市では実用化製品化支援事業といった補助金もあり、補助対象経費の半額を最大500万円まで援助してくれるような制度もあります。

http://www1.city.matsue.shimane.jp/jigyousha/sangyou/kigyou/sin-kaihatu.html

これらの優遇制度を知ってる方ってどのくらいいるんでしょうか? 私は島根で働くようになる以前は全然知りませんでした。

もちろん優遇制度についての予算は決まっているので上限はありますが、その上限内でかつ条件を満たしている限り補助は受けれます。 ということなので起業したい方や、他地域への事業所の開設を検討しているIT企業の皆様は是非島根に来ることをオススメします。 ちなみにここで紹介したからといって私には1円も入りません・・・w

私が働いている会社もこの優遇制度の恩恵を受けている立場なので、いずれ何倍、何十倍にもして県や市に還元したいと思ってます。(じゃないと申し訳ないです)

また松江市では毎年ビジネスプランコンテストを開催しており、最優秀賞は20万の賞金がもらえます。(起業支援できるくらい賞金がよくなるともっといいな〜)

http://www.shimane-oss.org/biz-contest2016/

今回は2016年1月7日まで応募できるようなので、我こそはと思う方は応募してみましょう。 私もしれ〜っと応募しようかと企んでおりまして、年末年始はネタ探しに没頭する予定です。

では私のように応募する方もしない方も、よいお年をお迎え下さい〜。

「リモートチームでうまくいく」はリモートワークだけでなく新しい働き方を提案してくれる良本

書評

リモートチームでうまくいく マネジメントの?常識?を変える新しいワークスタイル

リモートチームでうまくいく マネジメントの?常識?を変える新しいワークスタイル

この書籍には以前ブログで書いた「リモートワークのデメリット」を埋めるための試みがたくさん盛り込まれていたので、いくつかピックアップしてみました。

sakahara.hatenablog.jp

会社や同僚の協力がないとリモートワークをしている人が孤立しやすい

  • リモートワークのメンバーを特別扱いしない
  • 最初から社内の全員がリモートワークであるという前提で仕事をする
  • 雑談を推奨する

部下が見張っていないと仕事をしないのではという考えが根本にあると成立しない

  • 採用において「セルフマネージメント」ができる人かどうかを重視する(そのためにも採用は慎重に)
  • 新人にいきなりリモートワークはさせず、まずは一緒に働いてもらって教育しながら「セルフマネージメント」をできるようになってもらう

働かなくなる人よりもむしろ働き過ぎになる人が多い

  • 上記と同様に「セルフマネージメント」をできるようになってもらう

文章力が無い人がやるのは難しい

  • これは本人の努力が必要w

同僚との会話が減る分、仕事の成果に注目が集まるので成果を出せる人でないと難しい

(仕事の成果で判断されるのはむしろよいこととも言えるのでデメリットでもなかったけど)

  • 雑談を推奨することで目の前で仕事をしているのと変わらない状態を作る
  • 存在感を出すために積極的に本人が発信しやすい環境にする

上記で何度か登場した「セルフマネージメント」の定義はこんな感じです。

自分の時間やリソースを自身で把握した上で、どんな仕事にどれだけのコストをかけるかを考えて、誰かに指示 ・管理されることなく成果を発揮することのできるスキル

リモートワークにおいて一番重要なのはやはりこのセルフマネージメントなんだと実感しました。 自分で自分を管理できない人にリモートワークはまず無理でしょうから、 極力セルフマネージメントができる人を採用するか、もしくは育てることが必要と言えます。

また社内の全員がリモートワークであるという前提で仕事をするために全員がビデオチャットで会話するなどの方針にすることは、やはり経営者がトップダウンで進めた方が効率的だったりすると思うので、このあたりは会社によってはかなり難しいかもしれません。

この本はリモートワークという仕事のやり方についてだけ書いたものではなく、マネージメントや会社の文化をいかに作っていくか?ということに関しての側面の方が強いので、そういった部分に興味がある方が読むともっと違った知見が得られると思います。

最後に本書にて特に印象に残った箇所を記載しておきます

  • リモートワークは信頼を前提とする
  • 雑談はリモートチームに助け合いの風土を作ることができるのであえて推奨する
  • オフィスにいる人とリモートにいる人との間に情報格差があるとチームの一体感はうすれてしまう
  • 社員をマネジメントするために閲覧できる情報を制限しているとしたら、社員の主体性を奪っていた原因だと考えられる
  • ガチガチに管理するよりも自由な裁量で働いてもらった方が生産性は高くなる傾向がある
  • セルフマネージメントができる人材が集まったチームは生産性が高くかり、結果としてリモートチームでもやっていける

上記のことはリモートワークに限らず仕事をしていく上で重要なことだと言えるので、常に意識していきたいことだと思いました。

「リーダブルコード」は英語で原書を読んで見る方がおもしろい

書評

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

この本、実はずっと読まずにスルーしてたんですが、 先週社内でちょっと話題になっていたので、いいかげん同僚から借りてようやく読みました。 内容はまあいろんな人が書評書いてるので、あえて言うほどでもないですが ある程度の経験、またはスキルのあるプログラマーであれば知識としてはそんなに新しい発見があるものではないかなぁという感じです。

ですが本書の本当のいいところは翻訳にも関わらず、 原書の内容を損なうことなく日本語で非常に分かりやすく、面白さを損なうこと無く反映してくれていることです。 訳書のほうは数時間で読めてしまったんですが、コメントの書き方の部分など英語で書く時はどうだろう?と 気になってしまい、結局原書をKindleで買っちゃいました。

The Art of Readable Code (Theory in Practice)

The Art of Readable Code (Theory in Practice)

原書の方を読みつつ、ここは日本語ではどう書いてあるだろうと訳書を確認しながら読み進めるとより理解が深まるし、何より楽しめました。 特に挿絵の部分は原書を読んでも、訳書を読んでも面白いので比較してみてほしいです。 このあたりは英語が苦手な人でも比較することでなるほど!とうなずける部分は多いと思います。

お金に余裕がある人は訳書だけでなく原書もセットで買うのがオススメです。 (私のように訳書は誰かに借りて原書を自分で買うのもありです)

最後にこの書籍を読んで感じたことですが、 変更しやすいコードを書くことを徹底できるかどうかというのは、自分が理解して実践できるだけでは不十分で 一緒に仕事をするメンバー、もっと大きい範囲で見ると会社全体でそういうことを大事にする文化が無いと 中々成立させにくい部分があります。 動けばいいで作りはしたが、後になって破綻するって話はいくらでもあります。 そういう部分を妥協せずにどこまで徹底できるかがやはり、こういった書籍のノウハウを生かせるかどうかだと思います。

現場によっては人が書いたコードに訂正を加えてもっといい方法を提案したり、コードレビューをしたりすること自体に違和感を感じるメンバーがいるかもしれないけど。 ただそれはよりいいものを作りたいがためにやるのであって、指摘を受けたメンバーに問題があるなどという話ではないということを、切り分けて考えてもらえるように会話していけば大丈夫なはずです…きっと。

それにしてもこれまで買っても読めてない本が溜まり続けてたけど、ここ数ヶ月本を読める時間が増えて本当ありがたいなー。 (これも島根効果だろうか???)

書籍「納品をなくせばうまくいく」を読んでより良い開発手法について考えてみた

書評

この書籍自体は昨年出版された当時に一度読んだのですが、最近は受託の仕事が多く今後に活かすために改めて読み直しました。

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

ちなみに納品のない受託開発と勘違いしそうになりますが、人材派遣とは違い、顧客企業のオフィスで働いたり、時間単価での契約ではなく、顧客の得る成果と満足度による契約をするという前提にしています。

今回この書籍を読み直すことで新たな発見があったので理解を深めるため整理してみました。

従来通りの納品する受託開発のデメリット

  • 要件定義で事前に全てを決めることは難しい(要件定義後に様々な事情で要件が変わることは多々ある)
  • 人月の問題 - 工数の精度にもよるが、下手をするとだめなエンジニアほど時間がかかって儲かるという変な仕組みがうまれる
  • 開発と運用で業者や担当者が別になることで、ドキュメントが欠かせなくなり価格がその分上がる
  • 上記のように開発と運用で別の人間が担当すると自分達が開発したわけではないため、リスク回避のため少しの修正でも高く見積もってしまう
  • 最大時を想定したハードウェアの購入になってしまい、あとからの変更が難しい

とデメリットをいくつか挙げましたが仕様変更が難しかったり、価格が高くなりがちだったりと問題は多々あります。 また構造的に発注した顧客にとってはビジネスの成功が目的だとしても、開発会社にとっては完成したソフトウェアに自体に価値があると勘違いしやすくなるため、気をつけないといけないと思います。

納品のない受託開発のメリット

  • 月額定額の料金体系にできる
  • 要件定義をしなくてよい - 最小限の機能を決めて、なるべく早い段階でユーザーへ提供できる
  • どれだけ仕様変更してもよい
  • 例えば打ち合わせは全てリモートで行うことで、無駄な経費を削減できる
  • 仕様決めから、開発、テストまで1人のエンジニアが担当することで、ドキュメント等の作成を簡略化できコスト削減につながる。

他にもメリットはありそうですが、次にデメリットをあげてみます。

納品のない受託開発のデメリット

  • エンジニアに幅広いスキルが必要
  • そもそも大規模で要件定義がしっかりできている案件には向かない
  • 顧客との信頼関係が構築できないと難しい

ここにあげたものはデメリットというより、エンジニアに交渉のスキルやフロンドエンド、バックエンド含め広い範囲の技術が必要になるということが、実現するためのハードルの高さになっているかもしれません。

まとめ

本来クリエイティブなはずのプログラミングという仕事が日本、特にSI事業に関しては最下層に位置づけられるような残念な会社がたくあります。 ですが著者が考えるコンセプトはプログラマーを非常に大事にしており、どうすればお客さんと実際に仕事するプログラマーがお互いに幸せになれるかということを突き詰めた結果がこの書籍の内容になっているのだと思います。 私もプログラミングを生業として10年以上生きてきた身としては、現状の環境を少しでも改善するためのヒントがたくさん詰まっている本で、大変参考になりました。

プログラマー以外の人がこの本を読むことで、より良い成果を上げるための議論ができるきっかけになればよいと思いました。

生活を犠牲にしてやる仕事に疲れたら書籍「ナリワイをつくる」を読んでみるとよい

書評

会社の同僚がたまたま持っているのを借りたらおもしろかったので紹介します。

ナリワイをつくる:人生を盗まれない働き方

ナリワイをつくる:人生を盗まれない働き方

ところでナリワイの定義は

個人レベルではじめられて、自分の時間と健康をマネーと交換するのではなく、やればやるほど頭が鍛えられ、技が身につく仕事を「ナリワイ」と呼ぶ。

と一番最初に定義されています。 会社に就職して毎日通勤しながら同じ仕事のするのでなく、ナリワイをいくつかすることで生計を立てること、そしてそれをどのように実現するかを提案する内容になっています。

ちなみにこのナリワイをベースとした生き方と対極にいる人の例として冒頭に

グローバル社会で全世界を相手にした殴り合いの競争をして健康が維持できるのは、かなりのバトルタイプ(戦闘型)だけだ。

とあります。 こんな生き方ができるのはどちらかというと少数の人だけだろうけど、このバトルタイプとは違う、いくつかのナリワイをもって生きるのも決して簡単ではないなぁというのが正直な印象です。 自分から自発的に動いてその行為によってお金をもらうという事を、雇用された立場で与えられた仕事をすることに慣れてしまった人にすぐにできるか?と思ってしまいます。 ただ個人的にはバトルタイプとして生きるのもいいと思いますが、「ナリワイ」を作って生きる方がより面白そうな感じがするので、すんなり読めました。

本書の中で印象に残った部分をいくつか紹介します。

クライアントワークの限界

クライアントの依頼を受けて作業をして納品して報酬をもらうだけの仕事はナリワイとは違うという話が出てきます。 仕事をしたらお金が一時的にもらえてそれで終わりってことなんですが、このやり方だと限界もあるし、今の自分の環境に踏まえて考えさせられました。

固定費を減らす

家賃などの固定費は給料の何割かを占める人が多く、結局それは1年の労働の何割かは家賃のために働く状況に陥っていることになります。 支払いのために簡単に仕事を辞めることもできないので、週末も仕事で疲れきってしまうと何かを始めようにも気軽にスタートできず悪循環です。 私も島根に引っ越してから家賃がこれまでよりも下がったことで、妙な安堵感がありました。 ですので家賃などの固定費を下げる努力は自ずと必要かと思います。

プロがやると逆につまらなくなる

ミスが許されなかったり、要望を聞きながら効率よく回していくために変化に富んだ内容にできなかったりとマイナス面もあるとのこと。 これは効率化を進めていけばいくほど、短時間により正確にアウトプットを出せるけど、それしかやらないと新しいものを生み出せなくなるジレンマみたいなものかなという印象です。 普通に仕事をしていく上でもこの視点を持つのは大事でしょう。

形式重視の価値観への疑問

実際の中身ではなく、形式だったりミスがない方が評価されるという偏った価値観が一般化してるけどそれでいいの?という部分については妙に納得できました。 これはあくまで一つの価値観に過ぎないということです。無理にそれに合わせる必要はないし、「お金をもらうからには」こうじゃないといけないとかああじゃないといけないとか考えすぎにさっさと行動してその対価をちゃんともらえるようにすればよいと思います。

本書を通じて一番大事だと思ったこと

下記の内容が自分の中では一番印象的でした。

だがそもそも仕事の起源を考えてみれば、皆がやるのが面倒なことを誰かがやってくれたら有難いな、ということをやる気がある人が担当してきた、ということだ。

結局のところこの書籍に書いてあるような生き方を実現するのに必要なのは、スキルうんぬんよりも誰かのために貢献したいという気持ちをもって率先して取り組むことがもっとも大事なのかなと思います。 この視点が抜けていると名誉だとかお金のことしか見えなくなって、やる前から失敗しそうですw

逆にこの視点をちゃんと持ってる人ならば、後は行動あるのみでこの書籍に書いてある生き方に近いことはできそうに感じました。

世界に通用する高いレベルで仕事をするとか、自分自身を宣伝して稼げる仕事をするなどそういう生き方もいいけど、もっと違う行き方もあるってことを知りたい人に是非読んでほしいです。

島根県仁多郡奥出雲町にある「森田醤油」のこだわり抜いた醤油作りへの情熱がすごかった

島根

11/5〜6の2日間は島根県仁多郡奥出雲町で開発合宿を行いました。 (合宿の内容については別途報告したいと思います) 今回は合宿中に見学させていただいた森田醤油さんの醤油作りへのこだわりがあまりにもすごくて、 形は違えど同じ物作りをしている私としては紹介せずにはいられなくなりました。

http://morita-syouyu.com/

  • 使っている大豆は全て国産(島根が2/3、残りは広島など近くの県)
  • 遺伝子組み替えした大豆は一切使っていない
  • 添加物、化学調味料も一切使っていない
  • 昔ながらの製法を使って、自然の状態を生かした醤油作りをずっと続けている

f:id:sakahara:20151106100452j:plain

こういった昔ながらのやり方を続けているメーカーは全国でも1割程度しかなくなってしまったようで、 価格や効率化のためにこれまでの手法をやめるメーカーも多いようです。 ですが森田社長は周りの方から変人と言われるくらい(何度もおっしゃっていましたw) 徹底して安全かつおいしい醤油を作り出すために日々努力されているようでした。 そして昔ながらの製法は続けられていますが、その中から日々改善をされているようです。 その他にもたくさん醤油作りについて話をしていただきましたが、とても楽しい時間でした。

f:id:sakahara:20151106103531j:plain

確かに現在大手メーカーによって作られている調味料は化学調味料などを使用して 安くて美味しくなるように調整されています。 しかし化学調味料アミノ酸とひとくくりにまとめられたり、表記の必要のないものについてはラベルに明記されることはありません。 私自身も化学調味料の味になれてしまって、昔ながらの本当の醤油の味がどういうものかよく分からなくなってました。

更に大手メーカーの商品は大量生産により安く商品が提供されますが、 何でもかんでも効率化によって短時間に安く仕上げればよいというものではないはずです。 効率化という名の元に体に有害なものが含まれていいはずがありません。

こういったことを考えているうちにソフトウェア開発が抱える問題点と同じような問題が、 他の業種でも起こっているんだなぁとしみじみ思いました。 (効率化という名のもとに、不具合だらけだったり仕様的に全然使えないシステムを作っていいはずがない) 今回の見学はとてもいい機会になりました。 私ができる第一歩は価格は一旦置いておいて、まず食べる物をちゃんと選択することで本物の商品が残るようにしていく事だと思いました。

森田醤油の商品はインターネットでも購入できますので、 是非一度お試しください。

http://morita-syouyu.com/items.html

1日でJavaScriptを理解するために「パーフェクトJavaScript」を読んでみた

書評

ここ数年アプリの仕事ばかりやってて、Web周りの知識が乏しくなりつつあったんですが、仕事で必要になりそうなこともあり重い腰を上げました。 ホント久々に丸1日好きにできる時間を持てたので、どうやって学ぶかいろいろ考えたんですが、 結局会社にあった「パーフェクトJavaScript」をひたすら読むことに。

パーフェクトJavaScript (PERFECT SERIES 4)

パーフェクトJavaScript (PERFECT SERIES 4)

オライリーJavaScript 第6版」が一番よさそうでしたが、ボリュームが840ページと分厚いので今回は断念。

結局part3までを読むのが精一杯でしたが、ここまで読んだ感想としてはなかなかの良書だと思います。 Javaとの比較をしながらの説明がJavaをよく知っている自分からすると理解しやすく助かりました。 2011年出版の本ですが、言語仕様についてはECMAScript 第5版の説明が中心でJavaScriptの独自拡張については別途説明をする形をとっており、 今時のブラウザならほぼサポートしてるので安心して読めました。

各ブラウザの対応状況はこちらを参照。

http://kangax.github.io/compat-table/es5/

本書を読んでJavaScriptの言語仕様で気になった部分はこんな感じでした

  • 関数型プログラミングをサポートしてるけど、再帰処理はパフォーマンスの観点から使用することを勧めていなかった・・・
  • undefined型は潜在的なバグを生む可能性が高そうだしなんとかならないか?
  • thisの扱いを間違えるとハマりそう
  • 存在しないプロパティ名を指定して値を代入するだけでプロパティが追加できるのはすごい
  • アクセス修飾子(private, public)がない
  • 名前空間をサポートしてないので、クロージャ使って隠蔽するなどの対応が必要でなんだか面倒
  • アクセッサはあるらしい(これもクロージャで隠蔽する必要あり)

再帰処理の最適化については気になったのでググってみるとECMAScript 第6版からサポートしてるようでした。

http://qiita.com/pebblip/items/cf8d3230969b2f6b3132

JavaScriptガベージコレクションがどうなってるのかも興味あったのですが、すでにお腹いっぱいなので別の機会に。

継承の仕方も一つじゃなくていくつか方法あったりと何かと自由度高いですが、言語レベルで規定されてる方が迷わなくて個人的にはありがたい・・・。

最後に正直1日で理解って厳しいけど、それくらいの気概でいくと時間の使い方とか意識するし、最短で理解する努力もできるのでオススメです。 (ようはやる気の問題かも)