auientの日常

ノンジャンルで書きたいことを書くブログ

【読書】最後にして最初のアイドル、ほか5冊

おもしろい本をたくさん引いたので読書がはかどった。

 

最後にして最初のアイドル (ハヤカワ文庫JA)

掴みが良かった。適当に買う本を探していたところ、ぺらっと開いた1ページ目で購入決めた。内容はというと途中からぶっ飛んだ展開になる中篇が3本だが、どれもSF的には筋が通ってるらしい。アイドル・ソシャゲ・声優をモチーフにしてるところが現代を感じさせる。自分はあまりに超展開になると感情移入できなくなってしまうので「まあ、なるほど」という感じだった。

掴みの1ページを引用しようかと思ったけど長くなるので割愛。本屋でぺらっと1ページめくって見てほしい。

 

失敗の本質―日本軍の組織論的研究 (中公文庫)

有名な本。面白かった。目的の曖昧性とか、組織内の意思不統一とか、なるほどなーと思った。一方で当時の日本軍の判断にも一定の合理性があったことは覚えておきたい。日清/日露戦争の経験や、日中戦争初期の夜襲・奇襲の成果とか、これらデータを参考に作戦を立てたこと自体は間違ってない。データは常にアップデートしていくべきだし、それに応じて判断も変えていかなければいけない、という理解をした。

 

庭をつくろう!

子供の絵本として。素敵な絵とお話。舞台はオランダなのか、フランスなのか分からないけど、街中にこんな庭付きの家があるなんてうらやましい限り。長男も気に入った様子で2回も読んだ。絵本も読み応えのあるものはこうして感想を残していこうと思った。

 

東京定点巡礼

図書館で借りて流し読み。戦後〜現代の写真とコラム。著者は定点撮影の元祖の人らしい(インタビュー記事)。古い写真はいい。この人も特攻隊の生き残りだそうだけど、写真に写る風景から10数年前には戦艦大和とか零戦ばんばん作って飛ばしてたんだなあと思うと何とも言えないものがある。

 

図説 近代エクステリアの歴史

これも図書館で借りて流し読み。自分は看板建築の古い建物が好きで、それに関連した歴史や文化を期待していたんだけれど、それよりは豪邸やいわゆる由緒正しい日本建築の門の作りが主な内容で期待外れだった。大衆文化の香りは毛ほどもしない。「お高くとまってございますね」という印象。どっかに看板建築好きのため本がないかなー。

 

流れよわが涙、と警官は言った (ハヤカワ文庫SF)

面白かった。出だしから引き込んでいく面白さみたいなのは流石だと思う。肝心のところ、SF部分の説明はよく分からなかったけど(←残念な人)。解説読むと、これは著者の置かれた立場とか心境を色濃く反映してる作品らしい。そのうちもう一度読むだろうと思って書棚入り。

 

 

こどもパソコンを作った

長男がちょいちょいキーボードに興味を示すようになった。日本語入力してみたいらしく「パソコンやらせて」と言いに来る。何度かMacBookを触らせたが、かな入力に切り替えるのが面倒だしMacBookを占領されるのもアレなので、長男用のPCを与えることにした。Amazonでラズパイ3Bを購入、Respbianをインストールし、日本語入力やTuxPaintを入れる。日本語入力についてはこの記事を参考にさせて頂いた。

f:id:auient:20180506213050j:plain

▲できあがりの図。レゴでできた家はケースにしようと思っていたが「そのままで遊びたい!」と言って取られてしまった

使わせてみた結果、意外にもWorframのREPLでの計算(1+2など)に興味を示した。「計算機だよ」と教えたが、足し算の答えが出るのが面白いらしい。"12+9"の結果を一緒に検算してみたりして、「パソコンの答え合ってる?」「合ってるねえ」なんて会話するのは楽しい。2桁+2桁の計算をさせて結果に興奮している姿もほほえましい。

MinecraftとTuxPaintも楽しんでいた。TuxPaintを見ると昔遊んだKidPixを思い出すが、今となってはダサいAqua風のボタンやUIを見るにつけKidPixには及ばんなあという感想が浮かぶ。ドット絵のスタンプやOld MacのUIから感じられる「手触り感」みたいなのがない。(まあ、それは美化された自分の思い出が多分に含まれてるだろうけど) 長男はそんなことお構いなしにカエルのスタンプを押しまくって遊んでいたりした。

f:id:auient:20180506141208j:plain

