「設計」を含む日記 RSS

はてなキーワード: 設計とは

2016-12-04

[]

或るろくでなしの死を読んだ。短編集なんだけど、タイトル通りの強烈なキャラクターが代わる代わる出てくる小説だった。

全体的に貧者のホラーというか、弱者ホラーというか、社会的に追い詰められた者に降りかかる恐怖を描いた作品集だったと思う。

一話目の或るはぐれ者の死では浮浪者主人公だったし、六話目の或る英雄の死では第一線で活躍していたのに底辺まで転がり落ちてしまった人物が主になった物語がつづられていた。

自動車事故にあった遺族の物語があれば、若いのに将来設計もなく子供を孕んでしまった男女の物語もあった。

全部が全部そうじゃないんだけど、総じて昭和っぽいレトロ空気感でもって不快感をぶん投げてくる感じ素敵だった。環境モラルも整備され切ってない境遇昭和って、よく合うよね。

上で不快感をぶん投げてくるって書いたけど、全部で七つある短編集の全てで違った不快感を味合わせてくれるのも面白かった。。

例えば一話目の浮浪者の話だと貧者の善意健全に見える社会から踏みにじられる不快感が得られたし、二話目はとある人物の生き死にがたくさんに人々の思惑によって弄ばれている不快感がにじみ出ていた。

三話目はどうしようもない屑の話。ただ似通った話は昨今も絶えないので、実情を想像すると怒りがこみ上げてきた。

うって変わって四話目の狂ってしまった母親の話は終わり方が切なかった。鎮魂の儀式は人それぞれだけれど、そうするしかないってのがつらかった。

表題作である或るろくでなしの死は、ちょっぴり毛色が変わってダークヒーローものだった。ヨミさんかっこいいよ。サキかわいいよ。ただし、最後スナップフィルム撮影するシーンは短編集内でも随一の猟奇描写だった。

或る英雄の死は物語構造がちょっぴりメタい気がする。最終話の話はなんで二人で幸せに生き残るハッピーエンドにならんかったんやって思った。ホラー小説なんだし、死こそが救いなんだから仕方がないのかもしれないけど。

まあそんなこんなで雑多な作品が集まっていたので、どれか一つは好みの一編が見つかる作品集になっていたと思う。反面ずしんとくる不快な読後感はあまりなかった。

最後にもう一つ二つ。個人的に帯のセンスがないと思った。作者二人のコメント作品に水を差している気がする。ちょっとひどい。

そして解説もどき。あれいる? 自分語りブログででもやっててほしいと思った。イラストちょっとしたコメントだけ残してくれたらよかったのに。途中のポエムがひどい。

2016-12-02

増田が今年買ったもの10

12月に入ったので今年買ったものの中で良かったもののまとめてみた。特に大きなものが壊れたりしなかったのであまり大きな買い物はしてない。

来年は車を買い換えようかな。各社AppleCarPlayに対応してきたから使ってみたい。


1.iPhoneSEOCNモバイルONEの110MB/日コース

ソフトバンクで2年ほどiPhone5Sを使っていたが縛られるのが不満でMVNO転出した。

アップルオンラインストアSIMフリーiPhoneSE64GBを購入。やっぱりこの大きさ、この厚さ、そして完全なフラット状態が最高に使いやすい。カメラが高機能になったし、プロセッサWiFIもは指紋センサーも早くなった。その他に大きな変化はないけれど総じて使いやすストレスフリー機種変更できて大満足。とりあえずは電池がヘタるまでは使いたい。

5S下取りもしてもらった。使用期限のないアップルストアギフトカード7000円分。ゲオなんかの買い取りよりは随分高いし、多少の傷があっても付属品や箱がなくても減額はない。どうしても商品購入後に下取りになるのでSE購入代金に当てることはできず、その点だけやや不満。次にiPhoneMacを買うまで使わないかもしれない。

MVNOはとりあえず安定してそうなOCN選択。今のところ問題は感じないが、容量はちょっと心もとない。3GBコースへの変更も視野に入れている。自分ゲオパッケージ100円)を買って自分手続きしたがかなり面倒だった。パッケージを購入してネットアクティベーションコード入力して申し込み、その後4日後に佐川SIMが届いてもう一度ネットから変更手続き。大体1週間かかると思っておいたほうがいい。なんせ佐川から携帯関係バイトなどをしたことない人は辞めた方がいいかも。即日カウンター手数料3000円)もあるのでそっち行けば即日開通、ノートラブル。050Plusも使えるのだけど請求自分でまとめないと料金が発生するし、OCNでんわは専用アプリを使わないと割引料金が適用されないなど、落とし穴も多い。

でも安い。それにコールセンターはつながりやすいんでわからないことはすぐ電話確認するといい。

なお、OCNに乗り換えるなら毎月22日頃に申し込むのがおすすめ。開通日の10日後の月の料金が無料になるので12月22日に申し込んだら1月無料になります、たぶん。


