Latest topics 近況報告

セクハラを「軽い気持ちでやってしまう」人、の考える事：自分の場合の振り返り - Jun 28, 2018

このエントリは、女性エンジニアの権利を守りましょうとか差別よくないよねとかの社会に対する語りかけとは本質的には関係無い、個人的な述懐です。

女性エンジニアの差別やハラスメントの話と、それをきっかけに考えた差別やハラスメントそのものの話と、立て続けにクッソ長文を書いてしまったのですが、自分でもちょっとどうしたのと思う部分はあります。

「自分がやってる事まで一緒くたにされると困る」「下手したらこっちにまでとばっちり来そうだから先に釘刺しておきたい」みたいな自己保身、予防線というのも動機の一つではあったのですが（その割に、「シス管系女子なんてタイトルの物を作ってる奴がどの口で言うんだ」みたいな明らかに文章を読んでない反応もあったので、藪蛇にしかならなかったのかもしれませんが）、やっぱり最大の動機は、過去の自分を恥じる気持ちが強いからなんだと思います。

自分が言及した記事の反応（の一部）や僕の書いたエントリへの反応（の一部）なんかも、見てるとほんと辛いんですよね。憤慨してる人がいる一方で、何が悪かったのか全く分からないという人がかなりいて、それが過去の自分にものすごくそっくりに思えて。なので、「過去こういう中の一人だった自分だからこそ、こういう人達に届く表現ができるのではないだろうか？」と思って、色々な言葉でなんとか表現してみようとしたのでした。結果はお粗末でしたが。

続きを表示する ...

差別性・ハラスメント性は「どこかの極悪人」だけの物じゃなく皆が持つ物なんだよという話 - Jun 24, 2018

1つ前の女性エンジニアうんぬんの話のエントリの反応を見ていて、「これは差別だ」「これは差別ではない」という軸での対立が見られる事に気がつきました。

そもそも僕が書いたエントリ自体もざっくり言えば「これは差別だ」派に属しているわけですが、それに対して「これは差別ではない」派の方からの言及があり、その対立軸を自分自身がよりはっきりと意識する機会になりました。

1. Y社のエンジニア炎上について思ったこと -「女性エンジニア少ない問題：元増田
2. Y社のエンジニア炎上について思ったこと 続き：僕の1つ前のエントリへの言及
3. それへの僕のコメント
4. 僕のコメントへの返信

このやり取りを見ると、僕が長文で書いた事の諸々のうち大筋では「これはよいこと」「これはよくないこと」という認識が双方で共有されているものの、「元発言が差別か否か」という点で決定的に認識が対立しているようである事が読み取れます。

自分としては、「こういう点で問題があるから避けよう」「こういう理由で問題無いからこのままやろう」という線引きが明らかになる事で、同様の「やらかし」が世の中から少しでも減りつつ、「なんか炎上しそうだから……」という漠然とした不安からの萎縮も減ってくれる事が望みなので、敢えてこれ以上の事を続ける必要も無いかなとも思うのですが、その一方で、肯定派と否定派の対立が一点に集約されるのも興味深い話だと思ったので、自分の思う所を改めて記しておこうと思います。

あと、自分はこれを「差別」と「ハラスメント」の両方にまたがる話と捉えており、両者は同じ物事の異なる面であって不可分と考えているので、このエントリでは「差別」と「ハラスメント」をワンセットで取り扱う事にします。

続きを表示する ...

女性エンジニア少ない問題を解決する話、の何が問題なのか - Jun 22, 2018

自分の観測範囲で「女性エンジニア少ない問題」を解決するために、機械学習で男性エンジニアを女性に変換する - ログミーTech（テック）という記事が話題になっていたので見たら「ｱﾁｬｰ……」としか言いようがなかった。

概要を説明すると、技術職の男性の発表で「職場に女性がいないとやる気が出ない」「女性エンジニア増やしたい（※文脈的にはITエンジニアという意味のようでしたが、ITに限らず言える事のようなので、以下の文でもそのまま単に「エンジニア」と表記します）」「本物の女性エンジニアを増やすのは人材育成のコストがかかる」「なので機械学習で声質変換を実現した。男の声で喋った内容に対応する女声の音声を出力する仕組みを作った。」という話です。技術的には多分大したことなんだと思う（自分は機械学習には詳しくないのでよく分かってない）けど、その発表の「掴み」のための話が技術の良さを台無しにしていると思いました。

