読者です 読者をやめる 読者になる 読者になる

Murga

個人的に言いたいコト・主張・気持ち。

マインドは伝わらない。アクションは伝わる。

考え方 所感 効率化 ストレス

「マインドは伝わらない。アクションは伝わる。」

山田和史さんの「ズバ抜ける技術」という本の中の言葉みたい。著者も書籍も存じ上げなくて申し訳ないけど。

現場のココがイケてない、みんなこういう考え方をもってやれば上手くいくのに、みたいなことを思って、周りにこれは問題ですよとかこうしましょうよとかアピールするんだけど、一向に聞き入れてもらえない。

大きな要因の一つは、あなたの伝え方が良くないのかもしれない。独り善がりで、相手に分かってもらおう、分からせようとする話し方の工夫ができていないのかもしれない。「キミの言うことは分かるけどキミがなんかムカつくから聞き入れてやらない」と、相手も意固地になっているかもしれない。そうなったら終わりだ。あなたの願いは一生通じない。

じゃあ伝え方が親切丁寧ならいいのか、というと、そうでもなかったりする。つまり、相手はそれを解決すべき問題とは思っていない場合。

そもそも問題とする対象の事象が、「あなた個人の問題」に近いのだ。例えその効果や損失を数字で示したりしても、少なくとも他の人の立場からは「そこまでして変える必要があるとは思えない」と思われている。

相手の無知によるものかもしれないし、組織全体が腐敗しているのかもしれない。が、理由はどうあれ、彼らはどんなにそれが優れていようと、現状を変える気はないのだ。

で、ココまではあなたの思い、願い、気持ちといった「マインド」しか他人と共有できていない。そして相手からしてみれば「んな大したことじゃねえのにガミガミうるせえな」くらいにしか思われていない。

ココでもう少し、周りを変えられる望みがあるとしたら、「あなた1人で行動を起こす」ことだ。派閥を作ろうとしたり、政治的に裏から働きかけたりするのは逆効果だ。

変えるべきと思うことがあるなら、あなた1人でそれを実践し続ける。途中で反論されても、議論は無駄だ。議論して効果があるならマインドを伝えた時点でみんな分かってくれているはずだ。そうではなくて、「そうなのかもしれませんね、でも今に見ててください」とだけ返し、マインドは語らず、アクションだけを続けるのだ。

「ゴミを捨てるな」という看板がいくらあっても、「そうだな、ゴミは捨ててはいけないな!」とそこまで強く思うことはあまりないだろう。「まぁ、捨てないのが当然なのは分かってるけどさ…」ぐらいのテンションで。

でも、清掃員が朝から黙々とゴミを拾ってる姿を見ると、「うわ、こういう人たちに負担をかけちゃいけないし、綺麗な方がいいよな」と、より強く思うのではないだろうか。これはマインドではなくアクションが伝わったから、効果があったのだと思う。

要するに、マインドから入ってしまうと、相手のマインド、心というパーソナルスペースに踏み込むことになるから、反発を受けやすい。そうではなくて、自分には影響のない距離があって、誰かが何かをやってる姿を見る方が、冷静にそれを観察・判断できるし、自分もやってみようかな、なんて気分になったりする。「布教」は上手くいかないものなのだ。

個人でアクションし続けて、それでも伝わりそうにない時は、自分個人では変えられない大きなしがらみが、その環境に存在する可能性が高い。そんなときは周りの人達を変えることを諦めて、自分が居る場所を変えよう。そこは変えられない環境だ。

ただ、居場所がなくなるような場合は、あなたの自論に問題があるということだろう。

学習コストの見積もり方とスキル不足への危機感

エンジニア必須スキル 日本の SE 効率化 ストレス
  • 数百あるファイルの先頭に今日日付を付与する一括リネーム処理
  • 毎月決まったファイルをインプットに作る資料
  • エクセルファイルの印刷範囲を統一する設定

みたいな作業を、バッチスクリプトもマクロも書かずに手作業して、案の定「途中で間違いに気付いた」とか「このファイルだけやり忘れてた」とか言ってる連中ばっかりな SIer にいる。

パソコンが最も得意なのは同じ作業の繰り返しだし、プログラマやエンジニアが持つべき美徳は「同じことを繰り返したくない」という怠惰だ。