▲創造性を発揮する画伯。この後画面一面をツタだらけにした 

ScratchやMinecraft Piでプログラミングも教えてみたいが、まだ早いか。子供のものは「子供が自由に触れる状態にしておくこと」が大事だと思っているので、触っていればそのうち興味を持つんじゃないかと期待している。

 

2019.6.15 追記

次男用のラズパイを買って同じようにセットアップした。

  • 8GBのSDカードでは容量が少なすぎる。Raspbianのインストールではできるが、アップデートでファイルシステムがいっぱいになって起動しなくなる罠がある。
  • TuxPaintのインストールなどで、最初はネットワークにつないでおく方が良い。ネットワークの切断は後からでもできる。

というのが1年後の学び。

 

【読書】アイルランドの歴史、幼年期の終わり、子供が体験するべき50の危険なこと、他

間が空いてしまった。手にとった技術本があんま興味を惹かれないと、読書という行動自体をブロッキングしてしまうなーと思う。「一週間の進みが20p以下だったら警告出して読むのを中断する」とかできるといいな。

 

物語アイルランドの歴史―欧州連合に賭ける“妖精の国” (中公新書)

実家にあったやつ。おもしろかった。「アイルランドといえばイギリスと仲が悪い」イメージがあるが、その経緯は紆余曲折を辿っているんだなというのがわかる本。

 

日経ビジネスアソシエ 2018年 1月号 [雑誌]

なんかの電車に乗った時に活字成分補給で買ったやつ。社畜のための雑誌であり、それ以上でも以下でもなかった。多分もう買わない。

 

みんなのGo言語【現場で使える実践テクニック】

図書館で借りた。Mookらしい、現場向けの本だった。GOPATHをそのまんま作業スペースにするという発想になるほど、と思ったものの、PCのフォルダを組み替えるのがめんどくさすぎて手が止まった。うーむ。

 

Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~

会社でオススメされたものを流し読み。半分くらいは情報処理試験で見かけたなーという印象。残り半分は具体的なチューニングとかの話であり現場で役にたつ(が、今の自分には関係なさそう)という感じ。

 

幼年期の終り

blog.tinect.jp

このレビューを読んで。kindleで買ったけどiPad miniでは読みづらくて図書館で借り直し。面白かった。ただamazonで「この話、要は〜でしょ」という雑なネタバレレビューを見てしまい残念な気持ちになった上、結末はどう考えてもそのような解釈にはなりえず、二重三重の意味でモヤモヤした読書体験となってしまった。うーむ。レビューでネタバレ、ダメ。

 

子どもが体験するべき50の危険なこと (Make: Japan Books)

図書館で借りた。アメリカンな雰囲気が全編から感じられるが、巻末の訳者解説を読むとこれでも日本ナイズされているんだなと分かる。確かに小学生3年以上向き。書き込むスペースとかあるので、買ってさりげなく本棚に置いといて、子供が興味を持つよう仕向けるのもアリだな。

 

 

 

最近仕事が楽しい

auient.hatenablog.com

こちらでちらっと書いたけど、去年SIerから事業会社へ転職した。SIer時代にphpやgitなど今時の案件にアサインされ、ありがたく何年か安定して仕事ができた中でスキルを積んで、それが活かせる場所を改めて探したと認識している。

前の会社はゼロ状態から自分を育ててくれた恩があり、給料も良かったけれど、マネージャーとしてキャリアを積んで仕事を続けて行くのは難しかった。安い下請けをフォローしながら開発を回して利益を抜くという仕事に疲れきってしまったことが大きい。じゃあ担当に戻るわ、というほど会社が好きではなかったし、10年いて自社で仕事をしたのは合わせて数ヶ月ほどであったからそもそも帰属意識なんてなかった。

今の会社にはすごい人がいっぱいいて、たくさん学ばせてもらっている。じゃあコードもさぞ素晴らしいのだなというと全然そんなことはなくて、歴史と地層を感じさせるカオスが渾然一体となっており変化し続けている。汚いコードと取っ組み合いしているのはSIerの時と変わらないかもしれない。逆にそんな状況だから自分が活躍できるという面もある。

何をやって何をやらないか、どうやるかの裁量が自分にあるのが大変ありがたい。自分の責任においてバリューのあることを考えて進めていけるから。

そういうわけで、新しいことを学んで色々やっていく今の仕事はとても楽しい。楽しすぎて休日に会社の Slack を普通に眺めてコメントしたりしており、公私分離できないアレな人になるのを心配している。

