独身SEのすべて

システム開発の実態とか趣味とかITとかマンションポエムとか。

CIAが作ったスパイマニュアル「会社をダメにする11の行動様式」が日本企業そのものな件

f:id:arata32:20151127221503j:plain

CIAの前身となった組織が作った、会社をダメにするためのマニュアルが話題になっています。

「会社をダメにする行動様式って?」

chikawatanabe.com

元記事を超ざっくり紹介すると、「会社をダメにする11の行動様式」を紹介したうえで、「日本に限らず大企業は多かれ少なかれこんなもん」だけど、「昔の日本企業はこの様式に当てはまらなかった」という論旨です。
ですが、まとめサイト等では、「紹介されている11の行動様式がまさしく日本企業そのものだ」と盛り上がっているようです。
日々の仕事でこんな場面に遭遇して辟易した経験は誰しもありそうです。元記事の内容のうち、気になったものを紹介します。

これがなければもっと早く帰れるのに…となる5選

  • 文書は細かな言葉尻にこだわる
  • 重要でないものの完璧な仕上がりにこだわる
  • 重要な業務があっても会議を実施する
  • なるべくペーパーワークを増やす
  • 全ての規則を厳格に適用する

組織に属して仕事をしていると、なんでこんなことしなきゃいけないんだろう…と思っちゃうような作業って多いですよね。
無能な上司ほど、「言葉尻」を重視した「重要でない書類」を「大量」に用意してくれます。
エンジニアの中にもこういう方は結構いらっしゃって、技術に取り残されたお飾り管理職の方がよくやりがちな事です。
大手のSIerさんから「上司への報告のために作ってくんない?」って言われるような資料は概ねこんな感じになりがちです。なぜなら上司の方が理解できるのは、資料の内容ではなく日本語だけだから…

早く決めてくれよ…と嘆きたくなる6選

  • 何事も指揮命令系統を厳格に守る。意思決定を早めるための「抜け道」を決して許さない
  • 可能な限り案件は委員会で検討。委員会はなるべく大きくすることとする。最低でも5人以上
  • 業務の承認手続きをなるべく複雑にする。一人で承認できる事項でも3人の承認を必須にする
  • 前回の会議で決まったことを蒸し返して再討議を促す
  • 会社内での組織的位置付けにこだわる。これからしようとすることが、本当にその組織の権限内なのか、より上層部の決断を仰がなくてよいのか、といった疑問点を常に指摘する
  • 「注意深さ」を促す。スピーディーに物事を進めると先々問題が発生するので賢明な判断をすべき、と「道理をわきまえた人」の振りをする

仕様変更や進捗遅れなど、エンジニアさんを取り巻く環境は刻一刻と変化します。
早く手を打たないと手遅れになってしまうような状況でも、元請け、顧客、自社、様々なステイクホルダーが意思決定を邪魔します。
もちろん、権限やら責任範囲やらが重要なことは重々承知しています。でもこの瞬間に手を打たなければいけないのです。現場のリーダークラスはやきもきします。
提案当初は最善策だったものでも、実行までの時間とともにタイミングを逃し、悪手になってしまうことが多々あります。そしてしわ寄せが来る現場の面々はあきらめ顔で今日も残業をこなします。

なぜ組織がこうなってしまうのか

スタートアップ直後のベンチャー企業でもない限り、組織が5年、10年続くと概ねこうなってしまいます。社員30人にも満たない零細企業でも、「会社側」を自称するおじさん数名があーだこーだ言って引っ掻き回し、結果時間だけが無為に過ぎていくことがよくあります。
前述の無意味な資料とかもそうだと思うのですが、みんな意外と「仕事がしたい」と思っているんじゃないかと思うのです。
大企業の上役でも、長老お荷物社員でもいいですが、「仕事がしたい」けど「目に見える何かを生み出せない」というジレンマを抱え、「何か自分でもできる仕事」を求めて部下に指示を出している人も多いかもしれません。
それを自己顕示欲と呼ぶのか自己承認欲求と呼ぶのか、満足感の創造なのかはわかりませんが、我々が日々こなす作業の何割かは、こういった「誰かのための仕事」を作り出すことになっている気がします。
組織の新陳代謝が困難な大企業や役所なんかは、特にこういった傾向が強いので、みんな共感するのかもしれませんね。