これに対して、自分の観測範囲では「懲戒処分ものだ」とか「この程度で過剰反応しすぎ」とか色々な反応が見られましたが、賛否どちらにしても「何が問題なのか」という点がきっちり共有されていない印象を受けたので、その点にフォーカスして覚書を残しておきたいと思います。「なんかよくわからんけど、この辺の話題は怖いから触れんようにしとこ……」みたいに腫れ物扱いして萎縮してしまわないで済むよう、こういう根拠でこう言えるからこれは改めようとか、こういう根拠でこう説明できるからこれはそのままでいいとかの、明確な判断をするための材料の一つとして読んでもらえたら幸いです。

　

最初に明記しておきたいのですが、僕はこの発表を行った彼個人をやり玉に挙げて個人的な責任を問うべきとは思っていません。詳しくは後述しますが、これを通過させたチェック体制の方だったり、社風だったり、あるいは社会の風潮だったり、そういう事の方にずっと重い責任があると思っています。（そして、彼の所属組織にもイベントの主催団体にもメディアにも自分は全く関係ありませんが、別の所でその責任の一端を自分も負っている、と思っています。）

（28日追記）また、この件を非難している人は必ずしもジョークを解していない訳ではないという事も、本題に入る前に明記しておきます。恐らく発言者の彼にとっては「女性エンジニア云々は技術の本題に入る前のただの枕のジョーク」という認識だったと思いますし、擁護している方も「ただのジョークじゃないか」と思っている様子が窺えますが、批判している人の多くはこれを「悪質なジョーク」として批判しているのだという事は、最初に押さえておくべきポイントです。

続きを表示する ...

Qiitaで許容される内容の不明点 - May 15, 2017

Qiitaのコミュニティガイドラインについての発表で参照されているコミュニティガイドラインが何度読んでも肝心の自分の知りたい点について書かれていなくて不安をぬぐえずにいたんだけど、1週間近く経っても特にフォローアップがなされていないようだったので、Twitterで愚痴ってないでちゃんと直接聞いた方がいいかなと思ってお問い合わせフォームから以下の質問を送ってみました。同様の質問が殺到しているようだったら申し訳ない限りです。

---

http://help.qiita.com/ja/articles/qiita-community-guideline
こちらのガイドラインにおいてQiitaに投稿する事が認められるのは「プログラミングに関する」記事であると限定されていますが、この範囲をもう少し詳しくご説明いただく事は可能でしょうか？
具体的には、自分は以下のような内容が許容されるのかどうかが気になっております。

• プログラミング行為を伴わない、Ansible等のサーバー構成管理ツールの使い方やノウハウ
• プログラミング行為を伴わない、Linuxサーバー上でのApacheやOpenSSH（sshd）といったサービスの設定のノウハウ
• プログラミング行為を伴わない、MarkdownからPDFへのPandocを用いた変換処理のノウハウ
• 一般にプログラミング言語とは見なされにくい言語、例えばシェルスクリプトの書き方やノウハウ

一般に「プログラミング」は設計・コーディングなどの開発行為までを指し、その成果物の実行や実行に必要な環境の整備、運用行為は、「プログラミング」という語が指し示す範囲には含まれないように思われます。
貴社元エンジニアの方の以下の発言は、上記のような内容もQiita上で許容される事が想定されているように読めますが、貴社の公的アナウンスとしてはそのような情報を見付けられておりませんので、上記疑念を払拭するに至っておりません。
https://twitter.com/mizchi/status/861892695236550656

自分の個人的な認識としては、Qiitaは「プログラムを書くすべての人が技術の悩みを解決するのに寄与する、技術的な話題」全般が共有される場と見えており、そのように考え記事を投稿しておりました。
しかしながら、自分の認識が貴社の想定から大きく外れているようでしたら、結果的には貴社のサービスの質を低下させる行為をしていた事になるのではないかと考えております。
今後ともQiitaの健全な運営に寄与できますよう、お手数をおかけしますが、上記の事について貴社の公式な見解を、本問い合わせへのご回答または公式なアナウンスの形でお知らせいただけましたら幸いです。
（また、本問い合わせへの回答としてご連絡を頂く場合、その内容の全文または要旨を個人のブログで公開しても良いかどうかについてもご回答頂けましたら幸いです。）

