最近はゴルフ関連の話題をたくさん書いていますが、ゴルフ練習場向けのシステム開発販売の仕事もしていますので、単に趣味でゴルフをやっているわけではありません。 最初にゴルフのラウンドをしたのは、2012年10月6日でした。ちゃんとブログも残っています。「タイで仕事をするのにゴルフをしないなんて仕事をしないのと同じことだ」と言われて、まあ、そこまで言われるなら、とやってみた感じです。その後も2014年までほぼ全部タイでのラウンドです。やってみたら意外と楽しくて、タイに行く度にパートナーさん主催のコンペに参加していた感じです。 2013年5月16日に練習場さん主催のコンペに参加したのが日本での初ラウンドです。こちらもブログが残っています。スコア143でした。その後2014年5月15日にも同じコンペに参加しています。ブログもちゃんとありますね。スコア128でした。 2012年：2ラウンド 2013年

「開発の仕事をしたい！」と採用したものの、なかなか活躍してもらえず、他の仕事をやってもらうしかない状態になることはそれなりに多い気がします。とくに、もともと開発の仕事をしていなかった人を中途で採用する場合に多いかもしれません。 開発仕事の経験があったり、あるいは学生時代に開発関連の勉強をしていた人であれば、開発の仕事がどういう仕事であるかをある程度理解しているので、会社が求める状態と本人の能力や希望が一致しやすいこともあるのですが、そうでない場合は「そもそもなぜ開発の仕事を希望しているのか？」「開発のどういう仕事をしたいのか？」が具体的にイメージできていないことが多く、なかなか難しいかもしれないと最近感じています。 もちろん、開発の仕事にもいろいろな仕事があり、クリエイティブな能力を求められるものから、どちらかというと作業に近いものまであります。クリエイティブな開発仕事ほど本人の技量や思い

「自分には良い仕事が与えられず、仕事へのモチベーションが維持できない」と聞いたときに、どう感じるでしょう？ ・気の毒に ・会社や上司が悪い ・そんな会社はとっととやめてしまう方が良い と考えますか？ --- 仕事を依頼する側が、「誰に任せるか」をどうやって考えるでしょうか。 ・あの人でないとできない仕事なので、選択の余地はない ・他にもできる人はいるが、あの人はいつも良い仕事をしてくれるので ・経験はない仕事だが、あの人に任せてみたい こんな感じで私は考えます。良い仕事が回ってこないということは、依頼する人にとって自分がこれらのポイントにマッチしていないから任せてもらえないのです。 オンリーワンの能力を持っている人であれば、その能力が必要な仕事は必ず回ってくるはずですので、回ってこないということは能力が足りないか、認めてもらえていないということでしょう。 他の2つのポイントに関しては、日頃

「最近すっかりゴルフに熱中しているようだね」と言われることが多いのですが、単なる趣味として熱中しているわけではありません。もちろん数年前にゴルフを初めてやってみて、「これは面白い！」と思いましたが、それだけで熱中しているのではないのです。 私は仕事で長いことソフトウェア開発、とくにネットワーク系のソフト開発をしてきました。プログラミングも学生時代のアルバイトでやってみて、「これは面白い！」と思いましたが、面白いだけで熱中したわけではなく、やっぱり仕事に繋がるから熱中した感じです。私は知名度やブランド力のない中小企業で仕事をしてきましたので、「目の前の仕事をこなせばお金がもらえる」という感覚はほとんど持ったことがなく、「仕事を生み出さないとお金が稼げない」という環境でしか仕事をしたことがありません。プログラミングの仕事を得るためには、プログラミングの話題についていけなければなりませんし、つい

先日、「業績好調！」で最近の業績のことを書いてみましたが、2018年度の業績が経費までしっかり把握できたので、あらためてこれまでの「請負型ビジネスから提案型ビジネスへの過程」を自分自身の備忘録としてもまとめてみました。 2008年10月にメンバー向けに書いた資料をたまたま見つけたので、一部をそのまま張り付けてみました。 「 ２０１０年４月までに解決すべき課題 収益の確保 PLASMA事業部時代は良いお客と運を味方に付け、毎期結果的にはプラスの成績を出してきた。しかし、IT事業部での2008年上期は不景気のあおりを受け、受託開発は不振に終わった。 受託開発の実績や経験は今後も活かせるので収益の軸とするが、仕事の確保には十分な余裕を見込んだ動きをせねばならない。従来のように、この先によい話がありそうと言うことに頼ることはできない。取りすぎて困るくらいの状況を作る、相手から依頼が集中するような戦