それなのに、手作業で何時間もかけて低品質なことをやり続けている。

これが、まだ新卒で入ったばかりのプログラミング未経験者なら、「バッチとかマクロとか勉強しなね」で済むけど、上司がこういうこと平気でやってて、部下への作業時間見積も手作業でやる前提で出してくるからタチが悪い。俺がスクリプト書いて5分で終わらせてやると、それを一つひとつ目視確認して何時間もかけてたりして泣ける。

自動化しない人たちの心理

上に書いたような作業はいずれも、Windows バッチスクリプトなり VBA なりで1・2行、ループ処理の記述のために改行しても10行満たないようなレベルの簡単な処理だ。それなのに手作業を続ける連中は何を考えているのか。

彼らの言い分はこうだ。

  • VBA 書いたことなくて分かんないから、勉強に時間かかりそうだし…」
  • 「バッチスクリプトに間違いがあったら困るから…」
  • 「一気に色々自動で動くと何が起こったのか分からないから…」

この人たち本当にプログラマシステムエンジニアなんだろうか?

やったことなくてもやらんかい

何か一つでもそれなりに言語経験があって、パソコンがどう動いているのか、プログラミングとはどういうことかという認識があれば、どんな言語だろうと、やろうとしていることが「書けない」なんてことはないのだ。

現にコイツらは、開発言語問わず、「詳細設計書」なる、日本語で全ての処理を手続き的に書く、無用なドキュメントを作っているではないか。ということは、「要するに何がやりたいのか」は日本語なり擬似コードなりで書けるはずだ
(いや、もしかしたらこれは、「実は日本語でも自分たちが作りたいものを書けてなんかいなかった」で終わる話なのかもしれないけど。)

擬似コードが書けたなら、あとは対象の言語でどういう API (メソッド) を使えばそれが実現できるか、そこだけググればいい。何も言語仕様全てを押さえてからでないと1行もコードが書けないわけではないのだ。

それを、「やったことないからやらない」とはどういうことか。10年以上この仕事してて、やったことないことをそのまま放置する方がよっぽど悪いことだろうが。

ついでにいうと、バッチスクリプトが分からないというこの上司が、開発案件の中で作られたバッチファイルをコードレビューしている。こいつはレビュースキルもないのにレビュアーをやっている。詐欺じゃねえかこれ?

間違いがあっても平気なように準備しときゃいいだろ

次に「スクリプトが間違ってたら困るという話。間違っていたら、誰がどんな風に困るのだろうか?

一括リネーム処理が、間違ってファイルを消してたら困る?それってバックアップ取ってないの?てか動作確認すらせずにスクリプトを実ファイルに適用してんの?

スクリプトを書いたら実ファイルではなく適当なテスト用ファイルを作って試せばいいし、実ファイルをいきなり変えるのが危険ならファイルを別の場所にコピーして、変換したファイルを置き直せば良いだろう。

間違いがあっても大丈夫なようにしておくのはエンジニアが当たり前のように持つべき考え方。間違えても仕組み的に影響がないようにするとか、こうやればやり直せるとか、そういう不測の事態に備えておくのは当然だ。

「作業中にちょこっと書くスクリプト」における、エラーに対する考え方にもズレがあるかもしれない。

中途半端に Java 経験がある人間だと、NullPointerException に極端に怯えたりして、なんでも try / catch して例外を握りつぶす癖が付いていたりするが、例外やエラーというのは、正しくない処理が発生した時点で処理を中断してくれるものだ。だから、時には例外を踏まえた分岐を作ったりせず、「この作業範囲では例外は出ないはず」という状態を前提にコードを作り、それでも例外が出た時は前提条件がおかしいのだ、と区別できるようにしておく、といった考え方ができると良いだろう。

本番リリースするプログラムでないなら、別に間違いがあってもいいし、仮に間違えても平気だと言えるようにしておけばいいのだ。間違えたら最後、取り返しのつかないことになる、なんてモノにしようとする方が悪いのだ。

自分で組んどいて何が起こったか分からないとは

もはや何も言えない。自分が作ったものが作ったとおりに動く。うまくいっているならそれが当然だろう。

もし間違いがあって、結果が想定と異なる時に、どういう異なり方がありうるかも、書いたコードから事前にある程度想像できるだろう。move コマンドしか使ってないのに format が行われることはないだろう、でも違うフォルダに移動される可能性はあるかもな?とか。

