「システム開発」を含む日記 RSS

はてなキーワード: システム開発とは

2018-02-25

anond:20180225160814

システム開発作業にもよるけど、優秀な人は残念な人よりも何倍も成果を出すからなぁ。

適切な設計をするから無理が無くソースも簡易になり、結果として不具合も少なく期間コストが安く済むという良いサイクルになる。

先を意識せず見通せない人だと、その場しのぎの設計で後から手戻りが起き、ソースがツギハギだらけで複雑になり、結果として不具合が多発して時間も掛かり信頼性も低いというデスマーチが起きる。

2018-02-13

anond:20180213171933

よくある話だね。

どっちか一方じゃなくてどっちにも原因はある。


RFP顧客と一緒に作っていくものだ、顧客が丸投げであるのなら、

顧客システム開発に対する意識をこの段階で変えなければいけないし、

啓蒙をしていかなければいけない。

上記模範的意見であり間違いではないのだけど、

元増田顧客啓蒙成功したことあるのかな?

もちろん成功例はあるんだろうが、私は見たことないし自分でもそれができたと評価したことがないので単純に興味がある。

文化シャッターが悪い?IBMが悪い?

この界隈って、IT関係の人が多いから、どうしても目線がそっちになるので、

「どうせ顧客が今までと同じにしろ」とか「無理な要求したんだろ」とかの

コメントが多いが、自分は少し違う。

自分も一応エンジニアという職について、上流の仕事をしているが、

この案件あくまで外側から見る限りIBMに落ち度がありそうな気がしてならない。

 

なぜなら自分たちRFPを作って、自分たちで開発しているからだ。

RFPを作っている段階である程度開発の提案の形は見えていたはず。

RFPを作る段階で最上流の要件定義ができるはず。それが全くなされていない。

要求の変更が多かった。とあるが、その時点で最上流のRFPの失敗だし、

その責任IBMにないとは到底思えない。

 

RFP顧客と一緒に作っていくものだ、顧客が丸投げであるのなら、

顧客システム開発に対する意識をこの段階で変えなければいけないし、

啓蒙をしていかなければいけない。

システム刷新業務全体の刷新なのだということに。

だが、それを怠り、言われたままのRFPを作り、何とかできる形で、

作り上げ、RFPを作っていたコネクションでそのまま受注し、

後は開発部門エイヤ!っと丸投げたら、それは失敗するに決まっている。

逆に顧客システム開発に対する認識ギャップRFPの段階で埋められないなら、

その案件下りるべきなのだ

 

赤字が出るとわかっているプロジェクトなのだから

だが、IBMは受けた。受けた以上QCD責任をもたなければならないし、

それが履行されなかったのだから損害賠償は当然となる気もする。

 

だが、一方で、顧客はどうだったんだろう?

IBMがもしそういった働きかけをしていたとしたら、それにどれくらい応じれたのだろう?

システム刷新に対して業務が変わることを極端恐れ、RFPから多くの変更を

強いる形になっていなかったか

そういうところはこれから明らかにしていく必要がありそうではある。

 

だが、現時点ではIBM側に何等かの落ち度があったことは否めないと個人的には感じている。

2018-02-04

恵方巻の廃棄を批判した奴。お前の業界はどうなんだよ?

はてな村って大体IT系ばっかりだから、他の業界分かんないくせに叩くよなぁ?

分かりやす説明してやるから、少し反省しろ

まず、「廃棄をなくす」ための方法を教えてやる。

それは、「受注生産」することなんだよ。

事前に、「何個必要か」が分かった上で、「その個数だけ生産する」

これで、廃棄がなくなるわけだ。


で、今日食べるものを、生産するのに、どれだけ時間がかかるのか?

ってことがボトルネックになってくる。


食い物っていうのは、大体が生き物だから

1日でできるわけじゃない。


何が言いたいかというと、食品において、

受注生産は、不可能ってことだ。


から予測して食品を準備しておくしかない。


で、その予測の精度を上げるのにも限界がある。

その予測を外すと、欠品したり、廃棄になったりするわけだ。


これ、システム開発に置き換えると、

工数見積もるときに、多少多めに取るやつ。

あれと、同じだ。


で、「廃棄なくせ」っていうことは、

お前の業界でいうと、そういう「バッファ的なものをなくせ」(ただし、期日までには納品しろ

ということに他ならない。


恵方巻の廃棄を批判するってのは、

翻すとそういうことなんだよ。


もちろん、個人的にはフードロスは減るべきだと思っている。

売る側の力量によって、廃棄の量も異なるので、小売側は努力すべきだ。

そもそも廃棄=利益流出なので、各社抑える努力はすでにしている)


お前だって仕事を真面目にやってるんだったら、

少しでもバッファを消費しないように、努力してるだろ?

同じように、どんな業界だってみんな頑張ってるんだよ。


言いたいことは以上。

はてな村IT業界に甘く、他業界に無遠慮に厳しいところ、腹立つわ。

2018-02-01

ライセンス

システム開発会社のくせに開発ツールWindowsなど海賊版やらライセンス違反を繰り返しているのほと笑えてくる。

開発会社に密告するとどーなるかな?

2018-01-22

あるゲームをすごく時間かけて遊んで、クリアたからやっと設定資料集読める!と思って読んでて、ものづくりに対する開発者の想いを見ていたらそれとは対照的自分の今の仕事に対してますますやるせなさが募ってきた。

