教育こそが、良きを伸ばし、怠惰を淘汰する手段であるか?

うまく説明できるかわかりませんが、がんばります。

結論

ビジネスは細かく小さくなる。だから組織は小規模化または個人になって、小さなアプリを使って、コスパ良く稼いでいくこと。そのアプリは自前で用意すること。

IT、パソコン、インターネットを中心に書きます。

得意、苦手意識あるかもですが、この記事を目にしている人、なんだかんだたどり着いてしまった人は「IT、パソコン、インターネット、これらの技術の利便性」は認識していると思います。革命的ですよね!私はそう思います。

ひと昔前は「IT革命」とよく聞いたものですが、正直まだまだ「改革」、いや「導入」だと個人的には思っています。

勉強すれば自分で出来る。

これが前提です。ただちょっと難しい。だから高いお金を払って、保守は不十分だけど、委託せざるを得ない…。悲しい展開ですね。もし委託先、外注先の対応にいまは満足していても、相手に刀の柄を持たせているようなものですからね。システム質、データ質とも言えますでしょうか?もし委託先、外注先で情報事故、倒産、災害などがあってもその時はどうにもできませんからね。もちろんコストをかけて再構築はするでしょうけど。

将来的には小規模化、個人化していくと思います。

現時点で革命とはなっていないくても、徐々に変化しているのは目に見えています。いままでと同じ構成人数(社員、作業員)は不要です…まぁ文化として雇用せざるを得ないこともありますが、もう(作業員としての)人は要らないわけですね。ホントはそれぞれが自立できればいいんですけどね。「自立」より「言われたことをやる」教育を受けているので突然放置されても何もできない人がほとんどだと思います。学校教育についてはいつか書くと思います。

ちょっと話しがそれてしまいました。

事業、活動が小さいチーム、または個人になるならそれに紐づくツール、サービス、環境なども縮小していっていいと思います。

何が言いたいかっていうと、「小規模アプリでいいよね!」ってことです。それはクラウドでも、自分で作ってもいいということです。

例えば、1人のエンジニアが「小さな組織に小さな十分使えるアプリ」を作ったとします。普段の流れがそのアプリで完結するとします。データ閲覧、作成、注文、受注、決済、入金などなど。それで十分だと思います。世の中のほとんどの人が生きるためにお金が必要で働いていると思います。またこの小さなアプリ(ツール)で効率化できれば、労働に縛られなくなり、社会に貢献できる時間を作れるってことです。文化的な生活を送る物資の向上とかはインフラ化か寡占化してもいいです。独禁法とかあると思いますけど。ほとんどの生活必需品がコモディティ化しています。

そして、そのエンジニア自身もお金を稼ぐために、クライアントを3つ、5つ、9つと増やしていったとします。その結果、手が回らず、この保守が行き届かない、保守されない状況に対して全員(エンジニアも含めて)「どちらかといえば不満」というトータルでパイが腐ってしまいますね。変なエンジニアもいれば逆に変なクライアントもいますからね。こうやって考えたときに、「教えるって相手のためだし、自分にとっても最強のビジネスでは?」と思いました。こういうのってなんていうんでしたっけ?言葉忘れてしまいました。「相手の言いなりにお金を仕方なしに払ってしまうこと。」?

この「結局システム運用保守がグダグダになる」問題を解消するには?

ざっくりと「教育」だと思ったんですね。特にエンジニアにとってはクライアントを持たず、クレームもなく、システム保守をしなくていいのですっごくラクになります。

システム化、効率化が正しいってわけじゃない!?

これは…よりけりです。
この前、おいしいラーメン屋を見つけて、しょうゆラーメンならもうここ以外食べないってくらいおいしかったんです。(そうなるともっとおいしいしょうゆラーメンに出会えなくなるということになりますが笑、その話は置いといて。)

このラーメン屋にシステム化、このページでいうとPC化?コンピュータ化は要らないです。したとしても注文と決済のみでしょう。おやじがいい雰囲気を出しているのもこの店の魅力の一つです。ある意味おやじによってシステム化されていますから笑。

この記事で言っているシステム化、効率化は特に作業場、オフィス、倉庫など実作業がコモディティ化されたものについてですね。データの打ち込みなんて誰がやっても同じなんですよ。ファイリングだって、電話対応だってなんだってそうです。むしろユーザーとして腹が立つので対応者が人間より、ちゃんと行き届いた対応をするロボット、コンピュータのほうがいいです。

いくつか疑問が浮かびますね。