プログラマーとしてすでに30年くらい仕事をしてきて、最近になって「ひょっとして？」と気がついたことが1つあります。大したことではありませんし、勉強の偏差値の話しとかが絡むので、読んだ人がイラッとくる内容かも知れないのですが、まあ、このブログは自分のために自分で好きなことを書くのがポリシーなので、忘れないうちに書いておきます。 受託開発でも製品開発でも同じなのですが、長年この仕事で気になっていたことの1つが「完璧さ」に関することです。技術的に難しくてできないとか性能が出ないとかではなく、「作り忘れた」「確認し忘れた」「渡し忘れた」「書き忘れた」など、単純なことです。 私はずっと「気合いが足りない」「配慮が足りない」「メモしておくなど忘れない工夫が足りない」「心がこめられていない」などの原因だと思っていたのですが、確かにそういう要因もあるものの、もっと根本的なことなのではないかと最近思いつきま

たまにはまじめな話題で。 このところIT業界では技術者不足が深刻なようで、請負仕事や派遣仕事では人手不足が問題になっているようです。他人事な書き方をしているのは、私自身が請負仕事にこのところ直接関わっていないためです。そんな背景から、知り合いの方とお話をしているときに「御社の技術者を引き抜かれたりすることはないですか？」と聞かれました。 そういえば、引き抜かれるという経験は私自身あまり記憶にないな・・・と思いながら、「ありませんし、誘われてもうちのメンバー達はあまり移動したがらないと思いますよ」と答えました。 仕事を選ぶ要素はたくさんありますが、「待遇」と「仕事内容」が多くの人にとって重要でしょう。そして、技術者の場合、とくにできる人ほど「仕事内容」の占める割合が大きいのではないかというのが私の印象です。 請負仕事をしていた頃は、私自身が「裏方ばかりで仕事を自慢しにくい」「なかなか自分がこ

たまには技術ネタやビジネスネタを書かねばと思いつつも、最近はパートナーさんとの連携などの関係で気軽に暴露ネタを書きにくくなってきてしまい、趣味ネタをたまに書くことくらいしかできていないのですが・・・ さて、上期が終わってだいぶ経ってしまいましたが、自社のIT関連事業の荒利の内訳は以下のグラフの感じでした。 ゴルフ関連ソフトというのは、自社のゴルフ練習場向けシステム製品のソフト関連分ですので、これも自社製品です。80%くらいは自社製品で稼いだという感じです。製品関連は仕入れも多いので、売上で見ればさらに製品の割合が高くなります。 7年前の様子を振り返ると、売上ベースでの内訳ですが、2010年上期は以下のような感じでした。 製品は30%弱です。 さらに、10年前の2007年では、グラフは作っていないのですが数字を見ると全て受託開発でした。自社のIT関連製品で、最初に本格的に立ち上げたのは「In

アプライアンスのプロトタイプを開発するときにとても便利なのがラズベリーパイです。価格・入手しやすさ・使いやすさなども大事ですが、さらに、CPUがARMだということもポイントが高いのです。サーバ機クラスのアプライアンスはインテル系CPUが多いのですが、コンパクトなアプライアンスではARM系のCPUが多く、ラズパイで動くものはそのまま製品用ハードでも同様に動くことが多いのです。 さて、便利なラズパイですが、自分の手元で開発用に使う場合には問題ないものの、プロトタイプとしてパートナーさんなどに貸し出そうと思うと、「ケース」「なんらかのモニター」が必要になることがあります。 プロトタイプではユーザインターフェースが実装されていない状態のこともあり、当然マニュアルもありませんので、まず必要になるのが「IPアドレス」をどうするかという点です。ラズパイはHDMIでモニターを接続できますので、USBキーボ

