  |
はてなキーワード: ビジネスロジックとは
変な話だが早い話、傭兵ってやつだな
アホのネトウヨや訳知り顔のミリオタが日本ではまるで軍事技術は超高度な専門職だから一般人が片手間で身に着けられるはずがないとかたわけたこと抜かしているが(チキンホークの分際で徴兵制の話になるとその理屈で逃げるからでしかないわけだが)
確かに自衛隊は普通科でも、前期教育が三か月、後期教育が三か月だ、しかしこれは破格と言っていいくらい訓練に時間をかけている
世界最強のアメリカ海兵隊は、前期後期を合わせても３か月ギリギリあるかないかくらいの訓練期間だ、アメリカ陸軍も医者とかパイロットを除いて歩兵に絞れば全部合わせても３か月だ。
訓練内容をさらに絞って、ネトウヨや、学校や職場をテロリストが占拠してやっつける妄想してるみたいなイキリオタクの陰キャが血眼にして知りたそうな個人戦技だけを絞ってみても、銃の分解手入れ、安全な取り扱い、撃ち方や構え方、付属の機材や武器の使用法、タコつぼ掘り、格闘の型を軽くして、あとは銃剣格闘、手榴弾の使い方と投げ方、野戦戦術、室内での戦術(手榴弾放り込んでクリアリングしながら撃つだけ！)応急処置といったもので、あとは腕立て腹筋ランニング、といった具合だ、ハッキリ言ってプログラマーやＳＥの方が覚える内容が高度で多いというレベルなんだな(軍隊そのものを悪くいっているわけではありません、あしからず）
さてここで思ったこと、今の日本はもはや雇用慣行から商習慣が崩壊寸前のグダグダブラック化が超加速してるわけだが、アメリカのこういうった「個人事業主の傭兵」のようなビジネスロジックやモデルを輸入して広まったらどうなるだろうか？
まあ、一億総テロリスト時代の幕開けやで～、ヘタすりゃ１９７０年台のイタリアみたいになるかもな
そうならないように自民党と警視庁ははよ今よりももっとネトウヨを育成して、アホ軍事理論叫ばせてそんなことがネットで語れないほどに涵養させた方がええでんがなまんがな
まあ、この不景気どころか国が傾いてるご時世に、のんきにネトウヨやってくれる底辺なんてそうそう見つからない時代になってきてんだろうけどな
IT系のコンサルをしてて思うのが、今自分たちでやらなきゃいけない事が何か？を見失ってる会社がすごい多いこと
半分愚痴だけど書いておく
Windowsサーバのグループポリシー設定とかVLAN設定とかアカウント発行業務、サーバのメンテナンスパッチetc..
これあんた達が本当にやりたかったことなの？運用会社なら良いかもしれないけど開発会社だよね？
いざとなれば自分たちでできる＝ベンダーコントロールしやすい仕事だからこそアウトソースしましょうよ？
それプロパーにやらせてなんか知見溜まります？まあ得るものがゼロとは言えないかもしれないですが開発より優先させるんですか？
これよく聞くんですが、正社員だから信用できて、フリーランスだから信用できないってのはどういう根拠なんすかね？
最終的には人です。会社でも肩書でもなく信頼できる人を探しましょうよ
正社員じゃなくても良いじゃないですか？というか経験上できる人は一人会社かフリーランスの方が多いですよ昨今
そんなコア業務をなんで外注しちゃうんですか？開発会社ですよね？それでお金貰ってるんですよね？
そのビジネスロジックの実装把握してないとリリース後対応も大変ですよ？
Ruby On Rails得意なメンバー居なくてしょうがなく。。。じゃないでしょ！トレーニングさせましょうよ
手順さえ知ってればできるような運用業務に忙殺されてて、勉強する時間が取れないって本当頭おかしいですよ
要するにこれです
開発に集中してください
安易に「俺たちでもできるから」、「なんとなく外注するとセキュリティ的に心配だから」という理由で開発者を雑務に費やさないで、開発させてください
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust と Lua は無理だった。
rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
http://blog.masuidrive.jp/2014/11/06/optimization/
現状の憂いなき状況(支離滅裂に書いてる)
わけわからんほどのメーリングリストが飛んでくる。またそれを追えという
＞＞は？そんな時代は終わったはずなんだけども。。。。。。。
＞＞＞ えっとメールというツールの使い方をそもそもとして間違えているよね。今の時代に
その場しのぎのビジネスロジックの追加でやっている事はシンプルなのに複雑性をます運用保守
＞＞ 守る事のほうがビジネスの価値を証明するのが辛いのにそれを呆けた結果でしょ？
＞＞ それを真剣に議論した？時間が風化させるものはほとんどだけども、それを保守する人間に「そんな悲しい事いわないでよ」って言われてもどんなに頑張ってもモチベーション上がらんでしょ。。
世の中そんな綺麗なシステムは存在しないし、そんな夢のようなシステムがある所に自分が行けることはないとは分かったとしても、せめて中二病的な何かが日々があればいいと思うけどもそれも何もない。
＞＞ デプロイ一人ぼっち(大きな声で「リリースいやっほーい！！！！！！！」って声だしてもいい雰囲気はナシ
＞＞ IEで動かせ (は？お前ちょっとそこのヨドバシカメラでwindows8買って素敵って思えるならIE動かせって言っても許すよ)
改善をするものは世の中にあふれているはずなのに職人芸を要求するチーム(組織かもしれんね)。
＞＞ よってセグメンテーションを小さくフォーカスすることが正義になる。
＞＞ はいはい。言った言わないがビジネスにおいていいことなんでしょ。それを証明するためにダルい事すんだよね。
これだけアカンな事が一杯溢れていると燃えるよねと最初思ったけど、トドメの長老陣の洗脳化作戦
＞＞ 離職率が高い所しか基本長くいなかったけれども、長期的にやっている人がこれほどまでに事業部を歪んだ形にさせることは逆に学んだ。
頭がいいってなんでしょね？とか賢いって思ってるかもしれんケド結局目の前の事を棚上げにした結果でしょ。
そんな事を考えてる自分に嫌気が差してくるから最近は能動的な振りして、何も考えないようにしたさ。
何故ならば割り切ったから。
上記の事は全部個に対していってるわけではない。
みんな大なり小なり思うことであり、その人がそう言った訳ではなく集団的心理がそうさせただけ
極論言うと誰も悪くはない
だったら潔く
ん？なんか勘違いしてね？
SIerはとにかく何でもいいからシステム導入したいし、顧客はビッグデータ！とか言いながら
日経ビジネス程度の知識しかないんだから、実質的にやることの内容はどうでもいいんだよ。
出てくる結果的には回帰分析程度のことやっとけばSIerの顧客おじさんは満足するし(それ以上のこと見せられてもよくわからない)、
あとあと困ったことになれば保守契約でSIerおじさんは儲かってハッピーになる。
要するにそれだけのことを「業務知識豊富なSEがビジネスロジックを深く理解して顧客価値を最大化します！」とか言いながらやるだけ。
日本の(顧客側)大企業で、ソフトでマジに儲けてる会社なんて存在しないから、他の部門が出してる収益を食い潰してシステム部門のおじさんが仕事のような何かをしてるだけ。
ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジックをクライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。
RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語のデバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語で記述した場合よりもはるかに時間がかかる。
また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。
ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。
仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイルで管理し、それをバージョン管理システムに含めたとしても（というか、最低そうすべきなんだが）、あるリビジョンのコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。
トリガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。
さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。
一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合。
特定の事物を極力広めないようにするにはどうすればいいか？
「メジャーになると消費され使い古されてしまう」というアンチ消費主義思想の俺にとって、このことは重要な命題だ。
なるべく周知させない活動のことを仮に「逆宣伝」と呼ぼう。逆宣伝するには、どうしたらいいか？
これは実に難しい。なぜなら宣伝活動であれば、他者がどんなにあがこうと、ある程度のレベルまでは達成できる。
例えば、お金を沢山使うことで周知させたりできる。しかし、逆宣伝の場合、他者がクチコミなどで宣伝してしまうリスクがある。
いくら頑張ろうが、有志の手で周知させられる恐れがあるため、「いかに人々の宣伝活動を抑制するか」が上記の命題達成のためのサブ課題となる。
また、「情報を一定の会員の内部だけで流れるように囲い込むこと」も重大なサブ課題である。
ちょっと考えてみて欲しい。
いまの世の中はネットがあるため、ネットで誰かが晒す(ネットでクチコミすることをあえてこう呼ばせてもらう)ことで、
たちまち広まってしまい、良質なもの・興味深いものであれば、いとも簡単に周知されてしまう可能性がある。
その結果、我々が普段接している良い商品やサービスというのは、大多数が宣伝により周知され消費され使い古されたものである。
大衆の手垢のついていない、純粋な意味で良質な商品やサービスというものが皆無に近い。
ビジネスロジックに乗っかった、一般人の要求に迎合したような商品やサービスばかりで、まったく吐き気がする。
オカネや多数決に支配されるとワンパターンになるしロクなことがない。
よくネットの人が「オープンは正義」的なことを言っているけど、共有というと聞こえは良いが、ぶっちゃけそれ大衆化でしょ。
確かにオープンな情報の流れも大切だと思うけど、クローズドな情報の流れにも価値があることを忘れてはならない。
アルバイトの1人も集まらなかったっぽくね。
結局、しなもんとジャックをご挨拶させただけで終わったのかな？
相変わらず迷走しているようにみえてハラハラするよ。はてなは。
走ってから考える。もしくは走りながら考えるタイプなのか？
経営層全員？ ｗｗｗ
はてなの営業分析とかしてきたけど、相変わらずビジネスロジックがみえない。
みえないというか、何を目指しているのかがまったくみえない。
まだ一昨年の方が「つながるサービス」とか、そういうビジョンがあったきがする。
去年のテーマを振り返ったときに、どう評価していいかわからない。
過去につくったサービスが衰退期にはいったものがでてきて資産が遺産に変わって重荷になりはじめた一年か？
アメリカ目指したのはアツかったんだけどな。
一年でどれくらい経営者としての見識やネットワークが広がったのだろうか。
いくらなんでも戦線をひろげすぎじゃないかな。
狭い範囲で動いてれば個人の能力で勝てる目もあるけど、兵站が確率できないまま戦線広げたら身動きとれなくなるだけじゃないかな。
何か考えがあるのだろうか？
競業相手とマーケットの奪い合いでユーザー数増える見込みないけどサービスの向上だけ要求されるという事態をあまり意識してないのかな？
サービス数も拠点数もちょっと保守、防御コストのことを考えると自分なんかはゾッとしてしまうが、いったいこれはなんだろう。
ノーガード作戦なのだろうか。
ユーザーの囲い込みを考えなければ保守コストも減らせるぜっ！って考えかなｗ
去年ははてなハイクとかスターとか既存のユーザーに訴求するものはあったけど新規ユーザーを引き寄せるものではなかったと思う。
あせっちゃうよね。。。
そんな状況で京都になんて分散してていいのかな……。
新しい収入モデルもつくれていない。
マーケットが伸びてる時期だから、こういうやり方あってるのかな・・・
せっかくうまくいってるのにもったいないとか思ってしまう。
わからん。。。
テレビだと電波だから確実に送信されるというメリットはあるよね。
地上派デジタルとかインターネットでテレビ番組が使用されないのも、アーカイブされないのも完全に利権絡みなんじゃないの？
もっといえば有料チャンネルが国内軒並み苦戦したり潰されてるのもその関係なんじゃないの？
番組が面白くてまた見たいと思わせるというよりインパクトだけでチャンネルを変えさせずに視聴率を稼いで高い広告料をふんだくる！これがビジネスロジックだから。
日本ぐらいらしいぜ視聴率が10％越えちゃうぐらいチャンネル数が少ない国ってば。
中国ですらゴールデンタイムで視聴率が1%いけば人気番組いうぐらい分散してると聞いたよ・・・
よくしらんのだけど、スパーボールみたいな人気番組も日本の紅白みたいにひとつのチャンネルでだけで独占的に放映されてるの？？
こんだけみんなが同じメディアに触れてる国は他にないような気がするな。
視聴率10％だぜ。どんだけおまえら同じテレビを同じ時間に見てるんだよって話しだよ。
