愚かであることに対する報酬は不公平

はじめに

IT業界以外には”誰でも”受け入れることができるように業務の標準化やドキュメントをやさしく書くことが求められます。少なくともSierはその手の”配慮”が強く求められることが少なくありません。そのような”配慮”が続かなくなった経験を話そうと思います。

サンプル

なぜかは分かりませんが日々人間が成長するように成果物の”品質”も日々高めていくことが求められます。その品質の指標としてどれだけ”配慮”できているかを指標にしているケースがありました。

1か所見るだけですべてを理解できるドキュメント

“誰でも理解できる”ことを目指して（？）すべての情報が書かれたドキュメントが出来上がったことがあります。要求は徐々に増えてゆき、最初はそれぞれのドキュメントを見たらわかるから、一つのドキュメントを見たらわかるになり、最終的に1項目見たらすべてがわかるというように少しずつ”品質”を高めることが求められるようになっていきました。

以下のドキュメントがありました。

• テーブル定義
  一般的なテーブル定義…それでも普通のテーブル定義より詳細に作られていました。
• 画面項目書
  こちらが”進化”を続けていった設計書です。
  基本的には画面に表示された項目が定義されています。最終的にそれだけではなくなりましたが…。

1か所見ればすべてがわかるようにしよう

最初は画面に何が表示されるのかを示すだけのファイルでした。しかし、徐々に親切な設計書に進化していきました。

• onLoad、onChangeなどのイベントで更新される可能性がある箇所を記述しよう
• 画面の項目と対応するDBのカラムを書こう
• 実際に値を書き換える処理が走るのがクライアントサイドで自動で項目を更新するか、サーバーサイドで直接更新を書けるのかわかるようにしよう。
• 何らかのボタンを押したらどのテーブルの何のカラムがどの項目の値で上書きされるのかを書こう
• 自動的に入力される項目はどのテーブルのカラムが自動的に入力されるのかを書こう
• 処理で使う変数名に迷わないように設計書に書こう
• ファイル名がわからなくならないように設計書にファイル名を書こう
• 物理名の方がわかりやすい場面と論理名の方がわかりやすい場面があるから両方を書こう
• どんどん書き足したとしても、見た目が変わったら混乱してしまうかもしれないからフォーマットは絶対に変更しないようにしよう。
  …ほかにもあるような気がしますが、運用者にも製造者にも親切な設計書を目指していたようです。これが混迷を極めていったのは 最後に書いた親切、フォーマットが変更されないようにしたでしょう。書く内容は増えていくのに書く場所は増えない、その結果として、もはやどこに何が書かれていればよいのかは把握しきれなくなりました。
  以下は設計書のイメージです。実際の設計書とは書き方は異なりますが、考え方は合っているはずです。

サンプル

■画面項目

同じようなことが複数の場所に書かれていると思います。ただ、これで1行の項目を見ただけでどのテーブルに書かれているか、どんな景気で更新されるかがわかるようになったね！という事らしいです。私は正直に言ってまだ全容を把握しきれていませんが

無限に出来上がっていくルールとチェックリスト

書くことが難しいためミスが多発していました。同じような内容を複数のか所に記載しているため、直っているところと直っていないところが発生する。イベントを書く場所が間違っているなど、OneNoteで記述した設計書であり、Excelなどで記述した内容を転記することを禁じていたこともそれを助長しました。
そのような状況であったため、ミスを防ぐためのルールやチェックリストがどんどん増えていきました。誰かがミスをするたびに新しいルールが増えていく…。
真面目にチェックリストを先頭からなぞるとどんなに軽微な修正でも数時間はチェックに取られることになる。だからと言って作業が遅くなることは許されないし、もし、チェックリストにある内容であってもミスをしたら新しい対策とミスをしないためのチェックリストを考えさせられる。

IT業界に蔓延る愚かであることに対する報酬

Sier業界では人の入れ替わりが激しいためか、誰でも読み書きできることを保守性の指標とすることがあります。先のサンプルははっきり言って保守性がかなり悪いと感じています。一方でマネージャーあるいはリーダーは”保守性に優れた設計書”という認識をしていたようでした。
リーダーたちにとっては処理という難しい概念を持ち出す必要はなく、製造者にも運用者も理解できる設計書作成できている。また、知りたいと思われる1行分を見るだけでどんな情報が書き込まれて、最終的にどのテーブルのカラムに値が書き込まれるのか理解できる。
これは運用者だけでなく、製造者も満足に条件分岐や繰り返し処理といった基本的な構文すら理解していないことも原因にあります。信じがたいですが事実です。私はこのプロジェクトにおいて、メンバーに20行足らずの処理を記述するために8時間近い時間をかけて説明をした覚えがあります。
このような状況であったため、処理などという難しいことを事前に記述することは難しかったのです。メンバーたちも成長する意思はありませんでした。実際そのまま数年過ごしていたのですから、それは明白です。
リーダーたちはこの状況でも記述することができる設計書や処理を考える必要があったのです。その対策として行われた施策は間違った努力であったと感じています。私にはこれを愚かであることに対する報酬であると感じています。

なぜ不満を感じるのか

私も自分のことは愚か者であるという自覚があり、不公平感を感じているからです。
リーダーたちは自分たちが諦めた割にメンバーが成長するために技術的な説明をすることを私をはじめとしたある程度の能力があるメンバーに押し付けていました。
私もこのような設計書を書かされて、数時間にもわたるチェックリストを先頭からなぞらされるのは非常に面倒くさい。やりたくありません、サボりたいです。その結果、新しい施策を考える羽目になりました。より、面倒くさくなりました。もっとサボりたくなりました。
しかし、私に対する配慮はありませんでした。何故やらないのか？ということを問い詰められたこともあります。他の人にはそんなことしませんよね？

この施策は持続可能ではない

当然である…と思っていますが、自分だけずっと我慢させられているような気持ちにさせられています。そのような感情を抑え続けることには限界があります。愚か者は感情や衝動を抑えることができません。
このようなことに付き合いきれなくなったら、新しいメンバーと入れ替える。もし、入れ替えができなければ限界を迎えるまで使い倒す。
最もよいのはこの状況を何とも思わずに受け入れてくれる程よい技術力があるメンバーを探すことでしょう。そのような人物がいるのかはわかりませんが。

ケン

ヨワモンのパートナー

ヨワモンのパートナー