雑記 Archive

blog を下記に移転しました。今後とも、Shin x blog をよろしくお願いします！
http://blog.shin1x1.com/

新年、あけましておめでとうございます。旧年中は、お世話になり、誠にありがとうございました。

2015 年に入って、最初のエントリということで、2014 年のふりかえりと 2015 年の抱負などを書いてみたいと思います。

2014 年ふりかえり

2014 年の抱負は、「ちゃんと稼いで、食べていく」でした。

社会人である以上、当たり前の目標なのですが、その当たり前を今一度、目標として、足場を固めていく一年になりました。おかげさまで、無事に、1 年を乗り切ることができました。ありがとうございます。

事業としては、「受託開発」「技術サポート」をメインに行いました。新規開発の案件では、Laravel と AngularJS を組み合わせて、サーバーサイドは API を提供して、UI 等は、クライアントサイドで開発するというスタイルで構築を行いました。今後もこうした形は、増えていくでしょう。

技術サポートについては、後述します。

また、ロクナナワークショップにて不定期ながら講師を務めることになり、2014 年中には、2 回講義を行いました。2015 年も開催予定なので、参加お待ちしています。

コミュニティ活動では、勉強会などのイベントへの参加と発表を行いました。１×１を会場とした勉強会が多かったので、それ以外では、発表のお誘いを受けて参加する機会が多かったです。発表資料などは、こちらで公開しています。

技術サポート

技術サポートというのは、開発プロジェクトにおける技術的な課題を一緒に解決する役割です。呼び名としては「技術コンサルティング」や「技術顧問」なども考えられますが、今のところ「技術サポート」という名前で呼んでいます。

2014 年は、この形で、いくつかのプロジェクトやチームに参加することが増えました。

これまでも、単発での依頼であったり、別のロール（開発やインフラ構築等）で参加しつつ、兼任でこの役割を担うことはあったのですが、継続的に参加するということが多くなりました。

以前から、こうした関わり方に興味があり、また、お役に立てる場面があるのではと感じていたので、2013 年の終わり頃には、直接会う機会があった方には、こういったことをやろうと思う、という話をしていました。そのおかげかどうかは分かりませんが、いくつか、技術サポートの依頼を頂くことができました。

お話した方からの依頼もあるのですが、言霊といいますか、直接この話を聞いてはいない方からも依頼があり、何事も表明するというのは大事だなと実感しているところです。

具体的にどのようなことを行っているかは、案件により様々ですが、下記のようなことを行っています。

• リモートでの技術的質問の回答、調査（Redmine / Chatwork / Slack 等）
• インフラ移行に関する移行計画のレビュー
• 開発業務での困り事相談
• 開発案件への Vagrant 導入サポート
• AWS / Heroku などのクラウドサービス導入支援
• コードレビュー（アプリケーションコード、プロビジョンコード）
• サンプルコードの作成
• パフォーマンスチューニング
• 定例ミーティング参加
• 訪問による技術相談会

基本は、リモートで、技術に関する質問を頂いて、その回答を行うというスタイルです。ただ、案件によっては、訪問して対面でお話を伺う場面もありますし、コードレビューやサンプルコードの作成、パフォーマンス改善など、アプリケーションコードを書く以外の周辺タスクをサポートするという場合もありました。

ご依頼頂いた内容を振り返ってみると、コードを書いたり、アプリケーションを構築することは自分たちで可能だが、新しくチャレンジする領域に関する知識やノウハウを知りたいという要望が多かったように思います。また、第三者の視点からのレビューが欲しいという要望もありました。

契約については、月額固定での契約で、お互いに齟齬があれば、都度ご相談というスタイルが多かったです。

2015 年は、この「技術サポート」をより進めていきたいと考えています。ご興味がある方は、下記のお問い合わせフォームなり、メッセージなりでご連絡くださいませ。

お問い合わせフォーム

2015 年は

2015 年は、まず事務所の移転を行います。（といっても同じビルで階が変わるだけですが）すでに移転先の契約も済ませており、2月早々には移転が完了する予定です。

事業の方は、「技術サポート」を中心に進めていき、さらに開発現場をサポートできるようなツールやサービスの構築なども行っていきたいと考えています。もちろん、従来の受託開発についても、引き続き行っていきます。

これまでは、アプリケーション開発やインフラ構築など、システムを作り上げて、何かの問題を解決してきました。この「技術サポート」も、目的は同じく「問題解決」なのですが、その手段が異なります。開発現場における技術的な問題を、システム構築ではなく、対話やアドバイスなどで解決するのが役割です。