今はシステム企画から開発のようなものをやっているけれど、方向性も固まってないし、実体が何もないのに上はさもできてますという体で内外に言いふらすし、自分たちが何を・何のために・誰にむけて・どういうもの提供したいかということが何も分からない(各々が別々のことを思い描いている)この状況って何なんだろう、と。

ものをつくる作り手は少なからユーザが楽しんでくれるとか、役に立ててもらえるとか、何かしらのいい反応を願ってつくるし、それを見返りとして求めるのは自然な姿だと思う。いちおうこの「システム開発」が「ものづくり」になるのならば、そういうものを期待して然るべきかもしれないのに、本当に何のためにやっているかも分からないし、誰かがこれによって喜んでくれる姿なんて想像もつかない。言われている目標理想像を叶えたいのであればもっと他にやるべきことがある。

新しいことをやらなければいけない、って言われて集められたのが40代50代のおじさんばかり、かつ開発部門上長営業企画のことしか(ことすらも)分からない、っていう時点で分かりきってたことだけど、結局今の「なんだかよく分からないけど生活を保つための仕事はある」っていう状態を保ちたいだけなんだろう。

好きなゲームのことから嫌な仕事のことを考えてしまうなんて嫌だなあ~

2018-01-17

今の会社の悪いところ

今の会社SIer)への不満的なものが溜まってきたのでここに置いておきます

2018-01-08

anond:20180108174823

■■■総結論■■■

  

コンビニから改革案

  

エスパー店員を雇う。またはエスパー店員養成学校設立する(国の補助金もアテにする)

    

  

コンビニレジシステム開発している会社側の努力

  

レジの小銭ジャラ挿入口を客側にする

  

②投入した小銭の金額を客が確認して違ったら(納得できない場合勘違いしている場合等)、全額戻し。

  

③投入した小銭の金額を了承したら「OK」ボタンを押す

  

ポイントカードはいつでもタッチ認証。基本は最初タッチする。会計後の認証タッチは、レシートに反映されない。(レシートに反映したい場合最初からやり直し)

  

⑤一連の「小銭投入」「ポイントカード認証」「すべて確認」という客の行動の監視商品の袋入れは店員仕事

  

商品渡し&レシート渡し&「ありがとうございました。」の声掛けは店員仕事

 

  

客側の変更点:

  