【ぼっち検定チャレンジ】独身SEがおひとりさまを楽しむ

普段、なかなか時間が取りにくいシステム屋さん。
時間が不規則になりがちなので、人を誘って食事に行くなんてのも難しかったりします。

f:id:arata32:20151123170439j:plain

ぼっち検定で自分の生活を客観視してみる

今年の夏前くらいから、Twitterなんかで、ぼっち検定ってワードを目にする機会があったんですけど、ちゃんと見たことなかったので改めて自分を客観視してみましょう。

http://nikkan-spa.jp/wp-content/uploads/2013/05/BK3_130521_10.jpg

 とか

 みたいのが出回ってます。
個人的には後者の検定が扱いやすいように感じたので後者の検定を使ってわが身を振り返ってみましょう。

初段から三段

  • 初段 一人牛丼/マック
  • 二段 一人ラーメン
  • 三段 一人ゲーセン

独身男性なら、この辺はもう制覇されてる方が多いのではないでしょうか。
会社帰りに食事をとりたくなっても空いてるのはラーメン屋、牛丼屋のみなんてことはザラですし、個人的にはゲーセンなんて一人で行くところとしか思えません。
この辺は段位を付ける事すら意味を感じないレベルですね。

四段から六段

四段、五段あたりは、好き嫌いが分かれてくるところですが、ハードルは比較的低い方ではないでしょうか。
映画はあまり見に行くことが少ないですが、誰かと見に行っても見てる間は一人です。自然ですね。
一人カラオケも、昼前の早い時間とかに行ってみるとわかるんですが、一人客ばっかりです。名前を書く紙を除くとおひとりさまがずらっと並んでいます。ヒトカラ専門店なんて行く必要もありません。
ファミレスは、時間帯によっては孤独感を感じてしまうかもしれませんが、一人でもなんの違和感もない場所ですよね。

七段から九段

  • 七段 一人居酒屋
  • 八段 一人回転寿司
  • 九段 一人温泉

この辺になってくると、そもそも一人で行く価値を感じない方が増えてくるかと思います。一人で飲みに行くことに喜びを感じない人も多いですし、お寿司が食べたければテイクアウトのお寿司でも十分ですしね。温泉に至っては、一人だと自殺に来たんじゃないかなんて疑われるケースもあるみたいです。
ですが、この辺を一人で楽しめるようになれば行動範囲がぐっと広がる気がしますし、出会いなんかも増えそうな気がします。
私もこの辺は抵抗があるので、まだまだですね。

十段から番外

  • 十段 一人遊園地
  • 皆伝 一人ラブホ
  • 番外 一人鍋

一人遊園地、かなりハードルが高いですね。一人で遊園地に行ってテンション上げて楽しむまでには強靭な精神力を必要とする気がします。
一人ラブホは、デリバリー的なことをする人であれば普通なんじゃないかという気もしますが、何の目的もなく一人で入るとしたらかなりのつわものですよね。なんなんでしょう。
番外の鍋ですが、家で一人で鍋をすることって普通にありませんかね?外でやるには少し抵抗がありますが、ちょっと毛色が違うので番外なのかもしれませんね。

もっと一人を楽しもう

このご時世、一人で楽しむことはさほど難しくないのかもしれません。
とくにシステム業界では、一生一人で生きていく覚悟をしている人が一定数います。
いつも一人でいることも寂しいかもしれませんが、一人を極端に恐れても行動範囲が狭まってしまいます。
私も、チャレンジしたことがないいくつかの項目にチャレンジしてみようと思います。