はい、「すべての機能を自分で作るのか?」ということです。無理です。ここは矛盾ですね。物販ならAmazon、メルカリ、ヤフオク、楽天に出品すれば作業完了です。あとは全部これらの会社がやってくれますね。たとえすべて依存しなくても決済だけはPayPalを利用すればいいですね。広告なら各ASPやAdsenseですか。このように何かに「依存?」しないといけない部分が出てきます。私はそこに関しては矛盾を解消せずに目をつぶることにします。要はサービスを利用するということです。しかし、何も意識せずに完全にちゃらんぽらんに依存するのではなく、自分のしくみの流れと中身を理解するということです。上記出てきた会社やサービスがなくなったとしても再起できるようにですね。あとは勝ち逃げって方法もあります。稼げるうちに稼いで労働からリタイアするっていうっことですね。

JavascriptのNaNは非数という意味です

意味はそのまんまで「数値データじゃないよ」ということです。

例えばこのようなコードがあります。

let str = "abcdefg";
console.log(str -= "cfg");
//NaNと表示されます。

let str = "abcdefg";
console.log(str += "cfg");
//「+=」は文字オブジェクトにも使えます

要は「-=」は数値オブジェクトにしか使えませんよ!という意味だと思います。

JavascriptでHTML要素(DOM要素)のプロパティにアクセスする方法

結論

基本的にはdocument○○に対して「.ドット○○」でアクセスできます。
JavascriptでDOM要素を操作するときに絶対必要になる知識。できれば覚えたいところだが。

引用

Google検索「document プロパティ 一覧
https://phpjavascriptroom.com/?t=js&p=dom_property

DOM取得(HTML要素を取得する)

個人的にいままで書いたコードの7割が以下の2つを使用して取得しています。

  • document.getElementById(“idセレクタ”)
  • document.querySelector(“セレクタ”)

主なプロパティへのアクセス

  • .innerText
  • .innerHTML
  • .value
  • .href
  • .attributes
  • .id
  • .firstChild
  • .lastChild
  • .childNodes

Javascriptで変数を宣言する方法

結論

個人的に今後letconstだけにしときます。

「var」に関してはvarをそのまま使わないといけない場合だけvarを使います。パッと思い浮かぶのはライブラリとかですかね。letかconstに統一したいけど、コードが多い場合はそのまま使用すると思います。

変数にはリテラル、オブジェクト、配列、関数などいろいろ格納できます。「名札付け」のイメージでしょうか?昔は「箱」イメージがよく使われていましたが、最近は変数を説明するときには「名前付けイメージ」が使われるようです。何かしらの都合が悪くなったのでしょうかね?

let

再宣言不可。
再代入可能。

私みたいな少ないコード量を書く場合はあまり気にしないかもです。変数名が重複するとエラーが起こります。

const

再宣言不可。
再代入不可。

実質、定数?という情報もちらほら見ますが変数です。

let x = 123
x = "abc"  //これはOK

let y = 123
let y = "abc"  //これはエラーが出ます

/*
SyntaxError: Identifier 'y' has already been declared
*/

ドキュメント管理と部下の管理

結論

リソース(ヒト、モノ、カネ、ジカン、テマ)が無限にあれば管理しなくてもOK。でもほとんどは適切に管理しないと痛い目遭いますよ!ということ。。

・たいていのエンジニアはドキュメントを作らない。
・正確に言えば、その場しのぎ、独りよがりのドキュメントは作るが、多くの人に共通するドキュメントを作らない。
・それなのに「え?わからないの?」っていう。

誰がやっても同じになるように。

目標「誰がやっても同じになること。これを再現性という。」

  • ルール化
  • 言語化
  • 明文化
  • ドキュメント管理
  • ドキュメント作成方法

プロに対しても素人に対しても、ある意味「再現」という言葉がぴったりくるのではないだろうか?

プロ再現

スーパープレーを連発できるのであればプロになれる。これを何かのテレビで「Xシステム」と言っていたが、このXシステムを構築することが重要かもしれない。ひとつの方法にドリル、要は適した反復練習。

素人再現

バイト君が入社研修一日目で、ある程度仕事ができるようになることはとてもいいことだと思う。要は人が欲しいのではなく手と足が欲しいから。ロボットが欲しいわけですから、最終的にはロボットでいいわけです笑。

ロボットを作るときに何が難しいというと精密さである。
例えばゴミ出し。ごみを袋ごと取り出して補充する。ただこれだけの手順だけど100発100中を求めると、再現性が100求められる。そうじゃないとロボットを導入する必要がないからだ。同じように取り出して、同じように袋を開いて、同じようにセットする。再現100とは言ったが、閾値や許容範囲がある。目的は取り出し、すき間が無いように箱に袋をかぶせるということだ。