技術情報は、書籍やインターネットを見れば、豊富にあります。しかし、そういった膨大な情報から、自分たちの問題を解決する手段を見つけ出し、その解決策を落としこむのは、意外に手間や時間がかかります（もちろん、問題自体の発見も必要です）。こうした問題を円滑に対処する方法としてお役に立てれば嬉しいです。

2015 年は、開発現場での問題解決屋となるべく、「問題解決」を抱負としたいと思います。

さいごに

実は、元旦から食中毒でダウンして、三ヶ日を布団の中で過ごすという散々なスタートになりました。。。昨年の後半から熱が出たり、蕁麻疹が出たりと不調が続いているので、体調管理が大事だと痛感しています。（この「問題」も解決しないと。）

年初から、GoAzure での発表準備や原稿執筆があり、また本業の方も立て込んでおり、さらに引っ越しの手配などもあるので、体調を整えて、アクセル全開でスタートします！

2014 年は、Shin x blog をご覧頂きありがとうございました。2015年も、よろしくお願いします！

新年、あけましておめでとうございます。旧年中はお世話になり、誠にありがとうございました。

2014年に入って、はじめのエントリということで、2013 年のふりかえりと2014年の抱負などを書いてみたいと思います。

2013年ふりかえり

2013年は、最初のエントリでも書いたように、体質改善を行い、俊敏に動ける状態を作る一年でした。

そのために大きな決断も行いました。関係各位にご心配をおかけすることになったことは心苦しいのですが、ご理解頂き、後押しして頂けたこと、本当に感謝しております。結果がどうでるかは今後の頑張り次第なので、一歩づつやっていきたいと思います。

この体質改善には、意外に時間がかかりました。特にそれを感じたのは、考え方の変化です。それまでの体質で動いている状態での考えと、体質を変えていく中で考えることは、自ずと変化していきます。以前は当たり前だと感じていたことが、そうではなくなったり、別の視点が見えてきたり、ということがありました。人の思考は日々の習慣から生まれる、ということをあらためて意識した年でもありました。

まだ、完全に切り替わったというわけではなく、システムに例えると、旧システムは稼働したまま、新システムの構築を行い、その一部を先行稼働させようとしているのが現在の状況です。まだ道のりは長いですが、まずは舵を切って動き出したというのが、2013年の成果ともいえます。

2013年の活動など

2013年に行った活動のうち、公開しているものをいくつか並べてみました。こうして振り返ると Vagrant に関するものが本当に多かったですね。ここには記載していないですが、色々な Vagrantfile（とプロビジョニングファイル）を書いて公開しました。

PHPエンジニア養成読本

PHPエンジニア養成読本の巻頭企画を執筆を行いました。今回は、全体の取りまとめ的なことも行ったので、またこれまでとは違う関わり方ができました。普段一緒に勉強会を開催している Kansai PHP Users Group のメンバーと一緒に原稿を書くことができたので、スケジュールはタイトでしたが、楽しい執筆となりました。

Vagrant入門ガイド

初の電子書籍で、初の単著になりました。PHP カンファレンスに間に合わせたかったので、PHPエンジニア養成読本と平行して進める形になり、色々と大変でしたが、なんとか間に合わせることができて良かったです。担当の馮さんには無理を言いましたが、対応頂き、ありがとうございましたm(_ _)m

こちらではKindle ストアで技術専門書が上位にランクした例として紹介されました。
コンテンツの数と発売タイミングが大切になる1年――電子書籍と電子出版ビジネスの2013年→2014年

PHPプログラミング診断室

暮れから gihyo.jp さんにて連載がはじまりました。どのような反響になるか戦々恐々としていたのですが、初回についてはまずまずのスタートが切れたように思います。現場でお役に立てる連載にしていきたいと思います。なお、この連載では、診断コードが肝となっています。お手持ちのPHPコードがあれば、投稿をお待ちしています！

PHPプログラミング診断室

Phagrant

PHP Matsuri で作ったものです。Vagrant を PHP で実装してみたものですが、仮想マシンを作って、プロビジョニングを走らせる程度のことはできました。LT では、vagrant コマンド叩いている疑惑などありましたがw、実際は Vagrant と同じく、VBoxManage コマンドを利用しています。ネタ一発ですが、Vagrant 作者の Mitchell Hashimoto さんに見て頂けたので良かったです。

shin1x1/Phagrant

VagrantX

暮れに公開した Vagrant の GUI アプリケーションです。RubyMotion で開発しています。「いいね！」という声も頂けたので、少しづつ開発も進めていきたいと思います。

VagrantX

発表

資料未公開のものも合わせると 20 程度のイベントで発表を行いました。その中でも反響が大きかったのが下記の資料でした。ちょうど「Vagrant」というキーワードが浸透して、具体的な使い方を模索している人が多かったタイミングだったこともあり、公開して半年で 40,000 PV 近いアクセスとなっています。今年公開したもので、はてブが一番多く付いたのもこの資料でした。

