「CI」を含む日記 RSS

はてなキーワード: CIとは

2017-05-22

医学自転車通勤者は、自動車、徒歩の者より健康長寿

http://anond.hatelabo.jp/20170522214454

自転車通勤者は徒歩通勤者より全死因死亡リスクが低い/BMJ医師医療従事者向け医学情報医療ニュースならケアネット

https://www.carenet.com/news/journal/carenet/43895

自転車通勤は心血管疾患(CVD)・がん・全死因死亡のリスク低下と、徒歩通勤はCVDのリスク低下とそれぞれ関連していることが、

英国グラスゴー大学Carlos A Celis-Morales氏らによる、前向きコホート研究の結果、明らかにされた。

徒歩通勤自転車通勤は、日常身体活動を高めることができる方法として推奨されている。

先行研究メタ解析(被験者17万3,146例)において、有害な心血管転帰リスク低下と関連することが報告されていたが、同報告の結果は、

代謝性エンドポイント(高血圧糖尿病脳卒中、冠動脈心疾患、CVDなどの発生)の範囲が不均一で徒歩通勤自転車通勤かの区別がなされておらず、限定的ものであった。

BMJ2017年4月19日掲載の報告。

26万3,450例を前向きに追跡

 研究グループ検討は、2007年4月2010年12月英国内22地点から英国バイオバンク参加者26万3,450例(うち女性52%、平均年齢52.6歳)を対象に行われた。

仕事場までの通勤手段(非アクティブ自転車、徒歩、混在)を曝露変数として用い、主要アウトカム(致死的・非致死的CVDおよびがん、CVD死、がん死亡、全死因死亡)の発生について評価した。

 結果、追跡期間中央値5.0年(四分位範囲:4.3~5.5)の死亡発生は2,430例で、うちCVD関連死496例、がん関連死1,126例であった。また、がん発生は3,748例、CVD発生は1,110例であった。

自転車通勤は、全死因死亡、がん発生・死亡、CVD発生・死亡とも有意に低下

 最大限補正モデルにおいて非アクティブ群と比較して、自転車通勤群は、

全死因死亡(ハザード比[HR]:0.59、95%信頼区間[CI]:0.42~0.83、p=0.002)、がん発生(0.55、0.44~0.69、p<0.001)、およびがん死亡(0.60、0.40~0.90、p=0.01)のリスク有意に低かった。

同様に自転車通勤を含む混在群も、全死因死亡(0.76、0.58~1.00、p<0.05)、がん発生(0.64、0.45~0.91、p=0.01)、およびがん死亡(0.68、0.57~0.81、p<0.001)のリスク有意に低かった。

 CVD発生のリスクについてみると、自転車通勤群(0.54、0.33~0.88、p=0.01)、徒歩通勤群(0.73、0.54~0.99、p=0.04)ともに有意な低下が認められた。

CVD死についても、自転車通勤群(0.48、0.25~0.92、p=0.03)、徒歩通勤群(0.64、0.45~0.91、p=0.01)ともに有意な低下が認められた。

 一方で、徒歩通勤群は、全死因死亡(1.03、0.84~1.26、p=0.78)、がん関連アウトカム(がん発生:0.93、0.81~1.07、p=0.30、がん死亡:1.10、0.86~1.41、p=0.45)について、

統計学的有意な関連はみられなかった。徒歩通勤を含む混在群も、測定アウトカムのいずれについても顕著な関連はみられなかった。

 これらの結果を踏まえて著者は、「アクティブ通勤を促進・支援するイニシアティブによって、死亡リスクを減らし、重大慢性疾患の負荷を減らせるだろう」とまとめている。

ケアネット

原著論文はこちら

Celis-Morales CA, et al. BMJ. 2017;357:j1456.

http://pmc.carenet.com/?pmid=28424154&keiro=journal

2017-05-16

営業部長は受託開発はリスキーで客先への派遣は安定しているだとかで

社内での受託開発の縮小を進めたいらしい。

来週から僕も客先常駐を行うことになったため

面倒な顧客とのやりとりが増え、大好きなプログラミングをする時間は減っていくんだと思う。

出社時間も1時間早める必要があるみたいだ。

転職も考えているけれど

初めて勤務した会社素人に毛が生えた様なシステム開発を行っている会社

独学で勉強をして案件対応を行ってきたため、自分知識技術が正しいものなのか自信がない。

特にCIやらテストやらに関してはほとんどわからない。

独学で勉強して興味をもっているWebの開発会社転職したいと思うが

一般のまっとうな開発会社からみると僕には価値があるのだろうかと考えてしまう。

2017-02-11

http://anond.hatelabo.jp/20170211015458

> ユニットテストはすぐに金銭的な効果に結びつくから、はじめてしまって実績をつくればいい。

そうなのか。新しい機能じゃないとお金もらえないかユニットテスト導入は金銭的な効果に結びつかないのかと思っていた。

ちなみにもう勝手に導入してるがいくら言っても自分しかテストを書かないしCIがないのでいつのまにかテストが通らなくなっててメンテできなくなってる。

2016-10-16

バブル時代広報だった父の受けた接待

http://toianna.hatenablog.com/entry/2016/10/15/102629

80年代に父の会社CI改革プロジェクトがあって父はプロジェクト責任者だった

想像するにCI改革は、ロゴデザイン刷新CMもあったりでかなりの額のプロジェクトであったんだろうなと思う。

代理店はH社

なお、父の会社重厚長大系。父が就職した60年代はイケイ業界だったが、バブル期は、業界構造として低迷で、株もびっくりするほど安かった。母は給料の少なさに嘆いていた。

はいつも、打ち合わせで六本木だが麻布だがで代理店の人とごちそうになっていた。家に帰るといつも家族に食べたものを仔細に話していた。

その後、月イチくらい、接待で行った店に家族で行った。フランス料理の魚のムニエルが全く美味いと思わなかったり、中華風のしゃぶしゃぶで腐乳閉口したりした。そういえば青山フランス料理松濤に引っ越す前のシェ マツオだったりしていた。

代理店営業さんとサントリーホールコンサートを聞きに行った、ということも良く言っていた。たまに私も連れて行ったもらって、休憩の時シャンパンを母に内緒で飲ませてもらった。あと、「スターライトエクスプレス」というミュージカルの券にも一緒に行った。

バブル恐るべし、と思う。

当時品のない接待を求める会社もいっぱいあっただろう。

トイアンナさんの書くような下品なことを求めるクライアントもあるだろうし、それを全く求めないクライアントもいるだろうし、そこは当然営業さんは合わせるんだろうと思う。

今だったら昔より、品のないのは断ることがしやす環境には思う

私は現在仕事関係上、コンサルティング会社と何回か仕事をしたが、ハードワークと、クライアントへの丁稚加減としてコンサルは似たような点があると常々感じていた。

コンサルティングに無理を強いる時には、申し訳ないと感じながらも、下請けにやらすのは当然という思い、そしてコンサルのみなさん僕らよりお給料高いよねという卑屈な思いが入り交じる。その時、たまに父が漏らしていた「士農工商代理店」という言葉を思い出す。

現在も、ましてやバブル当時も、品のない接待要求しているクライアントはたくさんあるだろう。そこにはおれたちは客だろうという思いの奥に、高給へのひがみといった薄ら暗い感情があるんじゃないかなと思う。

2016-09-03

http://anond.hatelabo.jp/20160902031012

http://anond.hatelabo.jp/20160902031012

はてブ批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみますおっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。

大学に行っても実用的なソフトウェアを書けるようにはならない

実務の話!! 実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの

技術実態みたいなやつ。そういうのは学校で教わらないんですよね。

まず、日本大学勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。

これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間認知されてないというだけです。

具体的に挙げてみましょう。

大学で教えてる内容ってこんな感じなので、ゲームアプリサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学情報学科を出ていないのにゲームiOSアプリWebサービスを作っている人はゴマンといるし、逆に日本大学先生ゲームiOSアプリWebサービスを作れる人はほとんどいません。

日本大学先生実用的なアプリサービスを作った経験がない

これは重要ことなのでもう一度書きますが、日本大学先生ゲームアプリサービスを作れる人はほとんどいません。大学先生が得意なのはプログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。

そのため、大学勉強してもゲームアプリサービスが作れるようにはなりません。だって教えている側の先生が、ゲームアプリサービスを作ったこともなければ、作り方も知らないんだから

そういう経験のない人たちばかりですよ、日本大学先生って。そんな人たちの授業を受けて、アプリサービスが作れるようになると思うほうがおかしいでしょう。

ためしに、先生方のTwitterアカウント名でGithub検索してみてください。いまどきGithubアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないかGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ?

あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか?きっとXSSCSRFも知らないですよ。

ですので、そういうことを勉強したいなら、ベンチャーIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
(「大学はそんなことを教える場所ではない!」と怒る人いると思うけど、教えられる先生がいないという事実ごまかすために怒ってるだけだから。)

ジャンルが違う

はいっても、大学先生プログラムがいっさい書けないというわけではないです。彼らが得意なのはコンパイラインタプリタOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームアプリサービスとはジャンルが大きく違います

そのため、大学情報学科に進めばコンパイラOS機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームアプリサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。

大学で教えている内容ってムダなのか

じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。

大学で教えている内容って、ゲームiOSアプリWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、

こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。(情報系の学科で学んでいるなら、ライブラリ言語OSを「使う人」ではなく「作る人」にぜひともなってほしいですね。)

元増田に進めたい進路

元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。

こういう事情なので、元増田には大学ドロップアウトしてIT系会社入社することをお勧めします。ドロップアウトが難しいなら、インターンバイトでなんとしても入り込むことです。

入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなPixivクックパッドDeNAドワンゴ教育制度確立しているようです(違ってたらごめん)。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田目的にかなうのは間違いありません。

