「fix」を含む日記 RSS

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

2018-09-18

さら10選手

自分仕事で履く革靴は、就職後数年の間に黒の外羽根プレーントゥ、ダークブラウンモンクストラップ、そしてブラウンの内羽根ストレートチップの3足にFIXし、以後10年以上そのパターンで固定されている。

このうち、気が付けば10年以上履いていたストレートチップを買い替えた。

某国ブランドが当時2万ちょっとで売っていたモノで、まあ本格的革靴の視点で見れば、ソールを張り替えてまで10年も使い込む価値なんて、無いに等しい安物でしかない。

貧乏性の面倒くさがりも大概にすべき話だ。

そんな自分が買い替えを決断したのは、今振り返ると数年前のソール交換が根本的原因だった。


元々その靴は、アンティーク仕上げのアッパーに細身ラウンドトゥラストと来て、薄いベージュラバーをマッケイ製法で縫い付け、更に茶色の半カラス仕上げという、なんちゃって革底のクセに妙に凝った造りだった。

当時は黒の外羽根プレーントゥがグッドイヤーウェルトだったのだが、履いた感覚では断然マッケイの方が好みになり、結果的に長らく愛用する理由になった。

しかし靴は、特に靴底消耗品であり、可能な限り手入れしつつ大事に履いてきたものの、とうとう「これ以上削れたら修理になってしまう」程度にソールが薄くなったところで、張り替えを余儀なくされた。

とはいえソールを張り替えれば更に長く楽しめるだろうと、そこは努めて前向きに捉えていたのだが…なんと戻ってきたソイツはグッドイヤーウェルトで縫い付けられていたのだ!!

うそれだけで靴としては完全に別物になってしまった。

しかも悪い事に、靴を買った当時はヒョロガリだった自分も、加齢で体重が激増し、上半身こそ割と華奢なまま=下半身デブと化していたわけで。

結果、とにかく固くて固くて、「この靴は鉄で出来ているのか?」と履くたびに泣かされる事になった。

でもそれは最初のうち、きっと馴染むだろうと思っていたら…先日、右足の親指付け根にタコができて痛み出す展開。

OKギブアップだ。

ちなみにソールの材質も、黒のゴムベージュ塗料を塗っただけ(そしてすぐに剥がれた)という、まあ値段相応かもしれないが、あからさまに安っぽい感じで、履くたびに少々辟易していたり。


それで昨日、新しいストレートチップを買った。やっぱり色は茶色で、いわゆる今流行の「見た目なオーソドックスオヤジ革靴、中身はスニーカーみたいなの」というやつだ。値段は先代の3分の1。

こうして自分若い頃の持ち物が一つ減った。

減ったのは別にいいが、こういう形での卒業微妙かな。

そんな連休最終日だった。

2018-08-22

仕事しんどーい

たまにどうにも合わない人がいる。

ウェブデザイン(とも違うんだけど、まぁクリエティブ系)の営業みたいなことをやってるんだけど、

いま、とてつもなく苦手な相手とやりとりしてて苦痛

その人は仕事前は素人なんでわからないんで…とか素人を振りかざしていた。

実際にデザイン案をだすと、うわーこうきちゃいましたか。とか、

こういう風に捉えられないためにうちは一生懸命商品つくってるのに、と言われてNGがでる。

一応言いたいこともわかるし

ものすごくクレイジー対応されてるわけではない。

デザインがまずい部分もおおいにあるだろう。

しかし、どうにもメールの書き方がそこはかとなく嫌味でそれにイライラする。

なんか傷つく。

もっとばっさりNGだと言うクライアントもいる。

から、本当にNGの出し方、そのNGがなぜダメなのかの説明の仕方が嫌味たらしくて苦手なんだと思う。

そこはかとなくだから勘違いかな?と思ったけど、CCに入ってる同僚も嫌な感じだねと言っていたので、やはりメールが嫌味なのは本当だと思う。

なんかとにかく早く縁を切りたい。

でもデザイナーも器用なタイプでなくなかなか全くfixしない。

連発される嫌味メール

つらいつらいつらーーい。

やりやすい人とだけ仕事したい。

心穏やかに仕事したい。

いや、できれば仕事したくない。

2018-06-20

拝啓 アプリ制作者様

時候不順の折、いつもお世話になっております

色んなアプリがたくさんあってスマホは本当に楽しいです。

ただ、一点お願いしたいことがあります

もう少し、動作確認をきちんとしてからリリースしていただけないでしょうか?

ひどいアプリですと、毎日バグFIXアップデートがあったりして

また?更新?と目を覆いたくなります

まだインターネットが主流でなかった時代フリーソフトなどは

それはそれは丁寧に動作確認をして

バグのないように細心の注意を払っていたものです。

雑誌に載ったりなどすると修正は出来ませんし。

とりあえずリリース、みたいなお手軽になりすぎてはいませんか?

私達はモルモットではありません。

よろしくお願い致します。

敬具

2018-03-17

援交というビジネスモデル

炎上覚悟で書く。すごい世界だった。

具体的なフローはこうだ。

1.出会い系サイトメッセージフリーメールアドレスを聞く。

相手メッセージ課金制なので、フリーメールの方がありがたい。なので、割と簡単メールアドレスをゲットできる。

2.アポイントが決まって待ち合わせ場所FIX(ここまでは金銭的な要求はないように思わせる。)