また、devlove関西で行った、技術以外のキャリアや考え方といったテーマで発表は、気恥ずかしさもありましたが、自分を見つめ直すということで、良い経験になりました。

勉強会

関西PHP勉強会を中心に行いました。とくに年の後半は、関西PHP勉強会を毎月開催としたので、定期的に開催するという流れができてきました。このエントリでも書いたような「もくもく勉強会」の形式が面白いと思うので、メインはこの形でやりつつ、たまにセミナー型をやるというのが良さそうです。

blog

例年どおり月に 2–3 エントリだったのですが、年末に開催した Shin x blog Advent Calendar により、57 エントリまで増えました。せっかく書く習慣が付いたので、無理の無い範囲で良いので、週に 1 エントリくらいの頻度で書いていきたいです。

2014年は

2014年の今年は、「ちゃんと稼いで、食べていく」ということをあらためて意識してやっていきます。

昨年は、なぜこの仕事をやっているのか、なぜ会社をやっているのか、ということを考え直すことが何度もありました。そうした中で突き詰めると、当たり前のことなんですが、これが大事なことで、かつ自分がやるべきことなんだと再認識しました。

ここ数年は有難いことに、それほど強く意識せずともやってこれたのですが、そうした状況がいつまでも続くわけではありません。何を成すにも、まずは食えないことには始まらないのです。今後どうなっていくかは分からないですが、これからもしっかりと食べていけるように、色々な布石を打っていこうと思います。

まずは自分や家族、身近な人たちがちゃんと食べていけるように。そして、取り組んでいくことが結果として、より多くの人へ、少しでも良い影響となって広がればと良いですね。

さいごに

いつも Shin x blog をご覧頂きありがとうございます。2014年も、笑顔で終われるように頑張りましょう。今年もよろしくお願いします！

まずは、冬休みのタスク消化からはじめたいと思います:D

Shin x blog Advent Calendar 2013 の 22 日目です。

「世界を変えたいんです！」

インターネット上やイベントなどでたまに見聞きする言葉です。それを聞くたびに何か違和感のようなものを感じていました。

世界を変える？

「世界を変えたい！」というフレーズは、威勢が良く、何か立派な志のように聞こえます。その想いは素晴らしいとは思うのですが、聞いている方からすると結局何がやりたいのかが分からず、「なんかすごいね」程度しか感じなかったりもします。

「世界を変える」ということは、変える前と変えた後の世界があり、その二つの世界には何かしらの差分があるはずです。この差分を作り出すこと = やりたいということであれば、その差分をそのまま伝えたほうが良いのではないでしょうか。

ガンで死ぬ人を無くしたい、飢餓を無くしたい、空飛ぶ自動車を作りたい、人型ロボットを作りたい、みんなが夢中になるゲームが作りたい、なんでも良いのですが、こういった具体的な「差分」ではなく、「世界を変えたい」というのはあまりに漠然としすぎていて、どうにもピンと来ないものがあります。

どの世界を変える？

変える対象の世界はどの世界なのでしょうか。地球上全てなのでしょうか。日本でしょうか。インターネット上でしょうか。それとも自分の会社？学校？コミュニティ？

世界を変える、と聞くと、地球上（で人間が住んでいるところ？）を指すことが多いような気がするのですが、よくよく内容を聞いてみると、実際はもっと狭い範囲だったりもします。

どこの世界をどうしたいのか、これも考えておく必要があります。

世界を変えたいのか、自分を変えたいのか

世界は、自分自身を通して見ているものです。世界という周囲を変えるのではなくて、自分自身が変わることで見える世界が変わるというのも良くあることです。

変えたいのは、世界ですか？自分ですか？

スローガン？

実際のところは、この言葉をスローガンやキャッチフレーズとして使っている例が多いように思います。

会社やコミュニティの代表者などが、一緒にやっている人を鼓舞したり、対外的なメッセージを発する時に使うパターンです。本当は具体的なものはありつつ、それを毎回話すのは大変だし、また意気込み、思いの強さを伝えるために、この言葉を使っているのかもしれません。

これは理解できるのですが、あまりに乱用すると、「結局、何をどう変えたいんだろ。」などと思ったりもします。

さいごに

実は、世界は何もしなくても変わっていきます。変化は少しづつで、かつ自分の望むような形になるかどうかは別にしても、変化はしていきます。

言葉尻だけを取れば、何もしなくたって「世界は変わる」わけです。

「世界を変えたい！」と思うなら、何か具体的に変えたいことがあるのではないでしょうか。もし、そうなのであれば、抽象的な表現ではなく、その具体的に変えたいことを伝えたほうが良いです。