---

5月16日追記。本件、運営サイドから回答を頂けました。

• 少なくとも上記4例と自分の過去の投稿は大丈夫っぽい
• そのうちガイドラインについてフォローアップの公式アナウンスがTwitterとかQiitaブログとかでなされるっぽい

ということで個人的な心配はとりあえず解消されました。後は公式発表を待ちましょう。

---

5月29日追記。23日付けで公式な発表がありました。自分としては特に付け加えることはない感じですが、「まだスッキリしない」という方は直接問い合わせてみるのがよいのではないかと思います。

2016年のアドベントカレンダーのふり返り - Dec 25, 2016

今までアドベントカレンダーには熱心に参加した事はなかったと思うのですが、今年はシス管系女子の草の根広報活動の一環として、自分でもびっくりするくらい力を注いでおりました。

シス管系女子アドベントカレンダー

まず、自分で初めてシス管系女子 Advent Calendar 2016というアドベントカレンダーを立てました。IT系のクリスマスといえばアドベントカレンダーが定番という印象があったので、思いつきでのチャレンジです。

とはいえ、現状のWebでの認知度を鑑みるに読者の方のご協力だけで全日程はまず埋まらないだろうと見込んでいたため、全25コマの構成で事前にマンガを用意しておき、最悪の場合でも1日1コマ公開していけば日程は埋められるという準備を整えた上でスタートしました。Webでの試し読み代わりに自由に使える話を増やしたいという動機が元々あったので、「描くつもりだった話を描ければそれでまず成功。アドベントカレンダー関係のブームに乗っかって露出が増えれば一石二鳥。読者の方のご協力を得られれば一石三鳥」というつもりでした。

蓋を開けてみると、およそ3割の日程を読者の方に寄稿して頂けており、予想以上の結果に大変嬉しい思いをしております。自分なんかの思いつきに乗っかってくれた方がこんなにいた事、エールを頂けた事がとても励みになりました。本当にありがとうございます。

一方で、課題も色々あったと思っています。

• コラボ対象としてのシス管系女子のコンテンツ力不足。例えば湊川さんに寄稿頂いた記事は、大変な労作なのにも関わらず、ブクマ数は1桁台に留まってしまいました。ご恩に見合うメリットを提供できていないというのは心苦しい所です。
• アドベントカレンダーは大人数が参加するからこそ盛り上がるという事。世間には最初から最後まで一人だけで完遂しているITアドベントカレンダーもありますが、テーマ自体が魅力的であるとか話題性があるとかでも無い限り、ネットの片隅でひっそり始まってひっそり終わるだけになってしまいます。
• ファン向けコンテンツとして見た時の魅力の見えにくさ。ConoHaアドベントカレンダーでは参加者にカレンダーをプレゼントという事がアナウンスされていましたが、シス管系女子アドベントカレンダーでは具体的にどんなプレゼントがあるという事をアナウンスできていませんでした（現時点でも。これはグッズがまだ準備できていないせい）。また、こちらで投稿していく内容が本編でスキップした初歩的な部分についての物であったことから、多くの既存読者の方にとっては「知っている事」に過ぎず、連載を追う楽しみを感じられにくかったのではないかと思います。

以上を総合すると、今回誰が一番得をしたかというと自分自身だった（自由に使える特別編を1つ増やす契機になった、読者の方々からのエールを頂けて元気が出た）という気がします。つまり俺得。自己満足に付き合わせるだけになってしまってすみませんでした……こんな風に人の厚意を食んで自分のやる気に変えるような事ばかりしてたら信頼を損なうばかりですよね。ほんとに。

他のアドベントカレンダーへの参加

元々、自分から見つけてきてくれる人だけを対象にしていても認知は広がらないので、どこか「外」に出ていく必要があるという事は認識していました。

そんな折、Geek Women Japan 2016の懇親会で、「シス管系女子」を読まれた方から本編で扱っていなかった話についての質問を頂きました。それに対する回答を記事化して公開するにあたり、ちょうどそのタイミングで各アドベントカレンダーの参加募集が始まっていたため、「外」のアドベントカレンダーに参加すればその読者層に認知を広げる機会になるのでは？と思い至りました。ただ、無差別に参加して宣伝をばらまくだけではただのspam行為なので、