今が辞め時?誰も教えてくれない会社の辞め方

システム開発に携わっていると退職を考えるシチュエーションは珍しくないですよね。
今すぐに辞めるつもりはなくても、いつ何時でも退職というカードを切れる準備をしておくことは無駄ではないはずです。

f:id:arata32:20151118184617j:plain

1.退職するかを考えてみる

退職したい理由は日々何かしら浮かんでは消えていくという状況が珍しくない独身SEの生活。しかし、本当に辞めるべきかは一回考えた方が後悔しないと思います。
その判断をするときになるほどと思った方法がこれです。

d.hatena.ne.jp

楽しいかどうか、勉強になっているかどうかを考えて、どちらも"No"であれば辞める。シンプルな基準ですが、理に適っていると思います。
辞めたいと思うとき、概ね「楽しくない」「つらい」みたいな状況に陥っていることが多いかと思います。それでも、何かしら勉強になっている要素があれば少なくも「今すぐ辞める」にこだわる必要はないと思います。自分の体力、精神力が限界というわけでないのであれば勉強できる要素を吸収しきってからでも遅くはないかもしれません。
私が以前に会社を辞めた理由は、「プログラムを書く集中力、忍耐力」より「打ち合わせで顧客とコミュニケーションをとる」「広い範囲を漠然と理解する」方が得意だと感じたのでより上流に近い仕事ができる職場に転職しました。今の会社に入るまでは仕様書の書き方もわからないし、設計って何をするべきなのかもわかりませんでした。その点、今の会社では目的を果たせたと思っています。

2.退職を決意する

まずは、本当に会社を辞めるのかもう一度自分に問いかけましょう。
普段から辞める辞めると豪語している人ほど、意外とこの決意ができていないことがあります。
本当に自分が会社を辞める意志があるかを確認する方法は簡単です。コインを投げて決めてみましょう。

例えば「コインの表が出たら会社を辞める」と決めてみます。そして実際に表が出た時にどう感じるか。
辞める覚悟ができていれば「ですよねー」とか「やっぱりその流れなのね」と後押しされた気持ちが湧いてくるし、覚悟ができていなければ、辞めない理由を探し始めます。
コインなんて曖昧な事で決めるなんて…と思う方も多いかもしれませんが、なかなか理にかなった基準だと思うのです。

3.辞めたあと何をするのかを決める

辞めた後に何をするか決めないのが一番最悪です。
フリーランスになる、でも、別の会社に就職する、でも良いですけど、辞めたからどうするか考えると、ニート一直線です。
一般的には次の職場を見つけてから辞めることが推奨されていますが、5年前に会社を辞めた時も、そうしましたし、そうしてよかったと思いました。仕事をしない期間が間に1か月あるだけでも、次の会社で給料をもらえるようになるまで2か月間が空きますので、その辺をちゃんと考えて辞めるのがいいと思います。会社都合で退職して半年休むを目指すのもいいかとは思いますが、先の見通しは重要だと思います。

4.退職の意志を上長に伝える

いよいよこの日がやってきました。所属の上長に退職の意志を伝えます。
普段から辞める辞める言いすぎていると、「いつもの奴」的なとらえられ方をして話が前に進まなかったり、面倒な引き留めがあったりしますが、「次の会社が決まっている」「どうしても辞めたい」「どの口が言うんだ」等のリアクションは想定しておきましょう。私の場合、引き留めの余地を残さないために「家庭の事情」としか言わずにごり押ししました。
もしも口頭での話が全く進まない場合、辞表を出すことになりますが、「退職届」と「退職願」の違いは大きいので間違えないようにしましょう。

www.taisho9.com

