株式会社クリアコード > ククログ

ククログ


クリアコード:RubyKaigi 2015にスピーカー・スポンサーとして参加予定

12月11日から13日の3日間RubyKaigi 2015が開催されます。なんと、もう今週です。3日目は学生は無料で入れるということなので、学生の方は3日目の16:40から咳さんのActor, Thread and meを聞きに行くといいです。最後の「and me」がかっこいいですね。

クリアコードは例年RubyKaigiのスポンサーをしています。去年のRubyKaigi 2014のスポンサーに引き続き、RubyKaigi 2015もスポンサーになりました。

また、須藤がスピーカーとして2日目の12月12日の10:45からのセッションで話します。Rubyのテスティングフレームワークの歴史+αについて話す予定です。

例年、クリアコードにとってRubyKaigiは数少ない露出の機会となっています。RubyKaigiに参加したことで正社員への応募やインターンシップへの応募がきます。昨年はRubyKaigi関連の機会を活用し、正社員が2名増えました。今回の機会もぜひ活かしたいところなので、クリアコードを知っていて応援したいという方は、会期中、まわりの人にクリアコードを紹介してください。ご協力よろしくお願いします。

リーダブルコードワークショップのチラシとGroonga族のステッカーも配布する予定なので、こちらも応援よろしくお願いします。

タグ: Ruby | 会社
2015-12-09

クリアコードとフリーソフトウェアとビジネス

クリアコードの理念は、フリーソフトウェアとビジネスの両立です。

クリアコードは2015年7月1日から10期目に入っています。クリアコードが設立当初から大事にしていることの1つにフリーソフトウェア(ユーザーが自由に使えるソフトウェア)があります。ただし、それを大事にするにあたって「継続できること」という制約をつけています。言い方を変えると、「お金を稼ぐ」ということです。フリーソフトウェアを大事にしているという響きだけ聞くと、お金度外視でひたすらフリーソフトウェアを大事にしているイメージを持つかもしれません。しかし、お金を稼がないと継続できないので会社は潰れます。それでは大事にすることができなくなります。

ということで、クリアコードはどうやってフリーソフトウェアを大事にすることとお金を稼ぐことを両立させようとしているかを整理します。

お金を稼ぐ方法

クリアコードが使っているお金を稼ぐ方法は次の通りです。

  • 導入支援
  • カスタマイズ
  • サポート
  • 受託開発

それぞれ簡単に説明します。

導入支援

導入支援とはフリーソフトウェアのインストール・設定を支援することの対価としてお金をもらう方法です。

Mozilla製品(FirefoxとThunderbird)でよくある方法です。他のフリーソフトウェアの導入支援をすることもありますが、Mozilla製品が一番多いです。

この方法は大まかにいうと次のような流れになります。

  1. 依頼者が実現したいことをよく聞く
  2. 聞いた内容を理解し整理する
  3. どのようにしたら実現できるかを検討する
  4. 実現方法を提案する
  5. 導入する

導入支援の依頼者は対象ソフトウェア周辺に関する知識が不足しているためクリアコードに依頼します。そのため、クリアコードは自分たちが持っている知識を活かして、適切な実現方法を提案し、実際に依頼者が実現したい状態を達成することが大事になります。知識があっても、依頼者が実現したい状態と違う状態を達成してしまっては適切な支援ができたとは言えません。そのため、依頼者が実現したい内容を理解することは非常に重要です。

この流れの中でフリーソフトウェアを大事にする方法は次の通りです。できるだけこれらを実現するように依頼者と調整しながら進めます。

  • 調査や実際の作業で得た知見を誰でも利用できる情報として公開
  • 開発したツールをフリーソフトウェアとして公開
    • 例:↑のリンクに書いています。
  • 他の導入支援のために利用した・開発したフリーソフトウェアを利用
  • 導入支援中に見つけた問題を報告・修正

フリーソフトウェアを大事にするということは「開発に参加する・寄付する」というイメージがあるかもしれません。しかし、それら以外にも、関連情報を公開したり、ソフトウェアを広めたり、困っているユーザーを助けることなども大事にすることです。そうすることで開発者たちの作業が減ることにつながるからです。

そのため、これらはどれもフリーソフトウェアを大事にすることにつながります。

フリーソフトウェアを大事にするとき、依頼者のことを忘れてはいけません。クリアコードがフリーソフトウェアを大事にする行動をすると、依頼者にとってもよい状態になることを大事にします。そうしないと、依頼者の満足度が下がって継続して一緒に仕事をできないからです。仕事にならないとお金を稼げません。

ここに挙げた方法では次のような観点で依頼者にとってもよい状態になると説明して理解を求めます。

  • 調査や実際の作業で得た知見を誰でも利用できる情報として公開
    • 他の導入支援のときにすでに公開していた情報を更新することができ、依頼者は更新された情報を無償で利用できます。(たとえば、Firefox/Thunderbirdのバージョンアップがあった場合など。)
  • 開発したツールをフリーソフトウェアとして公開
    • 他の導入支援のときにも利用できるようになり、その際に機能追加・問題修正した場合は依頼者は無償でその恩恵を受けられます。(たとえば、Firefox/Thunderbirdのバージョンアップに追従する作業など。)
  • 他の導入支援のために利用した・開発したフリーソフトウェアを利用
    • 作業時間を短縮でき、費用を少なくできます。
  • 導入支援中に見つけた問題を報告・修正
    • クリアコードが独自で調査・修正してパッチをメンテナンスするよりも、メンテナンスコストが下がるので、長い期間でみると費用を少なくできます。(導入して終わりではないので、長い期間をみるのは妥当なことです。)
カスタマイズ

カスタマイズとはフリーソフトウェアの設定変更、本体変更、既存のプラグインの変更、プラグインの新規作成などの作業の対価としてお金をもらう方法です。他のお金を稼ぐ方法である、導入支援、サポート、受託開発の一環として実施することが多いです。

依頼者固有の内容については公開しませんが、一般的に使えそうな知識やプログラムは、依頼者に説明して理解を得た上でできるだけ公開します。このときの方針は前述の導入支援のときと同様です。つまり、「クリアコードはこういうポリシーなのでこうしていいですよね?」ではなく、「依頼者にとってもメリットがあることなのでこうしていいですか?」というところを大事にするということです。

サポート

サポートとは運用中に発生した問題の調査、開発時の技術的問題の解決支援などの対価としてお金をもらう方法です。Webで検索すると「OSSサポートサービス」を提供している会社がいくつか見つかりますが、それらと同様のお金の稼ぎ方です。

Mozilla製品は導入支援後にそのままサポートを提供するケースが多いです。受託開発でシステムを構築した場合はそのシステムのサポートを提供することがあります。

一般ユーザーから直接問い合わせる形でのサポート(ヘルプデスクと呼ぶのでしょうか)は提供しておらず、情報システム部門の方経由、SIerさん経由、既存のサポートサービスのエスカレーション先としてサポートを提供します。

サポートは基本的にリモートから提供しています。つまり、直接依頼者のところにいって調べることはせず、情報を提供してもらい、それらを使って問題を解決します。ただし、「行ったほうが早い」ときは行きます。

リモートでのサポート提供ではどういった情報を提供してもらいたいかを適切に伝えることが重要になります。そうしないと闇雲に時間が過ぎていくからです。そうなると問題が発生している期間が長くなりますし、依頼者の負担も増えます。結果として、依頼者の満足度が下がり、サポートサービスの利用を打ち切るでしょう。

リモートで調査するというのはフリーソフトウェアの開発では普通のことなので、フリーソフトウェア開発で培った知見を活かします。どういう知見かというと、どういうときにこのケースが発生する可能性があり、それを確かめるためにはどういう情報を知ればよいか、また、その情報をいかに少ない負担で取得してもらうか、というのを考えるということです。そのために、状況を整理する、ソースから問題が発生する可能性のあるケースを洗い出す技術などが必要になります。具体例としていくつか過去の記事を挙げます。

サポートのときのフリーソフトウェアを大事にする方法は導入支援と同じですが、「導入支援中に見つけた問題を報告・修正」が多くなります。多くの場合、なにか問題があって問い合わせがきています。そのため、それを開発元に報告する機会も多くなる、ということです。

受託開発

受託開発は依頼者が欲しいソフトウェアを開発する対価としてお金をもらう方法です。契約方法は次のどちらかのパターンが多いです。

  • 最初は請負契約で、お互いに信頼できることを確認できていて準委任契約の方が向いていそうな内容(たとえば、作業開始時にすべての作業内容が決まらないとき)なら準委任契約にする
  • 準委任契約が向いていそうな内容のときは最初から準委任契約にする