3.相手が待ち合わせ場所につく時間をあらかじめ聞き、その手前ぐらいで、「実はお金に困っているので初回だけ助けてほしい」アピールをする。

相手からすると移動してしまっているので、合理化一貫性心理が働き、援交だとわかっているのに「どこかこの子だけは違う事情があるのかもしれない」と信じたくなる気持ちが生まれている。

4.もし相手が「どうせ2回目以降もないんでしょ」疑ったら、「私は嘘はつかない。あなたは真面目そうな人だから、今回がよければ次回以降はお金無しで会いたい」とプッシュする。

→ちなみに、「無料での出会いを求めるなら美人局ヤクザとの絡みがあるので注意してね」という煽り文章を送ることで、ある意味お金要求してくる方が目的がはっきりしていて安全かも、と思わせることができる。

5.それで実際にホテルに行くことができたら、フェラと手コキで即抜き。プレイ時間10分未満。(それで2万円)

5-1.相手キスしようとしたり、胸を揉もうとしたり、手マンしようとしたりすると、「それ嫌いだから」と言ってハネる。

→この時点で相手の性欲は減退。事実上ただの高級ピンサロと化す。

6.解散。以上のサイクルを淡々と回す。

これにより、2回目以降のリピートはよほど頭のおかしい人じゃないと起こらない。なぜなら抜くだけならピンサロ風俗に行けばいい話だからだ。

ひたすら事務作業のように新規アポを繰り返している。練りに練られた新規刈り取りビジネスである

もし、出会い系サイトでいきなりこちらのフリーメールアドレスを聞いてくる女性がいたら、この一連のフローを思い出してほしい。

2018-01-30

ゲーム会社入社しても夢なんて作れない

数年前、某大手ゲーム会社入社した。会社については億万が一身元特定を防ぐため、嘘にならない程度にぼかしてあるのは許して欲しい。

ゲーム会社に入った理由単純明快で「ゲームが好きだから」だった。心に残るゲームを作りたいとも夢見ていた。名作は?と聞かれ名前が挙がるような。

実態は程遠い。まだ若手で経験が浅いという面もあるが、今のまま働き続けていても歴史に残る名作が生み出せる気はまったくない。

まず、会社で働いて作る以上、面白いかどうかより売れるかどうかを気にしないといけない。

コンシューマゲームの開発費も、最近スマホゲームの開発費も膨れ上がっている。

開発費が高いということは、会社としては当然それと同等かそれ以上のリターンがないと作りたくはない。

面白いイコール売れるという訳には必ずしもならない以上、作れるゲームは限られてくる。お金が稼げるゲームだ。ユーザーから評価で「面白かったです!」「続編待ってます!」という意見をたくさんもらえるようなゲームでも、数字が悪かったら続編が作られることはない。ファンの声より実際の数字の方が雄弁だ。

ソシャゲなら適当キャラがかわいくて確率が低いガチャ入れれば儲かるんだろ?」と言う人。ぜひ作って運営をしてくれ。そんな簡単はいかないから。

ソシャゲヘビーユーザーでも一日にプレイするソシャゲ数は限られているから、その限られた中にねじこめるようなゲームじゃないと企画が通らない。もしくはサービス開始から短期間で畳む羽目になる。

「どこかで見た○○のようなゲーム」「ガワ替えゲーム」は少なくとももう通じないのではないだろうか。結局のところIPに頼るしかなくなる。

さらに、何か少しでもまずいことがあると「公式」「ご意見フォーム」の向こうに人間がいると思われていないような罵詈雑言も大量に読む羽目にもなる。そのうち何も感じなくなるが。

次に、覚悟していたことだったが労働時間がキツい。

36協定を守っているのか疑わしいような部署が当然のように存在している。その部署会社的に問題になるかというと、なんと売れ売れのタイトルを作っているから特例として上層部から守られている。特権階級だ。アホらしい。世間の風潮と逆行している。

マスター前などが忙しいのはもちろん分かるし、毎日定時に帰れるなんて夢はそれこそ持ってなかったが、普段から人員数と仕事量が見合っていない。いくら世間が働き方改革と言っても、人と予算が増えない限り一生改善されないだろう。

自分が今作っているゲームが、自分が今まで全くプレイしないジャンルだったというのもモチベーションが上がらない要因のひとつだ。テストプレイデバッグ苦痛で、仕様アイディアに頭を悩ませても楽しくなくて、もちろんゲームの一ジャンルとして売られていると認識はしているが、誰が買うのかすら想像がつかない。勉強のためにとそのジャンルゲームを買ったが、やはり自分には合わない。例えるなら、スマブラカービィしか使えない初心者ガチ格ゲーを作らされてるようなものなので、スタートラインが遠すぎるのだ。

自分楽しいと感じられないゲームを、ユーザー楽しいと思ってもらえるにはどうすればいいんだろう。

仕事だと割り切って、どうにか自分のやりたいことをねじ込んで面白そうに作る先輩もいるが、到底自分には辿り着けない次元だ。若手が提案することなんて、FIX時には度重なる上司のチェックにより原型がない。それでもっと上の人にツマランこうしろと言われたらその通り直す。それが仕事だ。

やはり「会社である以上お金がないといけない、という理屈は覆しようがないほどの真実だ。

夢を作りたいという夢を見すぎていたのかもしれない。それでもあまりに悲しい。

全く興味がないジャンルの、お金を追求したゲームを作り、長時間労働のため帰宅するころには疲弊してコンテンツを吸収する時間もない。