• 記事の内容はそれぞれきちんとそのカレンダーの趣旨に則ったものになるように務め、その記事単体でちゃんと情報として価値がある物になるようにする。これはspam行為にならないようにという消極的理由よりも、積極的に良いコンテンツにする事で信頼の種を蒔きたいという理由が大きい。
• その上で、「その記事でやっているような事を自分でやれるようになりたい人向けのコンテンツ」としてシス管系女子を紹介する。
• そのために、参加するアドベントカレンダーは「シス管系女子」の内容や周辺事情と親和性が高そうな物を選ぶ。

といったあたりの事を考えながらエントリーを増やしていった結果、以下の8記事ができました。

• Linux Advent Calendar 2016： 定期的にブラウザのタブを再読み込みしてスクリーンショットをSlackに投稿するシェルスクリプト （Qiita）
• さくらインターネット（その２） Advent Calendar 2016： さくらのレンタルサーバーの一番安いプランでWebサイトを公開するノウハウ （Qiita）
• Shell Script Advent Calendar 2016： シェルスクリプト（Bash）で作るTwitterクライアント （Qiita）
• チャットボット Advent Calendar 2016： シェルスクリプト（Bash）で作るTwitter bot （Qiita）
• Shell Script Advent Calendar 2016： プログラマーの君！ 騙されるな！ シェルスクリプトはそう書いちゃ駄目だ！！ という話 （Qiita）
• 【その2】妻・夫を愛してるITエンジニア Advent Calendar 2016： 女性エンジニアが自分の好きなように生きられるように、あるいはただの惚気話
• 絵文字 / Emoji Advent Calendar 2016： 絵文字✨とTwitter Bot🤖と私👤とEmoji Editor📝 （Qiita）
• Git Advent Calendar 2016： GitHubが落ちてても慌てずに済む、SSHとGitだけでのPush/Pull （Qiita）

結論としては、この試みは一定の成功を見たと思っています。特にShellscript Advent Calendarに投稿した記事がどういうわけか若干バズってくれて、ここからの流入が突出して多かったです。この記事は日を開けて何度か紹介されていて、その度にアクセスが発生するという状況になっていました。

ただ、このアクセス増は狙って起こせたものではなく（記事のタイトルを付ける際に若干挑発的なタイトルを意識したのは事実ですが……）、それ以外の記事のPVはそれほど伸びなかった事、また増加したアクセスも継続的なものではなくあくまでスパイク状の一過性の増加に留まった事から、やるならもっと継続的にやった方が良さそうという事は思っています。そうする事で、「シス管系女子」の内容や技術レベルに対する懐疑的な見方を払拭する材料を増やせれば、という思いもあります。

自分のサイト内でコンテンツを公開するよりも、技術情報であればQiitaのように、多くの人が見ていて且つ情報をシェアしやすい場所で公開するようにした方が良いという事も実感しました。

Groonga

会社の業務の一環で、Groonga Advent Calendar 2016にもGroonga名義でいくつか記事を投稿しました。

• Groongaをマスターデータの保管先として使うことについて
• Groongaにおける位置情報の取り扱いと地図情報の相性
• Groongaの新機能「slice」の使い方
• Groongaのbetween()関数の改善点
• Groongaの複数カラムにまたがるインデックスの仕組み
• Groongaでの複数カラムとインデックスと--match_columnsパラメータの複雑な関係

これらはGroongaの知名度向上や盛り上がり感の演出、既存ユーザ・新規ユーザ向けの情報の整備を目的に行いましたが、シス管系女子の場合と同様、これ自体が知名度向上に役立ったという事は言えなさそうです。

まとめ

以上をまとめると、認知度向上のための手段としてアドベントカレンダーを使う時は、既に人が多く集まっている場所（サイトもそうだし、アドベントカレンダーもそう）に飛び込んでいくのが有効なようです。 という、当たり前といえば実に当たり前の話なのでした。

片付いた部屋が苦手なのではなく、変化のための努力や、変化そのものが苦手なんじゃないのかということ - Jun 28, 2015

最近、10年近く使っていた使い勝手が微妙な机を処分して、別の机に入れ換えた。