2.DRETECのデジタル温度湿度

Amazonで一番人気のデジタル温度湿度計がこれなんだけど、すべての部屋とトイレ、脱衣所に設置した。何がいいかというと不快指数に応じて顔のマーク笑顔になったり怒ったりすること。暑かったら窓開けたり、寒かったらストーブつけたり、乾燥したら加湿器つけたりってのはこれまでなんとなくやっていたのだけど、温度湿度可視化されるので客観的判断できる。これが案外、素晴らしいこと。とても快適に過ごせるようになって風邪などひきにくくなったし、無駄エネルギー消費を抑えることもできていると思う。当方北海道なのでエアコンは使わないけどエアコン使っている人ならなおさらおすすめ


3.Panasonicの49インチテレビ4Kではない、普通の)

NTTXで8万円くらい。5年前だと32インチも買えなかったんじゃなかろうか。これまた激安。

スポーツ見ないし画質はさほど気にしないけど映画は大きな画面がいいなと思って購入。まあこだわりのない普通の画質。今の機種は以前のような遅れ等はほとんど感じないのでこれで十分。

音は薄くなった分、さらにひどくなったけどホームシアターに繋いでいるのでどうでもいい。というか今のテレビホームシアターにつなぐのが前提で設計されてるんだろうね。

まあ安かったんで何年使えるかなーと思っているけど、LEDなので蛍光管よりは遥かに長持ちするだろう。10年は無理でも8年くらいは使えるかな。


4.Amazon Fire TV Stick

上に書いた49インチテレビに挿して使ってる。

ドラえもん映画見放題キャンペーンやってるときに購入。子どもが全部見てかなり満足した模様。だがしかし今はPRIMEビデオからは外れてる。これにはがっかり

自分ナショナルジオグラフィックドキュメントをあらかた視聴。とてもよくできているのだが番組の数が少ない。

まりこだわらなければ暇つぶしにはちょうどいい。地上波よりは遥かにたくさんのコンテンツの中から選べる。地上波を見ることがほとんどなくなった。

回線auひかりだけど、画質、音質もDVDと遜色ない。普通の人なら十分満足のレベル

PRIME以外の映画レンタルが500円くらいなのでツタヤで新作を借りるのとさほどかわらない。借りに行かなくていいし返さなくていいのでたまに使う。楽ちんだよ。


5.YOSHIKINグローバルの研ぎ直しサービス

10年くらい自分で研ぎながら使っていたグローバルのペティナイフ、小さな刃こぼれが目立ってきたので工場で研ぎ直してもらった。

包丁ダンボール梱包してレターパックライトに入れて発送すれば研ぎ直して代引きで発送してくれる。代引き手数料込みで1本1000円。激安。

少しだけ小さくなったけど、新品同様になって帰ってきました。硬いもの切らないように大事に使ってる。トマトを1ミリスライスにできるよ。

ティナイフは他に藤次郎プロも使ってるけど、グローバルの方が適度な重さで握りやすくて使いやすい。値段が藤次郎プロの倍くらいだから当然かもしれないけど。


6,マイヤー フジマル アゲイズ3 IH対応 フライパン 26cm

5年くらい東急ハンズハンズセレクトのテフロンプラチナフライパン使っていたのだけれど、テフロン限界になり、買い替え。半年前はアマゾンで1500円くらい。激安だった。今は3000円くらい。

こちらは素材がアルミではなくステンレス。なのでかなり重いのだけれどもそれが逆に良かった。温度が下がりにくいので素材が美味しく焼きあがります

滑り具合はテフロンほどツルツルではないけれどかと言ってこびりついたりはしない。業務用なので耐久性がかなり高いと思われる。何年使えるか、期待している。


7,デロンギエスプレッソマシンコーヒーラインダー

型落ちになったEC200Nをアマゾンアウトレットで購入。同時にKG364Jも購入。両方ともいわゆる新古品。ほぼ新品で使用感なし。前者が5000円くらい、後者8000円くらいだった。激安。

あとステンレスタンパー1500円とラトルウエアのミルクジャグ600cc3000円くらい、それとトラーニのフレーバーシロップやらソースやらをいろいろ買って自宅カフェをはじめた。

自宅でカプチーノ飲めるってのは最高。ほぼ毎日飲んで幸せになってる。


8,ロイヤルTのルイボスティーコストコ

今年はルイボスティーを飲み始めた。これがなかなかいい。

毎日ドリップコーヒーマグカップ3杯くらい飲んでいたのがカプチーノ1杯だけになった。で、そのかわりのルイボスティーカフェイン摂取量が激減。体調もすこぶる良くなったと思いますよ。疲れにくくなったな。


