はてなキーワード: ドキュメントとは
https://zenn.dev/sta/articles/2024-08-10-sat-what_is_si
少し前にブクマの集まっていたこの記事について、SIerでなぜITが軽視されるのか、SIerがしぶとく生き残っているのが何故なのかをもう少し深堀りしてみたくなった。なお俺自身は、もうずっと長いことSIerの中で働いている、現役のSIerの中の人である。
これから書くのはSIerの中でもBtoBの業務システムの中身の構築を主に手掛けていて、なおかつ元請けに近い組織の話だと思ってほしい。
まずSIerでITが軽視されがちな理由である。受託開発を主に手掛けるSIerの顧客は、だいたい以下のような特性を持つ。
このような顧客が日本社会にはまだまだいくらでも存在しており、その市場に特化した業態がSIerだ。このような市場は、いずれ消えると言われながら今でもしぶとく残っている。
こうした顧客の元では、新しい技術にチャレンジしてもあまりメリットがなく、枯れた技術や使い尽くされたフレームワークを使って、すでにどこかで見たようなシステムを生産するのが最適となる。古い技術は長期的には先細っていく運命にあるが、一方で経験者が多く失敗事例が出尽くしている、過去の資産を利用できるなどの利点があり、顧客側も冒険よりはリスク回避を望むため、古くて安定した技術を採用するメリットが大きい。
それを請け負うSIerで重宝されるのは、ITの知識よりも顧客業務を理解してロジックに落とし込むスキル、いわば業務をプログラム可能な形に翻訳するスキルだ。
顧客が自分で説明する業務のルールはだいたい矛盾していたり、条件が不足していたり、例外ケースが考慮できていなかったりするので、それらを整理してプログラム可能な形に変換する必要がある。特に金融などの業務がガチガチに法規制されている分野は業務ロジックを法律や制度に適合させる必要があり、そういう時に業務ロジックを「業務の専門家の立場で」検討できる人材がSIer側にいると顧客は安心して設計を任せられる。だからSIerでは上流工程が重視され、それができる人間が重宝される。
余談だが、俺自身は経理系システムを専門として長い間この業界で働いているが、俺がここに残っているのはIT技術も好きだけど経理の勉強をするのもそれと同じぐらい好きだったことが大きい。いざとなったら経理知識だけでも食いつなぐことができるぐらいには、そっち方面の知識もある。IT技術への興味は趣味で発散させており、仕事でそれを生かせる機会はなくてもいいと割り切っている。そういうタイプが、この業界には向いている。
閑話休題。
SIerでは上流工程が重視される一方、実装のフェーズでは使い尽くされたフレームワークを使って作るので最新技術への理解は必要なく、実装上の創意工夫が必要なほど難しいものや新規性の高いものを作るわけでもないため、設計書に書かれたことをそのまま実装できる人であれば十分、ということになる。そのため、実装要員は単価の安い人を大量に集めればいいという発想になり、かくして派遣ビジネスの隆盛へとつながっていく。
実装フェーズは業界全体で単価が安いため、元請けの比較的高給取りな社員に実装を任せてしまうと、それだけで利益率が悪化する構造があり、ハイスペックな社員はなるべく単価の高い上流工程にアサインしないと勿体ないという話になる。
実装のフェーズを丸ごと外注することも多い。フェーズ単位で外注する方式はウォーターフォールと相性がよく、発注のためにはきちんとした設計書を外注先に渡す必要があり、かくしてSEはドキュメントをひたすら書き続ける。
SIerは「ITを専門とする組織」ではなく「業務をプログラム可能な形に翻訳する専門組織」であり、翻訳した後の作業を自社の社員はあまりやっていないので、そもそもIT企業と言えるかは本来微妙な立ち位置なのだ。実際には翻訳の成果物である設計書でさえグダグダなことは多いのだが。
とはいえ、パフォーマンスチューニングなどで技術面の創意工夫はしばしば必要になるのだが、それが実装の工夫だけでどうにかなるものであれば、大体は現場のエース級の人(自社社員とは限らない)がなんとかしてしまい、経営者を含む大部分の人にはその必要性があまり深く認識されず、エースの人がどうやって解決したかも理解されない、というのが実情ではある。技術のスペシャリストはSIerでは立場が弱く、裏で活躍していてもそれが日の目を見ることはあまりない。
こうした姿勢のためにSIerはたまに来る技術の変化の波に弱く、大波が来た時はしばしば多くの人が新技術に適応できずにドロップアウトしたりする。日進月歩のITの世界で、お前は本当にIT企業かという感じではあるが、そもそもITの専門組織とはいえない組織なので期待するのは無駄である。
ではSIerがしぶとく生き残っているのは何故なのか。
SIerとは「業務をプログラム可能な形に翻訳する専門組織」だと言ったが、もっと大きなことを言うと、総じて日本のSIerというのは、日本社会を現状維持させるために存在する業種なのだろうという気がする。(日本に限定したのは、海外の状況はまったく知らないからだ。)
顧客もIT化の波に対応しないといけないが、かといって現状の業務を変えたくないし、ITのことを学びたくもない。SIer自身も新しい技術を積極的に取り入れない。その両者が結託して、古い技術で社会を現状維持させている。その良し悪しはともかく、多くの人がそれを望み、その望みがSIerという業種を存在させている。まるで邪教徒たちの祈りが邪神を生き永らえさせているみたいな話である。
古い技術を革新しないと社会が変わっていかないとしたら、SIerは変化に対する抵抗勢力であり、SIerの古い技術者が変化の波でドロップアウトするのは、社会にとって必要な新陳代謝といえる。
だからもし、技術で社会を変えようと望むなら、SIerは来るべき業種じゃない。技術の先駆者たちが社会を変えようとして切り拓き舗装した道を歩きながら、すでに出来上がった仕組みを維持するために働いているのがSIerだ。技術で社会を変えようと望む人は、是非他で活躍して、技術変化の波を起こし、俺をドロップアウトさせてみてほしい。
アニメ韓流恋愛リアリティに競輪格闘技公営ギャンブルというおじさんの趣味に深夜バラエティのなりそこないみたいな番組というニッチを寄せ集めてるラインナップ
これでなんとか食いつないでるんだろうなとは感じるが、アニメチャンネルだけでいくつあるんだよ。。。感は否めない
オリジナルコンテンツのニュースはニュースでひろゆきがインテリ枠扱いされるレベルだしという
地上波もつまらんつまらん言われてるけど、それなりに多様性があって選択肢もあり、深夜や日曜の昼には低予算なりに攻めた番組やったり採算度外視のドキュメントつくってるからAbemaTVの現状よりはかなりマシ。
まぁ考えてみたら「地上波より規制がゆるい」としても、客は地上波のドラマやアニメで育ってきた世代な訳で、今更平成初期や昭和の規制が緩かった時代のノリやり直すだけじゃ勝てるわけねぇんだよな
規制がゆるいネット配信だからこそできる新しい作品、を作れなかった結果がこれなんだろうなぁ。とかそんなことを久しぶりにダウンロードして思った
JTC SIerの研究職と長年お付き合いしてきたけど、彼らはそもそも研究なんて高度なことをしてる人はごく少数で、ほとんどの人は要件定義フェーズの派遣業をしてる感じだね。
研究所も自分でお金を稼ぐというプレッシャーのせいか、事業部門が募集する「研究(依頼研)」という名の開発をする作業員をやっている。
その中で適当に新規性を見つけて(無理やりひねり出して)特許書いて研究所としてのノルマ達成。
ちなみに研究職の人月単価は通常SEの数倍に上るため基本は上流工程しかさせられない。また研究職のためかドキュメントはあまりかけないし、
プロダクトコードレベルの品質を作ることはもちろん、プロジェクトマネジメント等もできない。
となると一体何をやっているかというと、PJ初期段階の技術調査という名のAWSのドキュメントを読んでまとめる作業をしてたりする。
おぬし、大変な状況じゃのう…まぁ、わらわも少しはおぬしの苦労がわかる気がするが、少しは休むのも大切じゃぞ♡。
システムが古くなるのは避けられぬ運命じゃが、何もしないでストレスばかり溜めても寿命が縮むだけじゃ。おぬし、一人で頑張っているのは素晴らしいが、そろそろ他の人を巻き込むことを考えても良いのじゃないか?
ほんに、後任がいないのなら早めに伝えておくべきじゃ。人員増強を頼むとか、外部のコンサルタントを頼むことも考えた方が良いのじゃないかの?
それに、システムのドキュメントをもっと整備することも一案じゃ。
設計書やインターフェース仕様書だけじゃなく、他の部分もできるだけ詳細に記録しておけば、後任がいない場合でも役立つのじゃ。
結局のところ、おぬしが健康を保ちながら長くシステムを維持するためには、自分一人で全部抱え込むのをやめることが重要じゃ。何とかして前向きに話を進めるのじゃ。そうすれば、少しは楽になるかもしれんぞ♡
ま、おぬしもわらわの言葉を聞いて、少しでも気が楽になれば良いのじゃよ。頑張れ、じゃの。
パリ五輪の開会式のドキュメントをNHKBSでやってましたが、コンセプトをちゃんと決めて動くという、まあ当たり前の感じ。
コンセプトが、とにかく政治家3人(4人か?)の要望を取り入れるということだった東京都比較する方が無理でしょう。
もともと東京五輪は政治家の欲望と投資が目的だったので、イベント会社にお金が渡ってそういう会社が潤えばミッションコンプリート。
パリ五輪でアルジェリアの選手団が昔アルジェリア独立を求めたデモで殺された人の追悼にバラをセーヌ川に投げ入れたというのはすごい話で、まあそういうことを許容する場づくりだったというのはなかなかなのでは。
「ChatGPTのようなモデルは、主に大規模なデータセットから学習されていますが、個別のファイルを読み込ませる機能も持っています。例えば、ユーザーが特定のドキュメントや情報を提供すれば、それを元に回答することができます。ネットに情報がない分野でも、提供された情報や知識をもとに助言や回答を提供できます。
Google翻訳やDeepLは、一般的にはユーザーの入力内容を学習に利用する場合がありますが、そのポリシーやプライバシー設定は各サービスによります。企業によっては、機密情報の翻訳にはこれらのサービスを使用しないこともありますが、他の情報にはそれほど気を使わない場合もあります。利用目的や情報の機密性に応じて使い分けることが一般的です。」
画面上でできなくしてもサーバーに直接リクエスト送ってくるからって同じことをサーバーでも実装しないといけなくてすごくめんどくさい
言語同じかつ単純な規則な共通化できたりするけど実際はそうじゃないものが多いし
画面での操作禁止とそれらを無視して編集後のデータだけ送ってくるのだとチェックの仕方も違う
追加できないなら追加ボタン出さないだけで済むが、サーバー側だと送られてきた件数だけじゃなくてもともとあったものと一致してるかもチェックが必要とかそういうの
ウェブのほうが楽だからデスクトップアプリからウェブに移すがここ数年は多かったが本当に楽か?って思う
画面の柔軟性はあるが、そのせいであれこれ細かい注文がついたりしてそれも面倒が増える原因だし
ウェブだとそれが当たり前だからってサーバー側もデータのチェックしてるけどデスクトップアプリじゃそんなことしてなかった
それのリプレースなんだし、別にしなくていいんじゃないかと思う
デスクトップアプリだってサーバーと通信してるんだから直接リクエスト投げれるわけだし
ウェブなら便利な開発者ツールがあるから今送ったものの中身を見てちょっとか書き換えて送るが楽なだけ
デスクトップアプリだってパケットキャプチャしたり、逆コンパイルしてソースコード見ればできるわけだし
クライアント証明書があるから~とかいう意見聞いたことあるけど、ローカルにあるファイルなんだから、直リクエストするときだってそれ使えるよね
デスクトップアプリだと起動後のホーム画面から順番にボタンを押さないと画面を開けない
だから一覧画面で編集ボタンを出さなければその項目の編集画面は開けない
そのせいで一覧画面で編集ボタンを出さないのに加えて編集画面で自分が編集可能かのチェックまで必要になる
めんどくさい
考えてみればURLで直接開けることは要件にあるわけじゃないんだし、URLにマッピングしないメモリ内でのルーティングでもいい気はする
業務で機械学首(データマイニング)、Web(業務システム)、組み込み(産業インフラ設備)の経験があるので、分野ごとの相違点と発生しがちな軋轢を書いておく。
- | 機械学習 | Web開発 | 組み込み開発 | 発生する軋轢 |
コードの寿命 | 半年間 | 20年間 | 40年間 | 組み込み開発er「産業系の組み込みは発売から40年後にアップデートするケースもあるので、ドキュメントは、開発担当者が全員退職して誰も残っていなくても理解できるように書いてください!」 |
コードのアップデート頻度 | 試行錯誤しつつ随時 | 2週間に1回 | 半年~5年に1回 | Web開発er「組み込みはどうしてそんなに時間がかかるの?アジャイルを導入してください。ウォーターフォールは硬直的でデメリットばかりですよ」 |
アップデートの提供方法 | -(コードは少人数の同僚だけで使用) | サーバに自動デプロイ | 技術者が現地訪問してアップデート | 組み込み開発er「アジャイルだから最初は若干のバグを残して発売し後日アップデートするって?グローバルで既にXXX台受注しているけど、誰が現地に行くの?費用を負担する部署はどこ?」 |
開発者の属性 | 数理系の修士~博士、少数精鋭 | 専門学校~修士、文理混在、大人数 | 電気系、機械系、情報系の修士~博士 | 機械学習er「数式で表現できない知識は民芸品です。エンジニアを名乗っちゃダメでしょ」 |
関係部署 | マーケティング・企画 | 顧客 | ハード開発・工場 | 組み込み開発er「納期3カ月前なのにソフトが完成していないの?生産立ち上げを工場に相談していない!?スケジュールをゴールから逆算できなかったの??今回は船便での輸送になるけど、それも計算に入れてあるよね?」 |
計算資源 | 潤沢 | 予算次第 | 貧弱 | 組み込み開発er「データマイニングやってたKさんがOSSを使うらしいけど、サイズが5MBあるんだぜ。5MB全部必要なのか聞いたら一部機能しか使わないんだって。で、他チームとの容量調整は丸投げされたの。感覚を破壊されるよな。」 |
3rdパーティライブラリ | OSS | OSS | 買ってくる | 組み込み開発er「OSSに不具合があったらどうやって修正して顧客にデリバーするつもりなんだろう?リスク移転の考えで、不具合の補償契約込みで買えばいいのに」 |
通信プロトコル・データフォーマット | 生データが王様なので、生データに従う | 最新のものを取り込む | 実績重視 | Web開発er「HTTPの実装がないの?TCPを直接使う!?暗号化や認証はS社の独自プロトコル?古いプロトコルを使い続けているから開発効率が低いんだよ」 |
電源OFFタイミング | 任意にコントロール可能 | 定期メンテナンス | コントロール不可 | 組み込み開発er「ファームウェアアップデート中に電源OFFしたらどうなるの?ファイル書き込み中の電源OFFは?状態遷移図って知ってる?」 |
性能 | 出来高 | 顧客要件、常識、予算に従う | ミリ秒~マイクロ秒単位のタイムスライスで管理 | Web開発er「性能改善でXX関数の10ミリ秒を1ミリ秒以下に短縮するために2週間も試行錯誤したって?プロパ社員の人件費は7万円/日だから70万円を消費したね?AWSでEC2の性能を調整すれば2000円/月で解決だよ。損益分岐点は350カ月だけど顧客のこれまでのリプレース実績から判断してこのシステムはそこまで長期間使われない」 |
学会発表・特許 | 結構ある | ほぼなし | 年1件の特許出願ノルマ | 組み込み開発er「学会発表も特許出願もなく、何を開発したの?ドメイン知識をソフトウェアに翻訳してAWSでポチポチやっただけなの?開発行為ではなく作業だね」 |
分野ごとに要求される製品特性が異なるから、異分野に移ると文化摩擦が起きるという話だと思う。製品特性の違いを理解し自らの行動に反映できるようになるには、ベテランでも数年かかるケースがある。開発期間10年のテーマを経験したことがあるが、そうした場合だとワンサイクルを経験するのに10年かかるので。経験から学ぶのが愚者、歴史から学ぶのが賢者ともいうが…。
「ん?AってなんでBなんだ?」
こう思った時はまず調べよう。
調べる時にはまとめサイトや個人のブログは避け、なるべく公的なドキュメントを探しましょう。
保安基準を満たす乗り物は公道走行OKで満たさない乗り物はNGなのは昔から変わらず、
キックボードに認可が必要だった時代などなく元から原付として公道走れたんだが、キックボード憎さから陰謀論に走るやつ多すぎだろ。
新しい変なミニスクーターみたいなやつも新しく認可されたわけじゃなくて特定小型原付の保安基準で作られただけだから認可も利権も関係ないだろ馬鹿か。
書くのは良いんよ
こっちもポーズとして作りたいんだろうなって思うから、成果物の精度なんて一般的なもので工数増し増しでいただくし
それに開発の職場は入れ替えが激しいから、開発環境を良くするためにドキュメントを書く事自体は開発上正しいと思ってる
ただ、普段から開発環境を整備をろくにできない(もしくは自己流の属人的なフレームワーク)=場数が足りてない素人かって思ってしまうと、発注先が客だと分かっていても不安が残るんよ…
chatgptに社内のドキュメント管理とかやらせればすごい効率化できると思うのだけどどうだろう。