「ていねい」ってどういうことだろう？

こんにちはでございまする。ゼバ会です。
当会では、いつもプログラミングの話をしているわけですが、今回は少しシステムから離れて、全ての新人社会人に告ぐ永遠のテーマの話をします。

具体的には、「ていねいな仕事」ってなんだろう？　ってこと。

昔の日本人はそういうの後輩に絶対教えないので、昭和カタギの師匠なんかに師事した日にゃあ、ていねいな仕事ができるようになるだけで２０年とかかかったものです。
でもエンジニアは、ていねいな仕事ができないとトラブルが大きくなりがちなので、人が育つのを２０年なんてとても待っていられません。

てなわけで本日は「ていねい」を具体的に定義します。
かつ、人や状況によって意見が分かれるものではなく、人類不変の定義を考えてみます。

一般に「ていねい」は意味が曖昧な言葉として扱われがちで、その解釈をめぐってケンカになることもあります。
なので、絶対反論しようがない完璧な定義を作りたいと思います。

〇 「ていねい」とは

はい。ズバリ。これが私の定義でございます。

1. 前提条件のない行動手順の理想形が
2. 現実に実施可能な方法論のみで定められているとき
3. その方法論に忠実である状態のこと

上記全ての状態を満たすような仕事の仕方をすることを、世に「ていねい」といいます。
つまりアインシュタインもエジソンも、それどころかユークリッドやヒトラーだって、絶対に間違っちゃいけないことをするときはみんなこれをやったってことです。

文体そのものは、あらゆる状況を考慮しすぎて多少意味不明になってますが、とはいえこの定義自体は絶対に間違いありません。
小指賭けてもええです。マジ。

なぜなら、この地球上のありとあらゆる仕事は、手順通りに事を進めることによってのみなしえるからです。
もちろん、あまりに面倒くさすぎて手順書なんか作ってられないケースならありますが、そもそも物理的に手順がないケースというのはありえません。
つまり理論上は、あらゆる仕事は手順書が作れるということです。
（なんなら、社員が行動したその結果そのものが手順とも言えますね）

ということは、もし仮にあなたがていねいに仕事をすることが苦手なタイプだったとすると、上述の定義を参照すると、あなたが仕事ができない理由は４つに絞られることになります。

仕事をていねいにできない４大理由
可能性1. 行動手順の定義に準備不可能な前提条件があった
可能性2. 行動手順の定義が理想的ではなかった
可能性3. 行動手順の定義が、現実には実施不可能な方法論を含んでいた
可能性4. 定められた行動手順の定義に、行動が忠実ではなかった

昭和カタギのパワハラ上司なんかは、部下が失敗すると、ナンも調べもせんと「可能性4. 本人の問題」と一方的に決めてかかったものです。
が、ていねいにやることが難しい仕事があるとき、その原因の第１位は「可能性1. 前提条件の不備」です。
前提条件。

「可能性2.」「可能性3.」もそれなりに数は多いのですが、それらに増して多いのが圧倒的に「可能性1. 前提条件の不備」です。

会社で定められた手順に、誰も気にしてなかったけど実は前提条件があった。
そしてそれを作業者自身が満たしていなかった。だからミスをした。
これが、世の中的にもっとも多い仕事にミスが起こる理由です。

この前提条件君って子はね、本当にかわいそうな子なの。
世の中で本当に本当に不遇な扱いを受けているのです。
必要なとき存在していても「あって当たり前でしょ」としか思ってもらえず、そのくせ普段は無視されて評価もされず、失敗したときだけ怒られる。
「おまえはオレか」って何回言ったかもう分からんくらいよ。

なのでこれを機に、前提条件とは何か？　ってことを少し考えてみたいと思います。

〇 業務における前提条件とは？

前提条件が不遇な扱いを受けている例として、ここ最近割とホットな話題になっているのはこれですかね。
育成プログラムのないＩＴ企業のＳＥＳ事業で「初心者歓迎」。

もちろん社会全体を見渡せば、前提条件が無視されてる状況なんてそれこそ掃いて捨てて煮て焼いて食ってもまだ売るほどあるわけなんですけど、想像しやすいところで、ってことで。

まぁ、これは少し考えれば分かりますよね。
パソコンのことを本当に何も知らない経営者とかが、「エンジニアは完璧超人である」というイメージを持ったまま「ITにご興味あればどなたでもＯＫです！」とか求人打っちゃう。
誰でもいいわけナイダロ！！　カッコ笑！！
エンジニアは職人技能だよ！！
そんで肝心の教育はどうすんじゃいってーと、ＯＪＴで現場の先輩とかに丸投げなわけ。
あるあるでしょ？

でもね、でもね？
そこで笑ってるあなたも、過去の某社に憤ってるあなたも、もう少し小さな単位で似たようなことやってない？

部下にパスワードが必要なことを伝え忘れて困らせたことは？
誰かに申請書を出すようお願いするとき、用紙の入ってるフォルダの場所を説明し忘れたことは？
お客さんの業務に完全に精通してないと分からないことを、業務に精通していないはずの人に事前説明なく話し始めたことは？
あと、その人の体力は平均よりも上である、と勝手に思い込んで残業の多い仕事とか振ったことない？