少し話が逸れてしまったが、結論として(適した)努力しない限り「作業員」として扱われることは必至である。私自身もそうなりつつある。そのくせに業務を効率化しようとして、自分の仕事を消そうとしている笑。でも考えてみたら実績証明としてはめちゃくちゃ強くポータブルなスキルかもしれない。

古い人がいなくなれば…。

いつの日か「リモートでバッチ(処理)でいいじゃん!それ俺がやること?」ていう時代が来る。要は邪魔になっているのは組織の古い文化である。そういうところは他が変わらない限り、変わらない。要は「みんながそうしているから…」というク〇みたいな反応でしかない。

世代交代ってのは、意識的には変わらない。日本人は特にそうだと思う。例えば政府が「デジタル化!」といえば、上司の考えがコロッと変わる。サ〇かよ!って思う笑。でもそれじゃ政府次第なので度外視して考えるべきだ。人は変わらないので、古い人が組織から去るのを待つしかない。この考えに至った後にある本を読んだときに同じことが書いてあったのでびっくりした。同じこと思っている人いるんだなぁって。うろ覚え「固定観念の変化は古い人が死んでいなくなることで勢力が弱まって、次の固定観念がスタンダードになる」みたいな。でもそれって面白くないし、時間の無駄。だから自分でやるしかないです。

この記事のテーマは「ドキュメント」についてです。

独りよがりの文書、誰かが作った関数まみれのエクセル、とにかく放り込んだデータベース設計、ファイル名は自分がわかればいいファイリング、お局さんの既得権益作業フローは世の中から消えてほしい。

誰でも直感的にでき、わかりやすく、効率が良く、PDCAを回して、良いことは即取り入れて、ダメなことは淘汰していけるしくみがあるといい。

ルールは不要です→えっ?いまなんて?

「ルールを作らない」って明言されると間接的に「会社はこのままで大きくもしないし、新しい事もしないで、同じことを永遠にやり続けます」と言われている気持ちになる。要は属人化。効率化やシステムの向上を図らないそんな会社でできることは毎日同じことをずっとやることだよね?中小の強みを全く生かせないっていう…。

あるとき業務フローについて上司に聞いてみた。

「ルールはあるけど、明文化されたものはない。」
「?じゃあルールはどこにあるんですか?」
「それぞれ持っているでしょ!」
「(え?バ〇?それルールじゃねぇじゃん、こいつの下で働くのか?)はぁ…。改めてですが、明文化はしますか?」
「しなくていいじゃん!」
終了。

できることとドキュメント化出来ることは違う。

状況が限定されるかもだが、例えばネットワーク構築、ルーターや機器の設定を例にしよう。
簡単だよ、何か新しいことをする、構築するにあたって、調べながら、掘って、掘って、掘ってたどり着いたとするよね?ここでは設定やネットワーク配線、社内のインターネットの状態が完成したってこと。調べているとき、構築中は一時的にスキルが上がるんですね。これってみんな当たり前なんです。自由研究とかゼミの発表とプレゼンとかもそう。こういうときって記録せずに進むんですよ。

一言でいうと「それドキュメント残ってる?」と聞けばいい。
正確には「全部ぶっ壊して再構築が簡単に出来るドキュメントは作った?」ということです。たいていの人は作りません。作ったとしても専門用語、コピペ、結局何を言っているかわからないドキュメントを提出されます。

じゃどうすれば?

「出来そうなことからレベルを一段下げた構築をすること。
前述のネットワーク構築の例では、「あれもこれもしよう。あっそうだ、これもやったほうがいい。こんなものもあるのか?このサイトに載っていることをやろう!」とか全部詰め込むとオワル。別にいいんだけどね。あなたが勝手にやったことですからね!ということです。

要はある意味無責任なんですね。もちろん労働者はやめれば関係なくなるので、その人が辞めた後「あいつが自分よがりで、会社のカネでいじりたくていじって、構築していったネットワーク。ドキュメントも残っていなくて、あいつしかわからない」そんなこと言っても構築者(世間的に無責任な人間)にとってはもう全く関係ないんですね。それは誰が悪いかというと…上司なんですね。(「悪い」という言い方はそれぞれなんか言い方変えてくれてもいいです。)結局、管理できてないんですね。「独りよがりのエクセル」と同じです。管理不足です。

だからじゃあどうすればいいの?

