会社でツールやサービスを運用すると、何処かで必ず、トラブルが発生します。
「Web開発の現場では、バグはつきものだ・・・」
とか、
「バグの無いプログラムは無い！」
と、自分の口で言ってるプログラマは今すぐ仕事を変えろと言いたい。
プロが失敗をした上で、自分を擁護する姿勢、反吐がでます。
トラブルの要因
それは、大体において、以下の3つになります。
1.webサーバーのトラブル
2.利用者の意図しない設定
3.プログラムのバグ
実は、これら全てが、開発段階における、設計による事が原因の場合が多いのです。
運用中の人的ミスも少なからずありますが、設計のミスは致命的です。
全てのトラブルが設計ミスに繋がる
サーバートラブルは、構築段階で、ハードウェアトラブルを考慮して、サーバー自体がダウンしても大丈夫に構築しますが、
こんなトラブルは、発生しないだろう。という、思い込みが、最悪の事態になる事も、少なからず見たことはあります。
ユーザーの意図しない設定については、プログラム設計段階における、検討漏れ、仕様漏れと、認識すべきで、設計者が足りていない事の証明だと考えます。
もちろん、ブラウザのアップデートによる不具合発生など、想定出来ないレベルのものは存在しますが、そこが設計者の手腕という事ですね。
プログラムのバグは、設計者以前の、コーディングスキルと、デプロイ前の検証不足に尽きるので、経験値などが決め手になるでしょう。
そのトラブル防げましたか？
少なからず発生するトラブルに対して、同じ過ちを2回以上繰り返さないということが、製品担保における条件なのですが、
実際の開発員を見ていると、どうやら個人でそういう意識を持っている開発員は、さほど多くない事が分かる。
ひとつは、トラブル発生の責任が自分に無いと考える人間がこの世の中には少なからずいるという事。
ひどい場合には、「会社の体制が悪い」と、環境避難に走るエンジニアもいて呆れてしまいます。
タイトなスケジュールは分かりますが、世間一般、どこの開発現場に行っても、十分な時間を、開発員の好きなだけ、気がすむタイミングまでという、贅沢な開発は、きっと無いでしょう。
限られた条件下で、パフォーマンスをだすというプロフェッショナルな仕事が、報酬の価値になると考えれば、納得いくのではないでしょうか。
設計は神のみぞ知るブラックボックスか？
多くの失敗する開発員は、設計を構築時に人に話したがりません。
成功する開発員は、必ず、設計を他人に確認し、改善をしようとします。
PDCAが回せているかどうかというポイントもそうなのですが、コミュニケーションの欠落が、設計精度に大きく関わることも、ポイントです。
設計者が、会社の役職というポジションを持つと、成功を意識するあまり、世界が閉ざされている傾向をよく見るので、
会社であれば、制度と、本人に対する意識付けを強化する事をお勧めします。
設計作業はどれほどの職人技なのか？
当たり前ですが、技術の全てを知っている必要があるため、非エンジニアが設計を行ってはいけません。
設計者は、仕様で漏れのある箇所を認識できていないといけない。本当に気がついていない仕様漏れは単なるバグでしかないため、仕様漏れも想定に入れられるスキルはひつようになります。
多くは、経験がモノを言いますが、ある程度のレギュレーションを構築してもいいかもしれません。
ドキュメント作成はマヤカシ
エビデンスとして、仕様ドキュメントや、設計図など、事前段階の確認として、技術者に強いられることがありますが、開発前におけるこれらの資料が意味を持たないことを認識しましょう。
全ては、パイロット版、モックアップ版、α版、β版、などを第1工程として、実働におけるモノを優先したほうが確実です。
ここで求められる事は、パイロット版をいかに短期間で作り上げるかが、開発者、設計者のスキルと理解すべきです。
僕の知る限り、この作業が出来ないのに、設計仕様を作成しているエンジニアは、無免許運転と同じレベルだと考えてます。
設計者のあるべき姿とその環境
ここで言う設計者は、開発もこなせる、プレイヤーという事を前提としますが、資料を作る前に、プログラムにて根拠が記せて、事前の予測がどれだけできるか？
不具合の予測は実は、エンジニア以外の方が得意だということも、認識すべき内容ですね。
そういぅたリーダーシップも大いに求められます。
そして、開発を行う工程は会社に起因しますが、無駄な手続きをどれだけ省力化し、開発員に集中させることが出来るかが、環境構築のポイントです。
個人的には、ヘッドホンをつけた開発員は、きっと、コミュニケーション能力が低く、周りが見えず、自らの失敗や成功を共有出来ない人が多く、伸びるために、ヘッドホンを外すことをお勧めします。
設計者は偉いのか？
会社に置いて、商材になり得るモノの設計を行う人は、成功すれば神、失敗すれば無能者として扱われます。
個人的には、設計を行っている行為は、素晴らしくレベルの高い作業で、本人もその認識が出来るという環境こそが、いいPDCAを回せる作業場になるでしょう。
