2012年8月24日に開催した第6回定時株主総会において、新任取締役が一名選任され、9/1付けで就任することとなりました。以下、新任取締役からの挨拶です。
この度、新しく取締役に就任致しました、足永拓郎です。
私は10数年ほど前、自由ソフトウェアによるデスクトップ環境が非技術者にも便利に使える日が来ることを夢見て、自由ソフトウェアの開発活動を開始しました。
最初は、単なる趣味の一つとしての活動でした。 しかしながら、片手間で行うような活動では、できることに限りがあります。 私は、自由ソフトウェアの開発活動を継続していくためには、以下のことが必要だと強く思うようになりました。
6年前、クリアコードの設立に関わったのは、そのような経緯からです。
クリアコードという社名の名付け親は現在の代表取締役である須藤ですが、その考案の際、「社名に『コード』を入れよう」と発案したのは私です。
そこに込めた思いは、以下のようなものでした。
我々は、自由ソフトウェアをただ利用するだけの企業ではありたくない。
自由ソフトウェアのコードを読んで、理解し、改善し、そしてまた新たな自由ソフトウェアを生み出していく企業でありたい。
あれから6年。
現在のクリアコードにそれが実現出来ているか?と言うと、もちろんできている面もあります。 一方で、ミイラ取りがミイラになってしまっている一面があることも否定はできません。このような現実を受け止めることは勇気がいります。 しかし、現実を直視しなければ、新たな一歩を踏み出すことはできません。
私は、取締役就任に当たり、初心に返り、
クリアコードは自由ソフトウェアの開発で社会に貢献する企業である
という目標に再度立ち向かっていきたいと考えております。
皆様方のあたたかいご理解・ご協力を心からお願い申し上げます。
短期前払費用というものによって節税する方法があります。先日、クリアコードのサービスがそれに該当するのかという問い合わせがありました*1。そこで短期前払費用とは何か調べてみましたので紹介します。
短期前払費用による節税とは、1年以内の短期前払費用については、収益との厳密な期間対応による繰延経理をすることなく、その支払時点で損金算入を認めるというものです。これは企業会計上の重要性の原則に基づく経理処理を税務上も認めるということです。
つまり、短期前払費用は条件を満たせば、支払時点で損金算入できるので、利益が減り節税になります。
短期前払費用を支払時点で損金算入するには以下の要件を満たす必要があるようです。
等量等質のサービスがその契約期間中継続的に提供されなければなりません。
例:土地建物の賃貸借、工業所有権その他の権利の資料、金銭の借入
前払費用≠前払金
前払費用は、役務すなわちサービスの提供に対する対価の前払いであるから、物の購入とか生産に対する対価の前払いである前渡金、手付金などはこれに該当しません。
収益の計上と対応させる必要があるものについては適用されません。
短期前払費用の要件についてその理解を深めるため、短期前払費用として認められるものと認められないものについて具体例を調べます。
国税庁の質疑応答事例に具体例があります。
このうち、事例1から4はOK、事例5はNGとなります。
札幌・税理士の 税理士 溝江諭 KSC会計事務所 札幌 -お知らせ-によると、みえみえの税金対策で、金額が税前利益に対してあまりに多い場合、重要性が高いと見做され、否認されることがあるようです。
では、どのような費用が等質等量で時の経過に応じて費用化するものとされるのでしょうか。
費用化しないものは以下のようなものです。
費用化するものは以下のようなものです。
クリアコードのサービスで短期前払費用として処理できるものがあるか検討してみます。
収益の計上と対応させる必要がないことが要件となるので、ユーザ企業で社内利用する何かに対するサービスとなります。 Mozilla FirefoxやThunderbirdのサポートサービスならユーザ企業内で利用するものなのでよさそうです。
ではサービスの中身が等質等量で時の経過に応じて費用化するかどうかですが、これは満たせそうにありません。
クリアコードのサポートサービスはログを解析したりパッチを開発したりとサービスの提供方法は様々で、サービスの提供量も問合せ内容や、問合せの数によって変化します。そのため、税理士費用と同じく等質等量とはいえないでしょう。
よって、いまのところクリアコードには短期前払費用として処理できそうなサービスはなさそうです。
クリアコードのサービスが短期前払費用の要件を満たすかどうか調べることが目的でしたが、自社で経費を短期前払費用として処理する際にも使えそうです。以下の要件を確認して正しく経理処理したいものです。
*1 消費税増税法案が可決されたことから、今後、費用を前払いしたいという話が増えるかもしれません。
2012年9月14日から9月16日の3日間にわたり札幌Ruby会議2012が開催されました。
3日間の開催、マルチトラック、国際化*1など日本Ruby会議のような地域Ruby会議でした。そんな札幌Ruby会議2012で「バグの直し方」と「クリアなコードの作り方」の話をしてきました。それらについてそれぞれ発表者本人が紹介します。
3日目の午後にあった沖元の発表です。
発表本番では、デモ中にRubyのビルドに失敗したため満足にデモができませんでした。そのため、デモでやる予定だったことをスライドに追加しています。
実行委員の気遣いが素晴しかったと思います。9月の北海道にしては気温の高い日々でしたが、実行委員の人たちのおかげで非常に快適にセッションに参加することができました。
スピーカーはみんなコードを書くのが好きな人たちばかりで、まさに「We Code.」のテーマにピッタリのトークばかりでした。たこ焼き仮面こと@tenderloveの日本語が来日するたびに上達していて今回はとうとう日本語でキーノートをしていました。
私もいつか海外のカンファレンスで英語の発表ができるようになりたいと思います。
最後のセッションだった須藤の発表です。
タイトルだけ見ると「クリアなコードを作るためのテクニックを教えます!」のように見えるかもしれませんが、実際は「知ったテクニックを活かしてクリアなコードを作り、維持する方法を教えます!」という内容です。つまり、テクニックを知った後の話です。誤解される可能性があるあまりよくないタイトルでした。
内容は「We Code.」そのもの、つまり、「みんなコードを書こう!」です。札幌Ruby会議2012ではどのようにコードを書けばよいか(「How to code」)や、自分はこう書いていると言った話がたくさんあり、「自分もコードを書きたい!」という思いが強くなったのではないでしょうか。この発表は、そんなこの会議で得たテクニックや「書きたい!」という気持ちを頭や心の中で終わらせるのではなく、実際にそれを活かしてコードを書いていきましょうということを伝えようとしたものでした。「We Code.」の「Code」は「コード」という名詞ではなく、「コードを書く」という動詞なんです。「コード」について知るだけで終わるのではなく、それを活かして「コードを書く」のです。そして、この会議に参加した私達が(「We」!)「コードを書く」ことで、会議に参加していない人たちにも会議で得た知識や思いを伝えて、さらに「We」を広げていきましょう。この話を聞いてくれた人たちが、「We Code.」(「私達がコードを書く!」)という札幌Ruby会議2012で掲げられたすばらしいテーマを思い出して帰ってもらえたなら、最後のセッションの役割は果たせたのではないでしょうか。
話の大筋はスライドでもわかるでしょうが、実際の発表内容までは伝わらないでしょう。ここで補足しますが、時間に余裕のある人はUstreamの録画も参考にしてください。3:00くらいから始まります。
まず、この発表の大事な言葉である「クリアなコード」について説明します。発表中でも触れていますが、「clear」という形容詞がついた「コード」のこと*2です。「clear」には「はっきりした」とか「明快な」というような意味があります。つまり、あるべきものがあるべき場所にあるべきように書かれているようなコードです。そのようなコードは、最初からそのように書かれることが当然のような自然なコードに思えます。そのようなコードはするっと読めて、すっと理解できてしまいます。そんな「自然なコード」をクリアなコードと呼んでいます。
それでは、どうしてクリアなコードを書いた方がよいのでしょうか。それはたのしく開発を続けるためです。
録画を視るとわかりますが、発表者だけではなく、札幌Ruby会議2012の参加者の多くもプログラミングが好きです。プログラミングが好きであれば、プログラムを書くことは基本的に楽しいことです。しかし、プログラミングが好きでもプログラムを書きたくないと思ってしまうときがあります。その1つが、開発が進むにつれてコードが汚くなっていくときです。汚くしてしまうのは開発仲間かもしれませんし、自分自身かもしれません。開発チームの誰か1人でも汚くしていく人がいると、楽しいはずのプログラミングが楽しくなくなってしまいます。そうなってしまっては開発を続けていけません。そうならないようにみんなでクリアなコードを書いていきたいのです。つまり「We Code.」です。もう少し言うと「We Code Clear Code.」です。みんなでクリアなコードを書きましょう。だって、そっちの方が楽しくプログラムを書けますからね。
もし、あなたがプログラミングが楽しかったことを忘れているなら、クリアなコードを書けば楽しかった頃を思い出せるかもしれません。新しい機能を追加しようとしたときに、パパッと実現できたら楽しいですよ。クリアなコードになっているとそういうことがしやすくなっているはずです。
クリアなコードの作り方はリーダブルコードの解説をベースにして説明しました。なお、この発表の内容はリーダブルコードの「解説」にだけ触れていて、リーダブルコードの「本文」には触れていません。なので、この発表の内容だけからはリーダブルコードに書いている内容はわかりません。リーダブルコードの「本文」と「解説」は、前述の「誤解されやすそうな発表タイトルだったね」というところと同じような関係になっています。「本文」には「テクニック」が書いていて、「解説」には「テクニックの活かし方」が書いてあります。もし、「解説」や発表内容に興味がでてきたら、リーダブルコードを購入して「本文」も読んでみてください。そこには「解説」や発表内容で言っていることを実現するために必要となる「テクニック」が書かれています。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
オライリージャパン
¥ 2,592
ところで、リーダブルなコードとクリアなコードはどう違うのでしょうか*3?どちらも同じところを目指しています。リーダブルなコードは「読みやすいコード」で、そのために読み手が「理解しやすい(easy to understand)」コードを書こうとします。クリアなコードは「明快なコード」で、そのようなコードは読み手がすぐに理解できます。どちらも理解しやすいコードです。
自分でもまだクリアな*4答えが見つかっていませんが、「リーダブル」は読み手の方だけを意識して、「クリア」は読み手も書き手もどちらも意識しているような気がします。読み手にとっても書き手にとっても、誰が見ても自然なコードがクリアなコードと使っている気がします。いつか、クリアな答えが見つかったら報告します。
クリアなコードを作るためステップは以下の3ステップです。
まず、クリアなコードを書くためのテクニックを実際に使ってコードを書くことです。リーダブルコードの本文に書かれていることも使えます。ここで大事なことは自分が実際に動くことです。本を読んで満足してそれで終わり、勉強会に参加してそれで終わり、ではなく、自分が得た知識やテクニックを実践することが大事です。この段階はまだ「We Code.」ではなく「I Code.」です。
実践して自分のものになったら、今度は自分のチームに広げます。当たり前に実践するのが自分だけではなく、チームみんなが当たり前にします。クリアなコードが当たり前な文化にするのです。そのためには、自分がちゃんとクリアなコードを書き続けるだけではなく、他のメンバーが書くコードをすべて読みます。読んで、よい書き方を見つけたら参考にしますし、そうじゃないコードを見つけたら一緒に改善方法を考えます。前のステップであなたがちゃんとクリアなコードを書くということを実践していたなら、他のメンバーはあなたの話を聞いてくれるでしょう。そして、少しずつクリアなコードが当たり前な文化になっていくでしょう。「We Code Clear Code.」
しばらくすると自分のチームに新しいメンバーが入ってくることでしょう。そのときが最後のステップです。新しいメンバーはまだクリアなコードが当たり前という文化に馴染んでいません。そんな新しいメンバーにはクリアなコードはこう書くんだということをあなたがクリアなコードを書くことで伝えます。あなたはプログラマーです。コードを書くことで大事なことを伝えましょう。プログラミングが好きなあなたにはそれができるはずです。コードを書いて「We」を増やしましょう。
よいプログラマへの道を歩き出したのなら、ともにその道を歩くものだと思っています。
育ててあげるという考え方はやめることにしました。
We Code. みんなでコードを書いていきましょう。
録画の最後のところでも言っていますが、発表では「コードで伝える」と言っておきながら実際はコード無しで言葉だけで伝えていた発表でした。もし、また機会があれば言葉だけではなく、コードでも伝えたいです。
セッションではしだらさんのセッションがよかったです。いいチームだなぁと思います。
1セッション30分というのは長すぎず短すぎずちょうどよいと感じました。
ぬRubyKaigiもよかったです。まさか、札幌でRabbitの集まりを持てるとは!嬉しいことです。
セッション以外のところでうれしいことがありました。久しぶりに会った何人かに「こういうときはどうするのがいいですかねぇ。」と相談してもらえたことです。これはセッションとは関係なく、ロビーや移動中に会ったときのことです。「コードレビューすれば細かいところはよくなっていくけど、全体の設計が変な方向に向かっていることは気づきづらいですよねぇ。」、「テストなしでpull requestしちゃっていいものですかねぇ。」、「いろんなソフトウェアを開発し続けるのは大変ですよねぇ。」といったことです。話を聞いて、自分はこう思うということは伝えました。もし、少しでも何かの役に立てたのなら札幌にきてよかったなぁと思います。
しまださんについて。札幌Ruby会議はしまださんの手を離れたんだなぁと感じました。これは、しまださんが札幌Ruby会議を捨てたということではなく、次の人たちに渡せたということです。もともと札幌のみなさんはすばらしいチームで、しまださんだけが頑張っていたというわけではないのですが、しまださんが中心にも前面にもいたように感じていました。しかし、今回の札幌Ruby会議はそっと後ろからサポートするようにしまださんがいたように感じました*5。毎年、しまださんの発表者紹介を楽しみにしていましたが、今年はこれがありませんでした。マルチトラックになったのでそもそも実現できないのですが、これまでとは変わったなぁと思ったことでした。
もちろん、札幌は相変わらずの心地よさでした。常に水が配布されていたり、電源を確保できたり、他の参加者と話をするスペースがあったりと会議中に困ったことはありませんでした。すばらしいチームですね*6。
クリアコードからは、須藤と沖元の二人がスピーカーとして参加し、発表してきました。また、会社としてもプラチナスポンサーとして札幌Ruby会議2012を支援しました。札幌Ruby会議2012実行委員のみなさま、参加者のみなさま、ありがとうございました!!
またどこかのRuby会議で会えたらいいですね!!
*1 日本語だけではなく英語でも情報提供をしたり、発表言語として英語も使えたり、IRC上でセッションの内容を翻訳したりしていました。セッションの内容が日本語なら英語に翻訳し、英語なら日本語に翻訳していました。
*2 動詞ではなく形容詞として「clear」を使っています。
*3 札幌Ruby会議2012の次の日に聞かれました。
*4 :-)
*5 会議中、ずっと疲れた顔をしていたのでそもそも前面に立てなかったのかもしれません。
*6 でも、疲れていそうで心配になりました。
札幌Ruby会議2012のチケットを譲るキャンペーンに当選したみなさんのレポートを紹介します。
ハードリカーエンジニア 札幌Ruby会議2012に行ってきました #sprk2012
都合が悪く初日は参加できなかったとのことですが、いろいろ得たものがあったようです。よかったです。
このご恩はコミュニティーへの貢献と良いコードでのお返しをしていきたいと思います。
先ずは東京Ruby会議10のLTに応募します。
実際に行動を始めていてすばらしいです。
札幌Ruby会議2012にいってきた! - Vestige is fragments of memory
須藤さんの発表は何度か聞いてますが、毎回、なにかやらなきゃって気持ちにさせてくれる。
ぜひ、なにかやりはじめてください!
わからないと言っているといつまでもわからないままなので少しでもコードを書こうと思い、dRubyやSmalltalkのハンズオンに参加しました。また、Lindaさんやyokoさん、万葉の方々にRails Girlsについてのお話を伺ったりして、自分なりに色々なことを吸収できたように思います。
ほとんどコードを書いたことがないというさとこさんですが、コードを書くハンズオンに積極的に参加していたそうです。会期中から積極的に行動し始めていてすばらしいです。
最後の講演の後、ClearCodeの 須藤さんとお話ししたときに、
「コードを書いたことない私がチケット頂いちゃってよかったんですか?」
と言ったら
「コードで返してくれればいいです!」
と言われ、すごく嬉しかったと同時に身が引き締まる思いでした。
楽しみにしています!
みなさん、札幌Ruby会議2012で何かを得て、そして実際に行動を始めていたようです。キャンペーンを実施してよかったです。