退職届を提出した場合、もう退職を撤回することはできませんし、会社も止めることはできません。退職届を提出しても尚引き留め等に合うことはありますが、退職日を明記しておけば会社は退職を阻むことはできません。退職届を受理されない場合は「配達記録付内容証明郵便」で送付するのが有効なようです。

 会社は自分を守ってくれるわけではないことを念頭に

例えば上司に会社を辞める相談をしたとき、「安定」とか「リスク」といったワードが出てくることが多いです。
ですが、会社のミッションは「事業の継続・拡大」であって「従業員を守る」事ではありません。
それに、会社に勤めている限り、特に年俸制を採用しているような会社であれば残業時間なんて青天井みたいなものです。そこで体や精神を壊すよりは契約で守られたフリーランスの方が自分を守るには有効なシチュエーションもあります。
さらに、システム開発業界は人月あたりの単価という比較的安定した食い扶持を維持し易い職業ですので、「仕事がなくなる」という可能性はとても低いです。
さらに2015年から2020年くらいまでは慢性的に人が足りないことが予測されていますし、若い人からの人気が最低に近いレベルですので、まともなレベルで仕事ができれば仕事がなくなる可能性は低いです。
本当に安定したシチュエーションなんてこの世には存在しないことを認識しつつ、自分の人生を自分で決めていくのが健全な生き方ではないでしょうか。

あえて今バブル。ベッド・インが耳から離れない

バブルっていいですよね。うらやましいです。
そんなバブルを現代に蘇らせるために絶賛活動中のベッド・イン。ご存知でしょうか?

www.youtube.com

吉田豪界隈とか大谷ビッグボスとかが結構おしてまして存在は知っていましたが、曲も結構恰好良いですねー。
ちゃんまいのギターがSGなのが渋いと思います。バブルならフライングVでもよかったかもですね!!

【年収シミュレーション】独身SEがフリーランスの夢を見る

IT業界にいると、オレは何をしているんだろうと考えちゃうことありますよね。
そんな時、フリーランスになったらどうなるんだろうって妄想しちゃうことありますよね。フリーになった場合の年収をネットの知識だけでシミュレーションしてみました。

f:id:arata32:20151112230537j:plain

年収はいくらくらいになるんだろう?

だいたいフリーになることを意識し始める人は、
・30代前半で、
・そこそこ腕に覚えがあって、
・給料に不満がある人
がメインじゃないかと思います。

 で、だいたいそこで月の単金70万円を基準に考えていこうと思います。
根拠は依然書いた記事で 。

sarata.hatenablog.com

 で、フリーランスのエンジニアがIT業界で働くと、会社員時代と変わらず現場に出ることが殆どと思いますので、年収は単金70万円×12か月で840万円が収入のほぼすべてになります。

で、税金やらなんやらでどのくらい取られるのか

フリーのITエンジニアがもらえる年収が決まりました。
じゃあどのくらい国やらなんやらに取られるのか。
何も考えずに年収すべてに税金がかかるような状況になると、白色申告の場合だと税金、保険、年金で3,146,400円取られ、手取りでいうと5,253,600円になります。この金額だと、福利厚生がないことを考えると会社員時代とほぼ変わらない条件が見えてきます。

個人事業主 税金・社会保険料計算シュミレーション

 会社員の夢、経費ってどうなの?

経費ってよく聞くけどなんなんでしょう。
所得税っていうのは、"課税所得"というものに応じて増えていくようです。
そして課税所得というのが、"年間総売上ー必要経費ー各種控除"であらわされるようです。出てきましたね。経費。
この経費というものを増やしていくと、税金が抑えられますと。これが噂に聞く経費というものの正体のようです。

何が経費として認められるの?

ITエンジニアはPCさえあれば体一つでできる仕事です。
PCも、セキュリティ上、現場で支給されることが多いので、何も経費として落とせるものが無いように見えますが、意外と経費にできるものは多いみたいです。

inqup.com

biz.moneyforward.com