この先当面自分がやること・できることはなくなりそうにないし、やれるだけやっていくつもりである。ありがたいことにビジネスも成長している。とはいえ強い競合がいて安穏としてられる状況でもないので緊張感も持ちつつ、どこまでいけるかな?という思いでいる。

餃子

お昼に餃子を食べたせいでもっと餃子が食べたくなってしまった。そういえば冷蔵庫に使いさしの、元の半分くらいになった白菜があるのだ。「今日は餃子にしよう」とその時思った。

ネットで餃子のレシピを調べつつ豚のひき肉を買って帰った。300gほしかったのに200gと450gしかない。少し迷って450gを買った。皮も40枚でなく70枚にした。多くても困らない。

餃子を包むのはいつぶりだろう、と考える。随分前、音楽仲間たちと闇鍋ついでに餃子を作ったのが思い浮かぶ。10年近く前のような気がする。それから今までにもやったかもしれないが、記憶がない。誰かと一緒に餃子を包むのは楽しい。子供と一緒に包む作業ができたら楽しいだろうな、と思う。

 

レシピを見ながら餡をこしらえる。長男に声をかけたら興味をもってくれた。すこし神経質な長男がいじけないよう包むコツを教えて、失敗してもいいんだよとやんわり伝える。

長男はすぐ作業に夢中になった。餡がはみ出ないよう少なめにしたせいで、皮が大きくぴったりくっついているけれど、真剣にやっている。それまで見ていたテレビに脇目もふらないで「ぼくは夢中になっているよお」なんて言ってるのがおかしかった。昼寝から起きてきた次男にも最後の1個をとじてもらった。

家族が風呂に入っている間に餃子を焼く。レミパンのテフロンは優秀だ。自分でも意外なほどよい焼き具合に仕上がった。

 

いつも白めしをおかわりする次男がご飯にいっさい手をつけず、代わりに餃子ばかり10個は食べただろうか。長男は自分で包んだ餃子に相当思い入れがあったらしく、先に焼いた私の餃子に手をつけずに待っていて、自分が焼きあがったら一生懸命ふうふうと冷ましてぱくぱく食べていた。こういう子供の姿を見るのは実に嬉しい。餃子は妻にも好評で、なんだか家庭の味って感じだねと感想をもらった。

 

今日の餃子は思い立ってから作って食べるまでがパズルのピースがはまるみたいにうまくいって、大したことではないのだけど、本当に嬉しかった。記念の写真でも撮っておけばよかった。よい、幸せなごはんでした。ごちそうさま。

客先常駐とSESの関係についての考察

コメント頂いたので考えてみた。この方のいう本質的な問題とはなんだろうか。

自分の見た客先常駐 - auientの日常

一連の記事で気になるのはこれ含め"客先常駐"と"SES"の問題を混ぜて扱っている点;本質的問題は客先常駐(SES/請負問わない)だと思うので,そこをもっと語って欲しい;柔軟な雇用については経営側の一方的都合としか思わない

2018/01/14 16:58

b.hatena.ne.jp

コミュニケーションの問題

常駐とリモートを比べたとき、物理的距離が近い方が圧倒的にコミュニケーションが取りやすいというのがある。システムの仕様や要件を正確に表現することは難しいから、メールとかチャットじゃなくて対面で話した方が望ましい。ウォーターフォールの要件定義ではMTGをたくさんするし、目的のものが変化していくアジャイルだとなおのこと多いと思う。客は文字にできなくても喋って伝えられた方が楽だし、受注側も客の要件をちゃんと理解しとかないと的外れなモノを作るリスクがあるので、受発注双方に常駐のメリットがある。

セキュリティの問題

次にセキュリティ要件の問題がある。作業は入室セキュリティのある場所で行えとか、ネットから隔離されたマシンでやれというやつ。これも契約書に条件書いて受託側に作業場所用意させるのが面倒すぎて、逆にお客さんの方で要件に合う場所用意してくださいよそこでやるから・・・となる。客も手元で作業環境が確認できた方が安心。これも受発注双方の常駐メリット。

契約の問題

発注側からすると「要件・納品物を定義できるか」という分かれ道がある。定義できれば請負にできるが、要件漏れのリスクがある。あとはアジャイルなどで作業人員を確保したい客の場合そもそも納品物を定義できない(定義したらアジャイルにできない・・・)。ので明確な目的があるプロジェクト(旧システムリプレイスなど)以外は準委任SESか派遣にしたがる傾向がある。あとはどうしても作業に口を出したがる人もたまにいる。