そして、その具体的に変えたいことに向かってアクションを起こしていくことで、結果として、世界は「変わる」ものだと思います。

世界は「変える」ものではなく「変わる」もの、というのが近頃思うところです。

Shin x blog Advent Calendar 2013 の 19 日目です。

2000年に個人事業として１×１を開業しました。それから 5 年後の 2005 年に有限会社として法人化（法人成り）を行いました。（その後、組織変更を経て、現在は株式会社です。）

個人事業から法人化した経緯や理由について書いてみます。

法人化への思い

当時、受託開発をメインに行っていました。仕事を受注して、家でこなすというスタイルが多かったのですが、仕事上で法人格を要求されることはなく、個人事業でも困ることはありませんでした。（今にして思えば、その時点で選別されていたのだと思います。）

開業した頃はとにかく食い扶持を稼ぐのに必死で、法人化など考えもしなかったのですが、ある程度、売上が立つようになると、「次のステップ」というのを考えるようになりました。

なんとなく、次のステップとしての法人化を意識しつつ、ただ必然性もそれほど感じないので、実行には至らないという期間がしばらく続きました。

法人化の理由

おかげ様で、色々なところからお声をかけて頂けるようになり、携わる案件もバリエーションが広がっていきました。携帯電話キャリア公式サイト構築やプロスポーツチームのシステム構築など、当時の自分としてはチャレンジし甲斐のある案件をこなすようになりました。

そうしたシステムを作っていると、いつも頭に浮かぶのがこの言葉です。

「もったいないなあ」

こうした面白いシステムを一人で作るのが、もったいなあ、と。

受注していた案件では、アーキテクチャの決定から全て任せて頂けることがほとんどだったので、要件に一番適していると思える技術を利用することができます。また、構築するのは多くの利用者がいるサイトだったので意気も挙がりますし、多数のリクエストを捌くための負荷対策なども行う必要がありました。

こうした経験はエンジニアとして大きな財産となります。座学も大事ですが、技術は適用して、そのフィードバックを得てこそ、身になります。もちろん、大変なこともありますが、そうした経験を積むことで、多角的な視野が広がり、技術を使う引き出しを増やすことができます。

私自身、こうした場を求めていたこともあり、実に多くのことを経験することができました。

一人でこうした経験をするのではなく、共に経験し、成長して、チームとして仕事がしたいと思うようになりました。

そして、チームを作る手段として、法人化を考えるようになりました。もちろん、個人事業のままで、チームを作ることも可能ですが、今ほどそうしたネットワークも無かった（自分は知らなかった）ので、法人化して、スタッフとして参加してもらって、一緒に成長していきたい、と。

つまり、チームとして一緒に仕事をするメンバーを集うために法人化した、というわけです。

さいごに

もちろん、節税のことや、より大きな案件へ対応できる、また自分たちのプロダクトを作りたいなど他にも理由はあったのですが、一番の理由はこれです。

この観点から言うと、今は、社外の人と一緒にチームとして仕事をするいうことがやりやすくなったように思います。これは、色々なことを経験して私自身の考えが変化したこともあるでしょうし、これまでの活動を通じて、多くの人と出会えたというのも大きいです。

チームとして仕事をしたいという想いは今も変わりません。ただ、それは「雇用」という形では無くても良いのではないか、というのが最近考えているところです。

Shin x blog Advent Calendar 2013 の 17 日目です。

「プログラマーには 2 つのタイプがいる。ブロックを作るか、使うか、だ。」

レゴブロック型プログラミング

プログラミングをやるようになって、思ったのは、部品を組み合わせていく感覚が、子供の頃、夢中になって遊んでいたレゴブロックに似ているなあということです。

ブロック（部品）は多数用意されており、それらを組み合わせることで何かを作っていきます。ただプラモデルなどと違うのは、何度でもバラして、また組み直せるということ、そして、ブロックはプリミティブなものであり、組み合わせ方によっては全く異なるものを作ることもできます。

扱う言語や環境によって、そのブロックの粒度は変わっていきます。C がレゴブロックなら、LL は、ダイヤブロックくらいかもしれません。ただ、それらを組み合わせて何
かを作るということは同じです。

ブロックの粒度が大きくなる

ブロックの粒度は次第に大きくなっていきます。構文や標準関数の大きさだったものが、それらを組み合わせたライブラリを大きなブロックとして使うようになります。

次はライブラリとしてではなく、その機能に特化したソフトウェアと連携して動かすようになります。例えば、データの保存処理をライブラリを使って行っていたものを RDBMS に切り出して、それに特化した処理は全て任せてしまうという具合です。