やらない理由は並べ終えましたか?ご苦労さん。

技術をもって仕事してて、技術力で金をもらってるはずなのに、スクリプト言語は分からないから書かないとか、パソコンが自動でやることは分からないとか、ましてや「機械がすることは信用ならない」なんて言い方、間違ってもするもんじゃない。それは機械じゃなくてお前が悪い

結局のところ、ただ自分がやりたくなくて、それを学ぶ気もなくて、新しくなにかするよりも今までと同じことを続けた方が楽だと見積もった結果なのだろう。

学習コストの見積もり方がズレている

今この作業を手でやれば1時間だけど、自動化するバッチスクリプトを初めて書こうとすると、言語仕様を押さえてバグを取って、トータル2時間かかりそうだ。だから手作業にしよう。一刻を争う緊急事態ならそれも仕方ないと思う。

でも、そういう緊急の期限がないなら、今日のところは2時間かけてスクリプトを書いてみたらどうだ?結局その仕事、毎週定例作業でやってるんでしょ?だったら今日は2時間かかるかもしれないけど、来週は5分だよ。

先程も書いたが、別に言語仕様全てを知る必要はなくて、「ここではループ処理でリネームだけできればいい」なら、その時は IF 文すら知らなくたっていいのだ。

最近ならやりたいことをどうやればいいのか、正解となるコードもネットに山ほど存在する。もしかしたらコピペするだけでもやりたいことができるかもしれない。本当に手作業よりも言語学習の方が時間がかかるのだろうか?

何が言いたいかというと、新しいことを学ぶのは、思うほど時間がかからないし、大した苦労でもないということだ。それを頑なにやろとしないのは、今より楽で便利な方法があろうとも、今までどおりの不必要で無駄な苦労をしたい特異な人たち、ということになろう。

勿論、やりたいことのレベルが上がれば大変になることもあるだろう。調べるのに1日かかったけど目的のものがまるで実現できない、なんて状態になるなら、その前に時間で区切って諦めて手作業に戻った方がいい。

でも、エンジニアが携わる仕事において、プログラムで解決不可能な問題はほとんどないはずだ。それに、自分がこうしたい、と思う程度の問題なんて、大体既に誰かもっと頭のいい人が考え尽くしてるはずだから、その文献を調べて真似ればいい。そうすれば自分は楽してその便益を享受できるし、それを改善してより効果的なものにもできるはずだ。

第一、自分が無知であることを怖くは思わないか?

「いや、俺そういうの分かんないから、できないんだよねえ。」

エンジニアなら二度とそんなセリフ吐くな。お前はもうエンジニアじゃねえ。

自分に何とかする能力、技術がないと思うなら、勉強しなきゃいけない。それで金もらってんだから。知らないままでいようとするってのは、金をもらう資格がないってことじゃねえか。

スキルがないのによくヘラヘラしてられるな、とぼくは逆に恐ろしくなる。技術のない技術屋なんて、無能じゃん。俺なら恥ずかしくてそんなヘラヘラしてらんない。

もっと気軽に、今の手作業を自動化する方法を調べてみないか?少しは自分のこと考えてみないか?

チーム運用を考え続け、運用ルールを変えていくこと

エンジニア必須スキル 日本の SE ストレス

チームでの運用ルールは一度決めたら FIX するものではない。というか、FIX できるようなものではない。

何も変えないでいようとしても、時間経過が様々な環境要因を変えていくので、ルールが現状にそぐわなくなるのだ。だから、常に同じ状態を保つためには、実は絶えず変化を続けていなくてはならない。

レガシーな現場ほど、形骸化したルールが多いことだろう。そしてそれらは「自動化すれば人力で守る必要なんかないのに」というようなものだったり、「どうやら以前はこれに対応する規則があったから存在するルールだけど、今はもうその規則がないからルールが合っていない」というようなものも多いだろう。

しかし、レガシーな現場をレガシーなまま放置する人たちのマインドは、「とにかく何も変えないこと」が正義とされてしまっている。「変えた方が良いのかもしれないけど、とにかく変えるのは怖いので変えない」という思考回路になっている。

ただ、彼らは大抵、個人の思惑でそうしているのではなく、組織構造が変化を許さないものになっていることが多い。