元の状態と比べて、手前への張り出しが減ったので開放感が増した。 サブディスプレイの方を、妻所有だけど今は使ってなかった物（ベゼルが細くて画面が大きくて、メインで使ってる物と仕様が似てる）に置き換えたので、普段の画面が広くなった。 作画はCintiq Companion Hybridでやってるから、作業時の状況にはほとんど影響ないんだけど。参考資料をたくさん出しておけるというくらいか。

スピーカーの置き場所はちょっと微妙になった。もっと小さいのにすればいいんだけど、これはそれなりの重さがあって落ち着いた音が出るので、高校生の頃からずっと使ってて、替えるならこれより音がいい物でないと嫌なので、このまま行こうと思ってるけど。

僕は部屋を片付けるのが苦手で、増えてきた漫画が本棚から溢れてしまったり、洗濯が終わった衣類をなかなかしまわなかったりで、妻に嫌な思いをさせがちだ。

でも、汚部屋が好きというわけでは決してない。汚部屋でもそこまで気にはならない、というのはあるかも知れないけど。

世の中には、片付いてない部屋の方が好きだとか、コタツに入ったまま必要な物全てに手が届くようにしてるのだとか、そういう人もいるみたいなんだけど、僕が自分を省みる限りは、そういうのとも違うように思う。 物が出っぱなしになっているのが、特別に便利なようになっているというわけでもないし。 汚いよりは綺麗な方がいいというのは、素直にそう思うし。

僕が苦手なのは、大きくて急激な変化なのだと思う。 毎日少しずつ変わるのは気にならない……どころか、気がつかない、鈍い。 だから、少しずつ本が溢れて、少しずつ洗濯物が溢れて……というのが続いてもそれを意識できていなくて、気がついたら本が本棚の横にうずたかく積み重ねられたり、衣類収納の中が空っぽで乾いた洗濯物の中からパンツを取り出してはいたり、そういう事になってしまうんだと思う。 そういう状態に改めて言及されると、「良くないなあ」というのは分かるし、元々自分でもうっすら「これ、良くないよなあ、なんとかしないとなぁ」と思ってはいるんだけど、その状況を改善するための大がかりな労力を割く事にどうしても抵抗を感じてしまって。

まあ、そういうのが億劫なのは誰もがそうなのかも知れないけど。 「自閉症スペクトラムの特徴の1つに、慣れた環境から変わる事を極端に嫌がるという点がある」という話を聞きかじって、それに自分を当てはめて考える事で、「片付けられないのはそういうビョーキのせいなんだ」と責任逃れをしてるだけなのかも知れないけど。

フィリピン行ってきた - May 03, 2015

フィリピンのセブ島に行ってきた。主な目的は、現地滞在中の家族へのごまだれの配達（現地で手に入るそうめんのマトモなつけだれが無い、とのことで）……にかこつけた、ダイビング。聞いた所では、ボホール島、モアルボアルなど、セブ島およびその近くにはダイビングスポットとして有名な所が多いらしくて、その中でも、セブ島南部のオスロブにはジンベエザメの間近を泳げるエリアというのがあって、そんな機会滅多に無いんじゃないの？！と思って、それメインで行ってみた。

結果、目的を無事達成できて満足度は高かった。他にも色々スポットがあるようなので、また行ってみたい。しかし、今回の旅はとにかく不安だらけだったし、意識していなかった所での気付きというのもあった。

続きを表示する ...

会社に所属しながら書いた技術記事の原稿料収入の確定申告 - Mar 17, 2015

この業界、会社に所属しながら実名あるいはペンネームで技術誌に記事を執筆しているという人はそれなりにいると思います。自分も株式会社クリアコードに所属しながらシス管系女子を連載させていただいております。そういう人が確定申告をするときの話を自分の経験に基づいて書いてみます。

そもそも確定申告ってなんなん？つう話なんですけど、給与所得を得ている人間にとっては基本的に、収入源が会社の収入だけだし、年末調整の時期が近づくと「保険の支払いの書類とかもってきてやー」とアナウンスされてそれを持ってって会社に提出すると事務の方がイイ感じに計算して諸々処理してくれるので、あんまり関係ない話のような気がしています。問題は、そういう風に会社が把握してくれてない部分でお金の出入りがあった場合についてです。冒頭に書いたような技術記事を個人で書いている人間の場合、給与所得とは別に収入があるということになるので、その分の所得税やら何やらを納めないといけないのです。そこで出てくるのが確定申告。