そして現在では、そのソフトウェアを自らセットアップする必要もなくなり、SaaS として提供されるようになりました。データベースであれば、RDS や Heroku Postgres のようなものです。

こうしてブロックの粒度は次第に大きくなり、またその調達コストも低下していっています。

粒度の大きいブロックは組み合わせるパターンがある程度限定されるので、自由度は下がりますが、扱いやすいとも言えます。反対に粒度の小さなブロックは、組み合わせパターンが多くなるため、自由度は上がりますが、その分扱いが難しくなります。

問題にあったブロックを探し、組み合わせる

そこで、解決すべき現実の問題にどのブロックを使い、どう組み合わせるのかという考えが必要になります。

先ほど書いたように、ブロックを調達することは容易です。とくにクラウドサービスの拡充により、以前では考えられないようなコストと時間でブロックを調達できるようになりました。

ただ調達は容易ですが、どのブロックを調達するのかを決めるにはそもそもブロックを知っておき、どの問題にフィットするのかを把握する必要があります。

調達した後も、それをどう組み合わせるのかを考え、時にはブロックを加工したり、フィットするブロックが無ければ、より細かな粒度のブロックを使って作る必要もあるでしょう。

大小様々な粒度のブロックが増えた今だからこそ、ブロックを選定し、組み合わせるのかという技量が重要になってきているのだと思います。

さいごに

冒頭の話でいうと、私は「ブロックを使う」側の人間だと思います。もちろん必要な場合はブロックを作りますが、それより、すでにあるブロックを組み合わせて、問題を解決するという方向が好みです。

総論的なブロックの選定に関する情報はインターネットや書籍でも見つかるのですが、個々の問題を解決するためのブロックをどう見つけるか、というのは当然ながら当事者が個々でやるしかありません。

近頃は、こうした個々の問題にフィットするブロック探しや組み合わせ方の模索を支援する仕事が面白いなあと感じてたりします。

Shin x blog Advent Calendar 2013 の 12 日目です。

写真の本は「MSXマシン語入門講座」という本です。この本を買ったのはもう 20 年以上前のことになります。

私にとっては、プログラムを学ぶ上で、また、何かにチャレンジする上で良い教訓を得た一冊です。

BASIC でゲームを作る

中学生の頃、ファミコンのゲームが好きだったので、その延長線上で MSX2（FS-A1）というパソコンを購入しました。

当初は、ファミコンとは違うゲームができるもの程度の認識しか持っていなかったのですが、なんとなくプログラムには興味があったので、付属していたBASICの入門書を片手にプログラムを作るようになりました。

サンプルソースを入力して、動かしてを繰り返す内に、少しづつBASICが分かるようになったきたので、次はBASICでゲーム作りにチャレンジするようになりました。

Z80 アセンブラへの挑戦

BASICで小さなゲーム（ほんと小さなゲーム）が作れるようになると、もっとちゃんとしたゲーム、販売されているようなゲームが作りたくなってきます。

そこで次にチャレンジしたのが、Z80アセンブラです。

当初触っていたBASICはインタプリタ型の言語（コンパイル不要の言語。まあPHPとかもそうですね。）で、書いてすぐ動かせるのが特徴です。入門としてはすごく良いのですが、いかんせん当時のMSXはリソースが少なく（メインメモリが64KBしかない。MB じゃないですよ。ちなみにこれ書いてる MacBook Air は、8GB です。）、凝ったことをするとBASICでは厳しくなります。

そこで、より速いプログラムが書けるように Z80（MSXのCPU）のマシン語を覚えたいと思うようになりました。

まずは勉強を、と思って買ったのが冒頭にある本です。

ワクワクして本を開いてみると、

「全く分からん。。。」

びっくりするくらい分からない。書いてある事自体はなんとなく理解できますが、それがどうなってゲームが作れるのかが全く分からない。

その後、何度か通読してみましたが、やっぱり分からない。最後には「ああ、自分にはプログラムの才能が無いんだ。」などと思い、半ば諦めて放置していました。

氷解、そして専門誌への掲載

諦めたものの、何だか分からないままというのは悔しい。しかも買ってきたのは入門の本。そして、やっぱりゲームは作りたい。

期間は開けながらですが、たまに開いて、諦めてを繰り返す内に、ある日からだんだんとうっすらとですが、イメージができるようになってきました。

何がきっかけだったかは、もう忘れてしまったのですが、いつしかすんなりと理解できるようになり、Z80マシン語（というかアセンブラですが）でゲームが作れるようになりました。

その後はゲーム作りに没頭して、またまた何度かの挑戦を経て、当時あったMSX専門誌へ掲載されるゲームが作れるようになりました。（読者投稿のコーナーがあって、みんながこぞって自作ゲームを送るのが流行りだった。掲載料も出たので、プログラムを書いてお金を貰ったのは、これが初めて。）

