レビューを省くと、その後の作業量がレビューにかかる予定だった時間の１．５倍になる。

レビューを省くと、品質が３割減になる。

レビューを省くと、運用に入ってからの不具合が２倍になる。

上記の数字に根拠はありませんが、

あらゆる失敗プロジェクトで最初に省かれるのがレビューというフェーズであり、

あらゆるプロジェクトが成功と失敗という別れ道で失敗を選択する最初の一歩です。

そろそろフリートライアルが終わるので、

アカウントを削除しようとしたら、

サブスクリプションのキャンセルまでしか出来なかった。

ヘルプもFAQもほとんど見たが、

どこにもアカウントの削除についての記事が無い。

仕方が無いので、フリーダイヤルでアカウントの削除をする方法を聞いてみることにしたら、

「こちらでアカウントの削除を承ります。」と応答された。

ついでなので

「アカウントの削除はアプリケーションやwebサイトでは出来ず、こうやって電話しないと無理なんですか？」

と聞いてみたら肯定されてしまった。

どこにも、そんなパスが用意されている事を説明した記事が無いのにだ。

この問題は、電話しないと削除できない事にあるのではなく、

全く、アカウント削除に関するアナウンスをしていない事にある。

新人研修で残業をさせてはいけない。

今の自分が、定時内で終わらせられる仕事量を覚えさせないといけないし、

「残業漬けの毎日で、勉強なんてやってられない。」

というこの業界の悪習を断つためにもやってはいけない。

二進化十進数。

パックとかゾーンとか、結構知らない。

ツールとの間に信頼関係を結べ

ツールをなんとなくで使っていたりしないか？

ツールが作用した結果に自信が持てないのではないか？

そのせいで、ツールにたいして漠然とした不安感を持っていないか？

それは、そのツールのことを知らないからだ。

人間対人間の信頼関係を結ぶときも相手を知る事で信頼できるように、

そのツールを知ることで漠然とした不安感はぬぐえるはずだ。

とりあえず、そのツールが持っている機能のうち、

君が利用する機能についてだけでも、ちゃんと知ってみてはどうか。

設計規約

コーディング規約

作業のワークフロー

もろもろ・・・

ルールは守れ仕事なんだから。

ルールに改善の余地があっても、勝手に適用するな。

まずは相談からだ。

相談して改訂されてから適用しろ。

ルールは守れ仕事なんだから。

金貰ってるんだろ。

最近、ユーザ企業にとって、とても憂慮すべき事態が、いろんなところで起こっているのではないかと思う。

それは何かというと、システム化されて数年がすぎて、システム化された業務の詳細を知る人が社内にいない。

もしくは、忘れてしまっているという事態である。

もちろん、ちゃんとモデル化し、業務の詳細が変更される度にモデルにも変更を加え、いつ見ても分かるように管理されていれば

良いかもしれないが、そうではない企業も多いのではないかと思う。

特に、中小企業なんかには多いのではないだろうか。

そして、いざリプレース案件が始まる段階で、システム化を頼んだシステム会社にお願いすると、そちらにも陳腐化した資料しか残っていない。

なんて事も少なくないのではないだろうか。

そうなると、業務の詳細を知る人は誰もいない。

知っているのは、動いているシステムのみ。

という笑えない状態になってしまう。

企業にとって業務の詳細は、とても大事なものである。

その手順に則る事で業務が円滑に行われているからである。

いわば、生命線である。

そんな大事な知識を、システム化の段階で、手放してしまってはいけない。

もちろん、業務の詳細モデルの改修等でアウトソースする事はあっても、業務の詳細モデルの理解を怠ってはいけないのである。

それ自体は、自分（この場合ユーザ企業）自身が理解して、守っていかなくてはいけないのでは無いだろうか。

そうする事で、リプレースの際に必要な改善ポイントも見出せるだろうし、

なによりも

「リプレースするにも、移植すべき詳細仕様が分からない。」

だとか、

「リプレース後に、業務が回らなくなった。」

なんて事態が防げるのでは無いだろうか。

昔から思っていた事だが、IT技術者も、自分自身のブラディングをする必要があると思う。

初めてプロジェクトリーダをする人は、礼儀としてその為に必要な知識を仕入れておくべきだろう。

特に、育てる的な意味合いが強い場合なんかは事前準備は当たり前だろう。

なんせ、自分は何も知らない状態なわけである。

でも、世の中には無数の知識があるわけだ。

学習すらしないまま、放り込まれたプロジェクトで四苦八苦したところで、リーダとして必要な知識の何が得られるというのだ。

そして、仕事である以上、成功させなくてはいけないことは当たり前なわけで、そのしわ寄せはプロジェクトの他のメンバに来るのである。

そして、プロジェクトが終了しても、せっかく育てる的な意味合いでリーダを任せたのに、何も成長しないまま終わってしまうのだ。

経験した事の無い領域に挑戦する時は、

１．その領域のセオリを知識として仕入れ、

２．適用してみる。

３．適用した結果を分析し、経験値とする。

というのが、初期段階の最善手である。

本当はプロジェクトリーダにかかわらず、そうであるべきだが、今回は特に影響を及ぼしやすいプロジェクトリーダにフォーカスをあててみた。

初めて、プロジェクトリーダをする人は、せめて礼儀として、そのために必要な知識を仕入れておくべきである。そして、任されたからに成長する気満々でやるべき。

そして、組織が誰かに育てる目的でプロジェクトリーダを任せようとする時、せめてその程度の知識を仕入れている人を選択するようにするべきである。

また、貴重な経験を獲得しようという気概のある人を選択しなくてはいけない。