聞いた所によると、給与所得以外で年間20万円以上の収入があると確定申告せんといかんのだそうです。僕の場合は原稿料×ページ数の額が20万円を超えていたので、しないといけなかったのですが、ちゃんと理解してなくて今までスルーしてしまっていました。が、このままではいかんと思ってちゃんとやることにしました。ほったらかしにしてると追徴課税とかシャレにならないことになるかもと思うと怖かったからというのもあります。それに、「シス管系女子」連載がついに本として発売されました、なんて大手を振って宣伝し始めたら、「おうおうおめえさんずいぶん羽振りいいみてえじゃねえか？　所得隠してんじゃねえのか？　あぁん？」なんて厳しく追及されるんじゃないか、みたいな。

具体的なやり方についてなんですが、世の中には確定申告について解説した本が山ほどありますし、税務署に行って「確定申告したいんですけど……」と言ったら懇切丁寧に教えてもらえるので、そういうのでちゃんと調べるのがいいと思います（が、僕の場合は税務署に話だけ聞きに行ってもピンと来なくてまるっきり身に付かなかったのでした……）。僕は実際には、以下のような手順でやりました。

申告書の作成は以下の通り。

1. 必要書類を揃える。
   • 会社の源泉徴収票
   • 原稿料の支払い調書
   • 原稿作成に必要で購入した物のレシートとか領収証とか
   • 国境なき医師団等、個人的にした寄付の領収証
2. e-Taxのページを開いて、確定申告書の作成→初めて確定申告される方→「確定申告書作成コーナー」と辿って、「申告書・決算書・収支内訳書等 作成開始」というボタン状のリンクをクリック。
3. 別ウィンドウ（タブ）で確定申告書作成のためのページが開かれる。提出方法の選択画面になるが、e-Taxを利用するにはICカードリーダー・ライターと電子署名のための証明書が必要になるので、そちらは何も手続きをしていないと利用できない。なので「書面提出」を選択する。
4. 利用環境のチェックのページの次に、作成する申告書の種類を選ぶページが表示される。青色申告というのをやるには事前の申請が必要だけれどもそんな物はやっていないので、「平成N年分 所得税及び復興特別所得税の確定申告書を作成」というリンクをクリックする。
   • 昨年よりも前の年の分の申告書を作る時は、下の方の「平成N年分の申告書等を作成する」というリンクを辿る。
5. 「収入が給与１か所のみ（年末調整済み）の方」「左記に該当しない方」「質問に答えて作成」という3つの選択肢が表示されるので、「質問に答えて作成」を選択する。
6. ウィザード形式で色々聞かれるので、情報を埋めていく。
7. 最後に印刷用のPDFを保存する画面が出るので、PDFを保存・印刷する。また、入力中のデータを保存できるので、それも保存する。
8. 3〜7を繰り返して、必要な年の分の申告書を全部作成する。
9. できた書類を持って、税務署または確定申告に詳しい人に相談して、間違っている所を教えてもらう。
10. 駄目出しを貰ったら、先の「確定申告書作成コーナー」で「作成再開」というリンクを辿って、7で保存したデータファイルを読み込ませる。するとウィザードの画面に戻るので、訂正箇所を直す。
11. 7〜10を、不安がなくなるまで繰り返す（面倒なので1回で終わらせましょう……）。

ここでちょっと「源泉徴収」について説明しておく。原稿料を貰う時に、「1ページあたりいくらです」と言われた金額よりもちょっと少ない金額が振り込まれていて、送られてきた支払い調書を見たら「源泉徴収分としていくら引きました」みたいに書いてあると思うけど、これはどういうことなのかという話。

所得税は稼いだお金の額に応じて課されるんだけど、総額に対して何パーセントという形ではなくて、経費がいくらかかりましたとか、医療費にこれくらいかかりましたとか、控除分とされる金額をマイナスした額に対して課税される。でも、そういうのって1年が終わってみるまで結局いくらだったのか分からない。かといって、最後にまとめて税金を払いますということにすると、極端な話、税金を1円も払わないでバックレてしまえる。なのでそうならないように、雇用者や原稿料を支払う側があらかじめ何パーセント分かを仮の税金として引いて、先に税務署に納めておく、これが源泉徴収。その後、1年の最後の最後に諸々の収入や支出が確定した段階で改めて「本当に納めないといけなかった税金は一体いくらなんだ？」というのを計算する、これが年末調整とか確定申告とかの作業なんですね。