開発するソフトウェアは、すべてがフリーソフトウェアの場合もありますし、一部だけフリーソフトウェアの場合もありますし、すべてがプロプライエタリなソフトウェアの場合もあります。仕事を受けるときはフリーソフトウェアになる度合いが大きい仕事を優先します。

開発するソフトウェアがすべてプロプライエタリなソフトウェアの場合でも、フリーソフトウェアを活用します。たとえば、RubyでWebアプリケーションを開発する場合は、Ruby、Ruby on Rails、Sinatraなどのフリーソフトウェアを活用しますし、GNU/Linux上でマルチメディアを再生するアプリケーションを開発する場合はGStreamerを活用します。これはフリーソフトウェアを大事にするクリアコードとしての最低限譲れないラインです。

なお、単に活用するだけでなく、問題点や改良点が見つかった場合は開発元に報告する、知見を公開するなどでよりフリーソフトウェアを大事にする活動につなげようとします。

ただし、このときもクリアコードの都合だけを考えないことが大事なポイントです。依頼者にとってもメリットがある形、少なくともデメリットがない形での実現を目指します。

最低限のラインは依頼者が満足することです。たとえば、依頼者と約束した機能を約束した妥当な期間内に実現していること、依頼者に素早く適切な回答を返し続けることで良好な関係を築いていること、などが満足につながります。もし、前に汚いコードで作ってしまった・本来必要ない作業も(気づかずに)実施しているなどの理由で、機能の実現にかかる時間が「長い印象」を与えることが続けば依頼者の満足度は下がっていくでしょう。(妥当な理由を依頼者が理解できるように説明できれば「長い印象」はもたれないでしょう。)

依頼者にとってのメリットが見いだせない場合(たとえば、それをやっていると時間が無くなって欲しいものが実現できない場合)は、業務の空き時間や趣味のフリーソフトウェア開発のときに開発元に報告します。

業務の空き時間を作るためには効率よく仕事をします。空き時間ができたクリアコードのメンバーは空き時間がない他のメンバーが溜めている問題を代わりに開発元に報告します。

クリアコードのメンバーはもともと好きでフリーソフトウェアの開発をしてきた人たちです。そんな人たちが、クリアコードに入ったから趣味のフリーソフトウェア開発をやめた、となるのはクリアコードとしてはうれしくありません。好きでフリーソフトウェアの開発をしていた人が減るからです。

クリアコードがフリーソフトウェアを大事にする方法として、メンバーが趣味に使える時間を増やすという方法があります。クリアコードは基本的に残業をしない働き方にしています。また、1年ほど前から有給休暇の有効期限切れ日数が0になるような取り組みを進めていて、今ではほとんどのメンバーが有効期限が切れる前に使い切っています。業務時間の一部を好きなように使ってよいという会社もありますが、クリアコードは休みの日を増やし、メンバーがフリーソフトウェアの開発に使える時間を増やすことでフリーソフトウェアを大事にしています。

まとめ

クリアコードがどうやってフリーソフトウェアを大事にすることとお金を稼ぐことを両立させようとしているかを整理しました。

クリアコードは、依頼者のことを大事にし、これからも継続してフリーソフトウェアを大事にしていきます。

タグ: 会社
2015-09-17

クリアコードに入社した理由: フリーソフトウェアを仕事にしたい

はじめまして、今年の2月にクリアコードに入社した横山です。この記事では、私がクリアコードに入社した理由のひとつである「フリーソフトウェアを仕事にしたい」ということについて、フリーソフトウェアやクリアコードに興味を持ったきっかけと、入社までの経緯をお伝えします。

フリーソフトウェアに興味を持ったきっかけ

私は社会人になってから本格的にプログラミングを始めました。研修や仕事でプログラミングに触れるにつれて楽しさを感じ、研修で触れたRubyがよさそうだったので、趣味でもプログラムを書いたりしていました。

その頃、何度か社内外の勉強会で発表する機会があり、既存のプレゼンテーションツールに不満を感じていました。そこで、新しいツールを探していたところ、Rubyで作られているRabbitというソフトウェアがあることを知り、次のような点が気に入って使い始めました。

  • テキストエディタで書けるのでバージョン管理しやすい
  • うさぎとかめのタイマーで経過時間とスライドの進捗がひと目でわかる
  • フリーソフトウェアなので不満があったら自分で直せる

しばらく使っていると、SlideShareにアップロードする機能がうまく動かないことに気づきました。Rabbitがフリーソフトウェアでなかったらそこで終わっていたのでしょうが、ソースコードが公開されていてすぐに読むことができたため、プログラマーとして成長したいと思っていたこともあり、自分で直してみる気になりました。

そこで送ったpull requestがこれです。おそらく、私が初めて送ったpull requestだと思います。数時間後には取り込んでもらえて、その日のうちに早くも修正が反映された新バージョンがリリースされました。すぐに好意的な反応をしてもらえたのが印象に残っています。

自分で使っているソフトウェアの問題を自分で直すことができるというところがとても気に入って、その後もRabbitを中心にいろいろなフリーソフトウェアに関わり始めました*1

クリアコードに興味を持ったきっかけ

初めてpull requestを出してフリーソフトウェアに関わり出した頃の私は、Javaを使った金融系システムの開発や保守を仕事にしていました。公開できるシステムではなかったので、フリーソフトウェアに関われるのは夜間や週末になります。初めのうちはそれで満足していたのですが、だんだんもっと深くフリーソフトウェアに関わりたいと思うようになりました。

そんなとき、RubyのカンファレンスであるRubyKaigiの過去の資料や動画を見ていて、フリーソフトウェアを仕事にしているクリアコードという会社があることを知りました。本当にフリーソフトウェアを仕事にできるのか、にわかには信じられませんでしたが、会社のWebサイトやブログにビジネスについての情報が公開されていて、本当なんだと思いました。

入社までの経緯

そのうちクリアコードの選考プロセスであるパッチ採用に応募してみようと思っていたところ、偶然にもRabbitの作者の須藤さんがクリアコードの代表取締役で、クリアコードに興味はないかと声をかけてもらったのが入社の直接のきっかけになりました*2

そして、今年の1月に今まで住んでいた札幌から東京に引っ越し*3 、2月から入社となりました。

まとめ

私がフリーソフトウェアやクリアコードに興味を持ったきっかけと、入社までの経緯をお伝えしました。フリーソフトウェアやクリアコードに興味がある方に参考にしてもらえるとうれしいです。

*1 Rabbitには今もコミッターとして関わっています。私のRabbitへのコミットの一覧はGitHubで見ることができます。

*2 特に採用試験のようなものはありませんでした。Rabbitまわりの活動が、すでにパッチ採用の選考プロセスとして認められていたようです。

*3 引っ越す直前、札幌地区の勉強会などでお世話になっていた方々に(私の希望で小規模でしたが)送別会をやってもらいました。正直なところ札幌を離れるのに抵抗があったのですが、東京に行く勇気をもらいました。疲れたときはそのときにもらった紅茶を飲んでほっと一息ついています。

タグ: 会社
2015-03-19

消費税率引上げへの対応 契約時の対応編

はじめに

10月に消費税率引上げへの対応を書いたところ多くのアクセスをいただきありがとうございます。前回の記事の時点では、2014年4月1日の消費税率引上げの日をまたいだ契約はそれほどありませんでした。しかし、この3ヶ月間で締結した契約のほとんどが2014年4月1日をまたぐもので、取引先ごとの消費税率引き上げへの対応がまちまちで調整に時間がかかりました。例えばまだ社内システムが消費税率8%に対応していないので、8%での支払いはできないケースや、2014年3月31日までの支払い分はすべて5%とするケースなどがありました。そこで今回はこのような取引先の事情にあわせて、クリアコードがとった対応を紹介します。

インシデントサポート契約について