不正接続対策製品「IntraGuardianシリーズ」や大規模向けDHCPサーバ「ProDHCP」を中心にIT製品の開発販売がIT関連売上の7割以上を占める状態までになり、結局10年近くかかりましたが、ほぼ事業を請負型から自社製品型に移行できたと考えています。やってみなければ分からないことばかりでしたが、やってみた今となってみれば「ここがポイントだったなぁ」というところが分かるようになった気もするので、少し書いてみます。 請負型から製品開発販売型にビジネスを移行する上で非常に難しいのが、請負型は毎月といかないまでも検収後にお金が入ってきます。しかし、製品は開発が完了しても売れなければ全く入ってきません。「開発期間中にお金をどうするのか」「売れはじめるまでにお金をどうするか」「本当に売れるのか」と、実に経営側としては悩ましい期間が続きます。いずれも私なり（というより、私たちなり）にどう乗り越

昨年、「ラズパイの有効活用など」で紹介した、ラズパイを使ったカーネルパニックログ取得の仕組みがついに役立ちました！ 対象のシステムのカーネルパニックが発生しました。 本当は、ラズパイ本体を回収しなくてもログが取得できる仕組みにしたつもりでしたが、ちょっとラズパイに入れたプログラムに問題があり、本体を回収しました。 ↑半年以上しっかり動き続けて戻ってきたラズパイ ラズパイのLinuxはSDカードに入れて動かすのが標準的ですので、このラズパイでもSDカードで動かしましたが、SDカードをカードリーダーに入れてLinuxでマウントして調べてみました。 見事にカーネルパニックのログが残っていて、私が作ったプログラムの問題ではないことが証明できました！ とはいえ、他人のせいでもカーネルパニックするのも良いことではありませんので、調査してみたところ、Linuxカーネルの208.5日問題だったようです。カ

私の勤務先では、良い意味での「技術オタク」が集まって事業を進めています。製品開発販売が事業の中心ですので、製品開発力はとても重要であるのは当たり前ですが、同時に「自分たちの製品をどれだけ愛せるか」が大事なのです。受け身の仕事ではなかなかその状態まではたどり着けず、単純に表現して「技術オタク」の存在が欠かせないのです。 技術オタクの採用で気を使うのが、相性問題です。技術オタクの多くは、良く言えば「思い入れが強い」、悪く言えば「頑固」で、相性が悪いとチームが構成できません。相性は開発など技術的な側面もありますが、それよりも、「一緒にいられるか？」がポイントだと感じています。 技術オタクたちは普段の会話もオタク度が高く、雑談でもオタク度満載の会話が飛び交います。オタクたちからすれば好きな話題を話しているだけなので、それについてくるかどうかはほとんど気にしていないのですが、加わった側からすると、ひ

4月から新しい就業規則の運用を開始して1か月ちょっとが経ちました。最も細かく改定した部分が就業時間管理関連で、とくに時間外労働に関しては明確化をしっかり行いました。 当社の場合、長いこと出来高制だった時期があり、基本的な月収以外は出来高に応じた賞与で分配、というのがメンバーの意識に擦り込まれており、昔から時間外手当の記載は就業規則にあったものの、実際はほとんどのメンバーが「どうせボーナスでもらえるから」と申請をしていませんでした。いくらメンバーが自らそうやっていたとはいえ、労働基準法には準拠しないため、揉め事が起きるとまずいと考え、途中からは給与明細に見なし残業分として毎月固定額を明記するようにしてきました。 当社では基本的にほとんど残業はしないで通常業務は間に合うのですが、ずっと気になっていたのが、メンバーが「自ら社内に残ること」でした。技術オタクが多いので、自宅に帰っても趣味のプログラ

昨年の春に自社の就業規則見直しの検討を始め、夏にはほぼ原案を書き上げましたが、その後、会長・総務と議論を続け、新宿労働監督署に質問に行ったりして修正と関係者の説得を重ね、ようやく先日OKとなり、4月1日から新しい就業規則が施行されることになりました。 就業規則というと、必ず記載しなければならない「絶対的必要記載事項」の項目が直感的にイメージしやすく、それさえ書いておけば、他は都度ルールを決めて運用すれば良いのでは？と考えてしまいがちですが、実際は、「全社に対する告知」は全てこれに含まれるという感じであり、要するに、自社でのルールは全て書く必要があり、さらに労働監督署に届け出なければなりません。従業員が10名未満の場合は届け出の必要がないため、就業規則を作らなくても問題はないのですが、ルールがない会社は基本的にないと思いますので、何らかの形で作るものだと言えるでしょう。 就業規則で経営側が一