9,コンビニの飲むヨーグルト(とコストコ冷凍ブルーベリーと季節のフルーツスムージー

季節のフルーツコストコ冷凍ブルーベリーと飲むヨーグルト適当ミキサーに放り込んでスムージーにして毎朝飲んでる。

以前はヨーグルト牛乳を混ぜていたのだけど、飲むヨーグルトで作った方が楽だし味も安定して美味しくなることに気づいた。

セブンローソンで1リットル買うと牛乳ほとんど同じ値段。ヨーグルトメーカーで作るのがめんどくさくなってやめてしまった。

ちなみにカレーに使う肉は飲むヨーグルト少しとカレー粉に2時間くらい漬け込んでから使うと臭いが消えてホロホロになってとても美味しいよ。


10,シャトルシェフ

暑い時期に煮込み料理するのがしんどくて型落ちの2.8lを6500円で購入。主な目的が暑さ対策だったのだが、少しはガス代も安くなるかなと思ってたけど、これが大成功。ガス代が激減。1年で元が取れたと思う。煮込み料理ってガス代かなりかかってたんだな。

シャトルシェフは高温にならないので圧力鍋みたいなシビアさがない。少しくらい煮過ぎても煮詰まらないし、火を使わないので見張らなくていい。外出前に仕込んでおけば帰ってきたら柔らかくなってるし、電気代もかからない。

カレー豚汁どて煮煮豚、蒸鶏なんかが楽にできる。ゆで卵温泉卵簡単。もう元には戻れないね

2016-11-25

東京の家が寒すぎるのは解消するのか(建築業界の人教えて!)

東京wwwwwこんなちょっとの雪でwwwww」と言ってた新潟まれの人が関東暮らし始めて思うこと

http://togetter.com/li/1052206

寒冷地から東京移住してきた人がほぼ全員思う事は

外の気温はそこまで寒くないのに、家の中が寒すぎる!!!!!

理由は当然ながら断熱を考えた家の設計になっていないからだ。

断熱は今や夏もヒートアイランドで1日中冷房かけっぱなしにしなければならない東京では必須だと思う。

最近立ってるアパートとか一軒家ってちゃんと断熱材いれたり二重窓にしてるの?

建築業界の人教えてー!

2016-11-24

東大女子 vs ダイヤモンド山崎元

http://anond.hatelabo.jp/20161115110829

東大女子


vs

社会に潜む「女性優遇」、日本男子微妙に生きにくい

http://diamond.jp/articles/-/108988 山崎元



しろ匿名ダイアリでこれだけの記事がかける東大女子

補助をつぎ込むことの正しさがよくわかるという意味で出色の

対決だと思う。



東大生女子記事自分実体験しているということもあるのかもしれないが

ものすごく的確に、どの層にどういった金額をしはらうとどういう補助が行える

のかということが極めて定量的に書かれている。


東大も、ばらまいているわけではなく、分析をしてきちんと必要な層に必要な援助を

しようとしていることもわかり、大変おもしろかった。



そこでこの山崎センセのこの記事である

どうやったらこんな印象だけで記事をかけてしまうのかが.. 経済学者ですよね..



どういう補助も、賛否両論は生まれるが、結局その補助がどれだけ、きちんと目的があり

そしてその目的に沿ってきちんと考えをもって、設計され、目的を叶える運用されるか

によって評価されるべきだと思う。




それはただの印象を羅列するだけでは決して評価できないし、自分の専門領域

経済学なのであれば、より定量的根拠を出しながら論じてほしい。



私もレディースデイとかで映画料金が女性だけに有利に値段設定されていることには

非常に不可解な気持ちになる。(完全に民間制度批判はできないのであろうが、

文化を育てるという視点とかなさそうで安いクーポン感がいや。)


ただ公的機関が(しか東大が)意図をもって

批判が起こることも知った上で)投入した制度なので、後ろにきちんと意図がある

のは考えた上で論じてほしいと思う。



この記事は一介の記者が書いたのかとおもってたら山崎元であることに気付いて本当に驚いた。

2016-11-23

IT芸人枠について、コード書くときより誰が来るかなーとワクワクしながらイベントブースで出すおつまみ選んでるときの方が活き活きしてるタイプの社交性の高い職業エンジニア広報ぽい部署ジョブチェンジした方がいいのでは、という気持ちは心の底からあります

IT芸人的な人が評価されるためにITエンジニア全般広報役割負担させるより、得意な人が技術広報になった方が幸せでは、と。

会社制度として、IT芸人大事、ならば一億総IT芸人的な雑い制度設計になりやす会社があることを踏まえると、そう思います

2016-11-20

からお前らはブラックなんだよ?

ローカル仮想環境たてて開発するとマシンスペック足りない人いるか

みんなで一緒の開発環境上で開発しようね。

その際上書き事故防止のためにロック機能必須だね」

→ アホですか?

Gitは使い方難しくて工数増えちゃうからSVNソース管理しようね。

ソース触るときは他に開発中の人いないかチャット確認してね。」

→ アホですか?

「開発環境を構築するときは全部ちゃんとメモしてね。

あとで検証環境と本番環境でも同じ手順で構築するからコマンドまで細かく書いてね?