それで、源泉徴収されてた分が本来納めるべき税金より多すぎたなら差額が返ってくる（これがいわゆる還付金）し、逆に、本来納めるべき税金より少ない額しか源泉徴収されてなかったなら差額を払わないといけない。この分はその年の期限までに払えばその金額で済むけど、滞納してると、ほったらかせばほったらかすほど利子みたいなものが膨らんでしまう。そういう訳なので、皆さん毎年ちゃんと確定申告しといた方がいいですよ、という話になるのです。

申告書ができたら提出と所得税の納付です。これは以下の通りの手順でやりました。

1. 印刷された物の中に資料の貼り付け用シートというのがあるので、給与所得の源泉徴収票と、寄付金の領収証を糊付けする。
   • 副収入の支払い調書や、副収入の必要経費を証明する領収証・レシートは、ここには貼り付けないでいいです。これらは提出書類の要件には含まれません。ただし、確定申告書の提出後に税務署が「これ収入少なすぎ。これ経費使いすぎ。おかしい。脱税の恐れあり。」みたいに怪しんだら、申告書に書いた内容は本当に正しいですよという事を証明するためにこれらの書類が必要になってくるので、捨てないで取っておきましょう。
2. 最寄りの税務署に行く。
3. 税務署内に確定申告書の提出コーナーがあるので、書類を提出する。
4. 形式的なチェックの後、提出分・控え分の両方にハンコをもらえたら、提出分はこの時点で回収されるので控え分だけ受け取る。
5. 税務署内に所得税の納付コーナーがあるので、そこに行って「納付したいんですけど」と言って申告書の控えを見せる。
6. 職員の方の指示に従ってお金を払って領収証を貰う。

書類の提出も所得税の納付も、郵送とか振り込みとか引き落としとかで済ませられるみたいなんですけど、僕は「ほんとにこれでええんか？　ええのんか？」と不安が大きかったので、駄目だったらその場で指摘してもらえる税務署窓口での直接提出・直接納付にしました。