そして何年か働いて、iOSアプリWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。

上で説明したように、大学というところは、ゲームアプリサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田IT系会社に入ってアプリサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。

なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています

残念ながら、そういう会社東京に集中しているようです。例外京都はてなくらいでしょうか。地方大学生にとってはつらい現実なので、はてなPixivドワンゴ地方でのインターン開催をお願いします。あとレベル5は九大と九工大学生を鍛えてあげてください。

余談ですが、学生さんにひとこと:

インターンバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトからとかインターンからという軽い気持ち会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。

大学で授業を受けなくても独学で効率的勉強する方法

ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。

リツイートが100超えたら書く。

2016-09-01

AI(人工知能)、BI(ベーシックインカム)、じゃあCIDI、EIもあるの?


瞑想運動野菜先生

AIの発達で今後失業者うなぎ上り。(略)。社会はBIに移行せざるを得ない。」

って仰ってて、素朴な疑問として

CIDI、EIが更なる未来に台頭してくるのかなって思いました。

2016-08-13

ソフトウェアエンジニア転職するときに気をつけること」その後

ソフトウェアエンジニア転職するときに気をつけること http://anond.hatelabo.jp/20160629082647

これを書いたあとしばらくして転職したので、その後の話でも。

はいっても、この「気をつけることリスト」は結局使わなかった。知り合いのエンジニアがはじめたベンチャーに行くことにしたからだ。

ベンチャーからIRなんてないし、社長が知り合いだから技術への考え方や開発スタイルは知っているし。だから話としては開発しているサービスの内容と将来性、あとは待遇を聞いたくらいかな。まあ、将来性については自分判断するしかないんだけどw

ちなみに知り合いの会社からといって「気をつけることリスト」を無視したわけでもない。基本的スタンスはこれを書いた当初と変わらないし、このリストにある項目について自分の中で納得したうえでの転職だよ。

ついでに気になったブコメにもレスもしていこう。

そんな会社存在しない、意識高すぎ、など

これははっきりと断言させてもらうけど、この「気をつけることリスト」と照らしあわせたうえで転職したいと思える会社は、都内だったら普通にあるよ。

意識が高いのかどうかはよくわからない、というか周囲と比較すると自分はむしろ意識が低いほうだけどね。好きなこと以外の勉強をあまりしないし。それが自分の弱いところなんだよな。

gitへの否定的あるいは懐疑的意見

gitが新しいツール玄人向け?冗談でしょ。

gitのいいところは、ツールとして優れているというよりGitHub, GitLabなどのgit serverと統合されたウェブサービスがよく出来ているところだと思う。

特に、いわゆるpull-request駆動開発、つまりある程度のコミットのまとまりをpull-requestなどでCIしたりレビューしながら開発できるようになったすばらしい。

からまあ、pull-request駆動ができるならバックエンドバージョン管理システムgitでなくてもいい。逆にいえば、gitを使っている会社でもpull-request駆動できる環境がなければ片手落ちだ。

就業時間, 待遇, 福利厚生などは聞かないのか

そりゃ聞くよ。聞くべきでしょう。わざわざ書かなかったのは、さすがに自明だと思っていたから。

ベンチャー特有というと、株の扱いくらいかな。このれはちょっと前にバズってた記事があるので読んでおくといいんじゃないだろうか。

GitHubコードを公開している会社は稀なのでは

なにかしらOSSを公開していなければ転職絶対ありえないというわけではないけど、判断材料になるのは確かだし、そういう会社積極的に探したほうがいいとは思う。

かつ、稀というほど少なくもないと思う。特に昨今のWeb企業であれば、OSSを開発してるところは沢山ある。そういうのは採用のためのアピールも兼ねてると思うんだけどね。

あとそういう意味では、最近エンジニアブログを持っている会社もあるからそういうのはチェックしたほうがいい。会社レベル感や雰囲気を知るにはちょうどいいと思う。

2016-07-11

アジャイルの害

アジャイルプラクティスマイクロマネジメント的なものが多い。

これらのプラクティスを,アジャイル文化であり精神であるところの「自律」なしに導入したらどうなるか。
 日本管理職マイクロマネジメント好きと相まって,地獄のようになるのは想像に難くない。

からエモいと言われようがなんだろうが,アジャイルはその文化精神理解なしに導入してはいけないのだと思う。
 アジャイル手法のように扱い,アジャイルプラクティスだけをあたかも「アジャイルであるかのように勧めるコンサルタントトレーナー危険まりない。

CICDのようなマネジメントにあまり関係のないものを,「アジャイル手法」ではなく,単に業務効率化の方法として取り入れるのはありかもしれない)

2016-07-05

http://anond.hatelabo.jp/20160705123324

今の時代リリースして終わりじゃなくてCIっていうか継続的インテグレーションが求められるものからプラットフォームごとに機能ソースが分かれていることは管理上も実用上も運用上も論外なんだよ。

実際にそういう糞アプリ運営する立場になって考えてみろ。

つのソースマルチプラットフォーム、がこの世界での正義だ。

とりあえずxamarinでも使ってればいいだろ。

2016-06-25

[] ウォーターフォールメリット

http://simplearchitect.hatenablog.com/entry/2016/06/20/080807

から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが,この記事もその反論記事支援記事も含めて,「ウォーターフォール採用する(せざるを得ない)理由」について書いてあるものはあっても,「ウォーターフォールメリット」について書かれた記事が見当たらないのには驚く。

各種記事

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い

http://simplearchitect.hatenablog.com/entry/2016/06/20/080807

まずこの記事。「メリットはない」って言ってるんだから,書いてないのは当然なのかもしれないが,アジャイルメリット=なぜアジャイルがいいのか,についても書かれていない。これではFUDといわれてもしかたない。

日本アジャイル流行らない理由

http://ledsun.hatenablog.com/entry/2016/06/21/102501

日本アジャイル流行らない理由」≒日本ウォーターフォール採用される(消極的な)理由は書いてあるが,ウォーターフォールメリットについては書かれていない。

ウォーターフォール開発プロセス有効

http://ledsun.hatenablog.com/entry/2016/06/21/102501

タイトルから期待して読んだが,「ウォーターフォール課題と言われてるものは,実は解決されてるよ」という記述が大半を占める。

最後の一節は「アジャイル問題」として,「変化に人間がついていけない」点が挙げられていて,その裏返しでウォーターフォールがいいよ,ってことを言いたいのかもしれない。しかし,アジャイルは「変化に機敏に対処する」ことが眼目であって,何でもかんでも変化させなければいけない,というものではないので,指摘自体的外れに見える。

ウォーターフォールアジャイルを考える

http://arclamp.hatenablog.com/entry/2016/06/23/172941

冒頭,

まず、「ウォーターフォールは何のメリットも無い」は嘘です。何のメリットもないもの存在するわけないので。

とあって,メリットを語ってくれるかな,と期待させるが,結局「スコープが確定しているならウォーターフォールでいい」,という消極的採用理由が述べられるだけで,メリット積極的採用理由は述べられていないように見える。

ウォーターフォールメリット

ではウォーターフォールメリットは何なのか?

それを語る前に,まずウォーターフォール定義しておく。現在日本ウォーターフォールとして認識されているプロセスは,国防総省式の「戻りの線」なしのものである。即ち,確定した要件なり仕様なり(以下まとめて「スコープ」と呼ぶ)は変更しない。「ウォーターフォール」という名前自体が,この一方向性に由来している。従って,ウォーターフォール定義としては,「(フェーズゲートを超える際に)確定したスコープは変更しないプロセス」で良いだろう。

この定義に沿わないプロセスは,「偽ウォーターフォール」であり,以下に述べるウォーターフォールメリットを受けることはできない。メリット享受できないだけでなく,この種の「偽ウォーターフォール」は(「偽アジャイル」同様)大きな害悪を撒き散らす。

さて,「確定した要件仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが,手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者/受注者含め何がうれしいのか。

答は

納期 and/or コストぶれるリスクを小さくできる」

である

すごく当たり前のことなのだが,これが書かれている記事が見当たらない。

そしてウォーターフォールメリットはこれだけで,それ以外にはメリットと言えるものはおそらく存在しない。

やはりウォーターフォールにはメリットなどほとんどなかった

ここで,前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。

よく見るとこれらは,いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく,本来意味での「品質」,即ち利用者の役に立つか,使いやすいか,ということまで含むものであるスクラムアジャイル)を知る人であれば,「トレードオフスライダー」の「品質」に相当するものだと理解してもらえればよい。

そうすると,前節のウォーターフォールメリットは,以下のように言い換えることが可能である

ウォーターフォールメリットは<品質を固定することで>コスト納期ぶれるリスクを小さくできる点にある」

これで問題が明らかになった。要するにウォーターフォールは,コスト納期のために品質二の次にするプロセスなのである

その結果,これまでどんなことが起きてきたか

あくまで変更を行わなかった場合

開発の途中で,要件仕様問題が見つかったとしても,あくまウォーターフォール定義に殉じると,出来上がるのは「使いにくい」「使われない」システムである

事業会社IT会社に転生させることが、これからSIerミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に,その実例らしきものがでてくる。

禁を破って変更を行った場合

これを行った瞬間からウォーターフォールはその(ほぼ)唯一のメリットを失い,混沌が始まる。

最も多いパターンは,発注者側が(もはやスコープ品質を固定するという前提が失われているにも関わらず)納期コストの確定というメリット享受を譲らず,プロジェクトデスマーチ化する,というものであろう。あるいは,コストは譲るが納期は譲らない,というパターンの方が多いかもしれないが,いずれにせよデスマーチ化につながりやすいことは間違いない。

そしてこの副作用として何が起きたかというと,受注者側がそれを見越して納期コストバッファを積むようになった。当然それは見積もりの不透明感につながり,発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。