chef?ansible? itamae? 自動化するとミスがあったときにハマっちゃうからね。

手動が確実だよ。」

→ アホですか?

「Java8?使ったことないか不安だね。今回はJava7で行こうか。実績あるから安心だね」

→ アホですか?

JavaEE?使ったことないか不安だね。今回は大規模案件から使いなれたJavaSEにしよう。

アプリケーションサーバTomcatいいね

→ アホですか?


設計書書くとき知識がない人がみてもわかるように書こうね。

かいロジックまで設計書まで落とし込めるといいね

もちろんExcelで書いてね。更新するとき更新履歴シートに更新内容書いてね。

ファイル名は日付をちゃんと書くこと。更新したらチャットで報告してね。」

→ アホですか?




こんな会社は僕のとこだけだよね?

大多数のプログラマは…

IT業界に努めてもうそろそろ二桁年。

そこそこの企業特にWeb系で渡り歩いた経験から真実を書こう。

一般的プログラマと呼ばれる人たちは

はっきり言う、ほとんどのプログラマ自称する人間の 9 割はコーダーである

言われたものを作る事はできるが、それ以外何も出来ないと言って過言ではなく、何もしない。

そんな驚きの生体をここに晒していく。

一般的コーダー自称プログラマ)は、アプリケーションの基盤が作れない

標準化と呼ばれるプロセスで、プログラマ環境設計、組み合わせ、開発プラットフォームセットアップ、開発環境の構築手順作成、開発手順の作成必要技術考察を行う。

なぜそうなったのかは知らないが、一般的にそうなっている。

その環境に浸っているせいか、彼らはゼロベースものを作ることが出来ない。

彼らにできるのは HelloWorldコマンドプロンプトで表示するプログラム程度の事しか出来ない。

複数ソースの連結、ライブラリの読み込み、サーバへのデプロイ、どれも手動で出来ないのだ。

一般的コーダー自称プログラマ)は、保守性を考えない

彼らは自分に任されたものを動かせればタスクが終了する。

逆にそれ以外のこと、コードの読みやすさや、クローン率の低減、メソッドコメント記載などの保守に関わることをしない。

それは彼らにとって「必要ない無駄作業」としか考えないのだ。

早く仕上げるためなら、似たような動いてる箇所から、よく読みもせずにコピペを行う。

そして彼らは、作るより運用する期間の方が遥かに長くて、その間に修正地獄を見るという簡単論理に気づかない。

…何度味わっても気づかない。

一般的コーダー自称プログラマ)は、勉強しない。

一般的プログラマコーダー)は勉強をしない。

たとえするとしても、業務時間中に業務で使ってる技術ピンポイント学習するだけだ。

勉強会は確かに多い。「.dits」何かがいい例だ。

だが、プログラマと呼ばれる人間の母数に比べれば微々たるものだ。

彼らは言う「土日にまで仕事してられるか」「勉強会行ってるの?馬鹿か?」

あえて言おう、馬鹿は彼らだ。

一般的コーダー自称プログラマ)は、自分の使う道具がわからない

Web仕事をするならIDE統合開発環境エディタコンパイルテストデバッグ実行などを画面から行えるツール)はほとんど必須エディタで済ませる事も出来なくはない)が、彼らは状況に応じたセットアップができない。

たとえば「Mavenプロジェクト管理ツール)、checkstyleコーディング規約チェック)、editorconfig(改行、インデント文字コード設定)」が入っていたとする。

するとEclipseなどを使うとして

  1. どのプラグインを入れればいいか調べられない
  2. どうやってプロジェクトを取り込めばいいかからない
  3. プラグインを入れても設定方法がわからない(IDEデフォルト設定と、プロジェクト内の設定の違いを認識できない)
  4. IDE の設定画面がわからない

マニュアルチュートリアルを用意しないと、道具の使用もままならない。

一般的コーダー自称プログラマ)は、テストコードで書かない

テストをなるべく機械やらせようということの利点が理解できない。

コンパイルして動かして確かめればいいと本気で考えている。

そのために、何十回もコンパイルデプロイアクセスログインの手順を何度も繰り返す。

関連する他の修正を行うたびに繰り返す…。

そしてやっと動くとひと仕事終えたと満足感に浸る。

一般的コーダー自称プログラマ)は、プライドが無いか、変なプライドを持っている

ラリー・ウォールというとある有名な人物Perl開発者にしてC言語ハッカー)がいる。

彼の言う三大美徳に「傲慢」がある。

これは、自分の作るもの完璧なのだ、だから完璧であるように出来る限りのことをするという美徳である

一般的コーダー自称プログラマ)は、このプライドはない。

彼らは金のために嫌々動くだけのものを作るのだ、動きさえすれば報酬は変わらない、よって当然完璧かどうかなどどうでもいい。

同じ金でより良いものを作るのではない、要件だけ満たせばよいのだ。