こんな状況で夢など作れるはずもなかった。

一番夢を持っていた新人時代企画書を作りプレゼンをしたが、「これ、○○(弊社同ジャンル有名タイトル)より売れるの?」と鼻で笑われるだけだった。

転職も考えているが、プランナーというものは目に見えやすスキルがつかないし、特筆して得意だと胸を張れることがない。独学しようにも今これを書いてるこの時間が帰り道だ。身体を保つには時間がなさすぎる。このままずるずると、今の会社でなにかの塊を作り続けるのだろう。

もしこれを読んでいる人で、ゲーム制作に興味があり、作りたいものが既に自分の中にあるとしたら、インディーズで作ることをお勧めする。会社に入ってまで作る必要はない。

スキルがないと悩むプランナーなら早めに得意分野を見つけて頭一つ突き出そう。放っておくとこのように手遅れになるから

2018-01-04

姿勢矯正メモ

背骨】平背

【首】ストレートネック

Restore Your Bad Neck Curve With a Simple Towel - Dr. Alan Mandell, D.C.
https://www.youtube.com/watch?v=A8baXHPjYeg

【肩】巻き肩

HOW TO FIX ROUNDED SHOULDERS
http://posturedirect.com/how-to-fix-rounded-shoulders/

Fix Your Bad Posture Now! | 3 EASY FIXES YOU CAN DO ANYWHERE! (Rounded Shoulders & Kyphosis)
https://www.youtube.com/watch?v=3DfihHPjVXQ

Help Correct Rounded Shoulders (Poor Posture) While Sleeping in this Position - Dr Mandell
https://www.youtube.com/watch?v=JS6gfuSmRYM

三角筋後部

Bigger Rear Delts by Bodyweight (NO WEIGHTS)
https://www.youtube.com/watch?v=rtRDHs6nTZ0

A Simple Exercise For Healthier Shoulders
https://www.youtube.com/watch?v=Bl7dwy2MHlU

前鋸筋

セルフex】前鋸筋を緩める方法
https://www.youtube.com/watch?v=PAOwhVWesO4

骨盤骨盤後傾

HOW TO FIX A POSTERIOR PELVIC TILT
http://posturedirect.com/how-to-fix-a-posterior-pelvic-tilt/

2017-10-14

Two years have passed since I moved to a developed country

ほらよ。

https://anond.hatelabo.jp/20171014071350

I am working as an engineer in the IT area, but I managed to hold it for some 2 years.

I do not have confidence yet, and I feel even more confident about my confidence for the rest of my life, the excellence of my colleague.

If I do not desperately do it I am working everyday with feelings that it is not amusing even if I receive a notification outside the fighting strength.

Still, in Japan, I think that Japan has much better skill than CTO in that area.

In the future I thought that if I could return to Japan and contribute to the Japanese society, Japan that is visible from the outside is bad.

What is bad, first aspect of politics.

Politics

The point that democracy is not fully functioning against the fact that there are stupid citizens who blind the LDP, such as Abe's descent.

That other party is also not good. Hope party? What is that lady like that disciple of Ru Ooshiba? Rou Koike?

The more you do not have it, the stupid will be clouded in katakana and psychology. You idiots, you guys say this. I love Katakana anyway, I love psychology, 100% I do not say big things. What is Y's Spending. Do not fix what you normally call katakana.

Since the political system is over in the first place, I think that it is the cause of failure of not receiving popular people, especially elderly people, only short-term and useless policies absolutely. So we will not attack only the LDP.

It is too fatal that politics is not rational and it is impossible to include the policy that should be done. Because it ends with poppiness if I can not vote.

Unfortunately, the trend of changing the political system probably will not happen if it fails.

In recent decades, politicians have accelerated the declining birthrate and aging society to a distortion with outlook on the preferential treatment for the elderly + measures against the declining birthrate.

The decline in Japan's birthrate and birthrate is partly spontaneous, but the world's low birthrate and aging society is not caused by natural phenomena.

There is not any future that putting all the energy to surrender the tax to the old man by tax free over medical care. It was already late when we were discussing whether a large amount of tax would be used due to politicians' old elderly votes or ten years ago, so it was already late, we have not corrected the orbit again so far I am going to politate on the same route.

An aged politician does not think about a short-circuiting policy, the future. Citizens delight in the immediate economic policy.

Grass grows now, as the nation 's collapse has become a reality.

If the declining birthrate and the aging population advanced at this pace as it is, the Japanese boat will sink in 20 years. Two years ago I thought I would have 30 years.

I gave up completely to Japan's politics. Defeated entertainment is not funny. I'm saying that it is japanese, but I do not dislike it. To give up means to accept failures.

Next is the aspect of business.

business

Did you have a business anywhere other than bidding? I do not have pieces of creativity. There is no further ethics.

What is it, Mercari or DeNA or moral business or something is a social sin. I just confused society, did not I? The country and the country came to know not ethics.

Ethics of the Japanese are lower than the Japanese think.

Although I derail for a while, accident happens in front of my eyes, the idiots who take pictures with smaho are not minorities at all Nationality is bad.

Even though there is service only where money is involved, do not say hospitality as if it were the national character of the Japanese.

It is not a minority to be a completely individualist society and people are troubled and help people.

At this time new creative business is born from one to the next. It is at an unthinkable pace in Japan. Of course, there are many doubtful businesses as to whether it will become money, but it is better than Japanese society where there is no brain except copying the business of another company at all.