うまくいくのは非常に限られた条件が成立する場合のみ

スコープの変更の必要が生じたら,どちらに転んでもいい結果は得られない。となると,ウォーターフォールがうまくいくのは,「スコープが明白で,変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので,そのような案件がどの程度あるかはわからないが,直感的には「ほとんどない」のではないかと思う。なぜなら,そこまでスコープが明白であれば,今はパッケージSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。

もう一つの可能性としては,スコープが変更不要になるまで,とにかく事前の準備と調査を徹底的に行う,というパターンもありうる。しかし,これは「準備と調査」の過程事実上いろいろ試作することになる(そうしないと変更のリスクが消せない)ので,もはや作業プロセスの大半が実はウォーターフォールではない,ということになるだろう。

アジャイル銀の弾丸ではない

ではアジャイルプロセスを導入すれば,これらの問題はすべて解決するか,というとそういう話ではない。ウォーターフォールメリットが(ほとんど)ないことと,アジャイル有効であることとは,独立議論である

そもそも「アジャイル」というのは考え方であってプロセスではない。だから,考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって,害悪を撒き散らすことが多い。

アジャイルの考え方は,主に以下の2点でウォーターフォールと大きく異なる。

1. スコープの変化がありうることを前提としている

2. スコープ品質=役に立つこと(=使えないものを作らないこと)が最優先であり,そのためにコスト納期が変化を(ある程度)受け入れる

この考え方こそアジャイル本質であって,CI/CDやDevOpsなどは,変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし,CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。

また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために,スコープはできるだけ確定する努力をする,というのはアジャイルでも変わらない。変えるべき時は変える,という点が違うだけだ。なんでも後で決めればいい/変えてもいい,というのは「偽アジャイル」であって,害悪しかない。

もちろんこれがあれば何もかもが解決する,という類のものでもない。上述の2点があるだけで(少なくとも今のたいていの開発案件において)ウォーターフォールよりマシになりうるとは思われるが,別の問題(例:納期コストの変化をどう扱うかという問題)も,同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり,これが「納期コストの変化」と絶望的に相性が悪い。

もっとも,今の「ウォーターフォール」によるソフトウェア開発が,請負契約の成立条件である契約時にスコープを確定(し,変更しない)」を厳密に守っているわけでもない以上,これだけを理由アジャイル否定するのはどうかとも思う。

契約については,IPA等でも取り組みがあるようだが,いずれにせよ契約を行うのは発注者と受注者であり,受注者側だけでどうこうできる問題でもないので,発注者側の意識の変化を期待するしかいかもしれない。

2016-05-17

40代後半以上のプログラマは糞

CTO含む

人によるとは思うけど、俺が関わった会社プログラマの年齢の傾向から言うと全員あてはまる。


理由

過去の栄光を引きずり過ぎ

過去にそれで納品したか、褒められたかしらないけど、遺物を自慢しすぎ

今の時代にそぐわないプロダクトや、フローを自慢気に話されても何の得にもならない

自動化とか意味ないでしょ、ドキュメントありゃ誰でもできるよ、DBマイグレーション?めんどくせえ、スキーマダンプ管理しろよ」

はあ?どんだけ時代に逆行してるんですか?CTOがそれいっちゃオシマイでしょ。時代の流れ読めないの?

そう言ってるヤツのおかげでどんだけチームが苦労してきたと思ってんだよ


PHPとか誰でもできんだからフレームワークかいらないでしょ、そんなの使わずにスピーディに仕事しろよ」

はあ?ひとりでやってろよ

口は達者だけど、svngit 使えない。svn も使いたくないけど。

誰かの書いた独りよがりコードのせいで、リリースはだいぶ辛かったりする。

それが最近自動化や、フレームワークのおかげで、リリースの負荷は軽減されてる。それを全然鑑みないのはマジでクソ。


技術力はひと昔前のトップクラスなのかもしれない(多分そうではないと思っているが)が、マジで迷惑

属人的な要素を排除しようと、自動化CIヒューマンエラーを極力抑えても、俺様一言でまたプロジェクトが壊れる

マジでお前それでどんだけ金もらってんだよ、邪魔しかねーし、口だけは達者だから金ももらってんだろうな

ほんと個人攻撃したくないけど、老害死ねばいいのに

2016-05-09

2016年俺的IT業界勝ち組ランキング(日本編)

情報大学生の私が今のIT業界ランキング付けしてみた。

第1位

海外大手支社(Go◯gle, Micros◯ft, Ci◯co等)

勢いもあって楽しそう。高収入。結局は支社で本社ではない。結果を出さなければならない。

第2位

シンクタンク(野◯総研,産◯研,日◯等)

好きな研究に専念できる。頭が良かったりコネがある人が入れるイメージ

第3位

通信系(N◯T, KD◯I, Softank)

インフラから安泰。泥臭いこともあんまなさそう。

第4位

大手SIer(N◯Tデ◯タ, オラ◯ル等)

下請けに任せて結構楽できそう。好きなことはできないイメージがある。クライアントにヘコヘコ頭を下げてるイメージ

第5位

メーカ(Sha◯p, So◯y, To◯hiba等)

かつての日本の人気企業最近落ち目。いつリストラされるか怯えながら働いているイメージ。入れれば親からすごいと言われる。

第6位

大手Web系(Cy◯er Agent等)

ちゃらそう。溶け込めれば楽しそう。

第7位

ソシャゲ(Cy◯ames, ◯Lab, De◯A, Gr◯e, mi◯i等)

勢いはあるが、流行り廃りが激しいから安定感はない。市場ドメスティック

第8位

下請けSI

大手SIにこき使われるイメージブラック

第9位

ソシャゲ以外のゲーム

海外が圧倒的すぎる(一部のNin◯ndoなどをのぞいて)

10

底辺ベンチャー

地獄低賃金

相関的には

1>2>3>4>>5>6>7>>>>>8>9>>>>10というイメージ

ただ4,5,6あたりは人によって考え方に差があるイメージ。あと最近大手SI研究開発にも力を入れているところが多い気がする。

番外

大学教授

好きなことできる。高収入。頭が良くないと無理。

2016-03-30

climactic feat in “The Avengers.”) In Snyder’s new film, Superman appears, from the sff

But while pundits have occasionally contorted themselves into logical pretzels to explain away Ford’s casual racism and misogyny — “He was just drunk!” “He always fights for the little guy!” — none has ever been able to explain away his deliberate and calculated anti-LGBT statements and actions.

Ford never hid anti-LGBT animus. From his earliest days on council, when he opposed funding small grants to diversity and AIDS-prevention campaigns, he made it explicit that his opposition stemmed from disgust with LGBT people, not from a desire to protect the public purse.Superman grany przez Cavilla to ten sam poziom, co w Człowieku ze Stali - moim zdaniem Cavill bardzo się stara, żeby jak najciekawiej zagrać Supermana, ale to i tak jedna z najnudniejszych postaci w całym komiksowym uniwersum, więc niektóre wysiłki pozostaniezauważone. Moim zdaniem to wina postaci i fani muszą się do tego przyzwyczaić.

Trzecią postacią, która ma szanse zaprezentować nam się trochę dłużej na ekranie jest oczywiście “ten zły”, czyli Lex Luthor, który grany przez Eisenberga kojarzył się raczej z o wiele bardziej szalonym Zuckerbergiem z The Social Network, niż komiksowym czarnym charakterem. Być może się czepiam, ale gdyby Luthor się w tym filmie nie przedstawił, nie miałbym pocia kim właściwie jest ten rudy gość, który z jakiegoś powodu postanowił być bardzo złośliwy.

he astonishments of the quasi-Biblical clashes and catastrophes in the director Zack Snyder’s “Man of Steel” left me impatient to see hisBatman v Superman: Dawn of Justice.” The earlier film conveyed an awed and even terrified sense of the colossal, a delight in the cinematic ability to realize wrenching destruction and, at the same time, to shiver at the very imagination of it. Snyder turned the superhero universe around on itself, constructing backstories and out-there stories of an apocalyptic force; it was silly but potent, shallow but thrilling. Perhaps Snyder’s new film is the victim of great (or any) expectations, but “Batman v Superman: Dawn of Justice” remains literally Earth-bound, and this fair planet is where Snyder bumps up against the limits of his vision.

Where “Man of Steel” opens big, with an intergalactic origin story that has the heightened tone of pseudo-scripture, the first big set piece in “Batman v Supermanis a catastrophe from home, a virtual replay of the 9/11 attack on the World Trade Center, with Bruce Wayne (Ben Affleck) looking on with horror and hatred as the tower of Wayne Industries collapses (vertically) into a blinding gust of light-gray powderas a result of the battle waged by Superman (Henry Cavill) against the Kryptonian usurper General Zod.

That start gives off a strange whiff of competition with—or emulation of—Marvel’s irrepressibly successful “Avengers” films, the first of which, in particular, is an unabashed post-9/11 allegory. (The connection is surprisingly direct. One of the climactic moments of “Batman v Superman”—a leap from the ground that vaults through the atmosphere and into outer space—is a virtual duplication, both dramatically and visually, of a similar climactic feat in “The Avengers.”) In Snyder’s new film, Superman appears, from the start, as a hopeless naïf, a battler for good who doesn’t admit to his own capacity to do incidental evil, a blinkered warrior who deploys his nearly infinite powers according to his unquestioned moral intuition rather than to the prudent calculation of results.

O Wonder Woman, która zgodnie z obietnicami zadebiutowała w tym filmie mogę w sumie napisać tylko tyle, że… do tej roli wybrano świetną aktorkę. Przynajmniej z wyglądu, bo po tych strzępkach dialogów, które pojawiają sie na ekranie z jej udziałem ciężko się zorientować kim właściwie jest ta pani, która w pewnym momencie pojawia się z tarczą i mieczem u boku Supermana i Batmana.