変なプライドを持つコーダーは、それで運良く成功すると、自分知識は正しい、自分技術は十分なのだと考えている。

こういう人間は、プライドの無いコーダーよりたちが悪く、うまくいかないと他人環境のせいにする。

そして調べず周囲を苛立たせるのだ。

おわりに

土日に自ら勉強会に行くプログラマや、それこそ 50 人以下などという会社であればこうした事はあまりない(んじゃないかと思う。)彼らは自分でなんでもやらないといけないからだ。

だが、大企業に飼われる子飼い企業派遣(そもそも人手のみを求められる企業)、100人以上の企業では、役割分担に伴いこうした状況が多々発生する。

だが役10年、エンジニアを見てきた結果は変わらない。現実問題こうなのだ、こんな人間が大多数なのだ

人の多い企業ほど考えたほうがいい、それでより良いものが生まれるのかと。

必要とされる技術だけを叩き込んで金にしたいと言うのは分からなくないが、基本姿勢思想はどうなんだと。

経営者マネージャーよ、あなた方の言う「最適化」とは現場が日々考え行っている最適化か?人員最適化だけを行って、生産性が伸び悩んでいないか

そのあたりは考えた方がいい。

都市NATM工法

NATM工法に関して妙な誤解が流れている様なので書いておく。

都市NATMは開削できない地下大空間工事区間で一番使いやす工法

開削は既設管を移設する必要以外にも覆工、かさ上げと開削部の周辺を大量に占有しないといけないので、

都市部採用するのが本当に大変な工法。「ここからここまで開く」なら平地でも排水が難しい都市部なら「ここからここまで開削の為にかさ上げ工事して、ここからここまで距離とる(道路なら工事期間利用停止)」となってしまう。昔は都市部からって距離取らないでやって水流れ込んだり踏み抜いたりで事故が発生したりした。

それなりに難しい工法だが大空間工事に関してはリスクは他とほぼ変わらない

シールドでも本坑から空間への拡幅工事を行うとき、同じ工事を行うために、先進抗となる部分の違いでしかない。先進抗での分割掘削ならば補助工法によって安定的に地山形成しながら進めるため、むしろ危険性は少ないとも見積もれる。

(もちろん海底下の浅いところに沈下が使えずシールドさないといけないみたいな特殊な条件なら別だが。そんなところはそもそも大空間施工しない)


事故の周辺状況

しか事故が起きた。二度も前あったじゃないか!というのはさすがにどうかと思う。

14年立坑の工事での横からの土砂流入による陥没はプロセスが違うし対策も違う。おそらく周辺地盤の改良ミスだろうが、埋め戻しを優先してしまったので確認が難しい。

(この点においてJV現場周辺の調査より先に埋め戻しをJVに指示した市の対応拙速かつ問題ではある。国交省から警告書を部長名でだされる理由がある)

いずれにしろこれは監督者としての市の問題ではあるが、工法選択レベル問題ではない。というかこれは工法の様々なパラメーターの問題可能性の方がはるかに高い。

日刊建設工業新聞に載った記事は公開期限を過ぎているようなので、日経コンストラクションの方を引くが、

http://kenplatz.nikkeibp.co.jp/atcl/cntnews/15/111600596/

かぶり2mも、傾斜を下げた先受け鋼管によるAGF工法も、先進抗も、通常の対策としては特におかしくはない。

 ただ記事中にもあるように、初期設計時より先受け鋼管の長さを切って上部長が減っていたのは、改良地盤連続性が減っていた(波打っていた)可能性があり、そこで上部層にたまりの様にあった可能性がある火山灰層で構成された帯水部が岩盤上部にスパイクのように風化により切り込んでいて、そこから抜けてきたというのはシナリオの一つとしては考えられる。

その場合は過圧密な地層が主体だったのが逆に災いしたのかもしれない。

*AGF工法というのは前方にある程度の間隔で傾斜をつけて挿入した先受け鋼管を通して改良材を加圧注入し、鋼管が重複する部分をつくることで連続的な地山改良効果を得るものなので、長さを減らすと硬化が及ぶ厚さも同時に減る。しかし抗の安定性自体は側面ロックボルトの変更で対応できるので地盤が急に傾斜していなければ問題ないし、傾斜してるだけならば挿入時にリークがあって変位計測にも出るのでそこからの支保工の変更などで対応可能なため、変更した設計自体は通常なら問題があるとは言えない。今回は先受け鋼管の一部にSAAという傾斜計のチェインを入れた変位計測システム(TN-Monitor)を運用していた様なので、その場合ならわかったはず。

いずれにせよ、地中工事現代でも、どの工法であってもどの区間であっても、適切と思われていたガイドラインによって施工しても、未だにミス以外のカバーできない問題が出現する世界であって、それは都市部では更に顕著であるということは言える。コスト的に現実的ラインに収めつつ確実性をあげるには、施工場所工事履歴を完全に活用できるようなデータ基盤が必要となるだろう。浅地下の埋設管からの影響も、そこでの工事状況から推定できることもたくさんあるので、調査費用の削減の為にも路盤情報システムの整備が進むことを期待している。

