とあるIT屋の独白

ITや経営について主に書きます

夫婦別姓と戸籍について考えてみる

少し前に、旧姓に法的根拠を与えるようサイボウズの青野社長が裁判所へ提訴しました。今日は少し趣向を変えて、この件について取り上げてみます。

 

夫婦別姓問題で国を提訴するサイボウズ社長の「痛快」な主張】

http://diamond.jp/articles/-/153253?display=b

 

私の会社でも旧姓で働いている方もいらっしゃいますし、結婚後に名字を変える方もいます。どちらの方法を選ぶにしろ手続き等が面倒だし、そもそも姓を変えなければいけないのは何故か、非効率だ、と言いたい気持ちは普通に理解できます。ただ、だからといって夫婦別姓を選べるということが対応として本当に正しいのか、という点はもう少し検討の余地があるのではということで、そもそも現状の戸籍管理というところから考えてみたいと思います。ちなみに、私は右翼でも左翼でもなく少年野球をやってた時は補欠でした。

まず、戸籍とはそもそも何かざっくりいうと自分の出自情報を管理する仕組みとなります。生まれたときは基本的には子供は親の戸籍に入り、結婚した時には親の戸籍から抜けて新しく夫婦の戸籍ができ、その際に姓を夫婦どちらかのものを選択しその履歴が自分の出自として残るわけです。

 

【公務員から聞いた戸籍早分かり術】

http://www5f.biglobe.ne.jp/~milty/koseki/koseki.html

 

ちなみに、外国籍の人と結婚した場合は夫婦別姓は許可されるのは何故かという指摘がありますが、そもそも外国籍の人は日本の戸籍法では対象外だからなのです。なので、結婚して戸籍ができる時はその戸籍は自分のみとなり名字を変える必要がそもそもないということになります。(手続きで変更することもできますが)

 

【国際結婚後の戸籍と苗字(名字)について知るべき4つの事】

http://visa-immigration.net/info/international-marriage-surname

 

そして、ではなぜ結婚したら姓を同一にしなければいけないのかというと、現在の戸籍の考え方では戸籍の単位は核家族単位となっていて、これを識別するものとして姓が用いられている為です。詳しくは下記のサイトに書かれていますが、このような管理の仕方は明治時代に始まっていて、当時としては、合理的な管理の仕方であったのかなと考えられます。

 

【ちょっと待った!夫婦別姓

http://syphon.bonyari.jp/index.html

 

では、なぜ核家族単位で管理するのかというと上記のサイトにも言及がありますが、それは生まれてくる子供の出自の管理と育児の責任の明確化の為という目的もあります。この、子供が属する戸籍については下記のサイトにも解説があり、例えば離婚した時に子供の戸籍を移す場合にどうすればよいかというと、姓(氏)の変更とセットで管理されています。

 

【離婚すると戸籍はどうなりますか?】

http://www.souzoku-sp.jp/m/koseki/detail/index3.html

 

長々と現行の戸籍制度について書きましたが、この戸籍の管理の仕方と姓はセットで考えなければいけないものと考えます。戸籍管理の仕方が現在の社会状況に合ってなく、管理の仕組み自体を変える中で姓の役割も変える、という議論であれば全然歓迎すべきことではあると思いますが、夫婦別姓という局所的なところだけ取り上げられ、制度を変更すべきだというのは、やはり少し違うのかなと感じます。

Elasticsearchについて調べてみた

全文検索のエンジンとして最近採用されることが、ちらほら見かけられるようになったElasticsearch、さわり程度ですが少し調べてみました。

まず、Elasticsearchの概要ですが、基本的には検索対象の文章を登録した上で、全文検索を行います。下記の記事にある通り、RDBMSとの違いは一致検索ではなく関連度が高いものを返すという点です。

 

【第8回 Elasticsearchの基礎を学ぶ】

http://gihyo.jp/dev/serial/01/js-foundation/0008

 

