  |
はてなキーワード: SIerとは
こんな簡単なプログラムのメンテナンスに時間かかるなんてボッタクリ
それSIerさんにもいってあげて
間違えるとお客様の情報にすこし近づく部分。ただし直接はまだわからない。簡単だろう。なんどもなんどもみなおして１日おいて 翌日みなおすおれは。
今朝、某ブックマークサイトにて大手SIerにおけるクソ設計書について少しばかり話題が盛り上がった。
SIerのシステム開発方法や、所謂「炎上案件」というのは具体的にどういうことなのか、できる限り思い出して書いてみたいと思う。
所属したプロジェクトは3件で、1つ前に所属したプロジェクトはコロナ騒動の直前の2020年1月である。
これを読んでいる人の中には、私よりも玄人なSE、もしくはPMがいるかもしれない。
手持ちのサンプルが少ない故に「ちげーよ！」ということもあるかもしれないが、そこは大目に見ていただけると幸いだ。
まず、ITに携わるシステム屋とはいえ、SIerとベンチャーWeb系は規模と客層も違うし、開発手法も違うと思われる。
開発手法というのは、「ウォーターフォール（各工程を最初から着実に終わらせる手法）」、「アジャイル（短い機能追加を繰り返していく手法）」が一般的にも有名だと思う。
開発手法には「ウォーターフォール」のさらに上の「メテオフォール」というのがある。本気の炎上、アジャイルのようにウォーターフォールする開発という意味だ。
（何を言っているのかわからないかもしれないが、私も何を言ってるのかわからない。https://eiki.hatenablog.jp/entry/meteo_fall）
多重下請けに所属しているSEが「メテオフォール」をかけられたら、もう刃傷沙汰にでもならないと逃げられないと思っていい。
炎上案件のSIerの客層は、金融系・公共インフラ系がほとんどだ、7割そうだろう。（※適当）
自社開発系はさておき、受託Web系やパッケージベンダ系の客層は、小規模案件のプロジェクトもある程度あると思う。
金融・公共インフラ系はべらぼうに規模がデカい。馬鹿みたいな工数が掛かる。
【要件定義 ＋設計開発UT＋結合テスト＋システムテスト＋ユーザー受け入れテスト＋システム移行】 ＋追加要件開発（保守運用）。
大雑把に言うと、「ちょっと顧客情報DBを参照してWebに表示させるシステムが欲しい」として受注した場合、約4000万円がお会計となる。
現行システムのリプレイスだとしても、2000～3000万円はかかる。高い（※謎仕様の現行システムだと炎上不可避案件となりさらに膨れ上がる）
当然、数千万円案件となるとプロパーの社員では人手が足らなくなる。
すると登場するのが「派遣社員（SES）」あるいは「下請け」というシステムだ。
会社によって異なるが、だいたい4～9割が「派遣」や「下請け」の割合となっている。
それでも工数不足になってしまったプロジェクトは、そこから鬼出勤をカマす。
納期を過ぎたらさあ大変、開発経費・損害賠償がSIerの自腹になってしまう。
それで最初に書いた「ウォーターフォール」ってのは何なのか？ってことになる。
「ウォーターフォール」＝「各工程（要件定義、設計、テスト）で客の承認を得て合意を握った上で着実にマイルストーンを固めていく」
「何のために固めるのか？」＝「手戻りを起こさないため（白目）、責任を押し付けられないようにするために」
と、ここまで前置きを書いて疲れてしまったので、続く。
駄文失礼。
https://b.hatena.ne.jp/entry/s/qiita.com/ko-flavor/items/e7a60bc897965943e0a0
ソフトウェアに適しているドキュメントは設計書ではなく仕様書だ。
なぜソフトウェアに設計書という場違いな概念を持ち込んでしまったのだろう？
ましてエクセルで書くなんて。
ソフトウェア構造はプログラミング言語以上に表現に適した記法はない。
プログラミング言語以外のソフトウェアの構造を表す記法には例えばUMLなどがある。
しかしUMLは概要を表現する（モデリングする）にはいいかもしれないが、設計をしっかりと表現するには無理がありすぎるのだ。
エクセルを使い、一般的にもなっておらず規格化もされていないオレオレ記法で設計を表現しようとするなんて、さらに無理がありすぎる。
エクセルで設計を書いているという現場では、きっとエクセルでの「設計書作成」という本来すべき設計とは程遠いブルーカラー的仕事にばかり力をいれ、まともな設計もされていないのではないか。
それに設計書作成に注力するあまり、まともな仕様書など書かれていないのであろう。
仕様に基づいて書かれたソースコードが設計を表現する。ソースコードが設計書なのだ。
これがソフトウェアに適したやり方であり、だからこそ仕様がしっかりと実装されているかどうかを読み解けないようなソースコードはクソと言えるのだ。
頼むからセンスのない奴はプログラマにならないでくれ。迷惑だから。
これが最もプログラマになってはいけないタイプ（犯罪行為などの言うまでもないことを除けば）。
たとえば
等。
不要なものを作ることで、プログラムは複雑になり、メンテナンスの手間は増え、バグは発生しやすくなる。
一定レベル以上のプログラマが最も自然だと同意するような実装（「実装しない」という選択肢もふくめて）をパッと思い付けない奴は、センスが足りていない。
将棋で言えば、駒がぶつかったら先ず取る手を考えるといった基本的な手筋が思い浮かばないようなもので、現実的に使い物にならない。
これは、「Code Complete」「The Pragmatic Programmer」等の著名なプログラミングの本に共通する結論である。
これが「The Pragmatic Programmer」にあるDRYの原則である。
要するに、すべての情報が単一のソースから決定されるべきということだ。情報が二重化すると、それらの間で不整合が生じバグの原因になる。また、二重化した情報は、修正の手間が二倍になる。
たとえば、ユーザーのプロフィールを管理するレコードやクラスに「生年月日」と「年齢」を同時に保持する必要はない。年齢は生年月日から計算できるからだ。
世の中には、「xxxFlag」みたいな不要な変数を作ったり、共通のロジックを抽出せずにコピペコードを濫造するダメプログラマーが多すぎる。
もちろん、合理的な理由があって、この原則が適用されない場合もある。
たとえば、多くの言語組み込みの配列や文字列は、その要素と長さを二重に管理している。配列の長さは要素を数え上げることで求まるが、それには要素数に比例した計算時間がかかるためだ。
ただし、こういう場合でも、公開されたメソッドによる操作では、必ず内部の変数は同期されるように作ることが可能である。それをしないのは、怠慢でしかない。
一文字変数とか連番とかは論外だが、「ary」とか「setData()」みたいな何の情報も伝えないような変数名・関数名を付けるやつ。
正直、コードの読みやすさなんて6〜7割くらいは変数名の付け方で決まると思っている。
名著「The Art of Readable Code」も、半分以上が変数名の付け方に関連する内容だ。
なぜ変数名が曖昧になるのかと言えば、怠慢を除けば理由は2つある。
1つは、コードを書いた奴自身が、そのコードの機能を明確に言語化できないということ。
もう1つは、1つの関数で多くのことをやりすぎたりしていて、その変数の役割が曖昧になっているということ。
たとえば、関数の内部で宣言した変数は、多くの言語では関数の外からは参照できない。
スコープは狭い方が良い。これはほとんど全ての状況に適用できるプログラミングの大原則だ。
スコープが広いということは、ソースコードの多くの場所からその情報を参照・変更できることを意味する。
たとえば、クラスのメンバ変数は各々のインスタンス内でしか参照できないが、静的な変数はすべてのインスタンスが共通に持つ。このため、静的な変数を変更すると、すべてのインスタンスに影響を及ぼし、影響範囲の把握やテストが困難になる。
スコープを広げるか狭めるか、2つの選択肢があったとして、広げる方に心が傾く奴は、プログラマをやめた方がいい。
結果的にメンテナンス困難なコードを生むというのも勿論だが、単に書くだけでも、スコープが広い方が書きづらいのだ。つまり、必要もないのにわざわざ変数のスコープを広げようとする奴は頭のおかしい奴しかいないということになる。
複雑なメトリクスなどを持ち出すまでもなく、たとえば1メソッドの行数が何百行もあるとか、1クラスのメンバ変数が何十個もあるとか言うの。
これは論外である。プログラマとしての能力云々以前に、明らかな怠慢であり、社会人としての常識が疑われる。
定期的にメンテナンスされ続けているOSSのソースコードなどを見ると、関数（メソッド）の行数は平均して5〜10行。20行を超えるものは稀である。
長いものであっても、外部で定義した関数を順番に呼び出しているだけであったり、リクエストをハンドリングして各々の処理に振り分けているだけのようなものがほとんどである。
それを超えているコードは、合理的な理由があってそうなっていることよりは、単に悪い設計であることの方が多い。
これらは実はプログラミング云々というより、内容の理解力や国語力の問題なのである。
ある情報を得るために必要十分な情報は何かが分かってないから、余計な変数を作ったり、無駄に変数のスコープを広げたりする。
そして、自分が作るものを正確に理解していないから、適切な名前がつけられないし、適切なモジュール分割ができない。
それがすべての原因。
こういう人がまず身につけるべきは、プログラミングのテクニックではなく、日本語を正しく読む力。
低学歴が「プログラミングなら自分でもできるかも」なんて思っちゃいけないってこと。もちろん、下請けのSIerとかで使い捨てのコード書きとして働くことはできるが、上に書いたような最低限の力がないなら、それ以上を望んではいけない。
ちなみに、上に書いていることと反対のことを思っている人も世の中にはいる。
特に、昔からプログラミングをしてきた自称ベテランに多い。その人は、能力があるというよりも、単に現代の開発に際して必要な知識がないだけなので、真に受けないように。
また、大学でコンピュータサイエンスの基礎を学びたての学生なども、知識をひけらかしたくて上と反対のことを言う傾向がある。その程度のことは、良識のあるプログラマはみんな分かっているのだが。
ほとんどの参加者は、コンピュータサイエンスなどの学位を持っているわけではなく、国内のSIerなどでパソコン弄りをしてるだけのただのオタクです。
彼らの大半は、まともなコードが書けるわけでも、インフラ等の保守ができるわけでもありません。
非エンジニアの連中に到っては、流行りのIT用語を援用したポエムを作ってるだけであり、話を聴く価値はありません。一部の技術のある人たちも、そういう人たちに合わせて話をしています。
よく、「プログラマはつねに最新技術を学ばないといけない」などと言われます。
これはある意味正しいのですが、この主張が指している対象は、新しいツールやフレームワークの単なる「使い方」であって、根本理念ではないのです。
実際のところ、ソフトウェア技術なんてものは、コンピュータの黎明期から大して進歩していません。進歩しているのはほぼ全部ハードウェアの技術です。
例をあげれば、「オブジェクト指向」なんてものはC言語ができた時点で既に確立されており、有能なエンジニアはみんな知っていたのですが、90年代に入りJava等が普及すると同時に量産型のコード書きの間でにわかに流行りだしました。
エンジニアが第一義的に学ぶべきなのは、コンピュータサイエンス全般の基礎であり、それを欠いた人が流行りに飛びつくのは虚しいだけです。
Sier→自社開発会社で合計10年以上エンジニアと呼ばれることをやってきた。だがスキルが追いついていない。10年以上やっているけどレベルとしては5年程度だと思う。わからないことばっかりだし、覚えたこともすぐ忘れる。なんとか目の前のことをこなしてきてそれなりに給料もらって生活できてきたけど、正直これをあと数十年続けられるかと言ったらつらい。
単純に技術に興味が無い。プログラミングも楽しいと思えなくなった。というか初めから興味が無かったんだけどこれしかできることが無かったから進んでここまで来てしまった感じ。同僚達が新しいデバイス買っただとか、最新技術がどうのこうの笑顔で言っているのを見ると、あー俺はやっぱ違うんだなぁと思ってしまう。自宅学習とかも全然してない。やらなきゃやばいと思いながらやる気が起きない。参考書買っても30ページぐらい読んで積む。技術ブログとか見ると他社の若い子のレベルの高さにゲロ吐きそうになる。最近は残業させないように変わってきて、自己研鑽に時間が取れる！みたいになってきて余計つらい。
専門学校行ってプログラミング勉強して資格取って就職したけど、そもそも努力（自習）できない人間が行く分野ではなかったな。ただ、要領の良さや人当たりに悪い印象が無い（あくまでエンジニアの中では）ようなので会社内でお荷物でも無いけどエースでも無く、まぁ平均点出せるから一緒にやってもらえる、ミスはあってもある程度結果出してるし、なんか許してもらえてる。（裏でいろいろ言われてるのかも知れないけど）
けどもう限界かもしれない。技術アップデートしようと頑張れないし、しんどい。設計・実装・テスト、どれもやりたくない、つらいと思いはじめている。今の会社はエンジニアが少数で属人化が激しく後輩もついてないのでマネジメントとか一切やったことない。マネジメントの勉強すらめんどい。この仕事することに自体に興味が無くなっているんだと思う。上司に「これからどうしていきたい？マネジメント？スペシャリスト？なんかやってみたい技術は？サービスは？」とかいろいろ言われるけど、正直どれも興味無い。でもこれでしか自分は金稼ぐ手段が無いし、迷惑かけられないしやるしかないからやってる。今の会社だから回ってるんであって他じゃダメだったろうな。
「今後こういう人間になりたい」なんてそもそも持ってない。やりたいことが無い。やれることもそんな無い。欲もそんな無い。元々だらしない人間が騙し騙し来ちゃったなぁ。どうしよっかなぁホント。。。。
個人事業主＝業務委託契約による派遣もちゃんとしてれば美味しい仕事なんだけどね。
ちょうど私はそういう立場で働いているけど、大手SIerから所属会社へ90万+税が払われ、所属会社から私へは80万+税が払われる関係性だ。
所属会社に取られてる10万は保険料だと思っている。この10万のおかげで、つまらん発注作業や聞くに値しないクレームなんかは所属会社が対応してくれてるし。
その代わり現場寄りの作業は設計/製造/テストなんでも出来ないとダメだけど、そこさえ抑えておけば、ちょー楽チン。
今も在宅ワークになって作業が想定より早く終わると、ここでこんな文章を書く余裕があるしな。
個人的には実力のない人が派遣やっちゃダメだと思う。雑用みたいな作業しか振ってあげれないし、その作業をやったところで実力が伸びるわけではないんだよな。
一時的な生活の糧としてやるのは分かるが、そこに未来はないから安住しちゃダメ。そこに気付かない振りをした結果、派遣切りで騒いでいるように見えるから、そういう人達は想像力がないのかな？って感じてる。
いいニュース専門ニュースサイト。はてブの解毒剤にもってこい。
GOOD NEWS NETWORKは、はてブでは2008年に初ブクマが付いて以来、サイト全体で20ブクマも集めていないからそんなに知名度があるわけではないのか。
日本語でググってみると
https://tanonews.com/ (サイト合計40ブクマ弱)
http://bright-news.jp/ (11ブクマ、リンク集なのでトップページのみ)
あたりが上位に表示された。無いわけではないんだな。
39歳男、既婚子供二人、妻は専業主婦、関東郊外在住。自分も妻も関西出身。
小遣い制ではなく、妻が必要な分だけ自分の月々口座に持ってく感じ
家を買ったので金融資産は2300万くらい。現金：投資：定期・学資保険等 = 6:2:2くらいかな
自分の学歴は大したことはない。MARCHレベルの私立大卒理系
新卒SIer年収350万くらいから始まり、数回転職し、600→800→30過ぎで1000→1200→1400と上がってきた感じ
妻自身の服は全然買わない、基本ユニクロ、たまに季節モノを通販で買ってる
基本妻が朝昼晩作って食べる
土日は昼はモスバーガー、マクドナルド、夜はたまにピザとか寿司とか。
5000万程度の3LDKの70平米の普通の新築マンションを購入
2000万頭金で入れて、残りを35年ローンで毎月8万円ほど返済。
超低金利なので急いで返す必要はまったくないんだな、と知った。
コロナ前は、よくショッピングモールにみんなで行ってフードコートで飯食って子供が遊ぶ施設に行って、みたいな感じ
妻は真面目で倹約家なのでほとんど金は使わない、趣味も昔から読書・音楽・料理など金のかからないものが多い。余ったら定期預金って感じ。
とにかくほとんどの行動は子供に合わせているので、派手なことはまったくしてない
車は特に必要性がないので買ってない。あれば合ったで良さそうだけど、子供が車酔いが激しくタクシーすら大嫌いなので、休日に家族でお出かけとかは、どうだろって感じ・・・。最近TESLAに興味が出てきたけどマンションだとパワーチャージャーも置けないし、諦めてる。
まだ小学校低学年と幼稚園なので、大した金はかからない。小学校は近所の公立。
最近習い事を始めて月２・３万くらいだけど、これからどんどん高くなってくるんだろうな〜
金のなかった頃は、あれもこれもほしい、って感じだったけど、今はびっくりするほど物欲がなくなったｗ
大した学歴もない自分としてはよくやったほうかなと思う。ソフトウェアエンジニアという職業が自分に合ってた、ってのが大きい。