http://www.chatakatka.sk/mega-hqtvdownload-batman-v-superman-dawn-of-justice-full-movie-hdq/

http://www.chatakatka.sk/mega-hqtvdownload-batman-v-superman-dawn-of-justice-full-movie-hdq/

2016-03-14

テストを書くとか、自動CIするとか、コードレビューとか、インフラ構築の自動化とか

うちみたいなギリギリの零細は、やってみたくてもなかなか手が出せないよね。今、目の前のリソースがないから

でも、いつまでも指くわえて見てるわけにもいかないから、少しずつでもやってちゃんと時代についていかないとね。

そういう所多いんじゃないかな。

2015-10-28

団塊ジュニアバブルと扱われるのはウンザリ 俺たちは就職氷河期ロスジェネだ!!

バブル景気バブルけいき)は、景気動向指数CI)上は、1986年昭和61年12月から1991年平成3年2月[1]までの51か月間

ただし、多くの人が好景気雰囲気を感じ始めたのはブラックマンデーをすぎた1988年からであり[4]、政府見解では、1992年2月までこの好景気雰囲気は維持されていたと考えられている[5]。

https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%96%E3%83%AB%E6%99%AF%E6%B0%97

 

 

団塊ジュニア

日本において、1971年から1974年までのベビーブームに生まれ世代[1][2][3]。第二次ベビーブーム世代とも呼ばれる[4]

https://ja.wikipedia.org/wiki/%E5%9B%A3%E5%A1%8A%E3%82%B8%E3%83%A5%E3%83%8B%E3%82%A2

現在の41~44歳

バブル景気1988年から定義すると、当時は14~17才学生

 

 

断層世代

1951年1960年に生まれ世代断層世代とされており、人口は約1660万人

団塊の世代の次に現れた世代であり、高度経済成長時代に育った。バブル景気経験しており元祖オタク世代でもある。

https://ja.wikipedia.org/wiki/%E6%96%AD%E5%B1%A4%E3%81%AE%E4%B8%96%E4%BB%A3

現在の55~64歳

 

 

もううんざりだよ!

高校生の時は大学生ブーム受験戦争

自分大学生になったらバブル崩壊して就職氷河期女子高生ブーム

社会人になっても正社員になれずでもううんざり

バブルなんか経験してねーっつの

2015-09-03

五輪エンブレム問題についての純丘曜彰氏(大阪芸術大学教授)の発言


五輪エンブレム白紙に戻った。

この一連の騒動の中で気になったのが、大阪芸術大学教授純丘曜彰である

反「佐野エンブレム」の急先鋒としてメディアで派手に〝活躍〟した人物だ。

エンブレム問題の経過をつぶさに見てきた者、デザイン周辺の知識をもっている者で

純丘氏の発言に疑問を持った人も少なくないのではないだろうか。

筆者の感じた純丘氏への疑問とは、

「明らかなデマの流布」「度の過ぎた個人的感情の表出」

そして「独りよがりデザイン論」「デザインに関する知識不足である



明らかなデマの流布


東京オリンピックエンブレムはもう無理筋8月10日

http://www.insightnow.jp/article/8591


瞬く間にメディアのあちこちに取り上げられ、反「佐野エンブレム」への動きを活気づけた記事である

デザインに関して識者といえる人物がここまであからさまにエンブレム下ろしを唱えたのは初めてであり、

純丘氏が五輪エンブレム問題の御用コメンテーターになるきっかけともなっている。

以下は、佐野氏のデザインしたトートバッグに関する部分である


ニーチェの独文の警句英文引用して、名前綴りコピー元のままに間違っていたり

(page:2 より)


Pinterest に一枚の画像として存在していたニーチェの一節、

その最後名前部分に綴り間違いがあり、佐野氏が孫引きしたために同じ箇所で間違えている、

すなわち佐野氏が Pinterest を利用していた証拠である、という論旨だ。


このニーチェの脱字の件は、丸ごと事実誤認なのである

Pinterest綴り間違いの画像などなく、佐野氏のほうだけがたまたま書き間違えていたのだ。

ここで問題なのは佐野氏が Pinterest を利用していたかどうか」ではない。

事実誤認、それも2ちゃんねるが発信源である単純なデマを、

純丘氏はのまま引き写して記事構成しているのである


この純丘氏の記事が出たころにはもう2ちゃんねるの当該スレは自らその事実誤認に気づいており、

ニーチェの一件は「佐野氏が Pinterest を利用した証拠」としては除外の方向へ向かっていた。

純丘氏は、佐野エンブレム下ろしに使えるものはなんの検証もなく使っていたのである

最低でもその誤字があるとされる Pinterest の元画像をその目で確認してから記事を書くべきだろう。


このような杜撰情報収集と決めつけで書かれた文章

大阪芸術大学教授」の肩書きで公にされてしまえば、何も知らずに読んだ人は事実と思い込んでしまう。

論文というのは人文科学であろうと事実を積み重ねなければならないものだが

こんなお粗末な方法文章を書いている人物が学生論文指導をしているのはいかがなものだろう。



度の過ぎた個人的感情の表出


オリンピックに潜り込んだゴキブリたち」8月20日

http://ironna.jp/article/1881


あんな黒いゴキブリ印は、生理的に無理。とても嫌な感じがする。汚らしい。穢らわしい。なにより不潔だ。あまりに不吉で、自分まで不幸に呪われそうな黒いゴキブリ。金と銀の足が夜中にカサコソと動き出して、きみの手の上に登り、パジャマの中にまで入り込んで来る。きみに、多種多様の救いがたい病原菌をなすりつけ、触覚をピロピロさせる。おまけに、突然に羽を広げて飛び上がり、きみの顔をめがけて襲い掛かる。考えただけでも寒気がする。あまりに気味が悪い。


この記事の、黒い生き物の比喩を用いた執拗レトリック

およびそこに貼られた画像は、読む者をいやな気分にさせる。

まるでいやな気分にさせること自体目的ひとつにもなってしまっているようだ。

純丘氏の「佐野エンブレムが嫌いだ」「黒が嫌いだ」という気持ちはよく伝わってくる。

だがそれは個人的感情であり、公にするにしてもせいぜい個人のブログにとどめるべきだ。

大学教授美術博士という肩書き付きでオピニオン系サイトに開陳するようなものとは思えない。

識者なら事実を元に冷静に分析し、問題を明らかにする役割を担うべきだろう。

騒動の中、感情ほとばしる文章で純丘氏は何を訴えようとしたのか。

これ以降、掲示板でもエンブレムゴキブリ呼ばわりする人が一気に増えていった。



独りよがりデザイン


佐野五輪エンブレム超弩級の駄作!」8月26日

http://www.insightnow.jp/article/8644


もはやリエージュロゴからの盗用かどうかは関係なく、

ひたすら駄作である、見るに堪えない、と力説している。

疑惑があるとはいえ、多くの人が関わって世に送り出されたもの

超弩級の駄作」「ゴキブレム」「梅干」と品なく形容する姿勢にもあきれてしまうが、

この他者制作物に対する容赦ない物言いは、おそらく氏の、

デザイン制作とは無関係な経歴(専門は哲学)と関係あるように思う。

むろんそれ自体問題ではないが、次章の「デザインに関する知識不足」も含め、

己の手にあまるデザインに関する解説を、あたかも〝識者〟として発表するのは

それこそ「無理筋」ではないか、と言葉を返しておきたい。


孤の中心がロゴの中心にある限り、この2つのパーツは、このロゴの四隅以外に配置することは不可能である

(1. 形態問題:パーツの寄せ集め より)


この一文の含まれ段落を「デザイン論」として理解できた人がいたら

ぜひ翻訳してほしい(もちろん逐語的な理解はしている)。

「9分割を元にフレキシブルな組み替えが可能」というアイデア否定するのが目的のようだが

なぜそこに「無理と矛盾」(純丘氏)があるのかわからない。

9分割の真ん中に必ず弧の中心が来なければならないデザイン上の理由とは?

さまざまな大きさ・形でさまざまな場所に弧が立ち現れていた、

あのアニメーションのどこに無理と矛盾があるというのだろう。


黒は、ほとんどすべての文化で、死や悪、権力、固着、腐敗、を意味する。同様に、赤は、血のシンボルであり、命や致命傷だ。それに金銀を加えるなど、まさに軍事配色のナチス悪趣味

(2. 配色の問題ナチスフラッグ色 より)


ここは純丘氏お得意の表象である

解釈はさまざま可能なのでナチスフラッグとみる者がいてもいい。

エンブレムを仮に芸術ひとつとするなら、芸術はさまざまな解釈に向けて開かれたものだ。

しかし、これは誰もが知っているようにオリンピックのために施された「デザインである

デザインとは、提示された課題を〝解決〟するものであって、

アートのように何ものからも束縛されない自由意志構成、配色したものではない。

見る者も「日本」で開かれる「五輪」の「エンブレムであるという情報とともに接する、

そのような場、コンテクストにおいて機能するようにあつらえたものだ。

解釈といっても常識的範囲がある。


佐野エンブレムスポーツを感じさせないとか、祝祭感が足りないとかいった批評は可能だ。

が、「ナチスフラッグである、「ゴキブリ」「致命傷」であるなどというのは

エンブレム出自コンテクスト無視した悪意のあるミスリードしかない。

ゴキブリ画像同様、ナチスの絵まで用意して独りよがり解釈

強くイメージとして植え付けていこうとする純丘氏の手法には疑問を禁じえない。



デザインに関する知識不足


どんな媒体でも、ほぼ同じような発色になるように考えておかないといけないのに、全体が印刷物無視RGBベースで出来ていて一般フルカラー印刷YMCKの四色のインクでは出せない「特色」の金銀が入っていたり