本当にお願いしますよ整備局の監督官庁地方自治体さんには。

2016-11-19

http://anond.hatelabo.jp/20161119020946

Webサービス会社というなら、早く作って早く出すことは最重要なんじゃないだろうか

「遅くても」正しいコードを、きちんとしたテスト設計を…というのは、受け入れられない発想だったりしないだろうか、少なくとも増田会社では

だいたい10年同じWebサービスを使うということが珍しかったりする

作って重ねて新しく作って古いもの廃止しての繰り返し

使い捨てのものビジネスニーズに合う短時間で作ることが重視されているのかもしれない

増田の正しく理論的なプログラム開発を否定しているわけではない

正しい構造テスト設計も、全体として考えれば早く効率的からこそ正しい、自分はそう信じている

増田必要なのは、チームに合わせた美しくないコードを書く努力をすることではなく

増田が拘っているプログラミング技術を皆が使うことで、結果的に全体として効率化されることを周囲に伝えることじゃないだろうか

2016-11-18

http://anond.hatelabo.jp/20161118215013

第一に、やはりマークアップ記述するコストが非常に大きいように思える。

元々HTMLが書けない素人向けの仕組みだぞ。Wikipediaでもゲーム攻略Wikiでも素人が覚えて編集してるのに技術者が何言ってんだ。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

案件ごとに設計書分けたり、後でマージしたりは、どっちにしろ面倒だと思うけど。


デメリットで思いつくのは、Wikiソフトウェアは廃れる可能性がある、かな。

メンバー設計書をwikiで書きましょうって提案された

私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。

UMLなどの作図にツール使用することはあっても、最終納品物としてはExcel画像として張り付けて提出していた。

もちろんExcel方眼紙については批判もあるのは理解しているが、開発者運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。

 

そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。

設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。

開発者運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwiki知識ほとんどない。

 

彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwiki用語集として活用していたそうだ。

wikiには顧客業務専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。

そういった運用をしているうちに彼はwiki自体設計書とできないか考え、調査したところ実際にwiki設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。

 

私も今調べてみたところwiki設計書を書くという運用をしている会社もあるようだが、メリットデメリットwiki知識があまりない私には判断しかねている。

ぱっと思いつくデメリットとしては、第一に、やはりマークアップ記述するコストが非常に大きいように思える。

記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコスト必要となるように思える。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

 

メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。

第二に、改訂履歴差分が標準で用意されていることもメリットであろう。

第三に、検索が容易であることがあげられる。この点はExcel比較して十分大きなメリットだと思っている。

 

私がぱっと思いつく限りではこんなもんである

はてな諸兄の中にwiki設計書を書いたことがある方がいれば、メリットデメリット、その他運用において気をつけるべきことなどあればご助言願いたい。

 

なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。

そのため自社の標準の設計テンプレート使用する予定だった。もちろんExcelである

 

また、設計作成使用するツールExcelWord以外の素晴らしいツールがあれば教えていただきたい。

どうかよろしくお頼み申し上げ候。

設計について善し悪しを議論をするのは難しい

ブレストとかあるじゃん

あれって、非常に単純なアイディアに対する議論が主なんだよ

構造的になっているような、設計必要タイプの話は中々議論ができない

できるとしたら、その筋のプロ同士とか、デザインパターンが決まったものについてとか、天才同士とか、そのくらいだ

 

からブレストから始めると、構造的な問題に対する話が漏れ

結果「みんなで考える」より「ひとりを中心にして設計する」方がうまくいくケースが有る

そして、そういうケースは得てして非常に重要ものだったりする

(例:物語脚本組織づくり)

 

何かしらの設計に携わる人は、この件について知っていたりするものだが

多くの人は「みんなで知恵を出し合えば解決する」と勘違いしている

そういう風にして手詰まりになるシーンを何度か見たことがある

2016-11-17

生命保険の乗り換え

40歳自営業

費用も安くなって内容もほぼ同じ生命保険に乗り換えようとしている。

でも、困ったことがひとつ

自殺できない。



自営業調子が悪くて、妻と子供2人のためにお金を作れない。

今入っている生命保険は、自営業調子の良かった時に入ったので

死亡保障もそれなりに設計している。

死ねば、公的保証と妻の収入を足せば大学学費も賄えそうだ。



でも、保険を乗り換えると3年間は自殺できない。



幸い、借金住宅ローンだけ。これも死ねばなくなる。

生きて得られる収入よりも、死んで得られる収入の方が多いか

そろそろ死のうかと思っていたところに、こんな話が保険から来た。



論理的に乗り換えを拒否する理由がないので、このままでは話が進んでしまう。

別に止めて欲しくて書いているわけじゃない。