上記改善点をすべて受け入れて、スムーズに実行する(スムーズに実行できない輩は、駅の自動改札ICカードタッチで弾かれるクソ馬鹿野郎の如く、周囲の白目対応

  

以上。

2017-12-29

あの記事の続き

anond:20170413064206 を4月に書いた。匿名ダイアリーで書いた日記としては、反響をいっぱい頂いた。耳に痛い意見もあったし、励ましや慰め、感謝言葉も頂いた。

今年の仕事も終わったので、あの記事が結局どうなったのかはまとめておこうと思う。

1. SIerへの思い

元の日記へのコメントでは発注者側の無知二次三次請を地獄に落とすことについて指摘があったので、それも併せて。

人月など意味がないことについて自分の中で割り切ったので、社内への説明では適当人月でっちあげることにした

社内で通りそうな人月単価はもうわかった。だから、うちの希望納期が通るかどうかだけ聞いておいて、通りそうな単価で割り算するだけにした。

そんなに人数必要か? と突っ込まれた時には「必要でしょうね。だってあなただったらプログラムからテストまで、一人でできますか?」と言い返すことにした。

これを続けた結果、人月について突っ込まれることはなくなった。

納期についてはメーカ意見を最大限採用している(これは前からだが)

納期遅れだけはまずいな、と思っていたか可能納期については昔からメーカから提示採用してきた。最近は3か月くらいはプラスしておくことにしている。

「短くならないの?」という問いについては「無理ですね。そもそもこの機能必要なら、もっと早く相談するべきだったでしょう?」と返している。

これを続けた結果、逆にこっちでスケジュールを作れるようになった。

また、納期プラス3か月することで人月計算に余裕があるから、通りそうな単価に近づけられるようにもなった。もっと早くにやっておけばよかった。

保守費の値下げについてはこれから交渉

交渉するけど、基本的には保守費を下げてもらえる条件などほとんどない。さてどうするかはこれから考えようと思う。実の支払金額を下げろと言われたけど、下がらなかったら仕方ないよね、と割り切っている。そもそも保守費をけずるのは私の本意ではない。

2. 偉い人への思い

・どうでもええわ、の精神

4月13日あの日記の後、上期・下期の人事評価がなされた。評価は大してあがりもしなかった。どちらも6段階評価の3。

昇格の条件で考えれば、2年間・4回の人事評価コンスタントに4を取り続け、上期評価後に部門長に審査されなければならない。

まり、この先2年は昇格しないことがわかっている。この4年ずっとそうだったから、もう昇進・昇格は期待していない。

どれだけ頑張っても評価など上りもしないのだから、社内の意向を気にすることもやめた。

何もかもどうでもええわ、それよりは自分のやりやす方法をとろう、と決めた。

システム開発における工数単価の比較バカへの説明に楽なので、使い続けている。

上でも書いたけど、工数単価をコントロールしているか理解のできない上司や偉い人への説明に苦労することは少なくなった。機能面を理解させるのも一苦労だが、バカにもわかるように擬人化させて説明することが増えた。

例:このデータをなげないと、システム側は「データが来ていなくて処理できませーん」って言うんですよー。

システム機能追加や保守ができるのは、そのメーカだけだよ→でも、似たような機能自分らで作るよ。

システムについて理解できない偉い人らに連れられて、メーカの人を何度も呼んで打合せするかわりに、こっちが作った仕様説明実装するのにいくらかかるのか? を問うだけの打合せを一度だけすることにした。あとは全部私とやりとりしてもらっている。

また、金額に折り合いがつかないから、別のメーカ代替機能をつくってもらうことにしたものもある。

ソースコートは開示できない。だから、代わりに私が必要となる機能仕様実装手前まで作って、コーディングをお願いする手口をとることにした。

上でも書いたが、どうでもええわと割り切っているので、多少問題があってもいい。実装手前までの仕様策定を私がやったのだから、それに従ったメーカは私が守るだけのこと。

場合によっては自分でも作ることにした。その代わり残業時間が増えたけど(後述)。

・「実際そういうやり口で、うちの仕事を受けてくれなくなった業者があったと聞くぞ。又それを繰り返すのか?」

繰り返している。前はそうならないように配慮していた。しかし、下っ端の私らが配慮しても、開発・工事現場担当たことがない者(大概は課長以上)の行動で業者を困らせつづけた。

もうリカバリーできない。業者からは不平不満がでており、この案件が終ったら、二度とうちの案件はうけないと言う会社もあるようだ。

バカ役職を与えたのは会社なのだから、そのツケは会社が払うしかない。

稟議を引き戻した件については完了した。

から思えば、嫌がらせにちかい理由だと理解している。

金銭面というよりも、ある種の機材を技術面/運用面/コストから否定した結果、その機材を使うことで微々たるイメージアップができると思っていた偉い人にとって不満だったようだ。2ヶ月遅れたが、引き戻しをさせられた稟議案件は完工した。

その機材は別の工事担当者案件で導入することになった。すでに私が指摘していた問題点が露呈している。

偉い人にとっては何のダメージもないだろうけど、導入させられた部署の不満は高まっている。バカの下で働くのは大変だな、と思っている。

3.個人的な話。

評価もされない

上でも書いたとおり、評価されないのはもう諦めたのでいい。理解できないもの評価できるわけもないし、そもそも理解しようという気もないのだろう。

ユーザからは「使いにくい」と文句を言われて、上からは「よく考えたのか」と怒られる。誰がそんな仕事に喜びを感じる?

未だに喜びは感じていない。しかし、辛いと思わなくてもいいように働く方法がわかってきた。

使いにくい、と文句をいわれても「どうせシステムなど、お金を生まないと思われていて、予算がでないかしかたないよね」と答えている。

その上で改善検討はするが、お金がでないのだからできることには限りがある。

自作ソフトでなんとかできそうなところはそれでカバーすることにした。

・内作を許容することにした。

ここまでで、予算が通らない分で小規模なもの自作することにした、と書いてきた。

以前ならば、自分退職するまえに死んだりしたら内作したソフトメンテができるひとが居なくなるので、極力メーカに作ってもらおうとしてきた。

そもそも、内作のメンテが大変なこと、開発者が死んだり会社に来られなくなったとき対応を考えておかないとならないことはずっと説明してきたし、退職者が好き勝手につくったソフトメンテで苦しんでいる部署が社内にある。だからメーカに任せましょうという説明をしてきた。

内作を提案したときメンテ担当者をふやすことも依頼したが特に増やされる様子もない。

それは会社の考えかたなので、どうでもいいと割り切った。私が死んだ後のことなど知ったことではない。

・新しい技術も身に付かない→残業しながら勉強してやれ

一番大きく変ったのはここだと思う。残念ながらかかわっている案件全体が炎上しつつあり、残業時間がそのまま勉強時間にはなっていないが、内作をしつつ興味のある言語勉強をすることにした。

それについて「家で勉強するべきではないか?」などとのツッコミはない。どうせ理解できていないのだろう。

もし文句をつけられたとしても、こっちには「内作で数百~数千万を浮かすんだから、内作に必要学習時間業務として認めろ」といいきる度胸がついた。

それで上司評価が厳しくなっても「どうでもええわ」、もとより評価されていなかったのだから

ちなみに残業時間がどんどこ増えた。体はだるいし、ストレスチェックの結果2年連続産業医カウンセラーとの面談を推奨する手紙をもらった。36協定上の制限時間などもブッチすることがあるが、それについて文句をいわれても「どうせ人がいないのだから仕方ないだろう? 文句あるなら仕様策定もできるような人材を確保するか、メーカに頼んで数千万はらえ」と言い切った。

開き直ると楽だとわかった。

・今の部署を離れるか、システム以外の仕事をするために勉強することにした。

実は法律に興味がでてきた。そこで行政書士試験をうけた。新しい分野を勉強するのはたのしい、合格していればうれしい。

また、本社システム担当者に「本社システムやらせてほしい」とお願いした。今の部署から離れられるなら嬉しい。バカ上司の下はもううんざりである

4. 日記コメントをくださった方々へ

一杯ブコメをいただいた。皆様ありがとう特に気になったコメントは次のとおり。

id:luccafort これに少しだけ似た経験若い頃にさせてもらった。その時言われたことが「なんでそんなに彼らの肩を持つの?」だったので根本の考え方や感じ方に断絶を感じて絶望した。増田はすごいよ。」

→私も言われました。「なんで業者の味方するんだよ」と。あー、そういう風におもってるんだ、と理解した瞬間にもうええわ、と切り変わりました。そこから上記のとおりです。

id:celaeno_w インフラのありがたさは、一回サーバー落ちて、保守費用なんかと桁が違う損害出すと分かるんだけれどな。こういうのは、「格安バスツアー」とか、「格安海外旅行」と一緒よ。後悔した時には遅い。 」

→そうですね。ですから保守稟議にはそういう話を書いてきました。停止からの復旧時間、その間に指図できなかったロット機会損失などなど。1日とまれ保守費など比較にならん損失がでるよ、と。

でもそれでもけちりたいようなので、もういいのです。一回地獄をみればいいんですよ。

id:otihateten3510評価もされない、新しい技術も身につかない。ユーザからは「使いにくい」と文句を言われて、上からは「よく考えたのか」と怒られる。誰がそんな仕事に喜びを感じる?” 至言問題はなぜ全員辞めないのかという点 」

id:su_zu_ki_1010 転職おすすめされても、その方の年齢とかスキル(新しい技術も身につかないとぼやいておられる)もあるので難しい場合もありそう。部署異動で無縁のところに行くのを希望するという手もあるのではないか。 」

無職が怖い、この一言です。部署移動はこの6年間、評価毎に話ししています希望は通りませんでした。今は他部署から是非貰いしてもらえるようにアピールしています

2017-12-22

anond:20171222165819

猿的な組織も考えてみる

序列が明確 → 国内企業っぽい

方針は振れるけど、上の指示は絶対ブラック気質法人向け企業かな

リーダー絶対世代交代以外は不動の地位金融業っぽいな

1人が強引に進める、達成はあまり気にしない → トンデモPMが率いるSIプロジェクトかな

総合的に (技術スキルが低い) 国内の老舗金融システム開発企業と思われます

2017-12-08

anond:20171208194240

ゆのって、単にシステム開発元がOEMで出してるだけで、別にパクリでもなんでもないんじゃないの?

2017-11-24

例のシステム開発Excel

Excelださいっていってる奴らはなに使ってるのよ

ぶっちゃけ上司が使ってるから使い慣れちゃったんですけど!

まだ引き返せる気がするからなにつかえばいいのかおしえろください

2017-11-23

転職して入った小さな会社

今時サイトホームページビルダー製で、fontタグとか使ってる一昔前のページだった

自分仕事システム開発で、web制作も任されているので

とりあえずみんなが更新し易いようwordpressにしようと提案した

予算もないし、それっぽいテンプレートを使ってそれっぽいサイトにした

しかし60手前の広報のおじさんが

「ウチの会社はずっとビルダーを使ってきた。だからそれで更新できるようにしろ。」と言う

新しい技術を覚える気がないのか、自分の知らない知識を使うことが嫌いなのか、

どっちにしろすごくめんどくさい

2017-11-11

スタートアップ界隈の人材が低年齢化してるけど問題ないの?

プログラマとしてIT業界に身を置いているのでスタートアップ界隈から相談や誘いが年に数回ある。

会ってみると創業2年ぐらいまでのスタートアップが多いのだが、そこにいる人達の年齢がどんどん低くなっている。

自分おっさんになっただけかもしれない。考え方が古いのかもしれない。

しかし、高校生インターンとして働かせたり就職経験のない学生に金を渡して起業させるのはほんとに大人がやることなんだろうか?

2つ気になっていることがあるのでぜひ意見を聞かせて欲しい。

1つ目はインターンシップと称した学生低賃金労働

ほとんどのスタートアップ10人以下のチームで、創業者が1〜2名と非フルタイムの手伝いが1〜2名、残りはインターンという構成が多い。

インターン定義上みんな学生になるのだが、やっている内容はシステム開発アポ取りなど通常の業務一般的だ。

というか会社として売上がなくてエンジニアが雇えないかインターンシップと称して無給やコンビニバイトの時給で自社の開発をやらせている。

組織が少人数ということもあって家族的・フレンドリーなチームになっていてプロフェッショナル集団にはほど遠い。

インターンに対してはスタートアップでの経験や成長を提供してファミリーの一員になったようなやりかたで運営されている。これは完全にやりがい搾取だろう。

また、休学してまでインターン活動することを勧めるような経営者言動

『優秀な若者が休学してまで参加してくれます!』なんて話をTwitterでも見かける。

挙げ句の果てには高校生までインターンとして採用する。おそらくインターンを確保するのも簡単ではないのだろう。

そもそも経営者自身高学歴大手企業で働いた実績を作ったのちに起業しているくせに

未来ある学生に対して休学させたり2年後も見えない零細ベンチャーに取り込むのは無責任じゃないのだろうか。

2つ目は個人投資家ベンチャーキャピタル学生囲い込み。

この辺りに関して専門的な知識はないのだが、どうやら多額の資産を築いた元起業家VC若者投資をして起業させている。

エンジェルやシードVCと言えば聞こえはいいが実態微妙投資名目大学生に端金を渡して就職せずに起業を勧める。

起業しても売上はなく活動場所もないのでコワーキングスペースと称した雑居ビル投資先のスタートアップを囲い込む。

そこで会社員経験のない若者が寝食も忘れてプロダクトを作り続ける。そもそも経験知識もないので出てくるアイディアはひどい。

VC提供している支援プログラムメンタリングはまともな計画運営経験もなく、ミーティングでは具体性のないアドバイス抽象的な成功論の共有。

たった数百万の金でオフィスに寝泊まりして3食カップラーメンで働く姿はまるでタコ部屋のよう。

極めつけは両者の奇妙な関係性。起業家投資家のことをパートナーメンター以上の目で見ていてあれはまさしく教祖信者のもの

彼らは平然とスタートアップはグレーな部分を攻めないと成功できないと言ってのける。

投資家自体もっとまともな企業投資してキャピタルゲインを得ているので学生起業家に出す金はほんとに遊びみたいなもの

数年後に残されるのは夢破れて学歴も実績もない20代若者だけ。

これらの問題に対して当事者達が主張するのは

「本人の意識で決めている」「ベンチャーはこれぐらいの気概がないとできない」「常識にとらわれない人が成功する」

というクソみたいな理論

個人的にはこんなことを大手企業がおおっぴらにやっていたら完全に叩かれると感じている。

無知若者につけこんだ搾取ブラック企業業務委託契約での長時間労働ネットワークビジネス洗脳、みたいな悪いところが形を変えて全て詰まってる。

以前はIT関係はひどい業界だと思っていたが近頃は健全化してきている。

いまはその下のスタートアップ界隈がほんとにひどい。

皆さんは間近で見ていてどう感じますか?

2017-10-30

プロトタイピングで時間稼ぎ

ウォーターフォールで進めているなら…

一番最初モックを作る。

リボテのモック(見た目だけ。画面だけ。中身の機能実装してない)を用意して、仕様不明点をつめておく。(以後の仕様変更納期の延長が必要

 

リボテで仕様を詰めておく 

作品を見せる『プロトタイピングモデル

比較的小規模なシステムでは,まずプロトタイプ(試作品)をユーザ提示し,システム機能操作画面・出力される帳票などの確認をしてもらい,ユーザ要求を始めの段階で明確に把握するプロトタイピングモデルが用いられます

プロトタイプ作りから始めますので,手間と費用がかかりますが,ユーザの具体的な意見設計段階で取り入れられるため,修正などの手戻りが少ないという利点があります

 

 

傾向と対策

リボテのモックだけでも用意して、仕事してますアピール。(小出しにして、仕様確認と称して時間を稼ぐ)

実装はいろいろ問題があって、進捗が遅れていると報告。(相手素人なら専門用語を連発して煙に巻く)

なるべく早めにリスケ納期延長)を依頼する。

2017-10-29

Good Loser(潔い敗者)のススメ

損切りタイミング

しろ時間がかかるネタなんかでやってる僕が愚かなだけだ。

俺も1回目の起業は失敗した。

 

(1)受託開発から(2)自社開発への移行ができなかった。(自転車操業で終わり)

どこで区切りをつけるかは、あらかじめデッドラインを決めておいて、一線を越えたら潔く撤退しても良い。

(俺の場合自分だけでなく他人を巻き込んで迷惑をかける段階をデッドラインにしてる)

 

前いた会社で、退社して起業したけど失敗して、出戻りの人がいた。

俺もその人のことを思い出して、失敗後は社畜生活に戻った。

 

縁起でもない話だが、もしも失敗してしまった場合でも「ただでは転ばない」という気概を持って欲しい。

自分体験たことをよく観察して、失敗の原因をよく理解したら、それは無形の財産になる。(負け惜しみかもしれないけど)

自分直接体験は、他人から教えてもらった間接伝聞よりは、比べ物にならないほど、たくさんの情報が詰まっているからね。

 

ブラック損得勘定おかしい?

前項で述べたように様々なマネジメントスキルなしで、いや、マネジメントがなくても、なんとか物を完成させようとしてブラックになったんだよなとも。

でも、前にも述べたとおり、日本人は人のアドバイスを聞かないし、指摘もできないから、

日本人って、ある意味クソ真面目なところがあるよね?

日本近代史を学ぶと「なんで無謀な戦争をやったんだろ?」とか疑問に思うけど、当時の日本人は「玉砕美学」だったんだろうなと思う。自己犠牲を厭わないことは立派だけど、今の世代から見ると当時の人は損得勘定おかしいと感じる。

翻って今の日本人はどうか?実はあまり変わってない可能性もあるね?(過労死自殺するまで働くって、意味が分からない。)

 

生きている限り、「捲土重来」で1回目はダメでも撤退して力を貯めて、再び勝負することはできる。

もしも、大幅な軌道修正必要になって、いったん体勢を立て直す必要が生じたら、そのときは失敗を認めても良いと思う。

 

失敗のとらえ方

俺の考えでは、(研究開発を一生続ける限り、)

失敗とは「終着点」ではなく「通過点」であり、プロトタイプ(試作品)の一つにすぎない

ということ。

 

 

インタビューで彼が強調したのは、「失敗から学ぶ」という姿勢

人生には、自分自身の「失敗」だけでなく、予期せぬ不幸や様々な「挫折」がある。

人間は「挫折」した時に、<その後、どう生きるか>で真価が問われる。

 

投資家ジョージ・ソロスは、Fallibility(ファリビリティー、人間判断誤謬性)を主張した。

失敗はゼロにできないが、失敗をいかに早く軌道修正できるかでその後の結果は全く違うものとなる。

大切なのは、素早い判断軌道修正であり、新規事業プロジェクト管理ではOODAが有効方法になる。

 

オペレーションズ・リサーチ効率的意思決定

システム開発をするときリスクマネジメントを学んでいると思う。

いろいろな準備が必要だが、最悪の事態を避けるための「保険」をかけておきたい。

 

物事の展開は、

  1. 最善:今より良くなるパターン
  2. 最悪:今より悪くなるパターン
  3. 現状維持:今と同じパターン

の3パターン以上を想定して、各々の場合対応できる準備をしておかなければならない。特に悪化したとき対策重要だろう。

自分がやっている仕事に応じて、しっかりと安全策、保険を用意しておき、ダメときはなるべく損害を最少にして退避できるようにしておこう。

 

負けを認めることは、恥ずかしいことじゃない。

賢い人ならただの敗者ではなく、「Good Loser」になれる。(また後で挽回のチャンスを作ればいいだけの話)

  • ダメで元々
  • できれば儲けもの
  • 失敗してもクヨクヨしない

割り切っていこう!

2017-10-20

anond:20171020123500

なんと昭和時代公共システム開発においてには「それを予想してはいけなかった」んだよなあ

懐かしいわ

2017-10-18

不可能を除外して残った物が信じられなくても

選挙というのはシステム開発と似ている。

必要最低限度の機能を満たすものを作ることも出来るし、使い心地のよさも実現したリッチもの可能予算とか時間かにあわせて色々なレベルで作れるけど、ともかく最低限の要件を満たしていないとおカネはもらえない。

いまの日本には、必要最低限度をぎりぎり満たすかどうかということで自民党選択肢としては辛うじて有効で、それ以外の野党と言われる人たちは、そのラインを満たすことが出来ない。だから、仕方ないか自民党投票することになる。積極的支持ではなくて、消去法で残ったのが自民党。それくらい日本の政治状況はお粗末で貧弱だと思う。

たぶん自民党もその辺がわかっていて、偉そうなことを言っているんだろうけど。

自民党がどんなにひどい政党だとしても、それ以外の政党が全くもってダメで、期待も希望も持てそうにないというところが、ほんと、もう、この国だめだろうな、と。

議会制なんてやめて、AIサポートするネットを使った直接民主制にすればいいのだ。それか昔ながらの貴族制とか君主制とか。問題意識も関心もない人民は、平民として安穏として幸せに暮らせばいい。

政見とか政策とかが必要なのではなくて、その前段階として一般人問題意識や関心、そういうものが全く不足しているのだ。だから議会制民主主義なんて形だけのもので、実質を伴っていないし、そもそもそんなの、日本では無理なんだよ。千年以上も君主制とか貴族制とかだったんだから。無理無理。

たとえ民主制でなくても、元禄時代のように一般人レベルでは十分に楽しく暮らすことが(たぶん)出来ていたわけで、つまり日本人には民主制なんて向かないのだ。

いっそのこと、一定所得以上とか一定学歴(最終偏差値?)以上の人にしか政治を触らせないようにして、人民には武力による革命権を常に保証するような仕組みにしておくといい。個々人では物騒だから町内会ごとに武器庫を持つことができるとか。エリート政治が気に入らなければ、いつでも革命・焼き討ちが出来るという具合にしておけば、政権者たちも緊張してコトにあたるようになるんじゃないかな。

ああ、そうすると軍事政権のようなものが一番安定するのかな。

どっちに行っても物騒か。

2017-10-14

http://gendai.ismedia.jp/articles/-/52889

スルガ銀行システム開発にかける覚悟が表れたのが、日本IBMとの訴訟です。同行は基幹システムの開発を日本IBMに依頼しますが、契約通りに開発できなかったとして'08年に損害賠償を求めて提訴しました。

これまで日本企業の多くはシステム会社に対して要求された額を唯々諾々と支払ってきましたが、スルガ銀行はその悪習にも風穴を開けたんです。

判決は、日本IBMスルガ銀行に約42億円を支払えというものでした。これで他のシステム会社も、スルガ銀行には開発費をふっかけられないと思い知ったことでしょう。その結果、システム開発費は他行より安くなっているはずです」(前出・加谷氏)

スルガ銀行には開発費をふっかけられないと思い知ったことでしょう。その結果、システム開発費は他行より安くなっているはずです」(前出・加谷氏)

いや、むしろ高くなってるだろ。この案件パッケージ使って安価に作りましょうってスタートしたが、そのパッケージではスルガの要望に全部は沿えないってのが判ってきて、仕切り直しが泥沼化して契約解除なのだから、次のベンダーは(見えていない)リスク分を多めに積むようになるでしょ。ふっかけたのがばれたんで、金返せとかじゃ全くないし。(泥沼の中で色々やらかして不信感持たれたとかもあるようだけど)

今回の京都市の例もそうだけど、システム開発には地雷多すぎで当初見積もり金額で一括受託は無理ありすぎるよなぁと。その辺りのリスクユーザベンダが納得する形でうまく扱える契約形態一般的にならないものかと妄想中。米国はいろんな契約形態があるっぽいが良くは見てない。ベンダースキルが~とかユーザーシステムに関する知識が~とかもあるがその辺は置いておく。小さなプロジェクトだとSESアジャイル系ってのが一番良いのだろうけど。なんか良いのないですかね~、正直大手SIer新規ではぶっこきまくってるから欲しいはずなんだけどなぁ。まぁ、下請けに被せてるから良いっすと思ってるかもだが。

2017-10-13

京都市システム開発トラブルに対する雑感

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

https://anond.hatelabo.jp/20171012165214

市町村役場で大規模開発が必要システムと言えば住記・税・福祉系の3つだが、この中でも福祉系がぶっちぎりで地雷

住記:住民票管理住民票はほぼ全国統一フォーマットなのでシステム移行は容易。

税:市町村の税で大きいのは住民税固定資産税軽自動車税。細かい税率は違うが基本の計算式はほぼ全国統一されてるのでこれも移行は容易。

福祉系:一言福祉系というが、その範囲は多岐にわたる。

国民健康保険住民への給付保険料徴収等。

国民年金運営日本年金機構が行っているが、申請受理審査の窓口業務市町村

高齢者福祉系:介護保険後期高齢者医療介護予防等。

障害者福祉系:障害者手帳交付自立支援医療給付・通所サービス・その他医療費助成(重心)等。

児童福祉系:児童手当・児童扶養手当・保育(保育園幼稚園)・妊婦健診・その他医療費助成(小児慢性や養育医療)等。

生活保護生活保護認定給付

保健所系:健康診断難病対策医療費助成)・予防接種等。