変更を入れるには上長承認が要るとか、変更を申し出た人間が主導して変更を周知したりしないといけなくなる (共有したり分担したりしようとする人がいない) といったしがらみがあるせいで、「変えるべきだと思うけど、変えようとしたら面倒だから変えない」というところが惰性で習慣化することで、個人的にも変化を嫌う体質になってしまうのだ。

だから、チーム全体で運用ルールを改善したいと本気で思うのであれば、まず組織構造、チーム体制から見直さないとうまくいかない。

チームメンバ全員が、変化に対して柔軟で、かつ効果的に役割分担と協力が得られるような組織体制にしなくてはならない。

「上司の指示がないと何も変更できない」ような仕組み、風潮があると、部下は主体的に動こうとはしない。上司が持つ「しがらみ」は部下全員を硬直させるので、上司がトップダウンで枷を外してやらないといけない。

ボトムアップで提案してほしいからといって、「キミ達も自由な発想で主体性を持って…」なんて言ったところで、そんなもん逆効果になるくらいだ。メンバがボトムアップで主体的に動けるようになるには、トップダウンで自由な範囲を与えてからこそ実現する。

そうしてメンバからルール変更の提案があったとき、「これまではそうやってきたから変えたくない」といった理由を返すような上司がいるなら、そのチームは一生良くならないだろう。その上司は「変えることによるメリット」よりも「変えることによる対応コスト」の方が大きいと見なしたのだ。もしくは「現象の不便を続けるコスト」の方が楽だと見なしたのだ。結局その上司は何も変えたくない、変えるつもりがないということだ。これからも同じ不便を続け、時間経過によってさらにコストがかかろうとも、「自分は何も変えていない」という安心感だけにすがって不必要な苦労を続けることを決意しているのだ。

ルールは、それを守ることによって得られる「全体への便益」のために存在しているはずだが、「ルールを守ること自体」が「特定の人物の便益」になっているのであれば、そのルールが適用される組織は腐っていく。

こちらとしては「悪いものはさっさと変えて、全体効率を高めようや」と思うのだが、ルールをあえて変えず、不便な中で低質な仕事をするのが生存戦略になっている人間も、案外いるものなのである。こういう人はエンジニアとしてのスキルがないまま過ごしてしまったが故に、自動化とか効率化とかをされると自分の存在意義がなくなってしまうし変化にはついていけないので、「何やらグチャグチャなところをその人の長年の経験と勘でなんとかやれる」ようなアナログな状態でないと困るのである。

正直こういう厄介者が1人でもいると、その組織はどうにもならないので、既に改善されたルールで動いている場所に移るか、なんとかしてそういう無能な人間を外すかしかないのである。

「ノート」と「メモ」の違いを考える

考え方 言葉

「ノート」と「メモ」はどう違う?

個人的には以下のような感覚で使い分けていた。

  • 「ノート」は自分のために蓄積していく情報を書き留めるもの。「ノートブック」というように、リングでまとまっていたり、帳面みたいになっているもの。
  • 「メモ」は一時的に記録を取っておくもの。ずっと残しておくものではなく、ポストイットのように「書いて用が済んだら捨てる」ようなもの。

さて、この感覚は合っているのか。各種文献から引用してみる。

まずは英単語としての意味を調査。

  1. ~を書き留める
  1. 〔社内の〕回覧状、連絡票◆【同】memorandum
  2. 〈英話〉メモ、覚書◆【同】memorandum

次に「覚書」、Memorandum の Wikipedia

あるトピックに関する出来事や観察結果を記録することにより記憶を助ける行為、および記録した文書(備忘録)、またはその他の情報伝達手段。

うーん、分かったような分かんないような?

では既に「ノート」と「メモ」の違いを論じている記事はどうか。

自分用ならnote誰かに渡すためならmemo、誰かに意見を伝えるためならcomment、という具合です。

日本語でふつうメモというものはnoteにあたり、ちょっとした連絡事項はmemo、コメントはほぼそのままcommentです。

また、面白い表現を見付けた。

ノートというのは 受信記録メディア です。あなたが「受信した」情報を記録し、あなた自身と一緒に持ち帰るためのメディア、それがノート。