受注側からすると派遣はうまみが少ない。一番大きな利幅を狙えるのは請負だが、納品物が決まるかは客次第だ。準委任SESと派遣なら、社員に対する指揮命令ができてチームとして運用できる準委任SESの方がメリットが大きい。先輩新人をセットにしてOJTで新人を育てるのはよくあるパターンだが、同じチームで席を隣にするなどできる点で準委任の方がやりやすい。派遣ではこうはいかない。

これは受発注双方の準委任SESのメリットである。

常駐させられる要員の問題

元増田で指摘されているやつ。客先に送られる要員の立場になってみると

  • まわりが客だらけで肩身がせまい
  • スキルが身につかない仕事をさせられる場合がある
  • 元の会社の福利厚生などを利用しにくい

など。請負でも準委任でも派遣でも同じだが、↑上の3つに社員の立場での論点が出てこなかったことから分かるように、受託開発ビジネスの上で割とどうでもいい扱いされる事柄である。強いていうなら受託側企業とその業務を担う従業員の間の問題だが、従業員に我慢させれば前述の理由でビジネスがやりやすいという構造がある。確かに一方的だろうが、経営リスクを負ってない立場では文句を言うぐらいが関の山かな(合法な限りは)という感じ。

まとめ

結局のところこの構造は需要(発注側)と供給(受注側)双方のニーズによるものであって、SESも常駐も、突き詰めれば現行の法体系や資本主義という原理原則と地続きなんじゃないかな、というのが自分の見解である。そういう意味でSESと客先常駐を分けて考える理由が自分にはよく分からない。

ちょっと前からしばしばアクシアという会社の社長ブログホッテントリで見る。こういう問題を認めて正直に向き合っているように見えて個人的には好感が持てる。こういう経営方針の会社なら従業員も諸々の問題を回避して幸せに働けるのかもしれない。

以上、ご参考まで。>id:vanbraam

自分の見た客先常駐

はてブで人月い件が話題になってたので、自分のケースを書いてみようと思う。

anond.hatelabo.jp

www.orangeitems.com

ossan.hatenablog.com

軽く自己紹介しておくと、自分は大手メーカー系の子孫会社SIerで10年ほど泥仕事をしていた人間である。請負に準委任、派遣、自社案件、なんでもござれ。ただし最後の常駐先ガチャで安定してよい仕事をできるところを引き、スキルを積んだ結果去年web屋に転職した。そういう意味では常駐肯定派、強いSEの一部である。

その話はさておき。

SESの実態についての肌感

当時の会社のポジションは概ね2次〜3次受けで、自分は係長(リーダー)クラスになっていたので、上の会社とも下の会社とも話す立場であった。その感覚から言うと元増田もid:orangeitems氏もid:dbfireball氏もみんなそれぞれ自分の経験に正直に書いているんだなあと思う。少なくとも嘘はないんじゃないかな。元増田は下流の方、orangeitems氏は上の方だなというのはあるけど。*1

一概に「仕事とはなんであるか」を言えないように、SESという形態をとってみてもピンからキリまである。アタリもハズレもある。その中で、まあ一般論として言えるかな、という話をいくつかあげてみよう。

受託開発なら法律は知っておけ

自分の会社はそれなりのブランド看板を背負ってたのでコンプラには相当厳しかった。おかげで労働関係の法律についての教育を受ける機会が度々あり、ちゃんとした知識を得られた。ちっちゃい会社で社長が営業して仕事ぶん回してるところじゃこうは行かないだろう。

受託開発するもの、法律を知るべきである。なぜか。それが法律だからである。自分の立ち位置を決めるものだからである。少なくとも請負・準委任・派遣の違いを把握することは最低限のラインだと言える。

明確な違いポイントの1つに「直接指揮命令するか」というのがある。SESで客先で仕事してるとき、アホな客がカジュアルに作業指示出してくるケースがあり「あっこれ指揮命令かな?」と思ったりする。違法か適法かの境目なんて案外そんなもんだったりする。

上下の会社と関係を良好に保ち売上に責任を持つ立場としては些細なことでいちいち波風を立てないが、末端で作業している諸君。君が今日受けた作業指示は違法かも知れないんだぞ。それがまず分かるようになれ。