それからエンジニアブログに多いのが、分かっていることが理想の知識を、分かってないとおかしい前提で説明省いちゃうケース。
たとえば Linux 関連の技術ブログで、タイトルでは「初心者向け」を謳っておきながらパーミッションの説明がないケースとか。
普段あちこち見てるとメチャクチャ多いです。

といっても、おそらくほとんどの人には、自分がそんなことをした心当たりはないと思います。
私だって「やられた」ときのことはよく覚えてても、自分が「やらかした」ときのことはほとんど覚えてませんもん。
でも私自身も多分、やられた回数よりもやらかした回数の方が多いです。
（このブログ含めてね）

自戒も含めて言えば、本当に気をつけないといけないのは、この前提条件を無視した説明というヤツは「やられた側からは意地悪されたように見える」ってことなんです。
本人にはそんなつもりはカケラもなくても、された側の心には一方的にあの人は意地悪な人という印象だけが積もっていってしまいます。
ですので最終的に、やらかした側からすれば、何もしてないのに相手が勝手に敵視してくるように見えるでしょう。
そういうときたいがいの人は「よろしい、ならば戦争だ」ってなるんでしょうけど、まぁ要は、説明の仕方が悪かったケースの方が圧倒的に多いってことなんですわ。

そんなことにならないよう、仕事で人に行動手順を説明するときは、この人は何を知らないはずであるかをよく調べないといけません。

それが分からないときは、基準を「幼稚園児」に置くのも手の１つです。
幼稚園児が知らないことなら、もしかしたらこの人は知らないかもしれないと考え、前提知識が身についてるか会話を通じて探りを入れます。
（エンジニアが非エンジニアとしゃべるときは、みんなそれを無意識にやってるはずです。でもエンジニア同士とか、あと立場が自分より下の人と話すとき、そういう探りを急にやらなくなる人も多いですね）

あなたに説明を受けた結果、その人が前提知識を持っていなかったがために手順を理解できなかったら、その人が失敗した責任の一部は結局自分のところに戻ってきます。
なので前提条件を無視すると自分が損するだけです。

〇 行動手順が理想的とはどういうことか？

はい、次。
会社の業務において、理想的な手順とは何か。
こちらは、割と想像するのが簡単だと思います。
よくある話ですからね。

典型的なのはハンコですかね。
「仕事で使う物品を私費で買うときは、申請書に部長のハンコをもらって後で清算しなければならない」とかとか。
で、その際に部長の袖机にしまってあるハンコを使うことに、あまりにも過度にこだわりすぎてしまうケース。

これ、理想的じゃないですよね。

本当に欲しいのは部長に認めてもらうことであって、別にハンコの美しさに酔いしれたいわけじゃないのです。
部長の立場からすれば「今までずっとそうだったんだからいいじゃん」ってことになるんでしょうが、でもハンコをもらう側からすれば不合理です。
それだけのための出社とか絶対イヤです。

分かりますかね？
あなたにとっては今までずっと当たり前だったことでも、「非効率的だと気づいちゃった人からしたら」、「やること自体がイヤ」なんです。

まぁ、たとえばデータベースに Oracle を採用しているシステムがあったとして、仮に「絶対に JOIN 句を使ってはならない」というルールがあったとしましょう。
で、そのルールを決めたのが実はあなたで、その理由が「コード内で使用しているテーブル名を grep で拾うことができず、そのせいでちょっとした不具合がクリティカルバグに発展したことがあったから」とでもしておきましょうか。

これ、多分ですけど、不合理に最初に気づくのは、速度が求められる分析処理を担当した人あたりでしょう。
もちろんあくまで例ですけど、複雑な分析処理はアプリケーション言語だけでは十分な速度が得られないことも多いので。

JOIN を使えばすぐ解決する問題に対して何日も何日も残業を強いられ、しかもお客さんからもあなた自身からもセッツカれるなんてことになったら、その人もう、ストレスフルプリキュア💛マックスハートですわ。

そういうことにならないよう、会社で仕事に使う業務手順（上記の例の場合は開発標準）は、常に研鑽し続ける意識を持っていなければいけません。
ハンコにこだわりすぎるのも、JOIN句を過度に怖がりすぎるのも、どちらもただの「行き過ぎ」です。

それが本当に必要なルールなのであれば、廃止することでどんなリスクが生じるかをキチンと精査すべきでしょう。
なぜなら、世の中の全てのルールは守らないとリスクが生じるからという理由で守るものだからです。
守らなくても何のリスクもないルールなど、守る価値はありません。

で、その意識に欠ける手順書が、ここでいう「理想的でない状態」です。
これは会社単位・部署単位の大きな手順書もそうだし、あなたの頭の中だけにある、あなた個人の手順書についても同じことがいえます。

〇 実現不可能な行動手順

こちらもイメージするの簡単ですね。
たとえばこんなん。

仕様改変時は顧客に納得していただき、承諾を得なければならない。