(上掲「佐野五輪エンブレム超弩級の駄作!」page:3 より)


デザイン生業としている人、その周辺に詳しい人で

この部分を読んで頭の中が「?」でいっぱいにならない人がいるだろうか。

この2行だけでも純丘氏が自分の手にあまること、自分のよく知らないことを

結論ありき、佐野下ろしを目的に書いていることが明らかである


CMYK を「YMCK」としているところはご愛敬だが、

純丘氏のこの不案内な言説はさまざまな場所で〝プロ〟のそれとして引用されてしまっている。

発表されたエンブレムRGB ベースでできていて、CMYK ベースではないらしい、

色指定の要領を知らず、特色を用いてしまっているらしい、

佐野研二郎氏は、デザイナーとしてはひどく低いスキルのまま今のボジションに祭り上げられ、

あたわない五輪エンブレム設計者の大役もしくは影武者の役を任されたようだ……


RGB ベースというのはモニターなど映像における混合方式であり

CMYK ベースというのは紙媒体など印刷で用いられる混合方式である

RGBCMYK は、媒体に応じてふさわしいデータを用いる、ただそれだけである

RGB ベースでできている」もなにもない。

ウェブでの使用に向けてロゴを配布するならば RGB だし、

ポスタープログラム印刷するなら CMYKデータを用意する。

純丘氏の中で佐野氏は、この知識としても初歩の初歩、

デザイン業務上、日々出くわしてはそれに従って作業している単純なことをまるで知らないという設定らしい。


ここに、さら意味不明な特色のくだりが加わる。

特色というのは印刷インクの一種で、

通常のプロセスカラーCMYK インク)で表現できない色をカバーするためのものである

エンブレムに特色の指定がしてあったというのはどこから情報かわからないが

(筆者は見たことがないので、まずはそのソース問題である)、

それだけをとれば、企業ロゴなどにおいては珍しいことではない。

RGBCMYK と同様、特色を用いるかどうかは運用現場に応じて「自然に」決まるのであって

雑誌カラーページなら金は4色分解(CMYK)で表現されるだけである

媒体や場面によっては、予算や仕上がりを考慮した上で

金や銀を特色にすることも、黒や赤を特色にすることも可能だ。

もちろんそのために CI マニュアルのようなものがあり、

特色で刷るならばここはこの色(PANTONE 、DICなどの番号)、

4色で表現する場合はこの CMYK 値、

そしてディスプレイ用にはこの RGB 値というように、列記されているのがふつうだ。


・特色番号(印刷用)

CMYK 値(印刷用)

RGB 値(映像用)


純丘氏の言葉を再掲する。

以下のような色指定を同一の紙の上に記すデザイナー想像できるだろうか。

すなわち、これが「ワンセット」になっていて、それ以外の指定CMYK 値)のない、

そのような色指定が本当に存在するだろうか。

純丘氏の作為産物か、氏がまたネットかどこかで拾ってきてしまったデマではないのか。

むろん常識的デザインの知識さえあれば、

このような「物理的に」とすら言っていいほど存在しえない〝キャラ設定〟をすることも

デマを拾ってきて書き写すとこともありえないのだが。


RGBベースでできていて(略)「特色」の金銀が入っている



最後


大阪芸術大学教授純丘曜彰氏の言葉は、目くらましのように効果を発揮してきた。

佐野五輪エンブレム超弩級の駄作!」での、ルネッサンスからフラットデザインへ至るくだりなど

エンブレムとはデザイン論において爪の先ほども関係ないが(ゴール地点のフラットデザイン自体なんの関係もない)、

このペダンティック解説や周辺タームは、氏の肩書きと一緒になって人々の目にもっともらしく映り、

エンブレム白紙化の力のひとつになったと考える。

芸術デザインの「専門家」(日刊ゲンダイ)と目される社会的影響力のある人物が、

この混乱の中で、明らかに事実に反すること、半可通なことを、

己の求める結論佐野エンブレム下ろし」に向かって品のない言葉作為的イメージを用いて

流布してきたことには、疑問を通り越してあきれてしまった。


ここには、筆者の知る事実デザインとその周辺に携わる者なら誰でも知っているような知識から

明らかにおかしいと思われるものについてだけ論じた。

五輪エンブレム騒動の中で交わされた、デザインに関する言葉への理解一助となれば幸いである。

2015-07-09

IT業界での悪は流行を追わないこと

流行勉強しないやつとは仕事したくない
最低限下記は知っててほしい

キーワード


■本

プロマネならアジャイルサムライとかチケット駆動開発とかリーン・スタートアップとか読んどけ。頼むから




頼むからこれぐらいは知っといてくれ。確かに流行り廃りがあって、追っていたもの崩壊したときツラいのはわかる。

しかし、上記はもはや流行りでも枯れてきてデファクトスタンダードになっているものばかりだ。

設定ファイルバージョン管理ちゃうとまずいだろとか、本番とは違うからローカル自分で手作業で変えろとか、何言ってんだおまえは。オーケストレーションツール使え。

クライアントが困ってるのに、オマエの環境で再現しねーとかあたりまえだろ。自分環境かえてんだから。同じにしろ

リリース対応20時間かかるとか何馬鹿なこと言ってんだ。10体制20時間とか1リリース予算300万超えかよ。本気かよ。

細かくリリースしろ。まとめんな。だから不具合もでかくなる。文言修正だけで3ヶ月待たせるな。機能の追加と軽微な修正は別だ。

あとエクセルやめろ。最初はいいけどメンテがつらすぎる。バグ管理テスト設計図なんかはもはやそれ用のオンラインツールあるやろ。それ使え。




もう少し最新のヤツは勝手に追え。

俺はそれらがデファクトスタンダードになるかコケるかは責任もてん。

少しだけいうならローカルビルドシステムはあっていいかもな。gulp とか grunt とか。

2015-05-14

最近フランス最高裁判決の一例

LA COUR DE CASSATION, DEUXIÈME CHAMBRE CIVILE, a rendu l'arrêt suivant :

Sur le moyen unique :

Attendu, selon l'arrêt attaqué (Cour nationale de l'incapacité et de la tarification de l'assurance des accidents du travail, 1er octobre 2013), rendu sur renvoi après cassation (2e Civ., 7 avril 2011, pourvoi n° 10-18.569), qu'ayant assumé au foyer familial la charge de son époux handicapé, Mme X..., épouse Y..., a été affiliée en1992 à l'assurance vieillesse du régime général, pour les années 1993 à 1997 ; qu'elle a saisi, en 2006, une commission départementale des droits et de l'autonomie des handicapés d'une demande d'affiliation pour la période du 1er janvier 1975 au 31 décembre 1992 ; que sa demande ayant été rejetée, elle a saisi d'un recours une juridiction du contentieux technique de la sécurité sociale ;

Attendu que Mme X... fait grief à l'arrêt de rejeter celui-ci, alors, selon le moyen :

1°/ que selon l'article L. 381-1, alinéa 5, 2° du code de la sécurité sociale, dans sa rédaction applicable au litige, la personne qui assume, au foyer familial, la charge d'un handicapé adulte dont l'incapacité permanente est au moins égale au taux fixé par décret et dont le maintien au foyer est reconnu souhaitable par la Commission technique d'orientation et de reclassement professionnel (la Cotorep), est affiliée à l'assurance vieillesse du régime général ; qu'en l'espèce, après avoir retenu que M. Y... était atteint d'une cécité post-traumatique depuis septembre 1946 et s'était vu reconnaître, dès le 1er novembre 1978, un taux d'incapacité au moins égal à 80 % avec attribution de l'allocation compensatrice pour l'aide d'une tierce personne, la Cour nationale a releexpressément que Mme Y... secondait son mari dans sa profession ; qu'il résultait ainsi des propres constatations de ladite cour que l'état de celui-ci rendait son maintien à domicile souhaitable au sens du texte susvisé ; qu'en l'excluant néanmoins, la Cour nationale n'a pas déduit de ses propres constatations les conséquencesgales qui s'en évinçaient et violé en conséquence le texte susvisé ;

2°/ que les circonstances, suivant lesquelles M. Y... avait exercé la profession de professeur de musique, avait été accordeur de pianos et organiste, avait animé les cérémonies religieuses, avait fait du tandem avec un voisin et avait été secondé par Mme Y... dans sa profession, ne sont pas de nature à exclure que le maintien de celui-ci, handicapé adulte, à son domicile fût souhaitable ; qu'en jugeant néanmoins le contraire, la Cour nationale n'a pas justifié son arrêt qu'elle a privé de basegale au regard du même texte ;

Mais attendu que l'arrêt rappelle que, selon l'article L. 381-1 du code de la sécurité sociale, est affiliée obligatoirement à l'assurance vieillesse du régime général de la sécurité sociale, la personne qui assume, au foyer familial, la charge d'un handicapé adulte dont l'incapacité permanente est au moins égale à 80 % au vu du guide barème pour l'évaluation des déficiences et incapacités des personnes handicapées, et dont le maintien au foyer est reconnu souhaitable ; qu'il retient que si M. Y..., né le 1er décembre 1937, atteint d'une cécité post-traumatique depuis septembre 1946, s'était vu reconnaître dès le 1er novembre 1978 un taux d'incapacité au moins égal à 80 % avec attribution de l'allocation compensatrice pour l'aide d'une tierce personne, son maintien à domicile n'avait pu être reconnu souhaitable ; que M. Y... a exercé la profession de professeur de musique, était également accordeur de pianos et organiste, animait les cérémonies religieuses et faisait également du tandem avec un voisin ; qu'il en déduit que M. Y... ne présentait pas un état rendant son maintien à domicile souhaitable ;