今回題材にするのはインシデントサポート契約です。この契約はフリーソフトウェアのサポートを時間制で提供するものです。サポート対象のフリーソフトウェアはmilter managerやMozilla Firefox,Thunderbird、GStreamerなどです。契約内容は期間1年で、たとえば最大30時間まで障害解析など問合せに対応します。価格は消費税別で30万円となります。 このインシデントサポート契約は、契約期間中に作業時間が30時間に達するとその時点で契約終了になります。またサポート依頼がいつ発生するかは契約時には不明で、契約当初に集中することもあれば、毎月ぽつぽつ発生することもあります。作業量が毎月一定ではないため、売上は契約終了時に全額を計上することにしています。もっとも一般的な保守契約であれば、年間保守料を12等分した金額を毎月売上計上するのが通例です。よって、このインシデントサポート契約はサポート契約という名称ではあるものの、契約満了時に一括して売上計上する点において受託開発的な契約と言えます。なお、契約金額の支払い条件は契約開始月末締め翌月末振込を基本としています。たとえば契約開始日2014年1月6日の契約を、2013年12月27日に受注した場合、2014年2月28日支払期日の請求書を2014年1月31日に発行します。

消費税率改定への対応事例

では、インシデントサポート契約の締結にあたって、消費税率引上げに対する取引先の事情を考慮してどのような対応(条件の変更)を行ったのか、事例を紹介していきます。

消費税率8%で前払いとする 契約が3月31日までに終了した場合は3%の差額を返金する

これまでどおりの支払い条件を踏襲した場合は、消費税率8%で前払いとなります。ただし契約が2014年3月31日までに終了した場合は、2014年4月1日をまたいだ契約とならないので5%を適用します。2014年3月31日までの契約にも関わらず8%分の消費税を受け取ったままというわけにはいきません。そのため、もし2014年3月31日までに契約が終了した場合は3%の差額を4月1日以降に返金することにします。このような消費税返金の条件は請求書に次のように記載しています。返金する場合はお客さまから振込先を通知していただく目的で請求書を発行してもらうことにしています。

  • 2014年3月31日時点で契約が終了している場合は、消費税率5%を適用します。この場合、消費税の差額9,000円を5月30日に返金いたします。その際は消費税差額の請求書を2014年4月30日までにお送りください。
消費税率5%で前払いとする 契約が3月31日を超えた場合は3%の差額を4月1日に請求する

もっとも多いのがこのパターンです。大手企業では2014年3月31日までに請求する場合は、2014年4月1日以降の部分も5%で消費税額を計算し、2014年4月1日以降に8%と5%の差額を請求するよう求めているところが多いようです。まだ消費税率引上げへのシステム対応が完了していないお客さまも、消費税率8%で支払うことが困難なため、一旦5%で支払うこの方法を選択されています。このお客さまの場合、8%で後払いにすることも検討されました。しかしお客さまがサポート契約を再販しており、後払いにすることによって下請法違反になることがわかったため、5%で前払いする方法を選択されました。下請法については、公正取引委員会のサイトで詳しく紹介されています。 なお、クリアコードが発行する請求書には消費税の取扱について次のように記載しています。

  • 2014年4月1日時点で契約が終了していない場合は、消費税率8%を適用します。この場合、消費税の差額9,000円を5月末にお支払いいただきます。なお、消費税差額の請求書は2014年4月30日に発送します。
消費税率8%で後払いとする 契約が3月31日までに終了した場合は5%を適用する

インシデントサポートを自社で利用する場合は、下請法の心配はありませんので、後払いで問題ありません。消費税率改定のシステム対応がまだのお客さまはこの方法を選択されています。請求書は契約終了時に発行します。消費税額は契約終了時の消費税率で計算するだけなのでもっとも手間がかかりません。

契約を3月31日までと4月1日からの2本に分割する

消費税率が5%か8%か確定しない契約はできないというお客さまの場合、契約期限を2014年3月31日で一旦切らなければなりません。そのため2014年1月から3月末まで3ヶ月間10インシデントの契約と2014年4月1日から2014年12月末まで9ヶ月20インシデントの2本の契約に分割しました。しかしこの方法は大きなデメリットがあります。例えば2014年2月28日までに10インシデントを使いきってしまうと、1本目の契約は終了してしまいます。そのため2014年3月にサポート依頼をするためには、再度2014年3月31日までの契約を締結しなければなりません。短い期間で複数の契約を締結するのはお客さまクリアコード双方の事務コストが大きくなってしまいます。

まとめ

今回は、インシデントサポート契約を例に、消費税率改定への対応のため、契約条件をどのように変更したのかを紹介しました。下請法を考慮すると後払いにできないということがわかった時はひやっとしました。前払いから後払いへの変更は受注する側にとって契約条件の不利な変更です。あやうくお客さまを下請法違反にしてしまわないよう注意が必要です。また一度支払い条件を変更すると、もとの条件に戻すことは容易ではありません。不利な条件へ変更する場合は、手許現金の減少など自社の財務内容への影響もあるので、慎重に判断することをおすすめします。

タグ: 会社
2014-01-23

消費税率引き上げへの対応

はじめに

2013年10月1日、来年4月から予定通り消費税率を8%に引き上げるとの発表がありました。そこでクリアコードでも消費税率引き上げに対して、どのような対応が必要か確認してみました。すると、すぐに対応しなければいけないものがあることがわかりました。そこで、今回は消費税率引き上げにともないクリアコードで実施した対応とこれから必要となる対応を紹介します。

今回の消費税率引き上げの概要

消費税とは

消費税は、国内におけるほぼすべての商品の販売、サービスの提供に課税する間接税です。消費税は、事業者が販売する商品やサービスの価格に含まれて、次々に転嫁されます。そして最終的に商品を消費、またはサービスの提供を受ける消費者が消費税を負担します。消費税を負担するのは消費者で、消費税を申告、納付するのは事業者となります。このように負担者と納税者が異なる税金のことを間接税と呼びます。では、消費税の納税義務はいつ成立するのかというと、原則として商品の引き渡しやサービスの提供をした時になります。

消費税率引き上げの対応にあたっては、この商品の引き渡しやサービスの提供がいつになるかによって税率が変わるので、注意する必要があります。また売上を計上するタイミングが消費税の納税義務発生のタイミングになるので、売上計上基準によって、適用される消費税率が変わることがあります。

消費税率引き上げの内容

消費税率は平成9年に3%から5%に引き上げられました。今回は17年ぶりの消費税率引き上げとなります。

「社会保障の安定財源の確保等を図る税制の抜本的な改革を行うための消費税法の一部を改定する等の法律」(以下、「消費税法改定」)により、消費税率は平成26年4月1日に8%、平成27年10月1日に10%へと2段階で引き上げられることになりました。この法律には「経済財政状況の激変にも柔軟に対応する観点から、消費税率引き上げ前に、経済状況を総合的に勘案した上で、消費税率の引き上げの停止を含め所要の措置を講ずる」ことが定められており、平成25年10月1日の閣議で平成26年4月1日に8%に引き上げることが正式に決定しました。

経過措置

今回の消費税法改定では、税率引き上げに伴う経過措置が設けられました。本来平成26年4月1日以降に行われる資産の譲渡等には8%の税率が適用されます。しかし経過措置によって、一定の条件を満たす取引については、8%に引き上げられた後でも5%を適用することができます。

たとえば、平成25年9月30日以前に契約したソフトウェア受託開発案件の場合、納品が平成26年4月1日以降であっても、5%の税率が適用されます。他には、平成26年4月1日以降に利用する鉄道や飛行機の交通運賃も、平成26年3月31日までに支払った場合は、5%の税率が適用されます。

経過措置の内容は、国税庁の資料「平成26年4月1日以後に行われる資産の譲渡等に適用される消費税率等に関する経過措置の取扱いQ&A」に詳しく記載されています。自社の取引の中で、経過措置に該当するものがないか、この資料をひと通り目を通して確認するのがよいでしょう。

売上への影響と対策

クリアコードでは、まず業績への影響が大きい売上への影響と必要な対策を確認することにしました。

売上への影響

クリアコードのサービスは請負契約と保守/サポート契約にもとづき提供しています。

契約形態によって売上計上の方法が異なるため、消費税率引き上げの売上への影響と、必要な対策をそれぞれ確認しました。

請負契約

請負契約では納品日に売上計上しています。契約締結日が平成25年10月1日以降で納品日が平成26年4月1日以降の契約は経過措置の対象外となるので、消費税率は8%となります。もしこれに該当する契約を消費税率5%で契約してしまっている場合は対応が必要です。なお、経過措置の対象となるのは物品の引き渡しがあることが条件となります。納品物の定めがない場合は経過措置の対象にはならないので注意が必要です。

確認のポイントは次のとおりです。

  • 平成26年4月1日以降が納期の請負契約
    • 契約締結日が平成25年9月30日以前なら経過措置の対象となり、請求時の消費税率は5%でOK
    • 契約締結日が平成25年10月1日以降なら、請求時の消費税率は8%