家賃、ネット回線料、携帯電話代、光熱費、交通費あたりが、使用割合に応じて経費として計上できるみたいですね。
家賃も、1Rの部屋だと最大50%くらいまで認められるみたいなので、家賃だけでも3~4万、全部ひっくるめると月10万くらい経費としていけそうな気がしてきました。
現在の段階で計算してみると、経費を120万円引いて、社保と税金が2,694,300円まで下がりました。手元に残るお金が452,100円も浮きます。この差はでかいです。

白色申告と青色申告って?

確定申告のことを調べていくと、白色申告と青色申告とかいう謎の単語が出てきました。ざっくり違いを見ていくと
白色申告→申告が比較的簡単
青色申告→申告がちょっと面倒だけど65万円の控除が付く
という違いがあるようです。
ここで、確定申告をちょっと頑張ることにして、青色申告を採用すると社保と税金の金額は2,499,300円になりました。何もしないときに比べると647,100円の差が出てきました。

会社員がいいのかフリーランスがいいのか

これは価値観をどこに置いていくかが最も大きく違うところでしょうか。
年収面では、福利厚生を加味するとそこまで大きな違いはないということが分かりました。
じゃあ会社員が安定しているのか。これは必ずしもそうとは言えないと思います。良くも悪くも実力主義なの業界なので、歳をとって仕事ができなくなって辞めていった人を何人も見てきました。決して安定はしていないと思います。会社がいつ潰れるかなんてわかりませんしね。
フリーランスは会社員だとし辛い副業がしやすかったりとか、自分で単金交渉してあげてもらえる可能性があるとか、自分でやりようがいろいろありますね。
フリーランスになるとついてくる自由と責任と実力主義。この辺をプラスにとらえられる人が向いてるのかもしれないですね。

ノスタルジックなWebサイト探訪

オモコロの記事を見て、インターネットってこうだったなーって懐かしい気持ちになったので、なつかしさ探しの旅に出てみました。

公立小学校のホームページの洗練されてなさがやばい

omocoro.jp

全体から漂う手作り感。
画像の配置の独特さ。
GIFアニメの異常な速さ。
いたるところにノスタルジーを感じます。

マウスストーカー覚えていますか?
わざとやってるっぽいJavascriptのハックサイト

oekakirenn.webcrow.jp

スマートフォン世代は見たことすらもないかもしれないマウスストーカー。覚えていますか?
マウスを動かすとついてくる鬱陶しくも愛らしいあんちくしょう。
実際使っているサイトは中々見つけられませんが、このサイトでサンプルが見れます。
このサイトも、デザイン感とかかなり90年代を意識している感じですが、絶賛更新中なのできっと狙ってやってるんでしょうね。好きです。

カウンターでキリ番ゲット

90年代のHPといえばカウンターが付き物。
1アクセスするとカウンターが上がり、キリの良い数字になるタイミングでアクセスすることを「キリ番を踏む」と呼んでいました。

www.ninja.co.jp

カウンター使ったサイトないかなーって探してたんですけど、学生時代に使っていた忍者カウンターがまだ生きていました!!懐かしいですね!!

キリ番を踏んだら掲示板に書き込み!!

キリ番を踏むんだら、サイト内に設置されたローカル掲示板に必ず書き込みをするのがマナーがでした。
当時はインターネットを見る人も全員ハンドルネームを持つのが主流でしたので、ハンドルネームを添えて挨拶を書き込んでいましたね。インターネットがまだ狭い村社会だったころの思い出です。リンクを張るだけでも、挨拶しないのはネチケット()違反でした。
当時を懐かしんでる方たちはこちら。

togetter.com

そして愛生会病院は今

www.yukawanet.com

すこし前に評判だった愛生会病院、残念ながら閉鎖されてしまっているようです。
真っ赤なゴシックフォント、ありえない色合いと衝撃が半端なかったこのサイト。Web0.1とでも表現でそうな一つの時代が終わった瞬間かもしれません。

インターネットも変わっていく