これさぁ、、、(苦笑
もしＩＴリテラシーの低いお客さんだったら、「Oracle じゃないと PRIOR に対応してないから、MySQLじゃ超高速再帰解析とか無理です」なんて、どうやって納得してもらうわけ？？
（もちろん「どうしても必要なのでお金ください」で納得してくれる人もいるんだけど、、、）

まぁ、こういう例に限らず、実現不可能な手順というのは、要は手順書が机上の空論ってことですね。
世の中には、実現できることが理想であることを根拠にできなきゃおかしいと判断する人も多くて、そういうケースのことを言っています。

もっと身近なところでいうと、開発エンジニアが、ＱＡサポートエンジニア向けの手順書を作るときなんか、実現不可能な手順になりがちです。
「お客様にコンピューターの説明をする以上、サポートエンジニアはコンピューターに十分に精通していなければならない」という前提で、ＩＴ用語とかメチャクチャ使われたり、手順の一部を一言で済ませたり。

うん、気持ちは分かるけどそれ、ただの理想論ですよね。
世の中のだいたいのＱＡサポートマンはあくまで「トークのプロ」であって、コンピューターのプロではありません。なんならサポート歴１５年のベテラン古参兵が「デフォルトって何ですか？」レベルの知識しかなかったり、割と普通ことです。

また、ていねいな仕事をするのが苦手な人は、このような実現不可能な手順を自分で自分用に作るときにもイメージしていたりします。
で、実際にやるときとか、あと上司にツッコミ入れられたときになって初めてそれに気づいたり。

自分用の手順書を頭の中に作るケースで特に多いのが、とにかく物凄く目が粗いケース。
たとえば頭の中にあるプログラミング業務の手順書が「組む ⇒ 確認」しかないとかね。実現不可能というより、目が粗すぎて手順として成立してないとも言えますね。

頭の中の手順がそんな状態の人は、具体的に何を「組む」んで、そして何を「確認」するのかの定義が自分の中にありません。
ですので、毎回異なる観点でセルフレビューしちゃって、出てくるコードの品質が毎回バラバラ、なんてこともよくあるわけです。

こういうのは、「プログラムを組むときの観点」や「セルフレビュー時の観点」を予め紙の手順書に織り込んでおくことで、解決できます。
具体的な業務内容が毎回違うんだったとしても、常に必ず絶対やることはあるはずです。
そのへん、暗記できないんだったら自分用のメモに書いておいた方がいいと思います。

たとえばこんな感じ。

- インプットに対するチェック処理が足りないケースがないか確認する
- 他人から見て分かりづらいコードを書いてないか確認する
- Cyclomatic complexity が極端に大きなメソッドがないか確認する
- メソッドの戻り値の型が他と異なる return 文がないか確認する
- サービスフローと手順の異なるロジックを組んでいないか確認する
- テスト設計書を網羅しても１度も実行されないコードがないか確認する

ここに書いた以外にも、ていねいな仕事をする人というアイデンティティを自分で作っていくためには、必要なチェックは色々あるはずです。
そういった知識の研鑽をするのも、プログラマーとしての仕事の一部です。

〇 まとめ

結局のところ、自分の部下が仕事をていねいにやってくれないとき、その理由が「その人物が雑だから」と断定するためには、上記が全て問題ない状態ことを証明しないといけないわけです。
前提条件も曖昧、やり方も不明瞭、しかも一部に無理がある。
そんなやり方を指導しておいて、あとから「ちゃんとやれ」と本人を叱るのは、それこそお門違いというものでしょう。

なぜなら、自ら好んで「雑な仕事したい！　雑な仕事超たのしー！　もっと意地悪したい！」なんて人、絶対いないからです。

仮に、チーム内に雑なアウトプットを出してくる人が１人だけであったとしても、その原因は若さゆえの経験不足かもしれないし、他業種からの転向組なのかもしれないし、得意分野が１人だけ他人と違うのかもしれません。
それは必ずしもやる気の問題ではなく、むしろやる気の問題ではないケースの方が圧倒的に多数です。

逆に、自分が雑な仕事しかできなくて悩んでいる人は、自分の頭の中の手順書を使って他人が作業できるかを、もう１度考えた方がいいでしょう。
本当に何千回トライしてもどうしてもできないときは、みんなが持ってる観点を、自分だけが持ってないという理由です。

それが何か、ということについて日々探求し続けることが、「ていねいな仕事をする」うえで一番大事なのではないかなと思います。

〇 次回予告

さて、「ていねいとは何か」という話が出たところで、次回はその続きということで、次回もプログラムではなくビジネス基礎の話題にしたいと思っています。
ビジネス基礎っていうか、自己啓発的な内容。
タイトルは「努力って、具体的には何をすることを指す言葉？」です。

あ、別にネタが尽きたわけではありませんよ！
プログラマーを育てる前の段階で先にやっておくべきだと判断したからです。

だって、プログラマーがプログラムを組むのって「努力」じゃん？
でも、その努力が認めてもらえなくて泣いてる人いっぱいいるじゃん？

じゃあ、何をすればちゃんと努力したことになるの？　というお話。
自分にとって必要だと思う人がいたら、楽しみにしていただけると嬉しいです。