あとで分かったのですが、あれだけ理解できなかった冒頭の本は、本当に入門の本で、書けるようになったあとは逆に読み返さないような内容でした。

さいごに

これは無理！と思っていた事にチャレンジしてみて、やっぱり上手くいかず、でも諦めず何度もチャレンジして、そしていつか成し遂げる。

どんな事柄（難易度は主観）でも、一度でもそういった経験を持っていると、次の困難に遭遇した時も「いつかはできるようになるかも」と思って立ち向かうことができます。

その後、何度もこういった場面がありましたが、いくつかの事は実際にできるようになりました。考えてみると、いま普通にやっているようなことも、はじめはできなかったことばかりです。

まだまだできないことだらけですが、少しづつ、少しづつで良いので、やっていきたいものです。

Shin x blog Advent Calendar 2013 の 11 日目です。

日常が忙しく、新しい技術なんか追ってられない。わかります。

そんなの使うかどうかも分からないのに今やる必要無いよね。困った時に探せば良いでしょ。それもわかります。

そんな忙しい毎日だからこそ、技術の「種」くらいは蒔いておきましょうという話です。

技術の種

「技術の種」とは何でしょう。

私がイメージしているのは、その技術のイメージをざっくりと朧気ながらで良いので掴んでおくということです。（ユースケースもあるとより良いです。）

きちんと土を掘って、一つ一つ植えられれば良いのですが、じっくりと植える時間はなかなか無いと思うので、とりあえずバサッとで良いので、撒き散らしておきます。

そうしておいた種は、何かのきっかけで芽を出すことがあります。

多くは解決すべき問題に直面した時です。この問題は手元の技術では解決できないものだったり、解決できても効率が悪いものだったりします。

その時に種がひょこっと芽を出します。「これ、あるよ！」って。

もしかしたら、あれが使えるかも。そう思って、あらためて調べ直し、試して、実行することで芽は育ち、いずれは成果という果実をもたらします。

しかし、種が無ければ、芽は育ちません。

「問題に直面したからで良いんじゃない？」

そうかもしれません。ただ私達が対峙する問題は Google で検索してすぐに答えが見つかるようなものでしょうか。そこから種を探すのはなかなか大変だったりします。

問題はそれぞれ固有のものです。似た部分があっても、そのままずばりの解決策がインターネットで見つかるわけではありません。

技術の使い方は見つかりますが、どの技術をどう使うかは自分で考えなければいけないのです。

知りもしない技術を使うことができるでしょうか。

技術の種を蒔く

では、どうやって技術の種を蒔けば良いでしょう。

情報収集

まずは情報収集です。技術の存在すら知らなければどうしようも無いです。

インターネット上には技術の情報は溢れています。特にはてブや SNS などを見ていれば、日々色々な技術を（名前だけでも）知ることができます。

一つ一つの内容をじっくり見て咀嚼するのは時間がかかるので、全体の傾向だけでも良いです。「あーこんなのが流行ってるんだね。」でも良いです。流行ってるものは大抵何か理由があります。

ここで何となくで良いので、何に使うものかを一緒にちらっとでも良いので考えておくと芽を出すきっかけ（フック）になります。

勉強会

勉強会などエンジニアが集まるコミュニティに参加してみるのも良いでしょう。

セッションでは色々な話題が登場して、知らない内容だと必死に理解しなきゃという気持ちになるかもしれませんが、これも「種を蒔く」感覚で、あーこう使うのかをおさえるくらいで聴くと気疲れせずに良いと思います。

懇親会などで話が聞けるチャンスは特に良いですね。出る話題はトレンドのものが多いですし、実際の問題を解決した話などが出るので、いっぱい種を拾いましょう。

人から聞くというのは、ネット上の情報をただ読むのとは異なる刺激なので、より理解が深まることが多いです。

rebuild.fm

情報収集するの面倒だし、勉強会とか忙しくていけない、という人に良いのが、ポッドキャストです。

なかでも rebuild.fm がオススメです。

情報感度高い人はすでに聴いてるとは思うのですが、今どき流行りの技術に関する話題がてんこ盛りです。

内容が全て理解できなくても問題ありません。ただ聞き流して、あー、Immutable Infrastructure がアツいのねと認識しておくだけでも良いです。

何かの機会に Immutable Infrastructure について触れることがあれば、あーあの時聴いたあれだ、となるわけです。（進研ゼミメソッド）

他の方法に比べると、通勤や夜寝る前など、すき間時間を活用することができます。また、ながら聴くことができるので、じっくり情報収集できない人にもおすすめできます。

（まあ情報収集というより、単に面白いから聴いてるわけですけど:D）