私の母親はVHSの巻き戻しがギリギリできるかできないかという最先端のネットリテラシーを持っているのですが、その世代から見て一瞬とも思える時間で、これだけインターネットが変わっていっています。
テキストサイト黎明期にインターネットをはじめ、ブログが流行ったかと思えば、無制限に世界とつながるSNS、そしてLINEというクローズドなコミュニティになっていくという時代の流れを肌で感じてきました。
昔のインターネットはお金がほぼ絡まない世界だった感が強いですが、商用利用が当たり前になった昨今、これからのインターネットはどの方向に進んでいくんですかね?

CSSを綺麗に書くためのプリプロセッサとかCSS設計記法とか

CSSを綺麗に、保守性高く書くのって難しいですよね。
前にこんな記事書いてみましたけど、今回はさらなる保守性向上のために できる事はないか調べてみました。

sarata.hatenablog.com 

CSSプリプロセッサSass(サス)でライティングの効率を上げる

www.atmarkit.co.jp

プリプロセッサって言葉に馴染みがない方も多いかもしれませんけど、実際に使う.cssファイルではなく、.scssファイルに記述した独自の構文を、コンパイラを通して.cssファイルを作ります。

http://image.itmedia.co.jp/ait/articles/1402/17/dreamWP03_2.jpg

これだけ見ると何がうれしいのかピンと来ないかもしれませんが、プログラム書ける人がcss書くときに使えるとうれしいなーと思いがちな変数定義、四則演算、制御構文(条件、繰り返し)なんかが使えるようになります。
Mixinsという考え方でコードの再利用性を高めることもできるので、プログラマが当たり前に使いたかった機能が網羅されている感じですね。
ただし、必ずコンパイルする必要があるので、TryアンドError的なスタイルを取る人にはまどろっこしいかもですね。

MindBEMdingで規約を共有する

MindBEMdingを説明するためにはBEMを説明する必要があります。
BEMは「Block:塊」「Element:要素」「Modifier:状態」の頭文字をとった言葉です。HTMLでいろんな部品を作るときの命名規約(名前付けルール)を定義したものです。
ドキュメント導入部分が日本語訳されていますので、詳細はそちらに譲ります。

github.com

で、このBEMをCSSに適用する際に使用する記法がMindBEMdingです。

blog.ruedap.com

命名規約って何がうれしいの?という方の方が多いかもしれませんが、チームで同じものを作るときはベースとなる何かを共有していないと話の進み方が全然違ったりするので、意外と重要な要素です。
ただし、BEMの命名規則、びっくりするくらいクソダサいので、それが我慢できるかが分かれ道かもしれません。

SMACSSとOOCSSで設計ルールを定める

BEMはHTMLの要素を3つのレベルに分割した命名規約でしかなかったのに対し、もう少し設計ルールを定めたものがSMCSSとOOCSSです。
例えばJavaで開発してる人なんかはデザインパターンでコードの再利用性なんかを学ぶと思うんですが、それのHTML・CSS版といった感じでしょうか。
まだ全然真髄が理解できていないので、これらを取り入れることによって生まれる「うれしいこと」についは、追って突き詰めていきたいと思います。

app.codegrid.net

app.codegrid.net

先人の知恵とノウハウを享受するためには

SMACCSもOOCSSもそうですし、Javaデザインパターンもそうだと思うんですが、設計ルールって、先人の知恵とノウハウが凝縮されています。
ただし、デザインパターンを勉強した時にも感じたことですが、ただルールに沿えば良いものができるかというとそれはおおむねNoです。
なぜ、このパターンを採用しなければならないのか、今このパターンを採用することが正しいのか、等々、いろいろ吟味したうえで取り入れていかないと効果は半減しちゃうと思うのです。
やはり、地道にいろんなコードを見て良い、悪い、綺麗、汚いの判断ができるようになることが一番の近道かもしれないですね。