これらの業務それぞれが国・県から権限移譲されたもの市町村独自のものが混在している。

市町村ごとに千差万別と言っても過言ではない。また、普通市町村中核市政令指定都市でも、どこまで権限があるかは異なる。

これらの業務を全て1つのメインフレーム運用しておりそれを新しいものに入れ替えるだけ、

であれば話は簡単なのだがもちろんそんなわけはない。

これらの業務根拠法令が成立して制度が始まった時期がバラバラなため、そのたびに入札を行って新たにシステムを構築する羽目になる。

そのため、役所内にメインフレームと、異なるベンダー・異なる言語パッケージが乱立する状態になる。

京都市は今回そんな状態を解消すべくシステムの一括更新を試みたがプロジェクト炎上した、と推測する。

パッケージ業務を合わせろという指摘、業務役所の内部だけで完結するシステムなら簡単

人事給与財務や決裁のシステムであればどこの役所業務を適宜修正してる。

問題仕様変更住民に影響を及ぼす業務印刷物を送って申請をしてもらわなければならない類のもの)。

毎年送られてくる役所から文書が変わると混乱してしま住民の方はものすごく多い。

もちろん事前に今年からこのように変更になります、とお知らせはするんだが読まない方は読まないので。

京都市レベル大都市役所から書類が全部いっせいに変更なんてことになったら、