Que de ces constatations et énonciations, procédant de son pouvoir souverain d'appréciation des éléments de fait et de preuve soumis à son examen, la Cour nationale a exactement déduit que Mme X... ne remplissait pas les conditions d'affiliation à l'assurance vieillesse du régime général pour la période litigieuse ;

D'où il suit que le moyen n'est pas fondé ;

PAR CES MOTIFS :

REJETTE le pourvoi ;

Condamne Mme X..., épouse Y..., aux dépens ;

Vu l'article 700 du code de procédure civile, rejette les demandes ;

Ainsi fait et jugé par la Cour de cassation, deuxième chambre civile, et prononcé par le président en son audience publique du sept mai deux mille quinze.

MOYEN ANNEXE au présent arrêt

Moyen produit par la SCP Delvolvé, avocat aux Conseils, pour Mme Josette X..., épouse Y...

IL EST REPROCHE A L'ARRET ATTAQUE D'AVOIR dit Mme Y... ne pouvait prétendre au bénéfice de l'affiliation à l'assurance vieillesse visée à l'article L. 381-1 du code de la sécurité sociale pour la période du 1er octobre 1975 au 31 décembre 1992 et de l'AVOIR déboutée de ses demandes,

AUX MOTIFS QU'au vu des dispositions de l'article L. 381-1 du code de la sécurité sociale, dans sa rédaction applicable au litige, est affiliée obligatoirement à l'assurance vieillesse du régime général de la sécurité sociale, la personne qui assume, au foyer familial, la charge d'un handicapé adulte dont l'incapacité permanente est au moins égale à 80% au vu du guide barème pour l'évaluation des déficiences et incapacités des personnes handicapées, et dont le maintien au foyer est reconnu souhaitable ; qu'au vu des dispositions de l'article R. 381-1 du même code « l'affiliation des personnes mentionnées à l'article L. 381-1 est laissée à la diligence de l'organisme ou du service débiteur des prestations familiales » ; que si M. Y..., né le 1er décembre 1937, atteint d'une cécité post-traumatique depuis septembre 1946, s'était vu reconnaître dès le 1er novembre 1978, un taux d'incapacité au moins égal à 80% avec attribution de l'allocation compensatrice pour l'aide d'une tierce personne, son maintien à domicile n'avait pu être reconnu souhaitable ; qu'en effet, selon les déclarations de Mme Y... et de son conseil, Me ORHAN, M. Y... avait exercé la profession de professeur de musique, qu'il avait été également accordeur de pianos et organiste et avait animé les cérémonies religieuses, qu'il avait fait également du tandem avec un voisin ; qu'encore Mme Y... indiquait dans ses observations qu'elle avait secondé son mari dans sa profession ; que Mme Y... ne pouvait prétendre à l'affiliation obligatoire à l'assurance vieillesse du régime général de la sécurité sociale au visa de l'article L. 381-1 du code de la sécurité sociale ; que M. Y..., qui avait présenté un taux d'incapacité au moins égal à 80% depuis le 1e r janvier 1978, n'avait cependant pas présenté un état rendant son maintien à domicile souhaitable,

ALORS D'UNE PART QUE, selon l'article L. 381-1, alinéa 5, 2° du code de la sécurité sociale, dans sa rédaction applicable au litige ce texte, la personne qui assume, au foyer familial, la charge d'un handicapé adulte dont l'incapacité permanente est au-moins égale au taux fixé pa r décret et dont le maintien au foyer est reconnu souhaitable par la commission technique d'orientation et de reclassement professionnel (la cotorep), est affiliée à l'assurance vieillesse du régime général ; qu'en l'espère, après avoir retenu que M. Y... était atteint d'une cécité post-traumatique depuis septembre 1946 et s'était vu reconnaître dès le 1e r novembre 1978 un taux d'incapacité au moins égal à 80% avec attribution de l'allocation compensatrice pour l'aide d'une tierce personne, la cour nationale de l'incapacité a releexpressément que Mme Y... secondait son mari dans sa profession ; qu'il résultait ainsi des propres constatations de ladite cour que l'état de celui-ci rendait son maintien à domicile souhaitable au sens du texte susvisé ; qu'en l'excluant néanmoins la cour nationale de l'incapacité n'a pas déduit de ses propres constatations les conséquencesgale qui s'en évinçaient et violé en conséquence le texte susvisé,

ALORS D'AUTRE PART QUE les circonstances, suivant lesquelles M. Y... avait exercé la profession de professeur de musique, avait été accordeur de pianos et organiste, avait animé les cérémonies religieuses, avait fait du tandem avec un voisin et avait été secondé par Mme Y... dans sa profession, ne sont pas de nature à exclure que le maintien de celui-ci, handicapé adulte, à son domicile fût souhaitable ; qu'en jugeant néanmoins le contraire, la cour n'a pas justifié son arrêt qu'elle a privé de basegale au regard du même texte.

--------------------------------------------------------------------------------

2015-03-26

フランスの20minutesからうんこじゃない文章を持ってきた

http://www.20minutes.fr/societe/1571911-20150326-crash-avion-a320-pilotes-enferme-hors-cockpit-moment-crash

L'analyse de la boite noire contenant les enregistrements des voix dans le cockpit apporte de nouveaux éléments cruciaux dans l'enquête sur le crash de l’A320 de la compagnie Germanwings, mardi dans le Sud-Est de la France. Selon une information initialement rapportée par le New York Times, l'un des pilotes se trouvait en effet hors du cockpit au moment de la descente de l'avion.

Le point sur les huit scénarios considérés par les enquêteurs

«Au début du vol, on entend l'équipage parler normalement», en allemand, «puis on entend le bruit d'un des sièges qui recule, une porte qui s'ouvre et se referme», a déclaune source «proche de l'enquête» à l'AFP. Cette source n'était pas en mesure de dire si c'est le commandant de bord ou le copilote qui avait quitté la cabine de pilotage.

«Il essaie de défoncer la porte»

Ensuite, celui-ci «frappe doucement à la porte et il n'y a pas de réponse», précise une «source militaire» citée par le New York Times. «Puis il frappe plus fort et il n'y a toujours pas de réponse. Il n'y aura jamais de réponse. On peut entendre qu'il essaie d'enfoncer la porte», précise lale source.

Ces nouvelles informations, que la compagnie Lufthansa, maison-mère de Germanwings, n'a pas confirmées, permettent de réduire les hypothèses sur les causes du crash, mais posent aussi de nouvelles questions. «On ne sait pas pourquoi il est sorti, mais une chose est sûre, à la fin du vol, l'autre pilote est seul et n'ouvre pas la porte», conclut la source anonyme du journal américain.

Le copilote entré récemment dans la compagnie

Une source proche du dossier a indiqué à l'AFP que le copilote était entré «récemment dans la compagnie» allemande Germanwings (filiale de Lufthansa), «fin 2013 avec à son actif quelques centaines d'heures de vol». Une autre source évoque «300 heures de vol». Sa nationalité n'est pas connue avec précision. Lufthansa avait précisé que le pilote, quant à lui, avait «plus de 10 ans» d'expérience et «plus de 6.000 heures de vol».

Selon le journaliste de CNN Richard Quest, si l'un des pilotes quitte le cockpit, il doit systématiquement être remplapar un autre membre d'équipage de manière à ce que deux personnes soient présentes en permanence dans le poste de pilotage. Les éléments rapportés par le New York Times n'indiquent pas si c'était le cas au moment du crash.

2014-11-10

http://anond.hatelabo.jp/20141110010954

別のベンダーエンジニアSESで雇って受け入れテスト設計/実施 させる。

テストパスしたら検収印押す。某携帯キャリアはそうやってた。プロパーテスト設計テスト結果報告のレビューのみ関わる感じ。

もしくはCIで受け入れテスト自動化みたいな形のが理想だけど、それだとまた検収発生するので。

このような工程を想定してないのが現在の状況なら、受け入れテストやらずに検収とかはどっちにも不幸なので社内で体制構築してやるしかないんではないか。

2014-09-18

IT?企業に勤めているんだが、もう俺は限界かもしれない

ブラック的な意味で、ではなく。

会社採用しようとする技術が合わない。

人が足らないからといって、GUIだけでできるコードレスシステムを導入しようとする。

高いライセンス払って。

ユーザーにしてみれば

GUIの設定だけでできる(誰でもアプリ作れます)→御社不要ですよね?ってなる。

自分の首絞めてるだけだと思うのだが。

社員毎日Excel仕様書とにらめっこ。

その社員プログラミングできるようにすればいいだけだと思うのだが。

GitHub Enterprise導入してー

pull requestで開発回してー

CIしてー

な開発スタイルがほぼ標準となっているWeb業界が本当にうらやましい。

…はぁ。VSSに死を。

2014-09-17

トマシュ・ベルネル 2014/09/16のテレビでのチャット 前半

出典

http://www.ceskatelevize.cz/porady/10435049455-dobre-rano/414236100071086/chat/4995-tomas-verner/

訳を推敲しましたがざっくり訳なので間違っていたら申し訳ありません

■Q:ダニエラ・ノヴァコヴァー:おはようございます彼女いるかどうか、恋をしているのか、質問したいのですが。この質問をするために今朝は早起きしました。ありがとう

A:おはようございます彼女はまだいなくて、さしあたって探してもいません。数ヶ月これからツアーなので誰とも遠距離関係でいたくない。だけど恋はしています人生生活)での恋…

■Q:ルツカ:こんにちは、トマーシュあなたタメ口をきいていいかわかりませんが、Jen počkej, zajíciアイスショーがどうなるか質問したいです。あなたをとても応援しています、ご挨拶とともに。ルツカ

A:すてきなアンサンブルや素晴らしい脚本があって、すてきなショーになります。練習は骨が折れるけど、こういう環境楽しいです。

■Q:カロリーナ:おはようございます サインをお願いしたいのですが、どうしたらいいですか?