さいごに

エンジニアという仕事は、技術を使って、何かの問題を解決することだと思います。技術だけがあってもしょうがないですが、技術が無ければ解決することができません。

そう、技術というのはまさに飯の種なんです。これを大切にせずに何をするのでしょうか。

最後に私の好きな格言で締めたいと思います。技術の種、今日はどれくらい撒きましたか。

毎日をその日の収穫高で判断せずに、まいた種で判断しなさい。（ロバート・ルイス・スティーブンソン）

あけましておめでとうございます。

新年が明け、2013年となりました。

昨年末は年またぎのプロジェクトが多数あり、さらに年末ぎりぎり（12/29）に勉強会を開催したので、全く年末感がなかったのですが、正月は家にのんびり過ごすことができました。日々のタスクから離れ、一息ついたところで2013年の抱負を考えてみたいと思います。

2012年ふりかえり

まずは昨年のふりかえりから。

昨年は「変化の年」ということで変化していくことを目標にしていました。

結果としては、変化したこと、変化していないことあるのですが、仕事面での大きな変化としては、１×１にこれまで在籍していたスタッフが（それぞれ理由は異なるのですが）次々と退職し、結果一人に戻りました。

2012年がこういった状況になるとは考えていませんでしたが、ある意味、開業当時に戻って新たなスタートを切れるチャンスだと前向きに捉えています。

事業面については自社サービスとして「イベ×めも」をリリースするなどチャレンジは行ったのですが、手応えを感じることはできず、大きな変化とはなりませんでした。

ともあれ、本業の開発についてはおかげさまで順調に推移したので、売上については昨年と比較しても堅調でした。本当にありがとうございました。

プライベートでは大きな良い変化がいくつかあり、その点についても良い一年でした。

Kansai PHP Users Group の活動としては、勉強会やイベントを1–2ヶ月ペースで開催でき、2回目となるPHPカンファレンス関西も5月に開催しました。2012年の大きな変化としては、自分以外の人が開催するイベントが増えたということですね。これは年初に期待していたところであり、良い方向に向かっていると思います。

2013年は「リーンな体質」を作り「目的指向」で動く

2013年は「リーンな体質」（贅肉のとれたスリムな状態）を作り、「目的指向」で動くことを目指します。

持てるリソースには限りがあり、特に時間は1日24時間しかありません。その貴重なリソースをどう振り分けるかを考えるにあたって、どういった目的のためにそれを行うのか、それは行う価値があることなのかを基準にしたいと思います。

さらにそれを効率良く実践するために、これまでの習慣を見直し、俊敏に動ける体質にしていきます。

仕事

これまでなんとなく習慣でやっていたこと、持っているものを見直して、目的を達するのに必要なこと以外は極力省いていきます。そして必要に応じて自動化するなどして効率化します。

例えば環境面として、まず社内サーバを全て廃止します。これには２つ理由があります。今後様々なロケーションで開発ができるような仕組みにしていきたいのが一つ、また可用性や安全性を考慮して、クラウド上にサーバを移したいというのがもう一つの理由です。

現在の社内サーバの用途としては「試験環境」「Git リポジトリ」「Redmine」「Jenkins」「ファイルサーバ」ですが、これらを外部サービスやクラウドへ移行します。

今のところ以下の構成を考えています。ファイルサーバは EC2 インスタンスに Samba なり WebDav なり入れようと思っていますが、そもそもファイルサーバ自体が必要なのかも再考したいところです。（ソースは Git へ、ドキュメント類はRedmineで管理すれば、それほど共有すべきファイルは少ないので。）

• 試験環境 -> AWS VPC(EC2)
• Git リポジトリ -> GitHub Private Repositories or Business Plans
• Redmine -> AWS VPC(EC2)
• Jekins -> AWS VPC(EC2)
• ファイルサーバ -> AWS VPC(EC2)？（まだ検討中）

また現在手作業で行なっている作業もツール化して自動化していきたいところです。特にサーバ構築、特にAWSを使う場合は、まだまだツール化できる余地があるので、ここはぜひやりたいです。

事業面においても、これまでリリースしてきたサービスの見直しを行い、効果が得られていないものについては順次閉鎖を行います。

blog

blog を書く時間もスリム化したいです。アウトプットの量はむしろもっと増やしたいのですが、1本書くのに要する時間が長すぎるのでこれを削減します。あえて時間制限を作って、その時間内で書き上げたものを公開するという方式が良いかもしれません。

SNS

SNS（主に Facebook / Twitter）との付き合い方にも贅肉があります。以前こんなエントリを書きましたが、ついつい見て時間を浪費することは避けたいです。

コミュニティ活動