問い合わせと苦情で窓口電話口は間違いなくパンクする。

なので、対外的住民に出す文書様式は従来のものから変更はなしで、という仕様になりがち。

京都市の件でもオンライン処理は無事稼動したが帳票印刷のためのバッチ処理の移行で躓いたとあったので、

おそらくそのへんの印刷物仕様で揉めたのではなかろうか。

はてなユーザシステム開発系が多くて身贔屓バイアスがあるから

https://anond.hatelabo.jp/20171012165214

「Q9.じゃあベンダーは悪くないのか?」

ココらへんをもっと掘り下げるべきじゃないのかね

っつかトップブコメの「業務システムに合わせろ」って思いっきポジショントークじゃね?

っつかつか、そもそもシステム開発側の能力が低いっていうか無能な人が多いかシステム開発案件って荒れるんじゃないの?

はてなユーザは我が身可愛さにこのベンダー側に立った意見ばっかりなんだよね

からまるで発注側の京都市無能権化みたいな意見大勢になってるけどさ

それは絶対違うと思うんだよねー

この手のトラブル一方的に他方だけが悪いなんて話あるわけないんだからさー


っつかさ、そういうニュートラル見方ができない人が多いからこそ、この手のトラブルがいつまで経ってもなくならないんじゃないの?

2017-10-12

