  |
はてなキーワード: 式年遷宮とは
COBOLで組まれた某大手保険会社の保険料金計算プログラムは、プログラムや影響範囲を把握しているスーパープログラマが担当しており、保険料金の改定があった場合には、計算方式の問題がないかのチェックをすべて担っている。とか。
某通信会社の光ケーブル運営担当が、日本とアメリカを結ぶ通信回線のネットワーク設定の全体像を把握しており、ケーブル切替時には、すべての回線を二重配線する物理的な準備をともとに戻すためのケーブル配線の切り戻し準備もしたうえで、切替作業をしている。とか。どちらの人物も転職市場に出ることはほとんど無いだろう。後者の人は転職しようとしたときに、別の通信会社のインフラ担当の人と、同じだよねと意気投合出来てよかったと話していた。
個別の技術については、当人より詳しい人はもちろんいるだろう。それでも「その」現場で「その人」以上に、詳しくて対応可能な人は世の中には存在しない。そんなすぐに代替不可能な人材がどの企業にもいる。
例えば、原発対応話題になった吉田所長もそういった人物の一人なのだろう。原発の事故がなければ、優秀な技術者から所長になった一人の東電社員として現役生活を終えていたことだろう。（もしかしたら再任用で、現場の指導をしたりなどしていたかも。）
それぞれの現場はの基礎は名のしれた技術で成り立っている。プログラムはCOBOLで誰かが読み解くことは可能だし、ネットワークは、設定資料を確認すれば、把握することはできる。
そういう人材をどうやって育てることができるのか？
こういう立場になれる人が、幸運なのか、不運なのかはわからない。当人は楽しくてやってることが多いし、ある一定以上の給与などはあまり求める印象はない。
こういう人はどんな分野にもいることだろう。
どれだけ世の中が便利になっても、便利さを支えるコアには、必ずこういう屋台骨になるような人がいて、回っているということを忘れないようにしたい。基本的に表舞台にほとんど出てくることはないからね。
一方で、属人性を持つ業務の技術継承は、常に課題になってくる。大手製造業だと、式年遷宮方式で20年に一度の技術体系全刷新を行うようにして、技術継承をしていると聞いた。50代の定年前の技術職と30代中堅社員でやるらしい。2025年のDX問題の問題設定は、技術継承の観点として、有用な課題設定だったとは思われる。ただし、担当する社員がいなかったのか、継承先の技術者がいなかったのか。
お金払えば解決って問題でもないし、技術継承さえできれば解決でもない。転職市場からたまたま人材ゲット出来たから大丈夫だったもあるだろう。
某ブックマークで、そんな属人性が高くて大丈夫か？というコメントがあったので、反論してみた。「何事もなく継続していること」それだけでもとても大きな価値なのだということに気付いてもらいたいと思って、投稿する。
同意なんだけど、現状ある意味、式年遷宮しなさすぎて宮大工がいなくなった状態、あるいは VistaがくそだからってWindows 2000 を使い続けている状態。
政権担当能力、地盤が長年の一党独裁で自力が違いすぎるので自分に都合のよい既得権易者は自公を選ぶのだろうね。
良いか悪いかはおいておいて維新がそれなり勢力になったのはある意味奇跡だと思う。それも自民が余りにひどかったという自爆からだけど。
日本で政権交代が起こるのは大体末期になってからだけど、末期に交代してもまともになるのには時間がかかりすぎる。
あのね、わざわざ式年遷宮って言葉を比喩に使うならそこに式年遷宮ならではの共通要素がないとだめなの
「同じものをあらかじめ別の場所に建てることでダウンタイムなしに移転できる」みたいにね
店舗を休んでのただの改修や建て替えの比喩に式年遷宮を使うのはほんと意味が分からないの
https://togetter.com/li/2381777
そう考えるとスーパーの定期的店舗改装って式年遷宮なんかなって思った。
地場のスーパー、定期的に、10年に一度ぐらい1ヶ月ぐらい閉めちゃって店舗改装するんだけど、その間従業員は研修会に出席したり、他の店舗を渡り歩いて色々な職場の知識を仕入れたりして過ごすらしいんだよな。パートも含めて。
あとコンビニもそうじゃん。契約期間がだいたい10年～20年になってて、契約期間が終了すると、そのまま契約更新して店舗運営する場合でも、本部とオーナーでカネ出し合って大改装するよね。
この時も一ヶ月ぐらいかけるんだけど、その間オーナーは休んだり、研修に出たりするらしいじゃん。
主に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つの大仕事を並行してやることになるので、そりゃ混乱もします
あと業務整理を自分たちで出来ないからコンサルにお願いしてやってもらうっていう事言う人いますけど止めたほうが良いです
コンサルからしてみれば他人事ですし、あなたの会社について世界で一番詳しいのはその会社に属している人です
その人たちがお手上げだと、外部の人間だって十中八九うまくできないです
仕様さえ明確に作ることが出来るなら、ツールの違いやら、プラットフォームの違いなんかは些細なことなんですよ
まあそれはそれで、大変ですけど仕様さえ決まってるなら何とかなります
というわけで各位頑張っていただければ
式年遷宮、コストは500億だけど経済効果2400億以上なんだよね。
もちろん儲け出すためだけで遷宮やってるわけではないけれども、
文化を継承し、育てていくことが価値になっているわかりやすい例だ。
芸術振興はもっとわかりにくくて必ずしも直接的に経済効果を生んでる訳ではないけれども、
ロボット工学の偉い先生の講演を聴いてきた。あの311から、原発事故の現場に関わってきた先生の話だ。
先生の発表はとても熱かった。みんな資源エネ庁の公募に応じてくれと、国内の学者、技術者、国公立の機関、民間企業、あらゆる所から英知と技術を集めて、あのぶっ壊れた原子炉を何とかしようとしていた。なんか発表中ずっと、BGMに逆シャアのメインテーマが聞こえる気がしたよ。私はもう平常の研究開発、普段の企業の業務に戻った気でいたけど、その先生はまだ非常時モードで、まだまだ戦っていたんだ。
先生曰く、あのぶっ壊れた原子炉の中身、溶けてしまった燃料棒を全てきちんと片付けてしまうには、30年から40年かかるという計画がすでにたっている、のだそうだ。
建屋の最上階に人類が到達できるまで数年。もう一度格納容器を水で満たすまで10年。それからすこしずつ核燃料を取り出し、しかるべき所に処理を始め、終わるまで30年はかかるんだと。
先生はロボットが撮影した様々な動画を見せてくれた。水のシャワーが滝のように流れ落ちる中をあっぷあっぷしながら進むかのような、原子炉の中をファイバースコープで撮影したノイズだらけの動画もあった。多分その動画はないけど、東京電力はサイトでも結構、動画を公開しているのだとか。
原子炉で事故が起こった時に、最初に入ったロボットはルンバの会社の軍用ロボットPackBotだった。あれに、なんでロボット大国の日本なのに日本のロボットじゃないのか不思議に思った人、結構いたんじゃないだろうか。そのあと原子炉建屋に入った日本のロボットはQuinceという。千葉工業大学の先生が作ったプロトタイプだ。恐るべき走破性の高さで建屋の最上階まで行けたが、1号機は帰り道で自分でケーブル切っちゃって帰れなくなった。
重要なのは、PackBotは量産機で米軍がいっぱい持ってて普段からいつでも使えるように用意してあるのに比べ、Quinceは先生と学生さんが手作りで作った一点物であるということだ。これは想像だが、一点物のこのスーパーロボット、使おうとしたら先生の研究が遅れちゃったり学生さんがうっかりすると留年しちゃったりモーター焼けたら代わりのモーター買うのに先生がやたら書類書かなきゃいけなかったり下手すると論文に間に合わせるために学生が居酒屋で稼いだ私財を投入しちゃったりするようなものなんじゃないだろうか。私の理解では、大学の研究室のロボットというのは大体そんな感じの物だ。でも、ルンバはいつでも買えるようになっているよね。リアルロボットであるというのはそういうことだ。PackBotもお金出したら米軍はいつでも売ってもらえるんだ。
2001年には、原子炉やその周辺で動けるロボットというのは、プロトタイプではあったが、相当数あったらしい。バケツでウランかき回した奴がいたせいで開発予算が付いたんだね。でも、ついたのは開発予算だけ。2011年には、動く状態で残っていた当時のロボットというのはなかったんだと。10年というのは、そういう歳月なのだ。
原子炉建屋の外で遠隔操作の建機ががれき除去を始めた時、何で中のロボットはないのに外のロボットはあるんだよ、と思った人はいないかな？あれな、雲仙普賢岳の火砕流から街を守る建設をする時に開発が盛んになったものが、今でも技術が受け継がれていつでもお金出せば買える状態になってるんだって。屋内の作業ロボットは滅びたのに、なんで遠隔施工建機は生き残っていたんだと思う？
これはな、国交省の役人が意図的に生き延びさせたんだそうな。私が思うに多分、まるで伊勢神宮の式年遷宮のように、工事費の多少の無駄は承知で、「この工事は無人でやらないと入札できません」ってやったんだと思う。そのおかげで、今、建屋の外はかなり片付いている。原子炉敷地内の線量マップもスライドに出てきたけど、ほとんどが2ミリシーベルト毎時以下まで下がってた。高いけど、即死はもうできないレベル。
日本の技術ってのは、プロトタイプを作るところまではアメリカにそんなに顕著に劣ったりしないんだと。ただ、無駄かもしれないものを軍が買い支えて育てるシステムがあるアメリカと違い、日本はプロトタイプが良くてもすぐ死滅しちゃう。商用に持ち込まないと、生き残っていけないから、なんとか技術を維持するために無理してでも需要を創出していかないといけない。ロボット工学の偉い先生は、そう語っていた。
これさあ、原子力技術にも言えるんじゃないかと、私は思う。原発事故の本当の終わりまで40年かかるのであれば、今まだ生まれていない子供が育ってたずさわらないと、終わらない。じゃあ、それまで原子力業界にちゃんと人が流れ込むようにきっちりと産業として生きていないと、こわれたあの原子炉は片付かないんだ。
まあこの辺でわかってもらえると思うけど、私は今の夏までに原子炉を動かすだの動かさないだの、そういうのは馬鹿馬鹿しくなっちゃった。とっとと動かして、その間に万が一への安全策増設を淡々と設計して、次の点検の時に追加すれば良いじゃない。即座の脱原発なんて無理よ無理。だっていちばん危ないのが片付くのが40年後、そこに40年後までまともな技術を供給し続けないといけないのだから、40年後まで他の原発もある程度動いていないと、技術の継承的に無理がある。40年後片付いたら、完全な脱原発の作業がやっと始められるんじゃないかな。
追記：6月10日正午
技術がおのずからお金を稼いでこないと、その技術を維持継承発展するのには意外なほど膨大なコストがかかるよ。
いわゆる伝統芸能、伝統工芸で残ったもの残っていないもの、投入されている公的な予算を考えると良いよ。
日本の場合軍需にお金がちょっぴりしか出ないから、それ以外の公共や民間がよろこんでお金を出すような需要を創出しないと技術は簡単には残っていかないよ。