勉強会などのコミュニティ活動も目的意識を持って取り組みたいと思います。昨年末に勉強会に関するエントリを書いたりもしましたが、「なぜ、やっているのか？」「なにを目的としているのか？」を自分の中で明確にして、活動を行なっていきます。

プライベート

プライベートでも、考えてみると無駄にダラダラと過ごしている時間があります。特に夜中にだらだらテレビ見るのがその最たるものです。夜中は基本何をやっても効率が良くないので、早く寝て朝早く起きる生活に戻していきます。

遊ぶ時間やくつろぐ時間はもちろん必要なので、それはそれとして楽しめば良いのですが、無駄な時間の使い方はしないようにしたいですね。

今年もよろしくお願いします

今年は「第二の開業の年」として、これまで少しづつ溜め込んでいた贅肉をそぎ落としていきます。俊敏に動けるスリムボディを目指していきますので、今年もよろしくお願いします！

蕁麻疹ができて痒みに苦しんでたという話。

昨年からのバタバタぶりが少し落ち着いてきた1月中旬、足に肌色の蕁麻疹が出てきました。はじめは少し痒いくらいだったのですが、日に日にひどくなり、ついにはとても強い痒みが来て、掻くと余計に痒みが強くなるというやっかいなものになりました。

実は、こうした蕁麻疹は2年前にも体験していて、その時は初夏だったので、汗なんかも関係あったのかなあと考えていたのですが、まさかこんな冬になるとは思いませんでした。

夜になると痒みが強くなり、起きている間はできるだけ掻かないように意識できるのですが、いざ寝てしまうと無意識のうちに掻いてしまい、それでさらに痒みが強くなって掻くという悪循環になってました。さらには強い痒みで何度も起きてしまい、掻いたことの罪悪感も相まって、ろくに寝れずに会社に行く日もありました。

前回の時は、はじめに行った病院との相性が悪くて、この辛い時期が長かったのですが、最終的には良い病院と出会い、2ヶ月程で治りました。

その点、今回はすぐに良い病院に行くことができ、1週間経ったあたりでかなり落ち着きました。今は発作的な痒みは無くなったので、心穏やかに眠れるようになりました:D

いつかまたなるかもなので、対処法をメモしときます。（この対処法は自分がうまくいった方法で、人によっては効果が無い、もしくは逆効果の可能性もあります。治療する際は病院等で相談して下さい。）

1. 痒くなってきたら、冷やす

冷やせば、その瞬間は痒みがおさまります。

逆に温めると痒みが増します。夜寝ている間に痒みが来るのも、温かい毛布にくるまって寝ているのもあるでしょうね。。。

2. 早く病院に行く

発作的な痒みがくる状況になると、もう病院に行って薬をもらった方が良いです。放っておいてもひどくなる一方でした。

病院で出された薬は以下。

• セレスターナ配合錠（飲み薬:朝夕食）
• アレロックOD錠（飲み薬:朝夕食）
• ステロイド剤（塗り薬）

3. 症状を緩和する市販薬

いくつか市販薬も試したのですが、一番効果的だったのはこの薬でした。

ジェルタイプの塗り薬でスーッとする成分が入っているので、痒みを冷ましてくれます。正直痒みを取る目的では病院でもらったステロイド剤より効果がありました。

【送料490円・税込5000円以上で送料無料】2/2 10時～ エントリー＆3ショップ購入で最大10倍!ア… 価格：520円（税込、送料別）

4. 調子に乗ってお酒を飲まない

蕁麻疹の原因は医者曰く「アレルギー」だそうです。

原因をあれこれと考えてみたのですが、痒みがきた頃に特に変わったものは食べていないし、生活環境も特に変わったことはなく、これ、と思い当たるものはありませんでした。

強いて言えば、正月頃から毎日お酒を飲んでいたくらいですかね。家で飲むのもそうですが、新年会やイベントやらで外で飲む機会もあったので、元来アルコールが得意で無い自分にとってはオーバーペースだったのかもしれません。

お酒が直接の原因ではないかもしれないですが、アルコールで血流が良くなると痒みが増すので、良くはないです。

そういえば2年前の時も暑くなりはじめた頃で、毎日梅酒を飲んでいたから痒くなったと思い、その後禁酒していたのを後から思い出しました。。。

痒みを舐めたらダメ

経験がある方なら分かりますが、あの発作のような痒みはホントに辛いものです。さらに掻きむしってしまった後の激しい自己嫌悪、あれも苦しいですね。

お酒が原因かははっきりしてませんが、「それ以上飲んだら体壊すぞ」という体からのサインだと思うので、完治するまでは禁酒を、完治してもほどほどにしたいと思います。

というわけで、宴の席ではしばらくウーロン茶になりますので、ご承知おきをm(_ _)m