これらを多少なりとも回避するには一言こういっておけばよかったんです。「最後わかりやすいドキュメントちょうだいね!」って。こうすればそれほどバ〇でなければ、私みたいなその他大勢の日本人であれば真面目なのでドキュメント作成してくれます。「わかりやすく」ってところがポイントで、構築者もドキュメント作成(正直かなり面倒)のタスクを処理したいので、書きやすいネットワークの構築をするようになります。ネットワークの知識はもちろん難しいところもありますが、シンプルな設計は本来はとてもスマートでセキュリティ的にも強いです。中小企業のネットワーク構築なら入門本で何とかなります。大企業は専門部隊を持っているので丸投げできますけどね。要は「管理」と「把握」が出来ているかです。

めちゃくちゃ調べて凝りに凝った設定をすると、「次も同じようにできる?一度やってるから次は早くできるよね?」って言われてもドキュメントなんて作ってないか、一か月後自分で読んでも理解できないドキュメントなんで、再構築はそうは簡単にはいかないわけです。もちろん前述通りに辞めてしまえば本人には関係ないことです。悪いのはスキルのない上司、グループ長とかその立場の人たちなんですね。正直、長くいるから立場が上がっていくシステムというのは、それを許している会社と最終的には社長の管理不足ということです。年齢からくるろ〇害ではなく、長くいることから生じるろ〇害なんですね。

じゃあどうすればいいか?

「自分に力をつけましょう!自分だったらこうする!」をとことん深く細かく網羅してみましょう。そのワークは必ずあなたの力になります。

今回のネットワークの例なら、構築としてはとても簡単だったとします。しかし、構築担当者が機器の機能をあれもこれも利用したいとして、なんかいろいろ調べて数か月かけてやっと構築、設定したとしますね。

次に力の入れるべきところはドキュメント作成です。要は説明できるか?言葉にできるか?どうかが問題です。

後先考えた構築か、新しい高い機器を会社のカネで買っていじり回したいかの違いです。組織が大きくて社内インフラ部隊がいて一斉退職しなければ上記のようなドキュメントは無くてもいいです。しかし、社内のネットワークが属人化している場合、上司はかなり注意しないといけません。すぐに言いましょうね。「それ、わかりやすいドキュメントちゃんと作ってね?または作っていると思うけど、あとでちゃんと提出してね!」って。

もちろんこの記事では上司が部下を管理することは強制しません。したほうが楽ですよ!ってスタンスです。あなたの会社のことなんて正直どうなってもいいですから笑!でもこの記事を書くってことは、少しでもあなたの手間を省いて、集中するべき仕事に集中してほしいという勝手な願いがあります。

「最悪な事態はほとんど起きない、起きても一時的だから気にしない。対応するのは私じゃなくて部下だから!」それもありだと思います。そういう考えは見抜かれれば、部下は辞めますけど。あなたは部下を責めれません。部下はあなたと同じ労働者ですから辞めたらそこまでです笑。

担当者がいなくなっても、ネットワークというのはいまは機器が優秀なので、しばらく放置しても動くでしょう。しかも年単位で。無保守で動いても別に経験上驚きません。停電とかで設定飛んだらアウトですけど笑。

それではそのように設定、構築、機器が故障、崩れたときにどうすればいいか?答えは「時間とカネと手間をかければ何とでもなります。」ということです。世の中そうですよね。自分でできないなら外注するか、専門家を雇うしかないですね。

普段は見えないかもだけど人間社会も競争です。結局、何かが他より強い人が全部持っていきます。先の管理不足の社長もグループ長も、生まれつきプレゼンや自己アピールに長けていたかもしれません。または頭がハッピーなので何も気付かずに長く続けられていたのかもしれない。それは運か実力かはどうっちでもいいです。彼らは意識的にも無意識でもそれ(才能?)を以ってしていまそこにいるということです。

「時間とカネと手間をかければ何とでもなります。」その通りです。条件としては資源の無尽蔵ですね。中小企業が見積とって「何千万です」って言われてもカネがあれば丸投げして、壊れたネットワークの再構築を依頼すればいいと思います。でも、そうじゃないなら管理しといたほうがいいと思いますよってことです。

ドキュメントはバックアップと同じです。
「やっときゃよかった…」まさにその通りですね。この一言で十を知ってください笑。

最後に。

やることは簡単です。

「あなたが理解できる文書」を部下に提出させてください。文書は部下の分身です。
部下にはいろんなことが起こるでしょう。病気、退職、事故事件、災害など不幸なことではありますが、会社は活動を継続していかないといけません。

いまは便利な世の中ですので、クラウドに投げるって方法もあります。会社にはネットにつながる機器と最低限の設定。あとはクラウド上であれこれやってもらうとかです。フットワークは軽くなります。多少値段は上がりますが、どっちを取るかです。