契約書に消費税率5%で算出した請負金額を記載してしまっている場合は、発注元に対して消費税率8%で算出した請負金額への変更をお願いしなければなりません。5%の金額で受け取った場合は、自社で差額の3%分を負担しなければなりません。

例えばもとの請負契約が次の内容で、消費税率上げにともなう請負契約の変更を行わなかったとします。

  • 契約日 平成25年10月1日
  • 納品日 平成26年4月30日
  • 請負金額 3,150,000円(消費税込)

納品日の平成26年4月30日に無事納品、検収が完了したとすると、この日に売上3,150,000円を計上します。この取引は経過措置の対象外となるため、8%の消費税が発生します。よって売上金額の3,150,000円には8%の消費税が含まれているとみなされます。消費税額は3,150,000 / 1.08 * 0.08 = 233,333円となり、売上に含まれる消費税額は233,333円 - 150,000円 = 83,333円増加します。つまり、消費税率引き上げによって、83,333円の消費税を自社で負担しなければならず、利益が減ってしまうことになります。

原則課税の場合、受け取った消費税から支払った消費税を差し引いた額が消費税の納税額となります。発注元が原則課税を採用している場合はこの取引で支払う消費税が増えても、納税時に支払う消費税額がその分減るので、業績への影響はありません。まずは消費税率改定にともなう変更契約の締結を発注元に依頼するのがよいでしょう。一方、発注元がもし簡易課税制度を採用していると売上金額から消費税額を算出するため、支払った消費税額が増えても納税額は変わりません。つまり支払う消費税額が増えれば利益が減ってしまいます。契約の変更が難しい場合は、納期を平成26年3月31日以前に変更すれば収益の減少は避けられますが、開発メンバーからの批判は避けられないでしょう。

また、これから契約するものについては、納期によって消費税率が変わってきますので、見積書作成の段階から注意が必要です。

保守/サポート契約

クリアコードでは過去に構築したシステムの保守/サポート契約を1年契約で締結していて、売上は毎月一定額を計上しています。保守は物の引渡しを要しない契約であり、経過措置の対象外となります。一方で保守契約の代金は契約時に一括して受け取っており、受け取った消費税はすべて5%でした。しかし現在の売上計上基準では、来年4月以降に売上計上するものについては消費税率が8%になってしまいます。つまり平成26年4月1日以降に契約期限が到来するものについては対応が必要となります。

確認のポイント

  • 平成26年4月1日以降に契約期限が到来するもの
    • 平成26年3月31日までは消費税率5%
    • 平成26年4月1日以降は消費税率8%

例えば次の保守契約を締結していたとします。

  • 契約期間 平成25年10月1日から平成26年9月30日
  • 契約金額 252,000円(内消費税12,000円)
  • 代金受取 平成25年10月31日

この保守契約では、毎月月末に21,000円を売上計上しています。平成25年10月から平成26年3月までは消費税率は5%となるので、売上金額のうち、1,000円が消費税となります。しかし平成26年4月からは消費税率8%となるので、もし消費税率引き上げ分を追加でもらうことができなければ、売上金額のうち、21,000 / 1.08 * 0.08 = 1,555円が消費税とみなされるため、1,555 - 1,000 = 555円を自社で負担しなければなりません。 対策としては、平成26年4月から平成26年9月までの6ヶ月分の代金120,000円について、消費税の差額 120,000 * ( 8% - 5% ) = 3,600円をお客様に追加で負担してもらう方法が考えられます。また、別の方法としては売上の計上時期を変更することによって消費税率改定による売上減少の影響を回避することができます。保守契約の場合、代金受け取り時に一括して売上計上することが認められているので、平成25年10月31日に全額を売上計上すれば消費税率は5%となります*1。ただし、売上計上基準を変更した場合はすべての取引について同じ基準を適用し、かつ毎期継続的に適用しなければなりません。

また、これから契約を締結するものについては、平成26年3月までは5%、平成26年4月以降は8%の消費税率を適用しなければなりません。さらに契約が平成27年10月を超える場合は、平成27年10月以降は10%とする必要があります。ただし、平成27年10月に10%に引き上げられることが確定していませんので、もし引き上げが行われなかった場合は差額を返還するなどの対応が必要となります。

支出面での影響

クリアコードの場合、請け負った業務について外注することはないので、売上への影響で行った平成26年4月をまたいだ契約のチェックは不要でした。またその他の経費の支払いについては、原則課税を選択しているので、支払う消費税額が増えても、それは納税額が減るだけなので業績への影響ないことが確認できました。

簡易課税を採用している企業だと、納税額は売上高から算出されるので、消費税の支出を抑えればその分利益が増えます。簡易課税の場合は3月末までに経費支出をするのがよいでしょう。

まとめ

消費税率引き上げによって業績にどのような影響があるのか、また影響がある取引についてどのような対策が必要か、クリアコードで検討した結果を紹介しました。請負契約、保守契約のいずれも平成26年4月1日をまたぐものについては、対策が必要となる可能性があります。対策が必要となった場合、お客様にも影響が及びますので、早期に確認するのがよいでしょう。

*1 経理処理については税理士事務所等にご確認ください。

タグ: 会社
2013-10-24

クリアコードのフリーソフトウェアビジネス

はじめに

7月12日につくばインターンシップ・コンソーシアム主催の夏休みインターンシップマッチングフェアにインターンを受け入れる企業として参加してきました。中小、ベンチャー企業16社と50名ほどの学生さんが参加していました。クリアコードのブースには10名近い学生さんがきてくれました。ブースではクリアコードの業務内容、インターンシップを実施する理由、現在実施しているインターンシップを紹介しました。ブースにきてくれた学生さんはフリーソフトウェアでビジネスをしているというクリアコードの特徴に興味をもったようで、どうやってフリーソフトウェアでビジネスができるのかという質問をよく受けました。そこで今回はクリアコードがどうやってフリーソフトウェアでビジネスをしているのか紹介します。

クリアコードの業務内容

クリアコードは2006年7月25日に創業し、今月7周年を迎えました。これまでの7年間、さまざまな業務を行ってきました。この7年間に携わった案件を3つの時代にわけて紹介します。

初代社長時代

初代社長時代は第1期と第2期です。エンジニアの雇用を確保する目的で立ち上げたのがクリアコードでしたので、雇用を維持できるように案件を確保することが当時の最優先課題でした。エンジニア全員がデスクトップ関連のフリーソフトウェア開発に関する高いスキルを有していたので、それを活かすことが案件獲得の近道でした。また当時は経済産業省主導でOSSの推進事業がIPAなどで行われていました。

第1期(2006/7から2007/6)

IPAや自治体など公共系の案件が中心でした。フリーソフトウェアのデスクトップ環境導入支援やフリーソフトウェアを使ったシンクライアントシステムの開発など、デスクトップ分野の案件が多くありました。また「ソースコードがあればなんとかできる」を合言葉に他社で対応できなかった案件や、開発が頓挫しかけた案件を獲得していました。

主な業務

  • IPAのOSS活用基盤整備事業
    • Linux環境における外字管理システムの仕様開発とプロトタイプ作成
    • 栃木県二宮町での自治体導入実証事業(OpenOffice.orgの導入支援やデスクトップ環境の整備を担当)
  • シンクライアントシステムの開発
  • シンクライアントシステムの自治体導入
  • マーケティング・デザイン業務の労働者派遣
  • 動画共有サイトの開発(Ruby on Rails)
第2期(2007/7から2008/6)

第1期にIPAの事業を一緒に行なった企業との取引が拡大し、フリーソフトウェア本体へ機能追加する業務がでてきました。またMozilla Japanのサポートパートナーとして、FirefoxやThunderbirdのアドオン開発やサポートを本格的に開始しました。さらにRubyをつかったWebサービスの開発など、民間企業との取引が拡大しました。またこの時期に、CutterやUxUといったテスティングフレームワークの開発を開始しました。

主な業務

  • IPAのOSS活用基盤整備事業
    • 国際標準文書フォーマットの日本語機能拡張開発プロジェクト(OpenOffice.orgの拡張機能開発)
  • 動画共有サイトの開発(Ruby on Rails)
  • Thunderbird、Firefoxのサポート業務
  • Firefoxのアドオン開発
  • フリーソフトウェアの機能追加や性能評価
  • テスト自動化フレームワークの開発
2代目社長の20代