セットアップや使用方法の詳細は、下記のリンク集にある記事を見ていけばイメージをつかめるかと思います。インデックスの考え方とかは、全文検索エンジンならではのものですね。

 

オープンソース検索エンジン/Elasticsearchとは】

https://www.ossnews.jp/oss_info/Elasticsearch

 

実際の活用方法のサンプルは下記のサイトにあります。Twitterからつぶやきを集計して表示するものとなります。

 

【楽しい可視化:elasticsearchとSpark Streamingの出会い】

http://www.intellilink.co.jp/article/column/bigdata-kk02.html

シャープの復活について考えてみる

昨年、12月にシャープが東証1部に復帰しました。以前にも本ブログでシャープについて取り上げましたが、

http://toaruit.hatenablog.com/entry/2016/06/20/164714

降格してから、わずか1年での復帰はさすがといったところでしょうか。下記の記事によると過去10年で2部から1部に復帰した企業はほぼなく、社長の手腕が優れていたのか、よほど前の経営が杜撰だったかどちらなのでしょうかね。

 

【シャープ戴正呉社長が、東証一部復帰に際して語ったこと】

http://ascii.jp/elem/000/001/602/1602459/

 

載社長が再建に当たり、まずやったことは徹底したコストカットです。自らも贅沢しない姿勢を見せて、社員の意識を変えていきました。その一方で親会社である鴻海への売上も、業績に寄与しているかなと。

 

【赤い帽子、カツラ、社員寮暮らし……再上場のシャープ・戴社長がいろいろすごい】

http://bunshun.jp/articles/-/5393

 

下記の記事でも、今回の業績回復について、コスト削減や鴻海グループないでの損失移転が要因の主なところと書いてあります。今後より斬新な製品が出ることを期待したいですね。

 

イノベーションなきシャープの〝復活〟】

http://wedge.ismedia.jp/articles/-/10482?layout=b

クラスタリングとシャーディグ

データベースの機能で、私的に混同してしまうのが、クラスタリングとシャーディングです。自分への備忘も含めて、今回は少し整理したいと思います。

まずはクラスタリングで、下記の記事に概要があります。

 

【データベース・クラスタの概要】

https://thinkit.co.jp/story/2010/10/05/1784

 

クラスタリングの目的としては、可用性と負荷分散による並列処理(結果的に性能向上)を実現するためと、主なところは感じています。クラスタリングの機能として代表的なものとしてOracleRACが挙げられます。OracleRACではキャッシュフュージョンという仕組みで、クラスタを実現しています。

 

【ゼロから理解する「Oracle RAC」】

http://www.atmarkit.co.jp/ait/spv/0904/13/news115.html

 

片やシャーディングではデータの分散を行う機能であり、各サーバでは定められたレンジのデータが格納されます。下記のMongoDBの例が、イメージとして分かりやすいかと。

 

【第5回 MongoDBのシャーディングを試してみよう】

http://gihyo.jp/dev/serial/01/mongodb/0005

 

Oracleでも12cR2から、シャーディングの機能が追加されました。Oracleならではの機能もあるようですね。

 

【12c R2ではじめるOracle Databaseのシャーディング】

https://enterprisezine.jp/dbonline/detail/9031

単体テストやデプロイの自動化

単体テストやデプロイに関して、Jenkinsなどのツールを使用して自動化している例はかなりあると思います。Jenkinsについては下記の記事で、解説されています。

 

【Jenkinsとは】

http://cloudbees.techmatrix.jp/jenkins%E3%81%A8%E3%81%AF/

 

Selenium WebDriverというツールを使えば、画面周りも単体テストのコードで記述可能です。

 

Selenium WebDriverでWebアプリのテストが変わる】

http://www.atmarkit.co.jp/ait/series/883/spv/

 

ツール類はそろっているといっても、いざ現場に導入しようとすると場合によってはハードルが高かったりします。自動化によってどのようなメリットが得られるか、という観点での説明や浸透をさせないと、仕組みは作ったはいいけど使われない、ということにもなりかねないです。

 

【ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった~自動化の現場の真実(前編)。システムテスト自動化カンファレンス 2015】

http://www.publickey1.jp/blog/16/_2015.html

システム運用保守の今後・SREについて

新年が明けて2018年になりました。2018年もIT業界は慌ただしく動くような気がしていますが、何とか波に乗り遅れないようにしたいです。さて、今日はシステム運用保守の関連トピックで最近話題になっているSREについて取り上げてみます。

SREは、「Site Reliability Engineering」の略で、日本語にそのまま直訳するとサイト信頼性エンジニア、という雰囲気はなんとなく伝わってくるけど何が目新しい概念であるかパッとは分かりにくいと思います。一般的に言われるインフラエンジニアと何が違うのか、下記の記事に概要が書かれています。

 

Googleが提唱した「Site Reliability Engineering(SRE)」とは】

https://furien.jp/columns/327/

 

重要なポイントとしては、信頼性向上のためにアプリケーションのソースも変更するという手段も、選択肢として与えられているということです。下記のミクシィの事例をみるとイメージがわきやすいのですが、改善のためにDBのシャーディングやアプリから呼び出すライブラリの改修とかも行っています。

 

【物理マシン約1,400台が稼働する、モンスターストライクの運用を支えるSREのミッション【夏サミ2017】】

https://codezine.jp/article/detail/10368

 

つまり、どういう仕組みでシステムが動いているか把握した上で、どのような手段が信頼性向上を実現する上でベストか考えることがSREの仕事になるかなと感じます。決まった運用の下ではなく、課題解決のためにいかに対応方法が考えられるかというのが、求められてきます。

 

【特集:情シスに求められる「SRE」という新たな役割】

http://www.atmarkit.co.jp/ait/series/4503/spv/

 

従来型の保守運用と異なる点は、原因究明や暫定対応のみではなく根本対応やそもそもの仕組みの見直しを含めて、あるべき姿を追求していくという役割になるのかなと感じています。

システム運用保守の現状について考えてみる

ぼちぼち今年も終わりですね、年をとるほど時間は短くなるように感じられるといいますが、本当にあっという間でした。今年一年はどちらかというと、保守寄りの仕事が多かったということもあり、今年最後は運用保守について書いてみたいと思います。

運用保守については本ブログでも、ログ分析について取り上げてみたり

http://toaruit.hatenablog.com/entry/2016/11/07/225822

関連するトピックとして、カスタマーサクセスの取り組みについて書いたりしてみましたが

http://toaruit.hatenablog.com/entry/2016/08/28/021953

あらためてその意義から考えてみます。

システム運用保守は、ほとんどの現場においてコストとみられていて、コスト削減の候補に挙げられることが多いです。極端にいえば運用業務を自動化したり、障害が発生しなければ払う必要が無いコストです。そういった意味だと下記の記事にある通り、もしもの時の保険の意味での安心料ともいえます。

 

【システム保守と運用の役割~現代のIT社会を支えるエンジニアの重要性~】

http://itpro.nikkeibp.co.jp/atcl/column/16/122000309/052900011/?ST=spleaf

 

最近ではユーザからのコスト削減圧力により、撤退を検討しているベンダーも増えてきているとのことです。

 

【「撤退」が3割、システム保守運用の仕事】

http://itpro.nikkeibp.co.jp/atcl/column/14/542472/120800018/?ST=spleaf

 

また、大手SIerのTISはシステム運用保守のビジネスについて、パッケージ藤の利用などにより今後縮小するのではとの見込みをたてています。クラウド利用が広がってきていることも、影響しているのかなと感じます。

 

【TIS役員「SIなど既存事業は半分に縮小、五輪まで持たない」】

http://itpro.nikkeibp.co.jp/atcl/column/16/122000309/052900011/?ST=spleaf

 

傾向としては、今後単にシステム運用保守として括られるビジネスは縮小していくと思います。では今現在、システム運用保守に従事しているエンジニアはどうすればよいのかというと、それはまた来年に。。