  |
はてなキーワード: SEとは
大阪府立図書館のシステムが新しいものになった。残念なことが２点ある。
1. レスポンスが遅い。
2. 情報閲覧性が悪い。
以前のシステムは、はっきり言って素人が作ったような簡素なものだったが、レスポンス性には問題はなかった。使っていても、「待たされている」感がまったくなかった。一方で、新しいシステムでは、いちいち「待たされている」感がするほどレスポンス性が悪い。システムの更新直後なので、今後、最適化がされるのかもしれないが、現状のレスポンス性で今後ずっと使うとなると、「どうにかして欲しい」と感じるくらいレスポンスが悪い。
情報閲覧性に関しても、前のシステムは「情報量が適度に少なかった」。そのため、自分の探しているものがすぐに見つけることができた。これが良かった。一方で、今回の新しいシステムでは、とにかく色々な情報を一つの画面に詰め込みすぎている。慣れたらいいのだろうが、UIの悪い例だと思う。UIの良いものというのは、使用者の経験(どれくらいの時間そのシステムを使ったか）にかかわらず、見つけたいものをすぐに見つかることだと思う。新しいシステムは、その点で劣っていると思う。
このシステムを制作したのは、それなりに経験のあるSIなりSEなりが用意したのだと推測するが、ユーザの立場にたっていないまま、使用者の意見を取り入れないまま、「えいやっ！」で作ったシステムのような感じがする。今後、ユーザの意見を取り入れて改善していって欲しい。
考えてみろ。今から１０年後に俺は何をしている？ システムエンジニアとやらか？ お客様に最適なソリューションをインテグレーションいたしますと、澄ました顔で言っているのか。
そんな心配しなくても、１０年後にはそんな仕事残ってないと思うよ。
某英語圏先進国の会社に転職して５年経つけど、プリセールス（営業支援）からプロジェクトマネージャまで、自分の手を動かせない、コードを書けない人はどんどん辞めていった。適当に中抜きして丸投げするだけの日本だけに生息する自称SEさまは、こっちじゃまず仕事にありつけません。
日本もそのうちこうなるでしょ。
オブジェクトによるコラボレーションを定義する時代に変わった。
でも、それだけじゃなかった。
オブジェクト指向プログラミングの時代でも、ただ窮屈な時代はあった。
動物を継承した犬のせいで、オブジェクトは現実の物質から切り離されない誤解。
デザインパターンは、ただ世界を難しくとらえるためのパターンにしか見えなくて辛かった。
その時代のオブジェクトは、フレームワークという複雑な仕組みを構築するためのツールでしか無く
プログラマは、オブジェクト指向プログラミングの申し子のようなフレームワークの上に、いるだけだった。
ただいるだけだった。
オブジェクト指向なんて概念の一切の無い、ただの実体定義する作業でしか無かった。手続き言語の時代と変わらない。
でも、本当に複雑なのは、フレームワークじゃない、表現すべき対象だった。
複雑が故にあきめてただけだった。
キレたら終わる糸をさまざまに張り巡らし、あとは時間という物量の力技で、
綱を渡り終えることを願う、諦める作業こそプログラマの仕事だった。
システムは、常に変化することを要求される。
時間という物量は制限された。
薄っぺらなシンプルな解釈は、システムに小さな変化が発生するだけで
ピンと張られた綱は簡単に弛む。
複雑な対象と向き合うことに拒否することはもう許されない。
そんな時代のSEの仕事は、複雑な対象を複雑だと定義することだ。
プログラマ達が、対象を定義するために必要な、本質を暴きだせ。
それが成功すれば、本質はオブジェクトに変換されて、システムは１つの世界の創造物に生まれ変わる。
※ただし、良いプログラマがいればだが。
お客様の言う通りにするんじゃない。お客様が願ってる世界の本質を暴け。
でも、神の意図を見つけ出し、世界の本質を暴く行為もまた同時に面白い。創造的だ。
もしそれが面白く感じないなら、お前まだコードを書くということに気が付いてない。
http://anond.hatelabo.jp/20131228223726
SEだなんてつまらない。なぜか？ つくるものを自分で決められない。お客様の望むとおりにいたします。ふざけろくそが。プログラムを作って売って生きて行きたかった。自分で作るものを決めてその通りに作り、それを売って稼ぎを得たい。使ってくれた人の満足が、お金に変わるような仕組みが必要だ。雇われるのではなく、雇ってみたい。企業して社長と呼ばれてみたかったのだ。
コードコードコード。それが全てだろう。それ以外の作業の全てはコードを気持よくかけるためにやるのだ。当たり前だ。それ以外なんてゴミより価値がない。
ゲームプログラマになりたいと一瞬くらいは妄想した。だがやっていけないだろう。いや本当にそれしかなかったのなら、できたはず。でも俺はそれ以外で進んでしまった。好んで崖から飛び降りる真似なぞどうしてできる。だが、このまま進んでいっても足から腐っていくのだ。わかっているわかっているのに。どうすればいい。俺は創りたいんだ。
創る。ただそれだけだ。俺の価値観はそれだ。創り出せる者は、人を名乗る資格がある。それ以外はゴミだ。人ですらない価値のないもの。どうしてこうなった。自分が無能であることは知っている。たかだか受験勉強程度すらできなかったのだ。俺は俺の思うとおりにやると間違うのだ。何も正しくなかった。俺の中に正しさなんてなかった。だから予備校が言うとおりにやっただけだ。凄いのは俺ではなくて予備校のカリキュラムだろうが。何も考えずに言われた通りにすることなら、人でなくてもできるじゃないか。高学歴？寝言は寝て言え。毎年毎年何万人も生まれるような高学歴に、いったいなんの価値があるんだ。
その気になれば今でもできるのだ。そうだろう？ ちょっとクリックするだけですぐに環境は手に入る。俺はJAVAを雑魚並には知ってる。学習コストは低い。なぜやらないのか。
仕事の苦痛をやわらげるために、何拍が置かなければいけないのではないか？
マイナスに振れた針をゼロに戻してからスタートしなければいけないのではないか。そのために。ただそのために。時間が奪われる。ゼロに戻ってからやっとスタートできるんだ。いややはりこれは甘えか。言語化した時点で陳腐化は免れない。俺はもう届かないのかもしれない。もう届かないとわかったなら。生きる価値なんてないだろう？
コード書くのが楽しすぎて何日も徹夜してしまうような体験を俺はしたいんだ。自分の指先が描くコードがこの世界を変えられると信じたいのだ。俺はロマンチストなのだ。そう考える。考えるくせに。なんで何もしないんだ？ 馬鹿なのか？ ゴミなのか？ どうしてそんな面して生きていられるんだ？
今このファイルをとじた瞬間から、コードを書き始めればいい。つくりかけのゲームだってある。Webサービスの設計だって用意をはじめている。やればいいだけだ。足りないのは、時間時間時間。それもいいわけか？ 時間なんて作れば良い。 いやできないんだ。マイナスからプラスに振り戻すには反動がいる。時間もかかる。逆に考えろ。その程度なのだ。俺にとってはその程度。だからいつまで経ってもできない。
考えてみろ。今から１０年後に俺は何をしている？ システムエンジニアとやらか？ お客様に最適なソリューションをインテグレーションいたしますと、澄ました顔で言っているのか。
怖い。
それは何を創るんだ？ 誰のために？ なんのために？ 何を創れるんだ？
わけのわからん会社の、どうでもいいような業務のために、コードを書くのか？
しかも自分の手は動かさない。こんな仕組みを実現するためのコード書けとほおりなげるだけだ。
それで生きていくなんて、自分を許せるか？
うちは「たまたま入れた会社がITやってただけで、プログラミングとかようわからん」で10年20年働いてるプログラマーもどきとSEもどきばっかり
増田のまわりにいる「プログラマー」が果たしてうちには何人いるやら
オフショア開発と言えば聞こえはいいが「よくわからん、中国人作って」→「動かしてみた(エンドユーザがやるような操作だけ)けどダメだった、どこが悪いかしらんけど直して」
プログラマといっても、大手ベンダーが作ったフレームワークに乗っかり
実際のフレームワークの仕組みがどうなっているかも全く知らない。
設計書を修正したりもするけど、言われたことを書き直すだけ。
SEなんて高尚なもんでもないし、
気が付けば来年もう３０才になろうとしている。
正直言って、うだつが上がらなさすぎる。
そんな自分を変えたくて
女性声優画像bot（https://twitter.com/w_seiyu_bot）
笑いたきゃ笑ってくれ。
できる人には数十分でできる芸当だと思う。
それでもなんとか自分を変えたくて、
０を１にしたくてがむしゃらに頑張った。
いろいろ試行錯誤を重ねて１ヶ月以上かかったと思う。
分かる人にはすぐに分かると思うけど
少しだけ特徴を紹介してみる。
仕事ではJavaやC#でプログラミングしているけど（リーマンプログラマの9割はそうだと思う。）
小規模でもいいので何か一人でものを作りたくてLLなpythonに挑戦してみた。
twitterのAPIのラッパであるtwythonっていうライブラリを使っている。
僕の唯一の趣味といっても過言ではない大好きな女性声優さん達の画像は
最近のAPIは有料のものが多いみたいなので一部スクレイピングで画像を取得している。
５分おきにtwitterのAPIで画像をアップロードしてたら、途中でbotが止まってしまった。
APIの制限で１日の画像アップロード数に制限があるみたいだ。
仕方なく時間帯を分けてtwitterのAPIでアップロードするパターンと
twitpicのAPIでtwitpicに画像をアップロードして、そのURLをつぶやくパターンを用意した。
（このtwitpicのアップロードにしょっちゅう失敗する。。。なんでかわからん）
なんとか多くの人にフォローしてもらいたいと思い、
KLOUTのAPIを利用して取得したスコアが50以上の人をフォローさせてもらっている。
（KLOUTについては僕も知らなかったけど、ググれば分かります。）
さも簡単に実装してきたような書き方だけど
一つのことをやるのに何日も何日も頭を悩ませた。
実際に運用してみてどうかというと、これがまたとんでもなくひどい。
ありがたいことに、沢山の方にフォローしていただけてはいるが、
昨日は南條愛乃さんといって三森すずこさんの画像をつぶやいてしまい
自分のユーザー名で検索するとフルボッキにされててみれたもんじゃない。
（不愉快な思いさせた方には本当に申し訳ないと思っています。すいません。）
あんなに苦労して作ったものがこんな情けない結果で本当に泣きたくなる。
所詮こんなもんかと。
それでもとりあえず、なにか変ったのかもしれない。
０が１ではなくて－１になったのかもしれないけど。。。
別に弁解したいとかそういうわけじゃないけど、
なんとかワザとじゃない、僕は声優さん達が大好きなんだ
ということが分かってほしくてモヤモヤした気持ちを
書きなぐってみた。
とりあえずこのbotをどうするかは決めてないけど、
なんとか画像間違いだけは解消していきたい。
ご助言いただきたい。
さて、そろそろ仕事に戻ろう。
最後に一つだけ言わせてほしい。
＿人人人人人人人人人人人人人人＿
＞ あすみん、愛してるっ！！ ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
さっきはてなブックマーク見たら、はてなブックマーク - jQuery最高の教科書｜株式会社シフトブレイン 著というのがはてブ集めてて嬉しかった。
最近はてなって、SEが少なくなったから、こういうテキストがはてブ集めると久々にはてな村に来たという気がしてテンションが上がるよね。
jQueryってのはid:blue1stが指摘しているとおりに、バージョンアップで使えなくなることが多くてゲンナリなんだけど（Ver.1.9で今まで使えた関数が削除されてゾッとした）、コツさえつかめばJavaScript使う上でこれほど便利なものはないんだよね。Webアプリ作ろうと思えばjQueryは避けて通れないんじゃないかな。
ASCII.jp：40分で覚える！jQuery速習講座 (1/6)
とかで勉強したり、
7つのサンプルでjQueryを学ぼう！「jQueryが全く分からない人のため」の超初級者向け入門講座 | OZPAの表4
それが、今回のテキストではかなりまとまった決定版めいたものになっているんではないかと期待している。アプリを作るならば、覚えておいて損はない知識と思うんだよね。
いろいろなテキストがあるけれども、せっかくだからここで俺もいくつか基本書を薦めたいと思う。ブコメにあった
DLmarket / jQuery入門道場 [ダウンロード]
はもともと jQuery入門道場の記事を電子書籍化したもので、このサイトには確かに一番お世話になった。
他には、
Amazon.co.jp： jQueryで作る Ajaxアプリケーション: 沖林 正紀: 本が画面周りについて詳しくて、分かりやすかった。
読みやすさを求めるならば、やっぱり
Amazon.co.jp： Web制作の現場で使う jQueryデザイン入門 (WEB PROFESSIONAL): 西畑 一馬: 本だろうね。これがオススメなのは、HTMLとCSSの知識があればなんとか理解できるというところ。
ただ、慣れてくるともっと実践で使えるのが求められると思うから、そんな人には、
Amazon.co.jp： jQueryクックブック: jQuery Community Experts, 株式会社クイープ: 本だろう。
割りとよくある話で、発注側も受注側もまあ、大変ね～～ と他人事に思うけど、
ふだんからExcelでそんなしちめんどくさい事やってるんだったら、ものすごくいいほうに改善出来る可能性あるのにね。
元増田は担当SEに不安がってるヒマがあったら、その担当SEに相談して自分とこの上司にどういうふうに進言
簡単。
新システムを導入することってのは即ち「仕事のやり方を根本的に変える」というとても重大で大変な話だということを誰も自覚してないから。
加えてそのことを誰も説明せず、一般層のパソコンに対するブラックボックスなイメージも手伝って、とにかくシステムさえ入れれば劇的に業務が改善してウハウハだと思い込むから。
大抵はこういう構図。
案件さえ取れれば後はｼﾗﾈという態度の奴が多い(どういうわけかこの業界の営業は「自分が何を売っているのか理解していないし、しようとも思っていない」奴が多い)ので、まるで魔法の水晶球のようにシステムを売り込む。
現場からは報告された書類しか見ておらず、利益が足りないのは問題だとは思っているが具体的に今のやり方のどこが問題なのか分かっていない。自身コンピュータのことはさっぱりという関係もあり、営業の話を鵜呑みにしてとにかく導入すれば業務が劇的に改善すると勘違いして導入を決める。
システムを何故導入するのか、何がいいのか分からないし知りたいとも思っていない(どうせ使うのは自分じゃないと思っている)ので、面倒なのでパソコンに詳しそうな部下Aを勝手に担当にする。
とりあえず割り当てられたが今のやり方から変える話だという責任重大なことを任せられても困るし、そもそも実務者は今の実務に問題があると思っていない。
http://anond.hatelabo.jp/20131204103422 を書いた増田だけど、そもそも元増田の場合、どういう経緯で新システムを入れることになったのかって所に行くと思う。
元増田が「何が問題で今のやり方を変えることになったのか」を全く理解していない所からすると、多分上層部が「業務システムを入れるから担当になってくれ」とかいきなり言って、その理由をろくに説明もしていないんだと思うけど。
いずれにせよ、今のままだとシステムは出来るが、現場の作業員は「使いづらい」とか言ってそのままExcelを使い続け、システムには期待するようなデータが入らず、上層部はキレ、SEがいつまでも改修させられて、費用が膨れ上がるだけ膨れ上がって結局業務改善には至らないという最悪の、しかしよくあるパターンが待っている。
これは、失敗プロジェクトだわ。
失敗の最大の原因は、増田の会社の上層部がシステム構築に元増田をあててしまったことだな。
会社の目的はたぶん、エクセルで散らばっているデータを一元化することだろ。
しかし、増田はそんなことに考えが及ばず、ただ単に自分の業務をやりやすくしようとしているだけだ。
新システムをいれるからには自分の作業効率があがらないと意味ないし、自分の作業の手間が増えるとかはありえないって考えている。
でもこれは仕方が無い。元増田は一スタッフに過ぎず、彼は目の前の自分の仕事をこなすのに精いっぱいだから。
まあ、えてして、こういうの実際に作業している現場の人間に任せた方が良いものができると勘違いしている上層部は確かに多いんだけれどね。
ここの作業員の質が悪くなると協力する為のコストが人数が増えるメリットを上回るのは良くある話。
そして、コーディング以前の問題として設計が悪いと大規模なプログラムはまともに動かないのも常識。
で、まともに設計できる人間ていうのは別に「天才」ではない。ただし、そこら辺に転がってるわけでは断じてない。
きちんと色々なモノを自分で作成したことがあって、その上で自分が設計したものを大人数に作らせたことがある、そういう経験の積み重ねをしてきた人間。
日本の下請け構造が最悪にクソなのが、製作の経験がなくて設計（）だけ出来るつもりになってるSEもどきが、製作経験のある下請けになんとなくモノを作らせてるとこ。
作業員、作業員というが、システムの設計はコーディングが理解できない奴に出来るはずがない。
優秀な設計者にきちんと設計者としてのポジションを用意した上で、きちんとしたヴィジョンを描ける人間がプロジェクトを導かないと、大規模なプロジェクトはうまく行かない。
ちなみに、土建業界でも下請け依存の体質は問題視されていて、日本のゼネコンは優秀な下請けが使える国内では高品質な仕事ができるが、海外に行くと途端に悪化するという事例が知られてる。
つまり技術的にキチンとした指示を出す能力が足りないという事。
下請けにやらせりゃいいんだよｗ なんて言ってるやつは本当に時代遅れ。
かといって、天才なんて言葉で簡単に片づけて、本当に個人に必要とされる技能とチームが作るべき仕組みについて考えられない奴もバカ。
ここの作業員の質が悪くなると協力する為のコストが人数が増えるメリットを上回るのは良くある話。
そして、コーディング以前の問題として設計が悪いと大規模なプログラムはまともに動かないのも常識。
で、まともに設計できる人間ていうのは別に「天才」ではない。ただし、そこら辺に転がってるわけでは断じてない。
きちんと色々なモノを自分で作成したことがあって、その上で自分が設計したものを大人数に作らせたことがある、そういう経験の積み重ねをしてきた人間。
日本の下請け構造が最悪にクソなのが、製作の経験がなくて設計（）だけ出来るつもりになってるSEもどきが、製作経験のある下請けになんとなくモノを作らせてるとこ。
作業員、作業員というが、システムの設計はコーディングが理解できない奴に出来るはずがない。
優秀な設計者にきちんと設計者としてのポジションを用意した上で、きちんとしたヴィジョンを描ける人間がプロジェクトを導かないと、大規模なプロジェクトはうまく行かない。
ちなみに、土建業界でも下請け依存の体質は問題視されていて、日本のゼネコンは優秀な下請けが使える国内では高品質な仕事ができるが、海外に行くと途端に悪化するという事例が知られてる。
つまり技術的にキチンとした指示を出す能力が足りないという事。
下請けにやらせりゃいいんだよｗ なんて言ってるやつは本当に時代遅れ。
かといって、天才なんて言葉で簡単に片づけて、本当に個人に必要とされる技能とチームが作るべき仕組みについて考えられない奴もバカ。
倍率4倍の業種がある。
一方で倍率0.2とかって極端な人気求人もある。
前者は、保安警備や建設業、飲食業。後者は、サービス業や一次産業に集中してた。
職種別に見ると、とりわけ事務職に人気が集中していて、一方で管理職が若干不人気の傾向。
もう一つ、警備保安関係や土方、下流SE、清掃業、介護医療は求職倍率がいやに低い。
求人数は供給過多気味なのに求職者数が圧倒的に少ない状況である。
他方、営業や事務などは人気職種として、逆に生産管理など要特殊資格の職種は人気が低い。
当然だが、警備保安や介護医療などの業種はただでさえ低賃金にも拘らず要特殊資格であり敷居が高く一見さんお断りの雰囲気もあって求職を妨げている。
更に、お馴染み中間搾取のされやすい構造であるため、低賃金ながら重労働であるといった悪循環も用意されており、またブラック企業情報が取り沙汰される度に
そういった業種職種の倍率は冷え込むばかりである。
ましてや今度施行される特定派遣法規制緩和などで、より倍率が冷え込むに違いないのだ。
ストライクswitch文 これはゾンビプロセスですか？ キル-9キル
シューウデンタイム 最終納期彼女 テイルズ・オブ・エンジニア
VeriSignのばら ガンプラC++ビルダーズ IT土方まさか☆デスマ
ブラックラー刃牙 ロード・ストア戦記 れじ☆すた 謎の変数X
シスターprintf 新製品エヴァンジェリスト 鉄腕atof 評価
コード規約～反逆のリリース コードゼロ 大ピンチ・コード コード：ブレイカー
OCamlと香辛料 あらいぐまHaskell ヒカルのGo ななかC/C++ コボラ
あした納める製品の仕様を僕達はまだ知らない。 LOTUS;NOTES
継承ダイモス 鋼の連勤術師 コンパイラ 機動戦士ガンダム0080 パケットの中の戦争
廻るpingDRAM とんでboolean ゼロ除算の使い魔 THEビッグオー記法