So almost no company wants to work in Japan.

And the fall of the company. Almost no international competitiveness. Even large corporations will be crushed.

With this aging birthrate and declining birthrate, you can not contribute even to domestic demand with the elderly who can not see the future if it is full of old people.

There are no people with a declining birthrate. It seems that young people are supporting the LDP by thinking positively as being a seller's market completely.

There is only one person who is not merely a policy of an aging population declining birthrate. Your future is pitch dark.

Were I so stupid as to whom I thought of going back to Japan? What? It is certain that at least the field of view and experience has been much lower than it was now.

If I see myself two years ago, I feel mercy only now.

Indeed it is visible that it will collapse in another few decades Indeed it will not be possible to return to Japan.

Why do I have to board a sinking ship? Parents are the only team to surrender, only you are to protect yourself.

Originally I decided not to make children from the uncertain future of society, not myself. I think that choice was right.

Politician Now, if you are not stupid, it means that you are doing intentional bankruptcy activities.

It is good that you are only interested in being inspected. I do not know anymore.

At the very least, please try to make Japanese citizens work in the world. If the hurdle of labor visa goes down, then you will be able to do it if you have English proficiency.

I had a lot of hardships. Although it is inferior to native, I am working without problems.

Oh, I wanted to go back to Japan. . .

2017-09-08

2週間やる気が出なくて辛い

やる気が出ない。

ホントでない。

出ない原因は何かと問われると仕事がないから。

その流れで仕事がきたけど仕様が決まっていない。

お陰で更にやる気が出ない。

仕様FIXしたとお知らせが来た。

よし!やるぞ!

仕様書を開くと、難解な項目の羅列に難解な説明分。

私「おめー!これ仕様書として書いたのか?初めて見る人でもこの資料をみて、作業ができるようになっていて、誰が作っても同じようになるよう誘導するもの仕様書なんだよ!」

FIXマン「い、忙しいんです。。。」

なんで忙しいかというと、この仕様書書いてるやつが散々サボってきてからだ。

それでも、とりあえずポチポチ作業を進めてみると。。。

この項目とこの項目一緒じゃね?それにこれも辻褄合わないよな。。。

私の理解が追いつかないのかもしれないから聞いてみよう。

私「こことここの項目一緒じゃないですか?」

FIXマン「待って下さい。」

・・・

FIXマン「問い合わせます

なぜ問い合わせるかというと、お客さんから言われたとおりにそのまま転写しただけのようだ。

FIXマン「一緒らしいのでこっちの項目消しますね。」

よろしこ。

ふ〜。。。。

私「ここのところの項目辻褄合わないように思うのですが、こういう意味であってますか?」

FIXマン「問い合わせます。」

・・・

こいついなくてもいいんじゃね?

そんなこんなで私が仕事していないみたいで辛いです

まぁ、他のところポチポチしてるからとりあえずは。。。

やる気でね〜!

2017-08-11

32bit LinuxではAndroid開発はお勧めしない

sdkmanagerでインストールされるツールバイナリがことごとく以下の通り

$ file `which emulator`
/data/Android_SDK/tools/emulator: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.15, stripped
$ emulator
bash: /data/Android_SDK/tools/emulator: cannot execute binary file: 実行形式エラーAndroid Studioなどでエミュ動かそうとすると Syntax error: ")" unexpected とか謎のエラー