ちゃんと調べていくと派遣法まわりはマジで頭のおかしい法律だというのがよく分かる。自分はずっと気になっているんだが、「労働契約申込みみなし制度*2」って誰か有効活用した人いるんですかね? 事例があったらぜひ教えてほしい。

受託開発なら自分の単価は把握しておけ

ITエンジニアは技術を磨いてなんぼ、という風潮がある*3。それはそれでいいんだが、受託開発している諸君。君らのスキルは、君の1人月に金を出す客がいないと1円の金にもならないことを理解しているか? ビジネスモデルを説明できるか?

今までに「面談」した多くのエンジニアは、自分の単価に興味を持つ人がとても少なかった。上司や営業の方針で単価を教えてないケースもあるだろう。だがあえて聞いてみてほしい。「自分の単価っていくらなんすかねえ?」と。

単価は=自分の評価額であり、自分が働いて出すべき価値の指標になる。そして何より、単価以上の給料・ボーナスがもらえることは絶対にないのである。受託で儲けようとすると、自分以下の人間(自社・他社問わず)をまとめてどーんと売上を上げて行く必要があるが*4、そういう一歩進んだポジションも担えますよ?というアピールにもなる。1人月しか売上を上げられない人間と、部下4人つけて5人月いける人間では、当然後者の方が上司の評価も給料も良くなるものだ。

ちなみにミルフィーユのような多重下請け構造の中にいると、自分より上の会社の単価は(普通は)知ることができない。もし何かの拍子に知ったとしたら、驚き、怒りを覚えるだろう。マージン抜いた会社は、少なくともマージン分は何かしら価値を提供して然るべきであるが、不思議なことに一人の担当者も置かずマージンだけ吸い取る会社がある。こういう会社を避けるためにミルフィーユはできるだけ薄い方が良いだろう。とはいえ、ミルフィーユの厚さを事前に測る方法はほぼないのであるが。

なぜSESが必要とされるのか

ここまでSESでの受託開発について書いてきた。リアル10年泥をやってみて感じるのは、「なぜこのような形態の仕事が必要とされているのだろうか?」という疑問だ。

自分の理解では「日本の解雇規制が強すぎて正社員だけでは需要の伸び縮みに対応できないから」という理由が一番説得力を持っている。システム開発の仕事は、そもそもがプロジェクト型(1回っきり)のケースが多く、需要に波がある*5。これを正社員で賄おうとすると、閑散期に社員を解雇できないので固定費の負担が重くなりすぎる。EC2のインスタンスが遊んでたら落とすの当たり前だよね?それができないとどうなる?

このポジションを埋めるのが本来は派遣の役割だったのかもしれないが、やっぱり正社員信仰のせいか政治的な問題が強すぎて、使役側からすると非常に使い勝手の悪い制度になっている。5年ルールとか、労務管理義務とか。

そこで都合の悪い現実への適応として選択されているのがSESなのではないだろうか。だから、実際は商流無視して指揮命令が横行して実質派遣じゃん、みたいなことになる。それは求められているのが「指揮命令可能・労務管理不要・需要の変化にフィットする、派遣」だからじゃないだろうか。

じゃあどうしたらいいの論でいえば、解雇規制撤廃すればーという話になるが、それも一概に良いと言えない。だって単に廃止するだけじゃ経営側が強くなりすぎるから。あってもいいかなーと思うケースは、年金など社会保障制度改革でBI導入するのと同時に規制緩和するやつ。ただ、クソ自民は論外として枝野にもできると思えない。

どうにかなんないですかね。

まとめ

自分の感覚に基づいた根拠レスな記事を書いた。とはいえ法律は根拠がある。みんな法律と単価を知ろう。きっとそれが自立につながるはずだ。

あと、理不尽に見える現状にもそれに至る理由があるだ。ビジネスの形であったり、法体系であったり。それを考えていく必要があると思う。

参考:過去に書いた人月い話

 

*1:境遇、誤字が多くて気にしない風の増田。派遣法の教育をちゃんと受けてるorangeitems氏、あたりから読み取れる

*2:違法派遣状態になると問答無用で正社員入社できるというすごいルール。ググると邪悪企業パソナのページがtop hitなのでリンクしない

*3: はてなブックマーク - ITエンジニア採用に欠かせない原則とは (1/5):IT人材ラボ

*4:ちなみにこのポジションの人間を奴隷頭という。自分も奴隷頭だった

*5:そんなことはない、継続して改善していくものだというイケイケweb屋のあなた。世の中を見渡してください