  |
はてなキーワード: フルスクラッチとは
本当に動いてるかどうか分からないから綺麗に書いてほしいんだよね
テストをパスするなら汚くても動いていればいい、っていう理屈は分からなく無いけど
大抵の場合は要件がはっきりしていないのでそこから定義しないとダメで
それをせずに思いつきでコードを書くと、処理が必要以上に複雑になってクソコードになる
要件を整理してきっちりテストを作って境界値あたりをテストすると絶対にバグがある
とか言うと
って言ってその場合だけを直すから他のところもバグったりしてて必要以上に時間がかかる
たいていの場合は誰かがフルスクラッチで作り直すことになるんだよね
そういうの分からないで
「汚くても動いていればいいじゃないですか」
とか言う奴マジで腹立つ
[B! togetter] 2ちゃんねるの開設当初の裏話をひろゆきが発言
この件もそうだが、あめぞう掲示板の話題になると事実を確認せずにテキトーなことを言い始める人が出てくるのはどうしてなんだろうか。
『教科書には載らないニッポンのインターネットの歴史教科書』で有名なばるぼら氏の掲示板考察～あめぞう型掲示板（ウェブアーカイブ）によると
という一連の流れがあり、あめぞう氏も「Terra氏はパイオニアとして師として仰いでおります」と語っている。
よって「あめぞうが発明したスレッドフロート型掲示板をひろゆきがパクった」という定説はそもそも前提が間違っている。
あめぞう氏はスレッドフロート型掲示板を発明していないし、掲示板CGIをフルスクラッチで書く技量があったわけでもない。
あめぞう掲示板はあくまでresbbsやMiniBBSといった既存の掲示板CGIにTerra氏のスレッドフロート機能を移植していただけで、何か技術的に優れたことをやっていたわけではないのだ。
主にDXとかノーコード(ローコード)周りについてコンサル目線で書いておく
表でこんなことを書こうものなら会社クビになる可能性あるのでここに書いておく
（なんでこんな世の中になっちまったんだよｗ）
DXって別にIT化するだけの意味じゃないんだけど、それすらできてないからIT化って意味で以下注意点かいておく
というより、DXやりたいって言ってる人のほとんどがDXができる状態じゃない
床が見えないほど散らかってる部屋でルンバが使えないように、前提となる条件をクリアできてない
それがもう絶望的にできてない
体感としては8割以上できてない
多分自分たちのやってる仕事が良くわからないし、行き詰ってるからDXという魔法の言葉に救いを求めてるんじゃないかな
まず自分たちがやってる仕事に対して、「どんな仕事をしていますか？」「その仕事をやる理由は何ですか？」という質問に答えられるようにする
人が増えて、長くやってる会社は目的がわからないルール、意味のない仕事が増えていく
これを整理できないと何も前に進められないです
収入印紙を貼る理由なんて良くわからない人がばかりなのにルールだからと貼っている
程度問題ではあるけれども、なんでこの仕事やる必要あるんだ？この会議に出る意味はなんだ？
先にそっちなんとかしてください
次に問題になるのは誰がやるかってこと
「IT部門の若手にやってもらう!」とか気軽に言う人が多いんだけど
これできる人って
ウルトラスーパー超絶優秀な人です
いやマジで
1000人にひとり見つかれば良い方
この業界に20年以上いるけどこれちゃんと出来る人、今まで一人しか会ったことない(その人はさっさと起業してしまいました)
ある程度大きな会社だと一人じゃできないから、仕様策定、運用、試験だったりを分割して誰かに任せる必要があるんだけど
責任感を持ってやってくれて、業務をよく理解している人を選定して説得する必要があります
これすごい難しいです
対人スキルが全方位カンストしてるような人じゃないと務まらないです
IT界隈だとプログラミング能力に秀でた人が優秀な人とイメージされやすいですが、この手の仕事ができる人も同じくらい評価されても良いと思うんすけどね
間接部門だからと出世コースに乗れない閑職扱いになってませんか？
もしそういう認識ならはっきり言って無理です
現場で活躍できなくてもITで活躍出来る可能性もゼロではないかと思いますが、
現場でNG出された方は要領だったり対人スキルに難がある場合が多く、その人がITツールを導入しても混乱を生んで余計な費用がかかるだけです
業務整理が出来て、IT化に着手する場合（まあ実際は役員のメンツとかそういう理由で、業務把握もままならないまま突き進むんでしょうけど）
「やらなくても良い作業を止める」、「SaaSで出来ないか検討する」、「ノーコード開発で頑張る」の順で検討してください
当たり前ですが、やらなくても良い仕事を止めるのが開発もなく、運用費もかからない即効性があって一番良いです
無駄な会議や書類、これらを探して削るところから始めてください
どこもやってる勤怠管理や会計処理等は既存のサービスで充足するはずです
SaaSで実現できなくて、ノーコードで開発する必要がある場合(ほとんどないと思いますが)
ノーコード開発をやってみるとわかるんですが、結構細かいところは出来ない場合が多く100%カバーするようなシステムを作る場合は
すげー大変になることがあります
結局の所ノーコードとは言っても形を変えたプログラミングなので複雑にすればバグも多く発生します
テストしにくい分コードを書くよりも悪くなるケースもあると思います
なので70～80%くらいカバーできれば良い
エッジケースだったり発生頻度の低いオペレーションはバッサリ切る
そんな感じでシンプルになるように努めてください
ノーコードの想定するユースケースを無理やり捻じ曲げてプラグインだらけの独自システムは地獄です
(そうは言っても、こだわりが強いのか、冷蔵庫をエアコンとしても使えるようにしたいみたいな人が多いんだよなぁ・・・・)
ここまで言うと、ノーコードって微妙なの？流行らない？って思うかもしれないですけどノーコードは流行ります
プログラミング言語もセキュリティも覚えることが多すぎて、みんなノリでやってます
セキュリティ対策なんて意味わからんチェックシートを大して理解してない人がYES/NOつけてるだけで実装はボロボロ
たくさんのライブラリは毎日のようにアップデートされ、膨大な工数をかけてアップデートしてます
誰も触れなくなります
というわけでフルスクラッチ開発で内製化とか現実的じゃなさすぎます(金が有り余ってるならやってもいいですが)
ノーコードでも属人化して、ブラックボックス化するのは一緒ですが
セキュリティアップデートとか、セキュリティ対策は幾分楽になるので、まだマシです
ちなみに今SIerにシステム開発頼むのは悪手なので止めときましょう
プログラマーの腕に激しく依存していて、プロダクトの品質が同じ会社でも全然違うみたいな状況はいずれ改善されていくと思います
カンナとノコギリを使って家建てる大工が少なくなって、プレカットの建材を運んで組み立てる家ばかりになったように
(つーか実際もう、ID管理とかメール送信は外部サービス使うのが主流になってきていて、どんどんコード書かない方向にシフトしてる気はしてる)
前述の内容と少し被りますけど、半分くらい作ったらさっさとユーザーに使ってもらったほうが良いです
負荷テストとか、UIとか拘るのは良いんですけど、方針レベルで間違ってた場合は全部やりなおしになるので、
早い段階で使ってもらうようにしてください
多少バグがあっても良いので早めにイメージを擦り合わせたほうが結果的に早く終わります
バグってるものをユーザーに使わせたら怒られるとかいう人いるんですけど、
使う人と作る人が気兼ねなく話せるような関係じゃないと開発はうまく行かないので撤退しましょう
席を隣にして談笑できるくらいには仲良くしてください
いきなりbubble, outsystemsみたいなガチなやつから入らないほうが良いです
kintoneとかairtableみたいなやつから使ってみるのをオススメします
あと選ぶ際に、営業にいろいろ聞く前にまず自分で使ってみること
最初から営業に聞いちゃうと、「頑張ればできます」みたいな回答しか返ってこない
実際に使ってからセミナー行くとか、営業と話して聞いてみるの方が良いと思います
システム作ったあとに、効果があったのかきちんと検証してください
大学受験して合格発表を確認しないようなことあるのか？と思われるかもしれないですが、
ということなのか単にめんどくさいのか分からないですが、ちゃんとやりましょう
いい加減な検証もやめてください
コンコルド効果で捨てられなくなって負の存在として生き続けます
そうならないように作る前から、効果検証の方法と撤退ラインを決めておくと良いと思います
保守なんて誰もできないです
10年もすれば、担当者も業務も変わってドキュメントは不整合だらけ
20年に一度作り直す式年遷宮は技術継承の意味合いが強いと聞いたことがありますが、それと同じでシステムを10年以内に作り直す気持ちでいた方が良いです
最低限のドキュメント更新とかアップデートは必要ですが、維持に多大な工数がかかるとか、修正に時間がかかるようになったら作り直してください
色々書きましたけど、業務把握が一番大変でそれができれば割となんとかなります
自分たちの仕事を管理できないから、システムを作って解決しようとするからおかしいんです
それって業務整理とシステム開発という2つの大仕事を並行してやることになるので、そりゃ混乱もします
あと業務整理を自分たちで出来ないからコンサルにお願いしてやってもらうっていう事言う人いますけど止めたほうが良いです
コンサルからしてみれば他人事ですし、あなたの会社について世界で一番詳しいのはその会社に属している人です
その人たちがお手上げだと、外部の人間だって十中八九うまくできないです
仕様さえ明確に作ることが出来るなら、ツールの違いやら、プラットフォームの違いなんかは些細なことなんですよ
まあそれはそれで、大変ですけど仕様さえ決まってるなら何とかなります
というわけで各位頑張っていただければ