ソシャゲ業界の仕組みが分からない。

ソシャゲ業界の仕組みが分からない。

どんなキャッシュフローになっているのか全く分からない。

詳しい人教えてください。

先日、今更ながらソシャゲにハマった。

今までパズドラとかツムツムには全く興味が無かったが、たまたま見たソシャゲ広告に興味をそそられて

無料だしダウンロードしてみようかなと思い、始めたら面白くてハマってしまった。

わずかだがお小遣い程度の金額課金もした。

ゲームプレイのためのスタミナ回復時間を待つためにももう一つのソシャゲも始めた。

2つのソシャゲを交互に遊びながら、みんなが夢中になってるソシャゲって確かに楽しいな!

と思い始めた矢先に「サービス終了」のお知らせがあった。

その翌週にはもう1つのソシャゲ終了のお知らせ

メインでやってたゲーム来年1月まで、サブで遊んでいたゲームは今年11月まで。

どちらもゲームサービス開始から1年もたたずにサービス終了だった。

「金返せ!」ってほど課金した訳でもないし、金額分は楽しめたと思うのでそれは良いのだがサービスの終了は残念だった。

どちらのゲームもこんなに面白いのになんで終了するんだ??と素人ながらに疑問に思った。

儲かってなかったようには見えなかった。(根拠は全くない。)