メモは送信用メディアです。あなたがメモに書いたものは、そのメモを他の人に渡すため。自分の手元にとっておくためのものではありません。ToDoリストのように使う場合は確かに手元にありますが、手元にあるメモはじきに破棄する存在です。
メモというのは floating な存在です。常にあなたの手元から無くなる。メモというメディアは、このように「他人に渡しやすい」ように作られたメディアです。

表現の仕方がそれぞれ異なるが、概念の方向性はどれも同じようだ。

ところで、「フロー情報」と「ストック情報」という概念

「メモを取る」「ノートを取る」どちらも不自然な気はしないが、個人的には、後輩に対し「人から何か見聞きした時は『メモ』ではなく『ノート』をとってほしい」と言っていた。「ノート」の方が、自分自身の知識の吸収のために情報が体系的にまとまっており、読み返した時に有用なもの、という感覚があった。一方「メモ」を取ってしまうと、体言止めで単語だけピックアップして書いてあり、それをどうするのか、といった体系的な情報は文書化されていない状態。その「メモ」はそのまま残しても有用ではなく、ずっと頭の中で正確に覚え続けておくか、正しく残すなら清書しなくてはいけない、というような感覚があった。だから「メモではなくノートを取ろう」と表現していた。

その感覚は、情報の性質や有効期限の違いで、「フロー情報」と「ストック情報」という区別の仕方がある。

ざっくり言うと、これら2つの情報は、

  • フロー情報 …… 「寿命が短い、日々流れていく情報」
  • ストック情報 …… 「いつでも探しやすい、まとまった情報」

というような区別があります。

その名の通り、フロー(流れる)情報とストック(貯まる)情報という違いですね。

個人的な感覚では、

  • 「メモ」は「フロー情報」
  • 「ノート」は「ストック情報」

という感覚があったのだと思う。先程の「メモとノートの違い」と照らし合わせても、方向性は近いものがある。

明確な区別はないものの。

英語で「Difference Note Memo」などと検索すると、英語のフォーラムでも同様な違いが論じられている。ニュアンスは上述のような違いがあるものとして回答が載せられているが、ネイティブでも「よくよく考えないと言葉の違いを意識しない」ということなのだろうか。

JAS 規格における「そうめんとひやむぎ」のように「明確な区別」というものがあるわけではないが、今回はある程度、「ノート」と「メモ」の概念の違いをまとめてみようと思う。

「ノート」は自分のための記録メディア

「ノート」は、日本では「Notebook」の短縮形として用いられているように、本・帳面の形状をしていることが多い。つまり、情報はその中に閉じ込めておく、ということになる。

情報を閉じておくということは、「ノート」とはそれを開く自分自身のための記録媒体と考えられる。見たものや聞いたものを自分の備忘のために記録する媒体なのだ。

「ノート」は帳面の形で長期間残しておけることから、情報の性質としては「ストック情報」を扱うことが多くなるだろう。

「フロー情報」を書いてはいけないというワケではないが、「自分が開いた時に意味のあるもの」にするには、「フロー情報」(時間経過によって無用になる情報) の塊ではあまり意味がない。

「メモ」は周りの人に影響を与える記録メディア

「メモ」というと「メモ帳」を連想するが、「メモ帳」は「ノートブック」と違って、紙を引き剥がせる形状をしていることが多い。これはつまり、情報をその帳面に閉じておくのではなく、むしろ帳面から取り出して外に発信するためのもの、ということになる。

紙を引き剥がして外に晒す、ということは、その紙を自分以外の誰かにも見せたいというワケだ。その紙の情報をもって、相手と合意形成をしたり、相手に何らかのアクションを取ってもらったりするために使うと考えられる。

紙ッペラを引き剥がすということは、台帳管理している紙よりは処分するまでの期間が短いイメージを持てると思う。そうすると情報の性質としては「フロー情報」が多いと思われる。

「Memorandum」の和訳は「覚書」であることから、相手と合意を取った証拠として長期間残すこともあるとは思うが、「いつまでもその紙の情報が必要かどうか」で考えると、「相手と合意を取り終わり、やることが済んだら不要になるもの」といえる。だから「ノートブック」と違って紙の集合体として保存しておく形状もとっていないということだ。

一言で違いを表現するなら