A:僕が演技する場所にきてください、もしくはスポーツインベスト場合によってはチェコスケート連盟に手紙をください。オストラヴァのサレザスタジアムでも(サインします)。

■Q:ミレナ:おはようございます。私の質問は、予定されているアイスショーとは関係がなくて、10月ジャパンオープンのことです。驚くべきSPを滑った最後世界選手権場所に帰れるのをあなたは本当にとても楽しみにしていますあなたの多くのプログラムから今なにを滑るのですか。回答ありがとう、多くの成功を祈ります ミレナ

A:ありがとう。またさいたまスーパーアリーナに帰れるのを小さい少年のように楽しみにしています。僕達のスポーツにおいてはユニーク環境です。フィギュアスケートをやるのに多分一番大きいホールで、スポーツを応援する満員の観客(自国選手だけを応援するのではない)。ジャパンオープンでは3月にとてもうまく見せられなかった昨年のフリーを滑ります。こんな感じでちょっとしたスポーツの追試です。

■Q:ペトル・コレチュコ:こんにちはマーシュあなたのように成功するには、何歳からスケートを始めないとなりませんか。ありがとう ペトル

A:いつかというなら4歳から7歳の間です。ですが100%成功するわけではありませんし、単なる推奨です。自分は5歳で始めました。

■Q:ニナ・ストゥルヘルコヴァー:おはようございますマーシュ。私は五輪からあなたの大ファンで、あなたをもう競技で見られないので母と一緒にとても暗くなっています。去年の世界選手権SP後の私たちの喜びは、言い表せません。私の考えでは、あなたの一番良い滑りでした。このようなスケートの喜びはものすごいです!質問したいのですが、トップスケーターは一日に何時間眠るのですか。:-D回答ありがとう、お元気で。

A:肉体的に一番きついシーズン中はなるべく休むように努めて、昼休憩や全部の時間で一日に10時間は寝ます。昔のシーズン必要に応じて7~9時間でした。

■Q:マルタノヴァー:おはようございます。狼または兎を演じるのですか?

A:僕は物語の細かい場面の要素をつなぐ人です。脚本では「運命」ということになっていますが、同時に狼や兎としても滑ります

■Q:DAYD:あなたの一番酷い転倒は?初めてスケートをしたときのことを覚えていますか?

A:初めて氷に立ったのは5歳のときで、初めてちょこちょこ歩いたのをとてもよく覚えています(頭の防具をやめてはずしただけです)。

一番酷い転倒は、くるぶしをケガした4Tの良くない訓練で。

■Q:DAYD:フィギュアスケートのほかのアマチュアスケートスポーツスピードスケートアイスホッケーはやりませんでしたか

A:スピードスケートは偉大な芸術やすごいしんどい喜びのためにやるスポーツという意見では僕はありません。ホッケーしますが、それは条件があって、余計なケガをしないでいい適切なチームがあったらという意味でです。

■Q:DAYD:誰かスケートのお手本はいますか?

A:エフゲニー・プルシェンコ高橋大輔です。あなたフィギュアスケートのファンなら、この二人について紹介しなくていいですね。

■Q:モニカ・スヴォボドヴァー:質問したいのですが、男性ファンもほしいですか?

A:こういう質問はされたことがないけれど、男性のファンも会場にはいますフィギュアスケートはみんなのための何かがありますきれいな女性音楽衣装

■Q:ラディスラフ:こんにちはバイクのヤン・ヴェルネル選手は親戚ですか、それとも名前が同じだけですか?

A:残念ながらただ名前が同じだけです。家族にこんなとてもスポーツでいっちゃってる人がいたらいいけど。僕の家族は、兄は僕のようにフィギュアスケートをやっていたのと、妹が新体操チェコ代表です。僕の家族内ではバイク熱狂する人は間違ってるようです…

後半は余裕があればやってみます

昼を食べます

2014-09-02

最近Web開発に感じる大きな谷(主にRails

10年くらいWeb開発業界にいて、ここ最近Railsアジャイルな高速開発的なものの周辺にいる。今は開発者マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。

あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニア面接やらに顔を出したりすることがあるのだが、ここ最近Web開発はますます主力級のゴリゴリ書けるエンジニア(いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る)と大したことのないエンジニアの差が開いてきたように思う。

主力級エンジニア

主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクト重要点とざっくりラフイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。

ソースコードフレームワークRESTfulの基本概念理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分フォローして修正することもできる。

仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい

大したことなエンジニア

一方、大したことなエンジニアは前述した流れが全くできない。

まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMSリッチUIなし)をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。

次に、品質が低い。できあがったと言われて念のためチェックすると、基本的CRUDレベルエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データseeds)の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。

パッと見に分からない部分もひどくて、ソース確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反JavaScriptエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能ソースコードコメントではTODOになっていたこともあった。

最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニア時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料ポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。

なぜ「大したことなエンジニア」がはびこるのか?

厄介なのは、こうした大したことなエンジニアも、Railsであればあちこちのチュートリアル記事書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。

彼らの作るサービスはまさに書籍チュートリアルサイトコピペ集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。

プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い(あえて「拙い」と書く)サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。

だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。

適切な例外処理担当者ミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニアなのだ

感じる「谷」

こうした主力級エンジニアと大したことなエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。

例えば、主力級エンジニアRailsだけでなくミドルウェアやprovisioning(chefとかansible)、最近ではdockerCIAWS新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん?」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。

そんなところに大したことなエンジニアはてブRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜(意訳)」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。

他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。

単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。

「大したことなエンジニア」の今後

こうした大したことなエンジニアは速度・品質難易度面で新規開発プロジェクトアサインするリスクが高いので、必然既存サイト運用メンテちょっとしたページデザイン文言修正)といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。

というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニア趣味ちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所(自作Webアプリ簡単に作れる啓蒙がなされている)がありそう。

ちょっと考えてみれば、文言修正デザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。

# もちろんそれでも保守契約責任分解点の関係外注するケースはあるだろうが、Rails採用するようなWebサービスは速度重視のことが多い

そんな中、この「大したことなエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステム運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。

せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。

早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか?

2014-08-16

職場上司ハイタッチをしてしまった。相手は一回り上のPM

そんなことが許される今の雰囲気が、とても楽しい

PMの口癖はフィジビリティ調査だ。

フィジビリティ調査とは、システムの実現可能性を調べることを指すけれど、

PMは、多分プロトタイプ開発によるCIを狙ってるのだと思う。

典型的なウォータフォール開発がメインの業務プロセスにあって、

フィジビリティ調査という名目ドキュメントの山を飛ばして、

とりあえず何でも先に現物を作ってしまうことで、

使用感や見た目等の非機能要求を洗い出しながら、

80%→120%への細かい微調整とレベルアップを可能にする。

設計書の山に、エクセルスクショ貼付けも健在ではあるけれど、

現物があるので、机上でデバッグを繰り返すよりよほど楽だし、そんなに辛くはない。

最も、表立って工数は積めないから"調査"の範囲である程度動くものを求められるわけで、

プロトタイプを開発している間は時間に追われること必死だ。

異常系の処理に全てTODOを書き込んで、ワンパスを通すことに腐心する。

メソッド名は悩んでいる暇はないからほとんど直感だ。

本来プログラム行程はリファクタリング機能の呼び出しとコメントの追加が

主な作業だけど、致命的な欠点が見つかってロジックをごっそり変えたことはないから

火事場の馬鹿知恵は、便器の上でうなり続ける時間匹敵するのだろう。

先日、朝の進捗の打ち合わせでお客様から出た業務アプリの改修案件について、

いつものように、とりあえず調べてみようよということになった。

システムテストまで含めて2.5人月かかるよと試算は出ていたが

俺とお前なら1週間かからないんじゃねえのとPMはこっそりうそぶく。

席に戻ったら、割り込み申し訳ないけど、と他のメンバーに謝って

該当機能調査PMと二人取りかかった。

今日のお題は、QRコードを取得している箇所でバーコードも使えないかという相談だ。

調査に取りかかる前に雑談をするのが最近の流れだ。

QRコードを開発したのは日本人だよと、トリビアから始まった会話の中で、

そういえば、と過去に行ったシステムテストで見つかったインシデントを話す。

バーコードを読んでいる箇所でふざけてQRコードを読み込んだら

通ってしまったので慌ててバリデーションチェックに追加したんですよと。

もしかしてバーコード関係API(GoogleのZxingをラップしたもの。他社開発)って

まりその辺を意識しなくていい?あ、やっぱりそうだ。今日中に終わるかもねみたいな流れから

Bluetooth機能のIF追加などやらなければ行けないことが決まって大雑把に機能分担して

コーディングに入った。

コーディングペアプログラミングだ。

Dドライブ下に同じドメイン配下の共有フォルダを置いてやり取りをする。

ここどうすればいい?みたいな質問をお互いのモニタを見ながら2,3回やって

残りの時間は黙々とコーディングをした。昼を挟んで小一時間

ほぼ同時に作業が終わったので、二人で個別に組んだコードマージする。

ビルドエラーもなく、すぐに終わった。アプリを立ち上げた後、

テスト用のバーコードQRコードはお互いに用意してくれているだろうと無言の目線を交わす一幕も。

バーコードスキャナを翳すと一発で読み込んでしまった。

上司が両手を上げる。普段空気が読めない自分が、何故かこの時は自然に手が出た。

普段表情が硬いメンバー女性クスクス笑っていたのでよほどテンションが上がっていたのだろう。

結果として、3週間PG時間を取るはずが、半日からずに終わってしまった。

別の作業に戻った後も、やり遂げたという高揚感にその日はずっと酔っていた。

今月末で上司プロジェクトを離任する。

上司はいつも笑っていて、仕事を楽しくさせることに努力を惜しまない人だ。