終了する理由はどちらも、お客様に楽しんで頂ける品質を維持できないうんぬんである

結局本当の理由はなんなのだろうか?儲かっていなかったのか??

知り合いのIT系人間が言うには運営費バカ高いそうである

運営費とは、宣伝広告費サーバー代、人件費、開発費だと思う。

その中でもサーバー代が特に高いらしい。知り合いは得意げにそう語る。

月額数千万円だとか。本当なんだろうか?都市伝説的に、伝言ゲーム的に、金額がどんどんでかくなってるんではないか素人は思ってしまう。

サーバー運営が高価なのは分かっているつもりだ。

ただ50万人がダウンロードしたゲーム同時プレイは多くても1万程度と予測するが、

それでもサーバー代はそこまで高価なのだろうか?

どんな会社にどんなプランいくら発注しているのだろうか?

知らない世界でもあるので純粋に知りたい。

そしてソシャゲが終了した会社倒産するのか?(そのゲーム1本しか運営してない会社

全然そんな気配はない。社長を調べてみたら終了発表後もfacebook普通にレストラン料理写真をあげてる。

いいね!で繋がっている人も違うゲーム会社社長さんのようで2016年初頭に同じように半年程度でソシャゲを終了していた。

その会社は今はVRゲームを開発中だそうだが、いつどんなタイトルリリースするのか、どこにもまったく情報はない。

それまで収入源がないまま港区の高級オフィスでやっていけるのだろうか?と余計なお世話だが気になってしまう。

そんな会社ちょっとググっただけで数社は出てきた。

そういった自社サービスを謳うが自社サービスが終了しているソシャゲ会社

wantedlyあたりで探せばいくらでも出てきそう。

そもそも自社のサービスである数年の歳月と数億の開発費をかけたソシャゲ、なんでそんなに簡単に終了できるのか?と不思議に思う。

ソシャゲの開発には平均2億円程度の費用がかかるそうだ。(知人情報で真偽は分からないが、相場だろうと思う。)

もしかしてソシャゲリリースしたらすぐに元が取れて十分に儲かっているのか?だから早々に撤退してしまうのだろうか?

何年も前から宣伝費をかけて事前予約で人を集めておいて、1年持たずに終了することこそ計画通り

リリースと同時にいきなり投資分の回収モード全開なんだろうか?

それともソシャゲ会社経営者投資金額が消えても大丈夫なくらい鉄のメンタルなだけなのだろうか?

中小システム開発会社社畜である自分にはどんな仕組みでどんなキャッシュフローになっているのか全く分からない。

詳しい人教えてください。

2017-10-10

id:catpowerブログが読んでて悲しい

英語プログラミングを覚えたほうが、広い世界に飛び立てる

http://catpower.hatenablog.com/entry/2017/10/09/190000

はてブ人気エントリーに上がっていたので、読んだらびっくりした。あまりの中身のなさに。

内容はこれから時代英語プログラミングが出来なきゃまともな職にありつけないよ、というものだが、前にどこかで聞いたことのあるような内容ばかりで、目新しいものは何もない。読んで得られるものも何もない。にもかかわらず人気エントリーに上がるのは互助会パワーのおかげである

この人のブログ記事は前も読んだことがあるのだけれど、実績も実例データもないのに根拠のない煽りdisを繰り返して終わってたので、今回も大したこと書いてないんだろうなと思ったら案の定大したことは書いてなかった。

このブログ主はどうやらフリーランスプログラマーを数十年続けてて、現在沖縄在住らしい。数十年もプログラマーやってたら、もっと泥臭くて面白いエピソードが書けるはずなのに、今日日大学生でも書ける内容のものを60近くのおっさんドヤ顔で語ってるのを考えると極めて切ないものを感じた。

実例も実績もデータもなく大学生でも書ける無内容なもの互助会パワーで人気エントリーに上がってくるのは明らかなノイズだ。

60年近く生きててひねり出せる成果物大学生レベルなのを見て、積み重ねの大切さを図らずも知ることとなった。

雑な結論しか書いてなくて、結論説得力を持たせる泥臭くて面白い具体的なエピソードも実績もなければ、具体的なアドバイスもないので、えっ?これで終わり?中身薄くない?ってなるのだ。毎回。

プログラマー業界若い。60近くのプログラマーもそんなに多くない中で、職業プログラマー歴ウン十年のキャリアに裏打ちされたアドバイスというものはそれだけで十分貴重だ。

人脈の大切さを説いているなら当然良い人間、悪い人間絶対回避しなければならない人間のことも書けるし、ひたすらフリーランサーとしてプログラミングをしてきた自分と、同じようにSIerとして会社の中で順当に出世してきてきた人との人生の違い、もしくはプログラマーであることを諦めて別の業界で働いている人間のことも書ける。Webアプリケーション開発が嫌いなら、自分が如何にしてWebアプリケーション開発を業務にするのをやめたかを具体的な事例をまじえて書けるはずだ。人生経験が長ければ、会社歯車として生き続けるのが嫌で脱サラするも夢破れてホームレス同然の生活をしている人も見てきたかもしれない。

生きていれば絶対に遭遇するであろう人間の業システム開発の楽しさや辛さが、このブログからは微塵も伝わらないのだ。

そういった具体例を一切出さず(出せず)に、雑な煽りを繰り返しているので、この人は一体何がしたいんだろう、60年近く生きてて得られるものはこんなものなのだろうか、と悲しくなってくる。

自分職業プログラマーとして数年やっているが、60過ぎたときにこんなブログは書かないようにしようと心に誓った。

2017-10-06

システム開発簡単なら、誰も苦労なんてしませんね。

簡単だと言うならあなたがやってみればいいんじゃないですか?

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