ブログを書くと考えがまとまっていいですね。もう少し考えてみました。
「真面目さ」と「誠実さ」の間：仕事に本当に必要なものは？
先日、少し不真面目な話や不謹慎な話が好きだと書きました。 また、真面目な医師が真面目に検査をすることが、必ずしも健康につながるとは限らないという話もしました。 あれこれ考えているうちに、もう少しお話ししたいことが出てきました。
大前提：社会は「真面目さ」に支えられている
不謹慎な話が好きだと言っても、社会全体が真面目さから逸脱してしまっては成り立ちません。 私たちが安心して経済活動を行えるのは、「相手が約束を守ってくれる」という信頼関係が根底にあるからです。
例えば、買い物の際にお釣りがごまかされないか、購入した商品に欠陥がないか、いちいち確認しなければならないとしたら、 計り知れないストレスが発生するでしょう（海外では稀にそうした経験をすることもありますが）。 銀行が倒産するかもしれないという噂が流れれば、人々は預金を引き出すために殺到し、取り付け騒ぎが起こります。 こうした事態を避けるためにも、多くの人が真面目に職務を遂行し、信頼関係が維持されていることが不可欠です。
「真面目」であれば本当にいいのか？
しかし、ただ真面目であれば良いかというと、必ずしもそうとは限りません。
コンビニで住民票を交付するシステムにおいて、別人の証明書が誤発行されるという事件がありました。
- 自治体コンビニ交付で証明書が誤発行されてしまう障害のまとめ｜ケンタロウ
https://note.com/kentarou_c/n/n73fcbf82ec51
技術的な観点から見ると、複数のリクエストが同時に発生した場合の処理（排他制御）はこのようなシステムでは基本的な考慮事項であり、考慮されていて当然のものです。 （可能であれば、処理空間を分けてロック（排他制御）などが必要でないほうがより望ましい）
- タイムスタンプをキーに使うな！システム設計の失敗例 « クロスイデアblog
https://blog.crossidea.co.jp/2023/3800/
一方で、日本のIT産業では、基本的な情報処理の教育を受けていない者が大多数です。 入社後の社内教育である程度は平準化されるものの、人により知識がばらつきがあるのが現状です。 私自身も文系出身でSEになった経緯があります。
このケースでは、富士通から発注を受けた下請けの社員は、設計書にある処理ロジックに問題があるのではと懸念し、周囲に相談していたそうです。 しかし、最終的には富士通から提示された仕様書に従ってプログラムを開発し、納品しました。
協力会社の声は富士通には届かなかったのか、あるいは届いたとしても、すでに設計が完了し納品済だったため、改善されなかったのかもしれません。 協力会社の幹部や営業担当者が、富士通との関係を気にして強く意見しなかった可能性もありますし、 報告はしたものの、納期などを優先して、対応できなかったのかもしれません。
両社ともそれぞれの責任範囲では「真面目に」業務を遂行したと言えるでしょう。 結果、トラブルが発生しました。
協力会社が悪いのではありません。 問題は、発注者が協力会社とコミュニケーションを取り、懸念事項があった際にフィードバックを受け入れる姿勢・体制を構築していなかった点にあるのではないでしょうか。 あるいは、納品物に瑕疵があるかもしれない可能性を上層部に説明できず、つまり上層部の期待値のコントロールができず、瑕疵が許されない状況を作った、あるいは瑕疵は許されないと思い込んだ点にあるのかもしれません。
発注者とは協力会社に対しては富士通ですし、富士通に対しては総務省などの行政になると思います。
「範囲外の仕事」が重要になる場面
ここは内田樹さんの話の受け売りになります。
特に学校や病院といった職場では、与えられた職務の範囲の仕事をはみ出た部分に、むしろ重要な仕事が存在する場合があります。
例えば、小学校の先生のジョブディスクリプション（職務定義）を「1日6回、45分の授業を行い、文科省の学習指導要領にのっとり、子供たちに教育を行う」と単純化したとします。
では、廊下で見かけた子供の表情が暗かった場合、先生は何もしないのでしょうか？ 落書きを見つけた場合、漫画の忘れ物があった場合はどうでしょうか？
つまり、イレギュラーな問題への対応は、通常の業務と同じか、それ以上に教育の本質と言えなくもないわけです。
またジョブディスクリプションに「給食では子どもたちの配膳を見守り、安全を確保する」「食事中、アレルギー発作の症状がないか観察する」と明記されているとします。 では、先生は監視カメラで子どもたちを見ているだけで十分なのでしょうか？
どこまでジョブディスクリプションを細かく記載すれば十分な定義になるのでしょうか。 （こう考えてみると、先生という仕事は本当に大変ですね。私には務まりそうにありません。）
ウォーターフォールとは「対話的な相互作用」のプロセスである
ソフトウェア開発におけるウォーターフォール・モデルは、W.W.Royceが1970年に発表した論文「Managing the Development of Large Software Systems」で初めて提唱されたとされています。 しかし、Royce自身は、ウォーターフォール・モデルを「iterative interaction」、 つまり前工程と後工程を行き来しながら相互作用によって進めていくプロセスだと述べています。
もちろん、各工程を段階的に進め、後戻りする際にはきちんと管理する必要があります。
しかし、後工程で問題が見つかった場合には、前の工程にフィードバックすることが不可欠です。 「手戻りがあってはならない」という考え方は適切ではありません。
特にソフトウェア開発は、人間が頭の中で考えたロジックを具体化する作業であり、いわゆる可塑性が高い作業です。 手戻りが発生する可能性は十分にありえます。 手戻りを管理することは必要ですが、いわゆる「無謬の神話（間違いがあってはならないという考え方）」に陥るべきではありません。
また、設計者と実装者が異なる場合、両者がしっかりと相互作用し、コミュニケーションを取ることが非常に重要です。 設計と実装がそれぞれの範囲を少し超えて、お互いに影響し合うような状態が理想と言えるでしょう。
私のお気に入りのRoyceのウォーターフォール・モデルの図です。どうでしょうか。単に、上から下に流れているだけではないのです。
真面目さと誠実さ
仮に、悪い真面目と良い真面目があったとして、悪い真面目を「悪い真面目さ」、良い真面目を「誠実さ」と呼んでみましょう。 このブログ記事内だけの定義です。
以下のように整理できるでしょうか。
「悪い真面目さ」
- 任されたことしかしない真面目さである。自分の担当範囲では絶対に誤りがないか詳細に確認するが、その外側には関心を持たない真面目さである。
- 自分が非難されないよう、自分を守るための真面目さである
- 上司や自分の組織を守るための真面目さである
「誠実さ」
- 自らが考える目的や職業観、倫理観に基づいた真面目さである
- 仕事を真に完成させるための真面目さである。
- 見もしない他人を守るための真面目さである。
哲学者／倫理学者であれば、もう少し精緻に文書化すると思いますが、いったんここまでにします。
マザー・テレサの言葉に「わたしたち一人一人が、自分の玄関の前を掃除するだけで、全世界はきれいになるでしょう」というものがあるそうです。 これは、個人が自分の役割を超えて、目の前の物事や他者に対して誠実に関わっていく重要性を示唆していると思います。
ただ、はみ出すのは少しだけ、自分の玄関の前だけでいいと思います。すべてに連帯責任では、ただのブラック企業になってしまいますからね。