第2期に黒字化し、取引先も順調に増加しました。フリーソフトウェア開発者集団として、社長はフリーソフトウェア開発者が務めるのがよいとの判断で、第3期に現社長に社長を交代しました。

第3期(2008/7から2009/6)

milter managerをIPAの事業で開発しました。このmilter managerが後の取引先拡大につながりました。また全文検索エンジンSennaを開発していた未来検索ブラジルさんとCutterをつかったテスト開発で取引が始まりました。Mozillaのサポート業務は順調に拡大し、数万人規模の企業への導入支援など大規模な案件が増加しました。

主な業務

  • Senna、groongaのテスト開発
  • IPAのOSS活用基盤整備事業
    • 迷惑メール対策ポリシーを柔軟に実現するためのmilterの開発(milter managerを開発しフリーソフトウェアとして公開)
  • Windows用デスクトップ・アプリケーション開発
  • 動画共有サイトの開発(Ruby on Rails)
  • Firefox、Thunderbirdの企業導入・サポート業務
第4期(2009/7から2010/6)

リーマン・ショックの影響で、Webサービスの開発案件やフリーソフトウェア導入案件が中止となるなど、案件の確保に奔走した1年でした。groongaやデジタルサイネージの開発がスタートし、拡大しました。これらのプロジェクトではお客様の開発チームと一緒に開発することになります。

主な業務

  • デジタルサイネージシステムの研究開発
  • groongaの開発
  • 大学へのLinuxデスクトップ環境ならびにmilter manager導入
  • Firefox、Thunderbirdの企業導入・サポート業務
  • Firefoxのツールバー開発、Firefoxをつかった研究開発
  • NICTベンチャー支援事業(モバイル分野の研究開発を行いました。後のデジタルサイネージシステム開発(組込システム開発)参入の基礎となりました。)
第5期(2010/7から2011/6)

2010年8月に主要取引先であるミラクル・リナックスさん、未来検索ブラジルさん、コスモエアさんと資本提携し、この3社との取引が拡大しました。さらにmilter managerの導入案件がきまり、milter managerとmilterの開発がビジネスに発展しました。他にも開発、サポート、システム構築などさまざまな業務が同時に進行し、かつ新規取引先との取引開始も多く、社内リソースが逼迫しました。

主な業務

  • groongaの開発
  • デジタルサイネージシステムの開発
  • 社内文書検索システムの開発
  • milter managerの機能追加とmilterの開発
  • Sambaの導入とサポート
  • Firefox、Thunderbirdのサポート、導入支援
  • メールマガジンシステム開発(リソース足りず外注する)
2代目社長の30代

あんなに若かった社長も30歳を迎えました。

第4期、第5期と激動の2年をすごし、あらためてフリーソフトウェア開発をしたいという思いを社員間で再確認しました。フリーソフトウェアの開発だけでなく、フリーソフトウェアに関する技術情報やノウハウを積極的に伝えることを社長だけでなく他のメンバーも意識するようになりました。

第6期(2011/7から2012/6)

第5期にgroongaの開発とデジタルサイネージシステムの開発が柱となり、お客様のビジネス拡大にあわせて開発体制を強化しました。また、milter managerの大規模導入案件は長期に渡る開発、テスト期間を経て、無事運用開始しました。Mozilla関連では、他のサポートパートナーとの連携やESR版リリースによって企業導入案件が増加しました。導入やサポートに関連して開発したアドオンをフリーソフトウェアとして公開できるよう契約を見直しました。

主な業務

  • groongaの開発(準委任契約)
  • デジタルサイネージシステムの開発(受託と準委任)
  • milter managerの大規模導入案件
  • Firefox、Thunderbirdのサポート、導入支援
第7期(2012/7から2013/6)

主要取引先との開発案件がすべて準委任契約になりました。クリアコードがお客様の開発チームに対して提供するものを最大化しながら、一緒に開発をすすめていくには、受託よりも準委任という契約形態があっていました。

この時期、新規のお客様からもフリーソフトウェア開発のお話をいただきましたが、一緒に開発するためのリソースが確保できない状況でした。そこでサポートサービスを利用し、設計支援やコードレビュー、障害調査といったサービスを提供して、milter manager、groonga、GStreamerをつかったシステム開発を支援することができました。また、クリアコードの開発スタイルを伝えるサービスとしてコミットへのコメントサービスを開始しました。

主な業務

  • デジタルサイネージシステムの開発
  • groongaの開発
  • milter manager、groonga、GStreamerのサポート
  • Firefox、Thunderbirdのサポート、導入支援
  • サーバ監視ツールの研究開発
  • コミットへのコメントサービス

クリアコードがフリーソフトウェアをビジネスにできた理由

クリアコードがフリーソフトウェアの開発やフリーソフトウェアを使ったシステム開発をビジネスにできたのは、次の2つの要因によるものと考えています。

確度の高い案件からフリーソフトウェアへ貢献できる案件へ

初代社長時代は国の事業が中心でした。また民間企業との取引においてもフリーソフトウェアと関係ない案件も請けていましたし、フリーソフトウェアに関係するものでも本体の開発よりは、システム構築などフリーソフトウェアの導入支援が中心でした。

2代目社長の20代ではmilter managerを開発し、groongaの開発やデジタルサイネージシステムの開発がスタートするなど、現在の事業のベースとなるものが始まりました。しかし契約形態は短期の受託開発がほとんどでしたので、経営を安定させるために、案件が途切れないようにすることを優先していました。そのためフリーソフトウェアとして公開できるできないに関わらず受注確度の高い案件を優先していました。

2代目社長の30代では、フリーソフトウェアへのこだわりを強く打ち出すようになりました。また、主要取引先からクリアコードの開発チームを評価していただき、長期の契約のもと、一緒にフリーソフトウェアやフリーソフトウェアを使ったシステムを開発できるようになりました。その結果、その他の企業との取引でもフリーソフトウェアに貢献できる案件を優先できるようになりました。

フリーソフトウェア活動の広告宣伝効果

クリアコードのはこれまでに数多くの企業と取引をしてきました。一般的に取引先を獲得したいと考えれば、こちらから対象となるお客様に対して営業活動を仕掛けるものですが、クリアコードの場合そのようなコストはほとんどかけていません。もちろんこちらからの働きかけによって取引先を獲得したこともありますが、お客様の多くはフリーソフトウェアに関するなんらかの課題を解決しようと調べた結果、クリアコードを知り、問合せしてきてくれました。

milterであればクリアコードが開発するmilter managerのサイトやククログに関係する情報があり、そこからクリアコードを知って、電話やメールでご相談いただくという具合です。GStreamerやgroonga、Mozillaなどはククログで公開している技術情報がきっかけとなることが多いです。クリアコードのメンバーが業務に関連してフリーソフトウェア開発プロジェクトにパッチを送っていたことを手がかりにお問合せいただいたこともあります。つまりクリアコードはフリーソフトウェアを開発したり、開発に関するノウハウを公開することで、他社から認識され、場合によっては技術力を認めてもらうことができ、取引先獲得につながっています。フリーソフトウェアに関する案件の獲得には、この戦略が実に効果的だったと思います。

まとめ

フリーソフトウェアを開発したりノウハウを公開することが、フリーソフトウェアの開発やサポートを求めるお客様と出会うための有効な手段となりました。真に必要としてくれるお客様と取引できるので、しっかりとしたアウトプットを出すことができれば、信用の獲得と取引の継続につながりました。お客様と長期にわたる取引関係を築くことができたことによって、経営が安定し、より一層フリーソフトウェアに貢献できる案件を優先することができるようになりました。

創業当時にフリーソフトウェアでビジネスしたいと願っていましたが、現在では実現できています。一方で課題もあります。それはフリーソフトウェアを一緒に開発しようと相談していただく新規のお客様にお応えできていないことです。これはエンジニアの不足とエンジニアの育成が間に合っていないことが原因です。インターンシップパッチ採用を通じた採用活動は、この課題を解決するための取り組みです。クリアコードで一緒に開発してみたいという方がいらっしゃいましたら、是非インターンシップやパッチ採用に応募してください。

タグ: 会社
2013-07-24

クリアコードがインターンシップを実施する理由

こんにちは。初代社長の南です。クリアコードでは開発以外のあらゆる業務を担当しています。

はじめに

2013年6月18日にTAMA協会主催のキャリア体験フェア2013が開催されました。このイベントではTAMA地域の学生さんと企業がインターンシップのマッチングを行いました。クリアコードはインターンを受け入れる側の企業として初めて参加しました。クリアコードの他には、IT関連や金融、製造業など幅広い業種の12社が参加していました。学生さんは100名近く参加していたようです。