自分自身でどっちがいいか客観的判断するために書いている。

2016-11-11

http://anond.hatelabo.jp/20161111142306

自分作業の合間にslack見たりメールチェックしたりするのと、他人から作業を中断されるのとは全然別の話。

誰でも1日のうちで生産性には波があり、それが低いとき設計コーディング以外の何かをするのは問題ない。

ただし、それを見たことにより10分以上の想定外作業をしなければならなくなるならば、1日の生産性に多大な影響を与える。

http://anond.hatelabo.jp/20161110110829

さらにその他の社会保障社会福祉費用をベーカムに移せば結構いけるかも?



[PDF]社会保障給付負担の現状(2016年予算ベース) - 内閣府

http://www5.cao.go.jp/keizai-shimon/kaigi/special/reform/wg1/280915/shiryou3-1-2.pdf




医療はともかく、年金福祉の80兆円はBIに置換可能だろう。かなりデカイ。

もっとも、財源の方は結構難しい。


失業者が増えた世界保険料どの程度取れるかは難しい。

といっても例えば66兆円を全額消費税で賄うとすると、単純計算で税率25%ぐらい必要だ。実際に25%に上げたらそんなに入らないだろうし。

ここらへん、人間雇用をどれだけ残すかとロボ税との兼ね合いで面倒くさい制度設計必要な予感。


他の人の意見がききたい。(再)

http://anond.hatelabo.jp/20161108221758

データベーステーブル設計について打ち合わせしている最中

何度となく耳にして口にした「主キー」がみさくら語に聞こえて吹き出しそうになったことがある。

2016-11-08

福岡沈没妄想

博多駅前、ド派手に沈没しましたね。

地下鉄七隈線延伸のせいだそうですが(延伸の必要性あるのかなぁ)。

シールド工によって地下を掘ってたら、粘土層を突き破って強度の弱い上部分が落ちてきたと。

設計段階ではわからないこともあるから仕方ないんでしょう。工法で裏に補強材充填とかやるけど、それは後からだし。

それより問題として指摘されてるのは、下水から少しずつ漏水して地盤を弱くしていたかもしれないということ。

全国各地(特に大都市)の都心部は網目のように上下水道管が張り巡らされていて、老朽度は軒並み高いです。

老朽度が高いなら、直さなきゃいけません。

ただ、地下埋設物ですから、老朽度を測るのにも上の幹線道路を止めて、掘って、調べる。

これが網目のようにあるわけです。

インフラなんだったら税金ジャブって調べろよ、大事だろうが。と思うかもでしょう。

上下水道(法適用)では、公営企業として、独立採算性をとっていますから、それが中々難しい。

水道料金でしか更新費用を捻出できない。最終的には、値上げという形で市民に跳ね返ります

水道料金の値上げは政治的にも致命的ダメージです。出来ればトップ的にはしたくありません。

こうやって老朽管は放置されはしないにせよ、更新スピードのアップというのは難しく

全国的に同じような事案が起きる可能性はあるかも、ということです。

2016-11-07

TOKYO DESIGN WEEKの火災物件Twitterはじめネットでは、これでは燃えて当たり前なのに/なぜだれも疑問に思わなかったのか/擁護のしようがないクソ設計という意見が目立つが、

そういう君らだって見学者の一人だったら声をかけることができてたのか?という疑問が残る。

何万人もの来場者がいるわけでTwitterのような意見を持った人は一人もいなかったのか?

一目見てそこまで高い危険性のあるものだと、何万人の中の何千人の人はおそらく気がついていたはずだと思う。

でもだれもなにも言えてないはず。現に燃えしまったわけだから

後出し批判するなら幼稚園児でもできるわけで、批判する人はまず結果を論じるのではなくその前のなぜのところを追求してほしい。

2016-11-06

SI下請けプログラマSI元請けのオッサンに思うこと

「ああうん、設計書は後でいいよ、どうせ変わっちゃうし。でも客に見せるもの必要からペラ1枚程度で作ってよ」と

言ったオッサンがいた

この人わかってるな!さすがでかいSI屋だと違うね、開発の実際と手の入れどころ・抜きどころ知ってるんだね、と思った

「先に設計書を出せ、詳細設計書を書いてから実装だろ」みたいなこと言う人に当たると、ああハズレだなと思う

こいつ物作った経験ほとんどないんだな~と思いながら、オッサン騙しの文書理論を用意する仕事が最優先になる

余計な仕事が増え本来の物づくりへの工数が削られる、コストは上がって品質は下がる

しかしこの手のオッサンは多い

「詳細設計(Excel文書)は自分が書いたけど、実際のプログラムは読めない。そこをうまく読んで書いてくれるのがプログラマじゃないの」

と言ったSI元請けがいた。コードレビューもこいつがやってた。読めも書けもしないくせに

そいつマネージャーではあったがスケジュールを調整する力は皆無で、客に言われた要望を受けて下に押し付けるだけだった