先日、自社製品であるProDHCPの調査を行う際に、straceを使ってみて便利でしたので、簡単に紹介しましょう（というより、自分の備忘録？）。 straceはシステムコールをトレースするもので、実行中のプロセスにも簡単にアタッチしてトレースができます。実際にProDHCPのプロセスにstraceでアタッチして様子を見てみましょう。 # strace -p 17030 -s 1600 -yy -o /tmp/strace.log -pでプロセスIDを指定し、-sで出力文字数をイーサフレームのサイズより少し大きく指定。-yyオプションでファイルディスクリプタ番号をファイル名、ソケットを送信元と送信先のIPアドレスとポート番号に置き換えを指定します。最後に-oでトレース結果をファイルに出力とします。 トレースファイルの中を見て、select()の後にread()しているところを探してみると、以

私の仕事では、Linuxでサーバを構築したり、アプライアンスを開発したりすることが多いのですが、Linuxのカーネルは意外と簡単にパニックになります。まあ、私の仕事では高負荷ものが多いので・・・。 カーネルがパニックするとOS全体が止まりますので、実運用では基本的に自動でリブートさせることがほとんどでしょう。冗長化していることも多いので、サービス自体が完全に使えなくなるようなケースは避ける構成になっていて、リブートで良いのですが、問題はリブートしてしまうとパニックのメッセージが見られない点です。そもそもサーバ機は大抵モニターも繋げずに運用することが多いので、たまたま目の前でパニックが発生しても見られないことが多いものです。 パニック時にダンプさせて解析するのも良いのですが、なかなか実運用状態のサーバでダンプさせてそれを取得するのも難しいものです。そんなときに便利なのが、netconsole

回線事業者などで豊富な実績を誇るDHCPサーバ製品「ProDHCP」ですが、実はこれまではほぼ私1人で担当していました。2005年くらいから続けていますので、10年以上ほぼ1人でやってきたのです。DHCPの案件はそれほど数が多いわけでもなく、開発も規模が大きいというよりは処理性能などをどう解決するかなど、閃きさえあれば何とかなることもあり、1人でもなんとかなってきました。 しかし、このところ社内の主力製品が軌道に乗ってきたこともあり、メンバー達から「実は回線事業者向けの製品も本腰を入れて取り組むべきでは？」という意見が多くなってきました。回線事業者向けのシステムは参入障壁が高く、せっかく10年以上も取り組んできてノウハウもたまってきているのにもったいない、という感じです。 ちょうど私自身、社長としての仕事も10年近くになり、そろそろ本格的に手をつけなければならない課題も増えてきましたので、

相変わらず忙しくてなかなかブログを更新できていません。趣味ネタくらいならお気楽に書けるのですが、仕事ネタは精神的余裕がないとなかなか書けないもので・・・ たまたま出張中で、逆に時間と精神的に余裕ができたので、最近の仕事の様子でも書いてみようと思います。 昨年あたりから、 ・IT関連製品のステージがかなり変わってきた ・メンバー構成もさらに強化された ・新しく加わってくれたメンバー達により新しい取り組みもどんどん生まれた ・ゴルフ関連事業もかなり業界内での位置づけが変わってきた という背景から、私自身の役割が大きく変化してきました。以前は、回線事業者向けDHCPサーバ製品のProDHCPを中心とした尖った製品は私自身が何とかしている部分が多かったのですが、今のメンバー達からは「その程度の開発面の仕事はいくらでも任せて欲しい」「そもそも小俣さんがやっているとソース管理や品質管理が個人に依存しす

最近、仕事でも電子工作が多いのですが、それはいろいろとあまり公開できない内容もありますので・・・。 ということで、自宅でのお話しです。息子が電子工作をしています。これはスピーカーネットワークキットを作っているところです。高校1年生の息子は、私の部屋から勝手に半田ごてを持って行って使っているくらいですので、このくらい簡単なものですが、学校での様子を聞くと、半田付けどころかネジを回す方向すら分からない人が結構いるらしく、半田付けの実習ではリードをニッパーでカットする際に飛ばないように押さえることを知らないので、教室の中でリードが飛び交って痛いのだそうで・・・。 男の子なら誰でも半田ごてくらい持っているものだと思いますし、一家に一台オシロスコープがあるのは当たり前、というのがうちの会社のメンバーの説です！？ すぐにできたので、早速音だし確認です。 息子が作ったスピーカーで聴いてみます。安いのにい