マッチングでは、クリアコードのインターンシップに興味をもってくれた学生さんに対して、業務内容とインターンシップの概要を説明しました。面談は1回あたり15分で合計5回行ったのですが、参加している学生さんのほとんどが経済学部や文学部といった文系の方*1で、IT業界には興味はあるけれどプログラミングの経験がほとんどない方ばかりでしたので、クリアコードのインターンシップの応募条件を満たす方には出会えませんでした。

そのような状況でしたので、最初2回は業務内容とインターンシップの説明をしましたが、3回目と4回目はなぜクリアコードはインターンシップを行うのかという話、5回目は就職活動の事例紹介として、筆者の就職活動の話やクリアコードで働くまでの経緯を紹介しました。合計5回の面談を通じて、学生さんの反応が良かった*2のはなぜインターンシップを行うのかという話と筆者の就職活動の話でした。

そこで今回は、学生さんがインターンシップ先を検討するときのアドバイスも兼ねて、なぜクリアコードがインターンシップを行うのかを紹介します。

なぜインターンシップを行うのか

インターンシップを実施する企業は、なんらかの目的を達成するためにインターンシップという手段を選んでいることでしょう。クリアコードは、4つの目的を達成するためにインターンシップを実施します。

インターンシップを実施する4つの目的

クリアコードが掲げている目的は次の4つです。クリアコードは、クリアなコードやフリーソフトウェアを大切にしていて、それらにつながった目的になっています。

  • 採用につなげる
    • インターンシップを通じてクリアコードのことを知ってもらい、クリアコードを就職先として考えてもらいたい。クリアコードの開発者は業務としてフリーソフトウェアを開発するので、クリアコードの開発者が増えるとフリーソフトウェアへの貢献につながります。
  • フリーソフトウェア開発者を増やす
    • インターンがインターンシップ終了後もフリーソフトウェア開発を続けるようになってほしい。インターンがフリーソフトウェア開発者になれば、フリーソフトウェアへの貢献につながります。
  • よいコードを書く人を増やす
    • 自分達が出会うコードがきれいであってほしい。インターンがよいコードを書くスキルを身につけ、それを実践するようになれば、クリアなコードが増えます。こうしてクリアなコードをさらに広めていきたいです。
  • 伝える技術を磨く
    • クリアコードが持っているノウハウや技術を効率よく伝える方法を確立したい。インターンから伝え方に対するフィードバックを積極的にもらえれば、よりうまく伝える方法を見つけられそうです。

この4つの目的のうち、1つでも多くの目的を達成できそうな方をインターンに採用したい考えです。

インターンシップに応募する学生さんの目的

クリアコードは前述の通りの目的を達成したいと考えています。一方、クリアコードのインターンに応募する学生さんもインターンシップで達成したい目的があるはずです。インターンシップを通して学生さんが目的を達成できれば、学生さんにとってこのインターンシップはやってよかったといえるでしょう。学生さんにとって有意義なインターンシップになるどうかは、クリアコードのインターンシップの内容が学生さんの目的達成につながるかにかかっています。クリアコードのインターンシップでは、学生さんは次の目的を達成できるでしょう。

  • プログラマーの仕事を体験したい
    • クリアコードのメンバーと一緒にフリーソフトウェアを開発します。クリアコードの場合、フリーソフトウェア開発も業務ですので、プログラマーの仕事を体験することになります。
  • フリーソフトウェア開発に関わりたい
    • インターンシップではフリーソフトウェアを開発します。フリーソフトウェアですので、インターンシップ終了後も開発に関わり続けることができます。
  • よいコードを書けるようになりたい

これらのほかにも、学生さんの目的を教えてもらえればそれをインターンシップを通じて達成できないか検討します。

インターンの選考でお互いの目的を達成できるかどうか面談で確認

このように、インターンシップを実施する企業、インターンシップに応募する学生それぞれに、インターンシップによって達成したい目標があります。そのため、インターンの選考では、インターンシップを通じてお互いの目的を達成できそうであることを確認する必要があります。そこで、クリアコードのインターンシップの面談では、クリアコードの目的と応募者の目的をお互いに説明し、インターンシップを通じて目的を達成できるか確認することにしています。先日の面談でもこのプロセスを通じて、お互いの目的が達成できることを確認しました。

インターンシップ先を検討する際のアドバイス

このようなプロセスがインターンシップを実施する他の企業でも行われているのではないかと想像しています。もちろん、クリアコードのように明示的に行うところもあれば、書類選考や面接を通じて企業側の視点から企業の目的を達成できるかどうかを判断しているところもあるでしょう。これからインターンシップ先を検討される方は、インターンシップを実施する企業の目的を理解し、また自分がインターンシップで達成したい目的を明確にした上で、お互いに目的を達成することができるかどうか確認してみてはいかがでしょうか。自分に適したインターンシップ先かどうかの判断基準になるはずです。

まとめ

クリアコードがインターンシップを実施する目的と、目的が達成できるか確認するために面談をすることを紹介しました。インターンシップ先を検討する際に参考にしていただけるとうれしいです。もちろん、クリアコードのインターンシップを検討するときは、是非お互いの目的を達成できそうか考えてみてください。

また、7月11日につくばインターンシップ・コンソーシアム主催の2013夏休みインターンシップマッチングフェアに参加します。クリアコードのインターンシップに興味のある方は是非お越しください。

*1 筆者も経済学部出身で、普通に文系就職し、新人のころ3年ほど新卒採用に関わっていましたので、文系の学生さんとお話するのはとても懐かくて楽しかったです。

*2 筆者と学生さんが楽しく会話できて、かつ学生さんからよい感想をもらえたという基準です。

2013-06-20

クリアコードの1日

クリアコードがこの「ククログ」というブログを始めたのが2008年5月なので、先月でククログを始めてから5年経ちました。今月から6年目に入ります。実は、ククログでは毎週1本以上記事を公開するという目標を設定しています。何度か公開できない週もありましたが、5年間こつこつと続けてきました。

記事を書くことはそれなりに時間がかかりますが、ふだんあまり意識せずに考えたり実行したりしていることがまとまるというメリットがあります。記事を公開することは知識や便利な情報などを社内・社外と共有する機会ができるというメリットがあります。私達は開発者なので、プログラムを書かずに記事ばかり書いていることには違和感がありますが、たまに書くのであれば十分にメリットがあります。

以前は特定の人だけが記事を書くという傾向がありました。記事を書くことには情報の整理・共有というメリットがあるため、特定の人だけではなく他のメンバーも記事を書くことにしました。記事は、空いた時間をみつけて書くのではなく、あらかじめ書くための時間を確保して書いています。書いた記事は社内Wikiにストックしてあり、毎週その中から選んで公開しています。

この仕組みにより、記事を書く人が特定の人に偏らなくなったため、ククログの記事の内容に幅がでてきました。ただ、ククログでは技術トピックが多めなので、クリアコードでの働き方という観点のものはあまりありませんでした。そこで、今回はクリアコードでの働き方を紹介します。

自己紹介

こんにちは。昨年4月にクリアコードに入社し、オープンソースのカラムストア機能付き全文検索エンジンgroongaMySQLで高速全文検索を行うためのmroongaのリリース、組込み機器向けのサイネージシステムの開発を担当している林です。

プライベートでは、Sylpheedのプラグインをあれこれ作ったりしています。

今回は自身の例をもとに、クリアコードでの働き方について「1ヶ月のふりかえり」の取り組みと、とある1日の様子について紹介します。

1ヶ月のふりかえり

筆者の場合、ひと月ごとに「1ヶ月のふりかえり」という取り組みを実施しています。この「1ヶ月のふりかえり」では主に2つのことを行います。

1つは、その月の業務内容のふりかえりです。もう1つはふりかえりを踏まえた上で、次の1ヶ月の業務内容を決めるということです。

その月の業務内容のふりかえりでは、以下の内容の報告をします。

  • 実施したこと
  • 実施できなかったこと
  • 業務を通じて思ったこと
  • できるようになったこと

報告のあと、次の1ヶ月の業務内容を相談します。

それぞれ順番に説明します。

実施したこと

まず、前回の1ヶ月のふりかえりで合意した業務内容のうち、実施したことについて報告します。業務内容は、前回の1ヶ月のふりかえりで決めた後に急遽変更になることもあります。その場合は、変更された内容について報告します。