こいつは早く死んだほうがいいなと心底思った

http://anond.hatelabo.jp/20161106122745

詳細設計書を読むべき主な人間は、設計書に従い実装するコーダであるのは言うまでもなく当然の事でありこの辺からすでにはき違えているのには呆れるばかり。

読んで憤慨。そんな現場どこにもなかったぞ。ただの1つも。ここ20年で。

一番ひどかった現場は、ソースの読めない書けないやつが詳細設計書の日本語を変更し日本語記述を追加し、あとは実装者任せってやつだった。

読めない組めない書けないやつが詳細設計って。おまえExcel文言修正するだけの事務のおばちゃんレベルやん。

当然システムが実際にどう作られていてどう機能追加すべきかは「詳細設計書」には載っておらず、実装工程プログラマが一から調査することになる。

追記みたいなもの

http://anond.hatelabo.jp/20161105155342

↑の記事を書いた元増田です。


色んなブコメトラバを頂いたが、その中でnekora氏の発言(http://d.hatena.ne.jp/nekora/20161105/p2)が看過できないというか、非常に示唆に富む内容を含んでいたので、釣られる形で以下に追記してみる。

いや、SI現場では久しく当たり前の慣習であり「何を今更」な話なんだけど。


注目したのは

詳細設計書を読むべき主な人間は、設計書に従い実装するコーダであるのは言うまでもなく当然の事でありこの辺からすでにはき違えているのには呆れるばかり。

この発言は、そもそもSIの元請や元請に近いポジションの、特にマネージメントを担う立場人間の、プログラマに対する認識がよく見て取れる。

即ち

という考えが透けて見えるのだ。

要するにプログラマライン工とみなしているわけだ。

昨今の「デジタル土方」なんて自虐ネタに照らし合わせれば「デジタルライン工」といったところか。


ここまで書いたタイミングで声を大にして言いたいのだが、こっちは別にプログラマライン工職種に貴賎があるとは思っていない。そこは勘違いしないで欲しい。

問題は、本来であれば知識集約産業であるはずのシステム開発を、労働集約産業手法マネージメントしていることである

プログラマ知識集約産業における「開発者」ではなく、労働集約産業における「現業職」みたいに扱われているのは、そうした歪みが産んだ結果の一部にすぎない。

まあこれには、開発のときだけ人を多く雇うみたいな営みが困難な日本労働環境とか色々な要因が絡むのは、既に今まで散々言われてきた通り。


はいえ、そんなマネージメントでは、品質の優れたものは今までもこれから絶対に作れないだろう。

何かの間違いで、実装精通したSEが詳細設計とやらを書いているなら話は別だが、そんな現場あるのか?という感じ。

あと、開発者としての創意工夫が求められない点について、控えめに言ってプログラマもっと怒っていい。

なんのために必要書類なのかっていうのが重要だと思う

詳細設計つっても、実装するのに必要なのか、ライブラリとして利用するために必要なのか

どっちにしろ詳細である必要はなさそうな気もするけど

現場レベル会社が別で何度もコミュニケーションが発生するコスト

下請けに一回ドキュメントに落としてもらえばあとはまきとれるかの違いじゃないか

nekora氏の発言説得力バカの壁

PHPビルトインサーバー2016年まで知らないような人には確かにソースより詳細設計必要で、ソース見りゃ分かるよって人にはソースを見ても分からない人の気持ちが分からないしその逆も同様という、いわゆるバカの壁みたいなものを感じた。

http://d.hatena.ne.jp/nekora/20161105

http://anond.hatelabo.jp/20161105155342

http://anond.hatelabo.jp/20161106000128

上流の人「こういう機能欲しい(2,3行の箇条書きレベル)」

下流の人「こういうのでどうですか?(実際に動くモックを見せる)」

上流の人「違う違う。そうじゃなくて、ここはこうで、そこはこうで(GUIに対してのみ指摘できる)」

下流の人「こう・・・ですか?(とりあえず言われた通り修正する)」

上流の人「まあ、そんな感じかな。じゃあ詳細設計書頂戴。それをもとに経費の計算するから

詳細設計書いらないってどういうこと?

自分今の会社しかいたことないし設計周りの概念って会社によって全然うから

イマイチ想像ができないんだけど、今の仕事の流れって



上流の人「はい超ザックリと基本設計書書いたよ、こういう機能作って欲しい」

下流ぼく「ふむふむ、これは具体的に実装するとするとこんな感じになりますね、細かく書いた詳細設計書どうぞ」

上流の人達「うん、これで認識齟齬ないよ、元請さんにもOKって言われたよ。こんな感じでお願い。」

下流ぼく「上流の人からこれで問題ないって言われたよ、この詳細設計書を元にみんな作ってね」

下流の他の人たち「はーい!カタカタカタ」



こんな感じで仕事進めてんだけど、詳細設計書が消えるってなるとどこがどう変わるの?

どの辺の工程おかしいの?