当初自分が持っていた感覚は概ね合っていたが、「メモは外部発信するもの」という感覚があまりなかったので、その性質を含めて違いを一言で表現してみた。

学校の授業で取るのは「ノート」だけど、電話に代理応答した時に取るのは「メモ」。

これでどうだろう。

  • 授業で見聞きした情報を記録する → 自分のため → 情報は普遍的で長期間保管して見返して有用なもの → 「ノート」
  • 他人への電話を受け取った時に情報を記録する → 相手のため → 情報は相手に電話の用件を伝え終えたら不要になる → 「メモ」

これで両者の性質の違いを表現できたのではないだろうか。

あなたは「メモ」を取っている?「ノート」を取っている?

どちらが大事でどちらが不要とかいう話ではない。

その場で記録する情報はどういう属性・性質を持つ情報なのか。なぜその情報を記録しているのか。

その辺をよく考えて情報を適切な媒体で記録することで、自分にとって、周りにとって、有用な情報を記録することができるようになると思う。

業務例外をどこまでシステム化するか

日本の SE ストレス 考え方 設計

「ココは絶対100万円以下の値しか入れられないようにして」「支払後に支払額を変更するはずがないんだから支払データは変更が入らない仕様にして」なんて要件を取り入れて作ったのに、「今期からは100万円以上の金額を入れたくなった」とか「為替変動があったからこの支払済データの支払額を変更したい」なんて要望が後々入ってきたりする。

「その当時はそういう仕様が正解だった」とか、「今回だけは特別」とか、理由は様々で、その理由自体が間違っているわけではないのだと思う。

ただ、システム化したもの、プログラムによって制御しているもの、というのは、「やっぱ変えたい」とか「今回だけちょこっと例外を許して欲しい」といった、人間ならできる「柔軟な対応」というのができない。パソコン、システムというのは結局のところ「人間が一度決めて命令したことを繰り返すことしかできない」と思うべきで、「空気を読んで毎回やることを変える」ということは、今のところ早々簡単にできることではないのだ。

とはいえ相手は人間で、システムのために自分の行動や業務を合わせにいくなんて工夫はしないのが普通 (いや、プログラマならそういうことって平気でできるんだけど、パソコンできない人って恐ろしいぐらいその感覚がないのよ)。何が業務仕様で、何が業務例外で、その業務例外には「特例で OK とするケース」が発生しうるのかしないのか。そのあたりの見極めと、システムでどこまで対応するか、どこまで顧客に諦めてもらうかを考えてもらう必要がある。客は金を払うので妥協なんてしない一方、自分の業務への理解も案外低く、それをシステム化するということはどういうことか (= 自分が手作業でやっていたときの「柔軟さ」がある種再現されないということ) を理解していない。

自分が担当しているシステムの一つは、一応「システム」というものを理解している人たちが、勘定を管理するためのシステムだったりするのだが、それでもこの人達は「やっぱり今回だけこうしたい」といったことを言い出したり、「自分が Submit ボタンを押す前に何度か変更をかけていた金額のうち、3つ手前の金額の情報を復元できないか」なんて依頼がきたりする。根本的にシステムができることというのを理解していないし、理解する気もない様子。

それに対してうちの上司は「じゃあ今回だけ支払済データに UPDATE 文流して金額情報変えちゃいましょう」なんつってデータパッチしてみたり「パッチしたせいで連携システム側のデータ取り込みが失敗した」とか言われたら「じゃあ取り込みデータだけ手運用で別に入れ直しましょう」とか無茶したりする。俗に言う「運用でカバー」しかせず、システム要件と現在の要望とが合っていないことを何とかしようとか、顧客業務を整理させようとか、システム側をなんとかしようとは絶対にしないので、下っ端のこちらは毎度毎度意味不明で成果のない仕事をさせられている。

この直属の上司をすっ飛ばして更に上の上司を巻き込んで文句を言ったりしたけど、組織全体が腐敗しているし、客も選べないままアホ相手に時間を搾取されるので、僕は全てを諦めることにした。

僕は物事を何とかしようとしている人と仕事したいし、自分が協力するなら「自分でも何とかしたいんだけど手伝ってくれないか」という姿勢の相手に手を差し伸べたいと思う。「イイカンジにしておいて」なんて依頼の仕方を本気でするような適当な人間なんか不幸になっていればいいのだ。