実施できなかったこと

次に、前回の1ヶ月のふりかえりで合意した業務内容のうち、その月に実施できなかったことについて報告します。自分で実施すると合意したのにできていない項目です。これは当初の工数見積もりの精度が低く、途中で軌道修正をした場合などが該当します。

業務を通じて思ったこと

実施したことと実施できなかったことを報告するとこの1ヶ月での業務内容が明らかになります。業務内容を踏まえて、業務を通じて思ったことを報告します。場合によっては、業務と直接関係のない会社のことや自分のことで感じた点を伝えたりもします。

できるようになったこと

最後の報告は業務を通じてできるようになったことです。これは技術的なことだったり、仕事の進め方だったりします。

これらの報告のあと、「1ヶ月のふりかえり」に参加した人からコメントをもらいます。

その上で、次の1ヶ月の業務内容を相談します。

次の業務内容の相談

1ヶ月のふりかえりの最後に、次の業務内容の相談をします。

このときは、事前に判断材料となる項目の洗い出しと見積もりをした上で相談します。項目についてはおおまかに以下の3つの分類からリストを用意します。

  • 定期的に作業が必要な項目*1
  • 積み残しのままとなっている作業項目
  • 取り組んでみたい項目

リストアップした個々の項目に対して、見積った工数などをもとに次の1ヶ月の業務内容を相談して決めます。

これをだいたい1時間程度で実施します。

この取り組みをしばらく続けたことにより、(始めたばかりのころと比べて)自分からこれがやりたいという項目がだせるようになってきたり、(相談材料をあれこれだせるようになったことで)1ヶ月のふりかえり自体も短時間で終わるようになるという変化がありました。

とある1日の業務内容

1ヶ月のふりかえりで合意した業務内容をもとに、日々の業務を行っています。

業務の中には、定期的に実施している作業があります。それは毎月肉の日(29日)にオープンソースのカラムストア機能付き全文検索エンジンgroongaMySQLで高速全文検索を行うためのmroongaのリリースを行うというものです*2

リリースに向けた作業自体はおおよそ1週間前から開始していますが、ここではリリース前日を例として紹介します。

  • 10:00頃 までに出社 朝会*3の準備
  • 10:30頃 朝会で昨日の業務と今日の予定を報告
  • 10:45頃 リリース用のソースアーカイブの準備
  • 11:00頃 groongaリリース用パッケージのビルド開始*4
  • 11:00 - リリース時のブログエントリの下書きをビルドの合間に行う
  • 12:00 - 13:00 お昼*5
  • 13:00 - ビルド済みパッケージの確認を随時実施
  • 15:00頃 mroonga リリース用パッケージのビルド開始
  • 16:00頃 リリースアナウンスやドキュメントの見直しをビルドの合間に行う
  • 17:30頃 ビルド済みパッケージのアップロード、リポジトリの更新
  • 18:00頃 Freecodeへのアナウンスの準備*6
  • 19:00頃 コミットへのコメントサービス向けにdairy-report提出
  • 19:00過ぎ あとはリリースアナウンスを翌日に行うだけなので帰宅

ぎりぎりまでリリースアナウンスやドキュメントの手直しをしていたりすることもあります。そのため細かな相違はありますが、毎月の肉の日リリースの前日はおおむねこうした進行となっています。

まとめ

昨年4月に入社した筆者の例をもとに、クリアコードでの働き方について紹介しました。より具体的にイメージしてもらえるように、1ヶ月の業務内容の決め方と、とある1日の業務の流れについて触れました。

実のところ1ヶ月のふりかえりという仕組みを実施しているのは筆者だけです。その人に合ったやりかたを模索するなかで、筆者の場合は1ヶ月のふりかえりという仕組みに(今のところ)落ち着きました。

クリアコードでは一緒に働く開発者を募集しています。昨年6月からパッチ採用という新しい取り組みを始めました。また、今年2月からインターンの募集も再開しました。インターンシップのテーマとしては以下を用意しています。

働く環境としてのクリアコード(福利厚生編)という記事もありますので、興味が出てきた人は参考にしてみてください。

今回は、どんな風に働いているかということに焦点を絞って記事にしてみました。「これでどうやってお金をもうけてるんだろう?」という疑問を持たれたかもしれません。クリアコードが会社としてどうやってお金を稼いでいるかについては、機会があれば別記事で紹介します。

*1 毎月肉の日のリリース作業が該当します。

*2 リリース作業は見習いから始めて、3回目のリリースあたりでようやく全部自分で一通りできるようになりました。

*3 クリアコードでは全員が出席する朝会を実施しています。

*4 wheezy, testing, unstable, lucid, precise, quantal, raringなどDebian系だけでもこれだけビルドします。これに加えてCentOSやFedora、Windowsのバイナリもビルドしています。

*5 クリアコードの近所にある「向日葵」でお弁当を購入します。

*6 参考:groonga 3.0.4のアナウンス

タグ: 会社
2013-06-10

働く環境としてのクリアコード(福利厚生編)

はじめに

クリアコードでは一緒に働くプログラマーを募集しています。昨年6月からパッチ採用という採用方法にしましたが、それ以来、採用へのお問合せがほとんどなくなりました。今年2月からインターンの募集を開始しましたが、まだお問合せがありません。しかし、採用やインターンシップページヘのアクセスは増加しています。採用ページを見た方がクリアコードは何か特別なスキルを要求しているように感じたり、パッチ採用のプロセスは時間や労力がかかりそうだがそれだけのコストを払う価値があるか判断できない、あるいはそもそも応募するかどうか判断するための情報が不足していることが原因ではないかと仮説をたてました。

実際、パッチ採用を開始する前の去年4月に入社した社員に聞いてみると、「いやあ、パッチ採用してなくても応募するのは敷居が高かったですよ。踏ん切りつけるのに1ヶ月ぐらいかかりました。面接して次はペアプログラミングと言われたときは結構プレッシャーかかりましたよ。もしパッチ採用をその時にやっていたら、ああ、求められているものが高いんだなあ、自分では無理だろうなと、諦めて応募しなかったかもしれません。」と言っています。なお、その社員は普通にクリアコードで活躍しているので、やはり応募者にとって必要な情報を提供できていなかったといえます。

クリアコードでは、ククログやRuby会議での発表などを通じて、主に開発に関する情報を発信してきました。一方でクリアコードにはどんな人が働いているのか、またどのようなワークスタイルなのかといった情報はこれまであまりお伝えする機会がありませんでした。そこで今後はこのような情報をククログを通じて発信したり、関心を持っていただいた方との交流の機会を多く設けてクリアコードのことを伝えていきます。

今回は、働く環境としてクリアコードはどんなところなのか福利厚生の面からご紹介します。

社員の健康

クリアコードでは「健全なコードを書くためにも健康であるべき」という考えのもと、社員の健康をとても大事にしています。健康を維持するためには社員の自己管理が大切です。会社としても社員の健康管理を支援する目的で、残業をなくして休暇を取りやすくし、健康診断を通じた健康管理を行っています。

フレックスタイム制で残業はほとんどなし

一般的に裁量労働制によって社員が働きやすくなるケースもありますが、クリアコードでは労働時間を管理して、残業や休日出勤が発生しないようにしています。フレックスタイム制を採用しており、コアタイムは10時から15時です。そのため、社員は遅くとも10時には出社します。10時に出社した場合、終業は19時となります。20時を過ぎて会社にいることはほとんどありません。夕方から予定がある場合などは、朝7時に出社して16時に退社することもあります。最近では遅刻はほとんどなくなり、残業は月平均で3時間程度です。

年1回の健康診断で健康状態を把握

年1回すべての社員が健康診断を受診します。一昨年からはアルバイトも健康診断を受診しています。希望すれば会社の全額負担で人間ドックを受けることもでき、今年は全員で人間ドックを受診します。クリアコードに就職して健康診断の結果が毎年改善されるケースはよく見受けられます。

完全週休2日制、各種休暇制度も完備

土日は必ず休みとなる完全週休2日制です。有給休暇は入社後6ヶ月で10日、その後1年毎に法定通りに有給休暇を付与します。有給休暇の消化率は50%程度であまり高いとは言えませんが、申し出をすればほぼ希望通りに有給休暇を取れます。有給休暇の半日取得も可能です。休暇を取りづらい雰囲気も特にありません。夏季休暇は有給休暇とは別に特別休暇として3日あり、毎年全員が取っています。その他結婚、出産時の慶弔休暇もあります。昨年1月から12月の年間休日数の平均は132日です。なお、休暇中に仕事の連絡があることはまずありません。事前にお客様に通知したり、他の担当者がカバーできる体制を用意しています。