以上のようなやり方でやった結果、僕の場合は平成23年(2011年）は所得税の納税の必要ありでだいたい1割くらいの延滞料込みの納税、平成24年(2012年）は納税も還付も無し、平成25年(2013年）はぶっ壊れた作業用PCの新調やらCintiq Companion Hybridの導入やらで必要経費が多かったので還付、平成26年(2014年）は納税の必要ありだけど割り増し無しの額面通り、という感じでした。

とりあえず、分からないことは税務署の人に聞けば教えてもらえるので、確定申告がどうこうと世の中が忙しくなってる時以外の時期に、税務署まで足を運んでみるといいと思います。税務署怖くないよ。バックレるつもりの無い真面目な納税者には優しいよ。

シス管系女子で取り扱っている解説の妥当性、危険性について - Mar 15, 2015

シス管系女子（正確には「#!シス管系女子 Season3」）の現在発売されている号の日経Linux 2015年4月号掲載分について、hostnameコマンドは与えられた引数でホスト名を設定する物なので、ホスト名を取得するためだけにhostnameコマンドを使うのは、誤操作で問題が起こり得るから危険だという指摘がありました。

別の話として、実際に指摘を見かけたことはまだ無かった気がしますが、過去の回でcrontab -eを紹介するにあたって色々調べ直していた時に、crontab -eは、確認なしでの削除であるcrontab -rとミスタイプしやすいから使ってはいけないという話も見かけました。

どちらの事例も、「その機能が正常に使われている限りにおいては問題ないが、ヒューマンエラーが発生した時のリスクが大きいので、そもそもその機能を使うべきではない」という、安全側に倒した考え方であるように自分は受け取りました。運用という側面から「シス管」を考えた場合には、尤もな指摘だと言えると思います。

hostnameについては、なぜ$HOSTNAMEを参照するようにしなかったのかというと、以下のような所が理由となります。

• 自分がその方法で覚えてしまっていた。
• ホスト名を変えるためにhostnameコマンドを使う、ということが普段無いために、そのリスクに無頓着だった。（hostnameコマンドによるホスト名再設定は、再起動したら状態が戻ってしまうことから「使えねー」「役に立たねー」と思ってしまい、それ以後存在自体をすっかり忘れ去ってしまっていた）
• なんとなく、環境変数の値は誰かが書き換えうるものという認識があり、コマンドの出力を見た方が安定した結果を得られそうに思った。（環境変数でもコマンドの結果でも同じ情報が得られるのであれば、コマンドの方を使うほうが安心、という認識がある）

crontab -eについては、「そんなん間違えへんやろ」と思っている部分が正直大きいです。が、自分がそう言えるのはcrontab -eというコマンド列を日常的に頻繁に利用するわけではないからかもしれないとも思っています。入力する回数が多いとcrontab -rというtypoの出現頻度が現実に問題となり得るレベルにまで高くなってくるものなのだ、と考えると、管理運用を業務とする人ほど敏感になるというのはありうるかも、と思います。

自分がこの連載で紹介する内容を考える時の判断基準としては、

• オプションの指定が不要なやり方と必要なやり方の両方があって、結果が同じなのであれば、オプションの指定が不要なやり方の方を紹介する。
• 簡単なやり方と難しいやり方の両方があって、結果が同じなのであれば、簡単なやり方の方を紹介する。
• 設定が不要なやり方と設定が必要なやり方の両方があって、結果が同じなのであれば、設定が不要なやり方の方を紹介する。（screenではなくtmuxを紹介したのはこれが最大の理由です）
• 確実なやり方と不確実なやり方の両方があって、結果が同じなのであれば、確実なやり方の方を紹介する。
• 安全なやり方とリスキーなやり方の両方があって、結果が同じなのであれば、安全なやり方の方を紹介する。

といったいくつかの基準があるのですが、「簡単だけど危険」「安全だけど難しい」のように判断が難しい時にどうするかというのは悩み所です。自分の中で決着が付かなければそもそもその話題は紹介せずに置いておくということもあります。が、多くの場合はcrontab -eのように、リスクを過小評価して利便性の方に舵を切ってしまいがちな気はしています。

ただ、可能な限り「簡単で、設定いらずで、確実で、安全で」という風に懸念点の少ないやり方を紹介していきたいという思いはあります。連載時の内容についての指摘は再録のタイミングで直せるので、全面的な改稿となると無理ですけども、セリフ回しや1コマの描き直し程度で乗り切れそうないい改善提案がもしあれば、Twitterアカウントへのリプライ等で情報を提供していただけると嬉しいです。

• 今の所、Season2でやったSSHの公開鍵の登録についてssh-copy-idを使ったほうがラクという指摘は頂いており、これは何かの機会に反映したいと思っています。
• このエントリに書いているhostnameの事については、既にuname -nやhostname -sなどの別案を頂いていますが、hostnameコマンド一発で済ませられるやり方に比べると若干面倒さが増す感があるので、「まんがでわかるLinux　シス管系女子」での追加コンテンツのような形で「より安全にやりたいならこういうやり方もある」という補足情報を載せる方向で行くのがいいかなあ、と思っています。

総じて、この連載については「初級者レベルの人がちょっとステップアップする」「文字の説明だけ見ても分かりにくい事を、ビジュアライズして説明する」という所にテーマを設定しているので、安全性最重視の解説にはしにくいと思っており、そこの所は本誌の他の記事の方々に期待しております（丸投げ）。

シス管系女子の刊行物の関係まとめ - Mar 07, 2015

「シス管系女子」関係の刊行物が色々あって状況がカオスなので、図でまとめてみました。

「まとめ読み」は、日経Linux本誌の付録としてだいたい年に1回ペースで制作されている物です。「まんがでわかるLinux シス管系女子」は、「シス管系女子」第1話から第13話、「#!シス管系女子」第1話（通算第14話）から第11話（通算24話）に加えて描き下ろしを収録した物となっており、作者の主観的にはこれが「初の単行本」という認識です。

各話は「まとめ読み」に再録する段階で一部修正していて、「まんがでわかるLinux」再録の段階でもまた修正しています。そこにさらに描き下ろしが加わっているので、今お買い求め頂ける物ではまんがでわかるLinux シス管系女子が最も内容が充実していておすすめです。「#!シス管系女子 Season2」については、「まんがでわかるLinux」の売れ行きが良ければ、今連載中の「#!シス管系女子 Season3」と合わせてまた本になるんじゃないかなあ……と思います。