まり64bitバイナリなのである32bitバイナリ提供されない(Won't Fix (Intended behavior))
逐一バージョン戻してもいいのだが仕様だし他のも32bit切り始めてるしメモリ4GBもしんどいし64bitやろう。うん。おかねください

2017-08-05

かわいそかわいそ増田

https://anond.hatelabo.jp/20170804223333

パッとみ、同じ人間の主張としては正直いってどっちもどっちだなー、って思う。

どっちが悪いってわけでもなく、「それぞれ流儀哲学もございますよね、生きた人間ですもの」といったところ。

仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

かわいそかわいそ増田

パッとみ、同じ人間の主張としては正直いってどっちもどっちだなー、って思う。

どっちが悪いってわけでもなく、「それぞれ流儀哲学もございますよね、生きた人間ですもの」といったところ。

仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

かわいそかわいそ

人間的には正直いってどっちもどっちだなー、って思う。

まず仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

かわいそかわいそ

人間的には正直いってどっちもどっちだなー、って思う。

ただ、仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

2017-07-25

ポケモンgoシカゴフェス感想

ご存知だろうが、フェスは最悪だった

https://headlines.yahoo.co.jp/hl?a=20170723-35104627-cnn-int

http://japanese.engadget.com/2017/07/22/pokemon-go-fest-lugia/

増田12時間かけて車を使ってシカゴに行ったので、すでに疲れも溜まっていた

しか参加者は約2万人

9時に着いたが、すでに長蛇の列ができており、10時開門で入れたのは12時近くだった

セキュリティを通過し、いざ記念メダルを手に入れようとしゲームを起動したが、ログインができなかった

呆然とするしかなかった。。。

入り口すぐのInformationブースには列ができており、みなログインできないことを問い合わせるための列だった

しかし、キャリア問題なので解決できないとの返答

その周辺の怒りが爆発した

"We can't play!"や"Fix the game!"コールも起こっていた

ニュースになっていた通り、メインステージアナウンスがあるたびにブーイングが起こっていた

タイプボーナス途中経過なんぞどーでもよかった

ただ、全てのスマホダメだったわけではない

一緒に参加していたBoost Mobileスマホを持つ友達プレイできていた

このBoost MobileはSprint系列キャリアで、安いプリペイド料金が魅力だが、エリアカバー率やつながりがよくない

しかし、このフェスではBoost Mobileの方が、全米のエリアカバー率が高いAT&Tよりも使えるキャリアであった

SprintとBoost Mobileポケモンgoスポンサーだったし、フェス内に独自ブースも持っていたので、おそらく優遇されていたのだろう

増田AT&Tだったので、グラントパーク内で割と人の少ないところに行かないと使えなかった。。。

これは人気のモンスターレイドバトルが始まっても参加できないことを意味する

これはAT&Tだけではないようで、現地で知り合ったVerizonの友達もつながらないと激怒していた

(この人は10分で売り切れてしまったチケットオークションで$200にて落札したと言っていたが。。。)

仕方ないので、Boost Mobile友達テザリングしてもらいなんとかログインし、プレイしていた

こういう知り合いがいない参加者は、このフェスずっと座っているか寝るかしかできなかった

お詫びの対応は当然だと思う

http://pokemongolive.com/en/post/pokemongofestupdate

そのうち、チケットの全額返金、100ドル分のポケコインイベント参加者全員に配布、参加者全員に伝説のポケモンルギア』を配布は良い

ちなみにイベント終了後、「詫びルギア」がバズってたのには笑った

しかし、「会場内に出現する予定だったレアポケモンタマゴを、公園を中心に2mile(注、日本の一部のニュースサイトでは2kmとなっているが、実際は2mile)圏内シカゴ市街でも出現するよう変更」について少し言いたい

フェス終了直後からこの変更が起こり、ルギアフリーザーレイドも始まった

この2mile内がポケモントレーナー群衆により、軽く騒動になっていた

さらシカゴの狭い道の中にあるビルホテルジムになってたので、群衆道路にはみ出し車の渋滞引き起こしていた

まるでお台場で起こったラプラス騒動のような。。。

結局、この群衆では通信障害が起こってしまうので、増田滞在日曜日の午前中まで延長し、レアポケモンルギアフリーザーをたくさんゲットした

CHICAGOアンノーンや、ヘラクロスをゲットできたことで、フェスの不満は40%くらい解消された

(ちなみに、グラントパークから2mile内のレイドでのルギアフリーザー捕獲チャンスは100%捕獲できるようだったので、皆パインの実を使ってキャンディー倍にして捕まえてた)

フェスでよかったのは、アメリカにしては安い料金でフードを食べられたことや、各チームのコンセッション内に充電器が完備されていたことだろうか

シカゴdeep dishを$3で食べられたのはよかった

脱水症状にならないように、水の補給は常にできるようになっていたし、救急班がすぐに出動できる体制になっていたのは評価したい

動画があったので、載せておく

http://www.businessinsider.com/pokemon-go-fest-chicago-video-niantic-john-hanke-booed-lugia-2017-7

特に以下のYouTube動画フェスの早乗りしたところからフェス終了後の様子まである

https://www.youtube.com/watch?v=KpoxnJGHGrA

ちなみに、7PMになると同時に会場は撤収

特に終了だというアナウンスもなくスタッフが"Leave imadiately!"と叫んでいたり、裏方がメインステージ液晶ライトの片付けを始めた様子を見て、

なんだったんだ、このフェスは。。。と思わせるのに十分であった

(追記)

7/26 6:30(JST)、nianticlabからメールにてお詫びがきた。チケットの返金は9月100ドル分のポケコインルギアは7日間のうちに自動的に入るとのこと。

7/27 10:20(JST)、気がつくと詫びルギアされてた。100ドル分のポケコインも振り込まれていた。

170ドルガソリン代と120ドルの3泊分のホテル代を費やし、寝不足と戦い、炎天下の中でほとんどゲームができなかったストレスと引き換えるにはちょっといかな。。。

2016-11-01

退職なさる先輩へ

近々退職なさる先輩へ、後輩からアドバイスです。

インデントや空白の有無にはきっちり規則性をもたせましょう

タブとスペース混じりのインデントなど、見るに堪えません。

きっちり規則を決めてコードを書きましょう。

Gitコミットメッセージをちゃんと書いてください

updateやfixなど英語単語だと何が変更されたのか非常にわかりにくいです。

あと職場英語圏の方はいなかったので無理に英語を使う必要はないと思います

手動でサーバを構築しないでください

環境再現することやサーバの中身を把握するのが困難になります

世の中にはAnsibleやItamaeなど便利なプロビジョニングツールがあるので是非使ってみてください。

手動でDBスキーマを変更しないでください

開発環境と本番環境で食い違いが生じてエラーが発生していましたよね。

DBマイグレーションツールを使うのをオススメします。

N+1問題などボトルネックになりやすい部分は気をつけましょう

キャッシュを設けても遅くなるものは遅くなるのです。

クエリの発行数や計算量など意識してみてください。

エラーが直ったかどうかはきちんと確認してください

動くかどうかも確認せずに「直ったよ」と嘘をつかれても他人迷惑しかなりません。

テストコードを書ければ良いのですが、最低限手動でもいいのでご自分確認してください。

コードドキュメント仕様は一致させてください

利用する側の人はドキュメントを見るので実際の挙動と異なっていると困惑します。

整合が起こらないように気をつけてください。

HTTPステータスコード意図にあったものを返しましょう

GETしただけなのに201を返すなど意図にあっていないものがありました。

ステータスコード意味を調べてよく考えてみてください。

他にも言いたいことは沢山ありますが、あまり長くなるのも迷惑かと思うのでこの辺でやめておきます

先輩は技術知識はたくさん持ち合わせていましたが、どうにも技術的に他人を思いやる文化を持ち合わせていなかったように思いました。

上記の点を直すことによって、そういった文化を養うことがエンジニアとしてのステップアップにつながるはずです。

次の職場でのますますのご活躍をお祈り申し上げます

2016-09-19

http://anond.hatelabo.jp/20160919192044

通りすがりアイカツおじさんだが、漠然アイカツスターズCGパートに不満感があったんだけどこれが理由だと気付いた

アイカツCGFIX気味でキャラダンスをじっくり見せつつライブDVDのようなリアリティがあったけど

アイカツスターズ場合は終始空間をぐるぐる動き回ってるばかりだからそれらの魅力を殺していたんだな

Twitterで調べても同意見の人が多いようだし、サンライズDIDにはもうちょっと頑張って欲しいところである

2016-08-17

Downvote because of recommending iPhone/Windows Phone. Btw, that's not a fix, the bug will still be there. – Jorge Fuentes González Aug 4 '13 at 10:55

Yes, "reboot and you're done" is not a fix, and still it's considered a fix in this all-fanboy world. Windows must be better than fanboy-exclusive software because it has tons of haters and absolutely no advocate, resulting in freedom of speech secured for healthy criticism and feedback. Don't join the uneducated witch hunters.

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-05-20

http://anond.hatelabo.jp/20160519220812 への返信です。

http://anond.hatelabo.jp/20160519220812 への返信です。

これは、らくからちゃさんが書いた http://anond.hatelabo.jp/20160519220812 への返信です。(いままで「らくかちゃ」さんだと思っていましたが、「らくからちゃ」さんですね。お名前を間違ってしまってすみませんでした。このエントリの時点で気がついたので、過去のものログの保管の観点から修正してません。そちらについてはご寛恕を請う次第)

総合原価計算個別原価計算選択について

http://anond.hatelabo.jp/20160519220812 にて、らくからちゃさんは

と、いう話を書こうと思ったのですが、もしかして消されちゃいました?(更新ボタン押したら原文が見えなくなっちゃったのですが)

と反応されていますが、この話は、 http://anond.hatelabo.jp/20160518115232 で私と、もともとは、http://anond.hatelabo.jp/20160517150742 で私では無い方が指摘した点に対する返信ですね。(らくからちゃさんは勘違いで消えてしまったと思ったようだけど、消してません。ずっとそのままの状態で在ります)

http://anond.hatelabo.jp/20160518011455 で、らくからちゃさんは、

それぞれの生産形態管理方法に合わせた計算方法選択すべきである。では、総合原価計算個別原価計算をどのように選択するべきであるのか

という点を踏まえつつ、

こういった生産体系にて『ある生産要素の投入と生成物との関連性』が明確である場合個別原価計算法は原価管理観点から有益情報を得ることが出来る。

一方、個別原価計算が不向きなのは『ある生産要素の投入と成果物との関連性』が不明である場合、例えば中間品にストックポイントが置かれる場合だ。

(略)

という説明をしてますが、らくからちゃさんのおっしゃる『ある生産要素の投入と生成物との関連性』というのは、具体的に何を意味していますか? 現時点でググったけれど、ちょっとわかりません。(ウェブ魚拓を取ろうとしましたが、robots.txtがあるという理由で取得できませんでした。それゆえ結果が固定できませんが、その点が問題にはならないと思います)

自分は『ある生産要素の投入と生成物との関連性』とは「『製品との関連における分類』を意味する」と読んで、「直接費/間接費の違いに応じて、個別/総合原価計算を分けるのか?、そんなことないでしょ・・・」、と理解した結果、

受注生産品でも間接費の配賦はあるよね

と、前提知識の確認しました。で、この点については私とらくからちゃさんの間で誤解が生じていないようです。

その説明の後で、 http://anond.hatelabo.jp/20160519220812 で、らくからちゃさんは、

ここで『総合』『個別』というのは、明示的な基準があるというよりも、あくまで程度の問題と考えることが出来ます工程単位を限りなく小さくすれば個別原価計算に近づきますし、逆に指図の単位を限りなく大きくすれば総合原価計算に近づきます

説明していますが、個別/総合原価計算は、工程単位の程度問題(?)ではなくて、製品生産するときに、

とするべきものあるはずですよね? つまり製造単位が1か、それ以外か。(私としては、工程製造単位が1に近づいたとしても、2単位であれば、それは総合原価計算だよね、という点を確認したい。それゆえ、工程に応じて前の工程では総合原価計算計算していたが、次工程では個別原価計算計算する、といったようなことがあると思いますが、その区別は、各工程において製造する仕掛品(第一工程仕掛品であれば、第二工程に振り替えられたときにはそれが前工程費となりますが)を「一単位としてみるか/(そうではなく)2以上の単位とみて、製造しているか」で分けるということです)

個別/総合原価計算説明はそういった「製品製造単位が1か、そうでないか」という点から説明でするべきではないのかな。

この点については、http://anond.hatelabo.jp/20160517150742 で、(←は自分ではない方が書いた増田です)

実は、個別原価計算は、通常、個別に把握しやすい『個別的製品』の原価管理に使うんです。よく出てくる例えは受注生産建物船舶ね。

一方で総合原価計算は、単一製品を『大量』に『反復継続して製造』する場合有効な原価管理で、例えはまぁカレーでオッケイもっとイメージやすくいうと製鉄工場とか石油プラントね。

説明していますが、これもおそらく私と同じ理解だと思います

私と http://anond.hatelabo.jp/20160517150742 (←は自分ではない方が書いた増田です) の指摘をまとめると、

とでもなるかと思います

原価計算の手順

これは、私が http://anond.hatelabo.jp/20160519113148 で指摘した部分です。これはらくからちゃさんが誤解されたようなので、ここで再び説明させてください。

http://anond.hatelabo.jp/20160519113148 で私が指摘したかったのは、 http://www.yutorism.jp/entry/costing の、 http://cdn-ak.f.st-hatena.com/images/fotolife/l/lacucaracha/20160515/20160515165334.png という画像が間違いであるという点です。

現時点では、↑の画像は、

        ┌─────────────┐
 費目別計算  │材料費  労務費  経費 │
        └─┬────┬────┬─┘
    賦課(直課)│    │    │  
          │  ┌─┼────↓─┐
 部門別計算    │  │ │ 補助部門費│
          │  │ ↓   ↓   │
          │  │ 製造部門費  │
          │  └───┬────┘
          ↓      ↓ 配賦  
 製品計算 ┌──────────────┐
       │ 総合原価計算個別原価計算│
       │ 標準原価計算/実際原価計算│
       │ 全部原価計算/直接原価計算│
       └──────────────┘

という関係図になっていますが、製品原価計算の分類は、本来は、以下のように、

        ┌─────────────┐
 費目別計算  │材料費  労務費  経費 │
        └─┬────┬────┬─┘
    賦課(直課)│    │    │  
          │  ┌─┼────↓─┐
 部門別計算    │  │ │ 補助部門費│
          │  │ ↓   ↓   │
          │  │ 製造部門費  │
          │  └───┬────┘
          ↓      ↓ 配賦  
 製品計算 ┌──────────────┐
       │ 単純総合原価計算     │
       │ 等級総合原価計算    │
       │ 組別総合原価計算     │
       │ 個別原価計算       │
       └──────────────┘

製品計算区分においては、生産形態の種類別によって分けるべきではないか?という点の指摘でした。

実際に原価計算基準上でもそのように分類しています。(原価計算基準区分は 『原価の製品計算、原価単位計算形態原価計算基準19、20】|会計知識、簿記3級・2級・1級を短期間でマスター【朝4時起き活動のススメ】』 http://ameblo.jp/studyja/entry-11483327103.html などで確認してください)

元の画像整合するように書くとすれば、

  ┌───────────────┐
  │ 総合原価計算個別原価計算 │
┌─┤ 標準原価計算/実際原価計算 ├──────┐
│ │ 全部原価計算/直接原価計算 │      │
│ └───────────────┘      │
│                        │
│         ┌─────────────┐│
│  費目別計算  │材料費  労務費  経費 ││
│         └─┬────┬────┬─┘│
│     賦課(直課)│    │    │  │
│           │  ┌─┼────↓─┐│
│  部門別計算    │  │ │ 補助部門費││
│           │  │ ↓   ↓   ││
│           │  │ 製造部門費  ││
│           │  └───┬────┘│
│           ↓      ↓ 配賦  │
│  製品計算 ┌──────────────┐│
│        │ 単純総合原価計算     ││
│        │ 等級総合原価計算    ││
│        │ 組別総合原価計算     ││
│        │ 個別原価計算       ││
│        └──────────────┘│
└────────────────────────┘

がより適切でしょう。(外枠に各種原価計算を移動させました)

これは例えていうならば、人間を何かに着目して分類したとします。仮に以下のように、

┌─────────人間────────┐
│                   │
│ 国籍   日本アメリカ/他もろもろ│
│                   │
│                   │
│ 肌の色  白/黄褐色/  他もろもろ│
│                   │
│                   │
│ 話す言葉 日本語英語/ 他もろもろ│
└───────────────────┘

国籍、肌の色、話す言葉で分類したとして、話す言葉の分類の中が、以下のような分けかただと変でしょ?という指摘です。(話す言葉の右側の枠が、話す言葉の分類だとします)

┌─────────人間──────────┐
│                     │
│ 国籍   日本アメリカ/  他もろもろ│
│                     │
│                     │
│ 肌の色  白/黄褐色/    他もろもろ│
│                     │
│                     │
│ 話す言葉 ┌─────────────┐│
│      │性別 男/女/他     ││
│      │身長 170cm以上/未満││
│      │視力 1.0以上/未満  ││
│      └─────────────┘│
└─────────────────────┘

話す言葉区分の中で、性別区分身長区分があると、話す言葉として「性別」という言語や、「身長」といった言語があることになりますが、そんなことはないですよね。

らくからちゃさんが http://anond.hatelabo.jp/20160519220812使用した言葉を使って、最も正確に表現するとすれば、

  ┌───────────────────┐
  │ 総合原価計算制度個別原価計算制度 │※←の枠の中は、必ずそれぞれどちらか一方を選択する
┌─┤ 標準原価計算制度/実際原価計算制度 ├──┐
│ │ 全部原価計算制度/直接原価計算制度 │  │
│ └───────────────────┘  │
│                        │
│         ┌─────────────┐│
│  費目別計算  │材料費  労務費  経費 ││
│         └─┬────┬────┬─┘│
│     賦課(直課)│    │    │  │
│           │  ┌─┼────↓─┐│
│  部門別計算    │  │ │ 補助部門費││
│           │  │ ↓   ↓   ││
│           │  │ 製造部門費  ││
│           │  └───┬────┘│
│           ↓      ↓ 配賦  │
│  製品計算 ┌──────────────┐│
│        │ 単純総合原価計算     ││
│        │ 等級総合原価計算    ││
│        │ 組別総合原価計算     ││※←製品計算の枠の中は、
│        │ 個別原価計算       ││  ↑の総合/個別整合するものとする
│        └──────────────┘│(あるいは、↑の総合/個別を消して、こちらでそれらを選択するだけの方がわかりやすいか)
└────────────────────────┘

というように、一番上の枠の中の各原価計算の末尾に「制度」と付け加えて、適切な補足を加えるのが最も良いでしょうね。

(ちなみに、今回の例だと問題にならないかもしれませんが、この図だけを見ると、材料費、労務費、経費の矢印がそれぞれ、製品計算製造部門費、補助部門費にそれぞれ移動しているだけのように思われるような気もします。 今回のカレーシチューなどの例であれば、工程別ではなく、組別であっても良い気もします。)

さらに指摘しますが、http://www.yutorism.jp/entry/costing最後の方にある勘定連絡図は、工程部門別勘定が全く存在しないですね。その勘定連絡図の下で、青の太字で「『部門』の名前を明記しておくこ」ととあるので、勘定連絡図の中にそれらが無いのは、デカミスに思えます

http://www.yutorism.jp/entry/costing を眺めていて思ったのですが、いらすとやさんの画像最初使用する程度に留めて、それ以降は勘定連絡図や、標準原価計算の例ならばシュラッター図や差異分析のためのボックスを直接書いたほうが、遥かにわかやすくなると思います

らくからちゃさんは、 http://anond.hatelabo.jp/20160518011455 で、

想定読者

一通り工業簿記について学習し、問題は解けるようになったが体系的な理解ができていない者

教科書的な内容については理解したが、実際の現場での処理や実務上の取り扱い、意味合い理解出来ていない者

対象としたものであって、『工業簿記学者』を対象とした、『ゼロから学ぶ』ではない。

という想定を置いたのだということでしたよね? だとすれば、わざわざ曖昧イメージ図を最初から最後まで使用する必要性は、皆無でしょう。イメージ図がむしろ理解の妨げになっている点もあると思いますよ。そのレベルの読者を想定したとき想定読者理解の最低レベルは、「簿記二級の範囲工業簿記計算面」を理解したレベルですよね。ならば、一通り理解できているはずなので、イメージ図はさほど要らないと思います

例えば個別原価計算総合原価計算説明として、蛇口バケツ説明していますが、上の想定読者イメージから何かが新たに「わかる」ようになるのでしょうか? ここでは、主に仕掛品勘定を中心にすえて、

などといった点を踏まえて説明しなおすべきではないでしょうか。

連産品

これは、私が http://anond.hatelabo.jp/20160519113148 で指摘した部分です。この点については特に返信したいことはありません。(「原価計算基準は、今もファイリングしてデスクの上においております。」ということなので、読んでないのかなあ、と思ったくらいです)


修正履歴

2016-03-28

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います

p.4
  • HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
  • gulpのgは小文字なのでよろしくです。
p.5
p.6
p.8
  • EditorCodingってなに
p.9
  • コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
  • npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです?
    • まぁ、この後gulpタスクについて出てるんでしょう……
      • 出てこなかった
p.10
p.15
p.16
p.18

コード品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

  • HTMLの話ですよね? コード品質が維持されない難読化や最小化やコンパイルってなんだろう。
  • あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。
p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

  • その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
  • いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
  • あと日本語が変なんで、それも。
p.20
p.21、22
p.2324
  • .editorconfigにどう書けばいいかをだな……。
p.25
  • HTMLルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
  • Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
  • でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。
p.26

正しいHTML

  • HTMLの正しさとは?
  • 参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。
p.27、28
p.29、30
p.31
p.32
p.36、37
p.40

CSS教科書

p.42、43
p.44、45
p.49、50
p.57、58
  • HEXの短縮は規定しなくていいと思います
  • ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
  • gulpでできますし、ググれば出てきます
  • ちなみに、#f00よりもredの方が1バイト少ないんですよ。
  • 容量削減は人が思いつきでやるには不十分なのです。
  • そんなのはビルド時に機械がやればいい。
  • 容量の削減を理由に人の行為制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。
p.61、62
p.63、64
p.71
p.72、73
  • FLOCSSとMindBEMding共存させるなら、書くべきことが足りなすぎませんか。
p.73

block__element__elementは使用しない

p.78、79
p.80、81
p.87

GoogleChromeなら変換時に右側にマーク

p.96
p.98

svgにすることで1つの画像でまかなえる場合svg使用する

p.102
  • ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
  • Jadeについては何かルールは設けないのでしょうか。
  • JavaScriptについては……?
  • そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
  • 誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。
  • 結論:いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

2016-01-27

http://anond.hatelabo.jp/20160127083125

そんで結局代わりに何もしないなら絶望fixだと思うけどなあ

ログイン ユーザー登録
ようこそ ゲスト さん