就業場所

ほとんどの仕事が持ち帰りの案件です。客先常駐で作業を行うことはありません。以前は特定労働者派遣事業の届出をしていましたが、昨年10月をもって廃止しました。現在は全員がオフィスに出社して業務を行っています。これは、場を同じにすることで、状況を共有したり、気軽に相談できたり、思いがけない情報にであったりするメリットがあるからです。そのため、お客様と一緒に開発するような案件では、お客様と打合せしたり、一緒に開発するために週1回など定期的にお互いのオフィスを行き来しています。

肉の会と社員旅行で親睦を図る

毎月29日あたりに肉の会と称して、社員全員参加の飲み会を実施しています。29日のリリースを祝い労うことが目的です。一緒に開発している取引先の開発者や社員がフリーソフトウェア活動を通じて出会った方をゲストとしてお招きすることもあります。

また、毎年社員旅行に出かけています。毎回貸別荘を借りて自炊し、同じ釜の飯を喰らうことで結束力を高めています。今年は2泊3日で房総半島に行く予定です。肉の会、社員旅行とも費用は会社が負担しています。

まとめ

クリアコードに入るとどんな働き方になるのか、福利厚生の面から、社員の健康管理、残業、休暇、就業場所、社内のイベントについて紹介しました。この他にも社宅退職金についての制度もありますので、是非参考にしてください。

タグ: 会社
2013-05-16

クリアコードのサポートサービス

クリアコードでは、Mozilla製品、milter manager、groonga、GStreamer、WebKitといったフリーソフトウェアのサポートサービスを提供しています。サポートの対象となるフリーソフトウェアについて、クリアコードで対応できるものは、できる限りサポートサービスの枠組みの中で対応しています。今回はクリアコードのサポート契約の特徴や障害調査における作業の進め方を紹介します。

サポート契約について

まず、クリアコードが提供するサポート契約の特徴を説明します。

価格設定について

クリアコードのサポート契約は、1つの問い合わせへの対応がいくらという契約ではありません。問い合わせに対する作業時間1時間あたりいくらという契約になっています。そのため、問い合わせへ回答するために要した時間が少ないほどお客様にとっては価値があがります。つまり、自分たちのためだけでなく、お客様のためにも効率的に調査、回答することが求められています。

以下は該当の契約条項です。

クリアコードがお客様に提供する本サービスは、本契約末尾に定めるインシデント数の範囲に限られるものとします。

・・・

消費するインシデント数は1時間あたり1インシデントとして、対応に要した時間から算出し、当事者間で確認するものとします。

作業時間について

クリアコードが独断で作業時間を使いすぎてしまわないように、契約書上で作業時間の上限を定めています。ほとんどの場合、クリアコードの判断で使用できる作業時間は4時間としています。4時間を超える場合はお客様が実施するかどうか判断することになります。調査回答にどれだけの時間をかけるのかはお客様が決定するので、クリアコードはそのための判断材料を適切に提供します。

以下は該当の契約条項です。

1件あたりの対応時間が4時間を超えることが見込まれる場合、クリアコードはお客様に対応時間の見積を連絡します。お客様は内容を確認し実施するかどうかをクリアコードに通知するものとします。

回答までの期間について

問い合わせへの回答は早いほうがよいため、速く回答することを心がけています。契約上では「受付日の翌営業日から起算して3営業日以内に回答する」としていることが多いです。月曜日に受け付けたら、遅くとも木曜日の17:00までに回答します。ここでいう回答とは原因の究明が完了し、その内容を説明するものとは限りません。お客様と合意した作業時間に到達したが原因が究明できていない場合は、その状況を報告することも回答となります。

以下、該当の契約条項です。

クリアコードはお客様から問合せを受け付けた場合、受付日の翌営業日中に回答期限を連絡するものとします。回答期限は受付日の翌営業日を起算日として3営業日以内とします。ただし、複数の問合せを一度に受け付けた場合や、回答までに4時間を超えて作業が必要な場合はこの限りではありません。

障害調査の作業指針

障害調査の進め方は以下のククログ記事が具体的な事例です。

ここでは特に大切にしている作業指針を紹介します。

ゴールを設定し意識する

調査するときは、まず、知りたいこと(得たい結果)をゴールに設定します。次に、ゴールに対して必要な手段を考えるようにします。手段を決めたらゴールを忘れないように作業を進めます。はじめに手段を決めて、そこから得られる結果を考えずに作業を進めてしまうことがないように注意しています。

問題を絞り込む

問題がありそうなところを計画性なくしらみつぶしにあたっていく方法は、効率的とは言えません。それよりも、二分探索のように問題範囲を絞り込んでいく方が効率的です。

問題があるところを絞り込むとき、「問題があるところを確認する」ことだけにとらわれてはいけません。「問題がないことを確認する」ことでも問題があるところを絞り込めます。例えば、1から10までの処理があり、1から5の処理に問題がないことわかれば、6から10が問題があると絞り込めています。

「問題があるところを確認する」ことだけにとらわれることを防ぐために、作業を進めるごとにチケットにやったことと結果を記載し、そのつど状況を整理する方法が有効です。

回答の書き方

回答はお客様が判断するための重要な材料です。問題箇所が特定されれば問題を回避する策を検討します。問題が特定できていなければ、調査方針が正しいかどうか、継続して調査するかどうか判断します。そのため、回答には以下の事項をもれなく記載します。

  • 調査の目的(ゴール)
  • 調査結果(調査からわかったこと、まだわかっていないこと。)
  • 調査に要した時間
  • 対策案もしくは今後の作業方針(ひとつ以上、できる限り複数)。案には以下を含める。
    • やることと結果(効果)
    • メリット/デメリット
    • 作業工数(明確に時間を算出できない場合は他の案に比べて多い少ないでよい。)
    • 作業期間(工数によって完了時期が異なる。)
  • おすすめの案とその理由。

対応のフロー

上記を踏まえた問い合わせ受付から回答、調査の継続までのフローは以下の通りです。

問い合わせの受付

問い合わせはメールで受け付けます。問い合わせのメールが届いたら、社内のRedmineにチケットを作成します。チケットの期日は受付日の翌営業日から起算して3営業日後となります。

問い合わせ内容の確認

メールの中身を確認し、ゴールをチケットに書きます。明らかに調査にかかる時間が4時間を超えると判断できる場合は、調査を実施するかどうかの判断をお客様に確認します。

例えば、問題を再現させる環境を用意するのに6時間かかり、その上で調査に更に4時間かかることが見込まれるとします。この場合は、「合計10時間は必要だが実施してよいか」ということを確認します。

調査

ゴールを確認し、意識して調査をすすめます。調査の過程は、随時チケットに記録します。作業途中であっても、回答作成を含めると4時間に到達することが明らかとなった場合は、調査を中断し回答作成に着手します。

回答

回答の書き方に沿って回答文を作成します。調査を継続するかどうか、どの案を実施するかどうかなどお客様の判断が必要になる場合は、それを明記します。回答はチケットにも記載します。

調査の継続

お客様と約束した4時間を超えて調査するかどうか判断を仰ぎ、お客様から調査実施の指示があった場合は、チケットの期日を更新し、作業を進めます。この時もお客様と合意した作業時間(回答に記載した工数)を遵守します。

最後に

クリアコードでは、ゴールを意識して作業に取り組むよう心掛けています。ゴールを意識せず、単に「やりやすいから」、「手段を知っているから」という理由で作業に取り組むと、効率的に作業を進められません。クリアコードのサポートサービスでは、非効率な作業はお客様の損失に直接つながります。これは、作業時間が増えればそれだけお客様との契約時間を消費してしまうからです。

例えば、障害調査で原因の目星がついていないケースでは、「ゴールを意識して作業に取り組むこと」を徹底しないと路頭に迷います。

フリーソフトウェアであればソースコードを確認できるため、このようなやり方を実践することができます。そして、このやり方を徹底するとよく知らないソフトウェアであってもサポートできます。よく知らないソフトウェアで問題が発生し、その調査をすることになった場合は試してみてください。

クリアコードのサポートサービスをご検討される際は、お問い合わせフォームからご連絡ください。

タグ: 会社
2013-02-14

タグ:
年・日ごとに見る
2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|