同じ会社だし、お会いする機会、仕事をする機会もまだまだあるのだろうが、

その時は今の距離感は許されないだろう。

短期で人が入れ替わり立ち替わりが当たり前の職場

自分はどこか人間関係も段々ドライに捉えるようになっていたから、

今はただこの寂しさに慣れない。

2014-08-02

戦う気力をなくした

普通の人からすると大したことじゃないと思うけど、もう会社の中に貢献しようと思う気が失せたので、その実態を書いておく。

ソフトウェアを自社開発していて、顧客自身Webアプリケーションを作れるようなマルチテナントサービス提供しています

直属の部長

上下関係にとにかく弱い

後述する彼の上司であるCTOの言いなり。

全てをイエスで返していくからCTOには都合がいいみたい。

とある機能設計CTOが「コレ出来るよね?」ってすごい適当な図((丸と線をつないだだけ))を書いて説明してて、

別の部署の部下がちゃんと理由((CTOには言葉意味すらわかってなかったらしい))を説明して何度も断ってたのに、

無関係なうちの部長が呼び出されて「出来るよね?」って詰め寄られて「簡単にできますよ」ってさらっと援護してた。

自身はその機能に関して別に作業も具体的な設計をするわけでもないので、頭を悩ませるのは援護射撃をもらった担当開発者たち。

社歴が長い分既存製品に関する知識があり度々オブザーバーとして呼ばれるが、今はその製品を開発している部署所属しているわけでもなく、

最近方向性技術動向に関しては全然理解していないにも関わらず。

普段は雑談しながら笑ってることも多くて人柄は悪く無いと思ってるけど、仕事に関しては全部CTOの発言を決定事項として下ろしてくる。

自分が板挟みになりそうなら部下を責める。あなた意図はどこ?

前例主義

思考停止と思えるほどに「今までもこうやって来たんだし」がバンバンから出てくる。

それを変えるやり方や新しい概念の導入に戸惑うとイライラして険しい顔でとにかく前例に合わせるようにする。

そうやって前例にこだわってきたからなのか、ちょっとしたエピソードがある。

たった4人の小さい部署から毎週のMTGの余った時間で持ち回りの勉強会を提案して実施してたけど、

彼以外の3人がミドルウェアフレームワークや新製品の説明をしているのに対し、彼は割とすぐネタが無くなったのか既存製品の話とか会社規則に関する話が出てくるようになって、

最終的に「忙しいから」というよくわからない理由で勉強会が消えた。

3人共「楽しかったのになぁ」って口を揃えたんだけどね。

製品開発

部長がいる僕の部署は新製品と銘打って開発を進めてるけど、例によってCTOの発言によって既に現行製品をなぞる方向でただの焼き直しを進める形になっている。

僕とサシで話した時は「現行製品と同じ機能を作っていくんだったら新製品を作る意味ってなんだろうねぇ(´Д`)ハァ…」とか言ってたくせにCTOの前ではハハハと笑っている。

以前指摘したけど、彼は新製品に関するプロダクトマネジメントステークホルダー立場ではなく、あくま開発者らしい。

じゃあ誰が責任者ステークホルダーなんだよと思ったけど、そんなもの既存製品にもいなかった。

おかげさまで「あの時はこんな事情があって…」ばかりで迷走しまくってるんだけど、そういう反省は生かさないんだな。

CTO

CTO(最高技術責任者)とは名ばかりの役員

CTO技術

基本的技術に疎い。もともと企画をやってた人らしいけど、アイデアマン((その場の勝手な思いつきは多い))ではないなぁ。

バズワードは大好きだけど肝心の内容は何も知らないし間違いを指摘しても「そんな解釈もあるよね」ってごまかす。

でもそれでCTOっぽく技術リードしていると思っているらしい。

その他にもいろいろ。「ifとforが使えれば何でもできるだろ」だの暴言も多い。

社長は彼がCTOとして問題があることに気づいているらしいが、役員だしなぁ。

来期は彼を開発部署の上から外してくれるといいな。でもその頃には僕はいない。

CTO案件相談と業績

目の前の利益にはすぐ食いつく。

「こんな案件の依頼が来ていてお金はいいんですが、確実に専用のカスタマイズ必要なんですが…」というのに開発陣にヒアリングなしに受注を確定させる。

サーバだってもともと予算はないけどサクッと購入する。開発者たちにサーバを買う予算はないって渋りまくってるのに。

うまく行けば自分の実績として社内で大々的にアピールしまくるが、火消しに走るときは営業に文句行ったり開発者に文句行ったり。

そして保守のことは全然考えてないので、積み残されたカスタマイズサービス群が開発者運用者、更には顧客への次の担当者を苦しめる。

現行製品仕様を切り替えた時にカスタマイズ問題が起こったおかげで製品仕様カスタマイズ考慮したあれやこれやを要求されてがんじがらめ。

ええっと、マルチテナントって一体なんだろう。

ちなみに、コレよりひどい自称SIerの営業が居るが、とにかくカスタマイズ案件を取って受注しておいてPMをしないもんだから

突然「お客さんが明日欲しいっていうんだけど」って焦って飛んでくる事態を連発する。

もちろんそんなことを連発してても「大型案件」を受注するから営業成績はMVPとりまくり。そこからずっと続く保守運用は彼の仕事じゃないしね。

CTOと新製品

CTOの話に戻ると、僕らが作っている新製品(?)に関してもとにかく自分理解範囲内に収めるべく発言しまくるし、

新しい概念を持ちだされて意味がわからない時は「それって現行製品のコレはできるの?」で畳み掛けてくる。

もちろんそれを聞いた部長は「そうですよね。それも必要ですよね!」って援護してきて考えてきた設計がことごとく旧製品になっていく。

どうやらCTOの中では既存ユーザが内容を移行できる新製品にする予定で、機能まで全て踏襲するらしい。

そんなもん誰が使うんだろうねぇ。

「新製品を世に出していくには実案件で実績を作っていかなければ」って話をして、案件を持ってきた。

最初は短期間で終了する案件だったけど、運用期限の決まっていない案件が発生している。

そのために製品名もリリース時期も何も決めてないけど、メインから分離した保守ブランチができ、APIv1は提供済みだから今後はv2にならざるを得なくなり、

それすら新しい案件で潰されていくことだろう。

当初は「お客さんにはあくま実験的なものと説明し、お金は取らない」((そんな話を受けるお客さんはたぶんいないって指摘したけど聞いてくれない))とか言ってたのに、

今は「売り上げあげなきゃこれまでの開発費がリカバリできない」とか言ってる。

現行製品の話

まともなデバッグシステムエディタを使わず果たしてユーザPHPコードを書いて開発をするだろうか?もちろん、否。

お客さんから依頼を受けたら営業担当者四苦八苦しながら開発代行を行い納品する。

それでも難しい場合パートナー企業に依頼をして開発をしてもらい、納品する。

あれ?うちって受託開発会社だっけ?

そもそもPHP以外の機能自体も複雑になってて、開発者自身が「ここに機能追加しろって言われたけど、そもそもこの機能どうやって使えばいいの?」と迷うレベルだし、

想定してた使い方を超えてバグを付く動きを相談なしでお客さんに提供しちゃってるもんだから

どれが正しい仕様なのかすら不明瞭になっている。

現行製品の開発の話

Javaってオブジェクト指向プログラミングが出来るはずの言語なんだけど、オブジェクトなにそれ美味しいの?って状態。

クラスがただの関数置き場になっててメンバー変数をいじるもんだから副作用のせいで同じオブジェクトを使う処理がことごとく影響を受ける。

それを避けるにはどうするか?もちろん似たような機能を持つ別オブジェクトを作ったり、別関数で違うメンバーを使うようにしたりする。

とにかく既存の流れを邪魔しないように新しいコードを作ればいい。おっと既存機能と同じ処理をする部分があるな。コピペコピペっと。

もうリファクタをしようと思う開発者はいないし、単体テストもないからできない。いや、無いんじゃなくて単体テストを作れない。

あちこちにDBコネクションとか埋め込んであって都度データ取得するからさなコードでも動作するにはDBコネクションが必要なんだ。

僕は新卒メンバーには「会社内の書き方は(どの会社でもそうだけど、ここは特に)独自のやり方だから、コレが正しいと思わないように。

今後も開発者であるためにはxUnitとかバグの少ないコードの書き方とか自分自身勉強するんだよ。」と言っておいた。

どの部署保守的

Conwayの法則とはよく言ったもので、まさしくリファクタできない密結合で暗黙のパラメータの多い組織。

自分部署立場を守る発言は多いけど、1年後2年後3年後どんなふうに仕事を進めていきたいからみんなでこうしていきましょう、って意思決定していくことは無い。

未来像を描いて推し進めようとする人とよく飲みに行くけど、その人もCTOからとにかく押さえつけられてたりする。

製品の結合度や他社サービスとの連携を図っていく基盤となる部分を提案しているのに、内容も全然理解してなくて「話が大きすぎて工数かかりすぎ」と言われ、

役員会でCTO勝手に「仕様検討にかかった時間負債になった」と報告したらしい。

僕の話

「なにより、こんなことで諦める俺が憎い!」じゃないけど、そんな中途半端に辞めようと思う僕も駄目なやつだとは思う。

誰にも頼まれないまま開発インフラを変える動きを有志で立ち上げて色々やってCI((例によってユニットテストできない))が回るようになり始めたけど、それも中途半端

運用インフラを変える部分もやっと使える状態になったけど、まだまだ中途半端

製品の1モジュールもきっと中途半端になるだろう。

そういった点は大変に申し訳ない。

でも、今のまま居たって僕に未来はない。

僕は僕自身未来の為に活動していかなきゃと思った。

こんなところでこんなグチグチ言ってちゃダメなんだ。

から、ゴメン!

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん