少人数+ソフトウェア+サーバやロボットの組み合わせで
新しい時代の会社経営を進めています。
そのプロセスの一部をこのコーナーでお伝えできればと思っています。
2024.01.15
いつもベストなプロセスで進められればいいのですが、必ずしもそうではありません。
むしろベストの方が少ないんじゃないか、と考えれば日頃からトレーニングの仕方が変わります。
ITサービスを作るにあたり、プロジェクトを立ち上げます。
メンバーを集め、お金を算段し、アイデアを出し、市場を調査し、スケジュールを立て、モチベーションを上げ、要件にまとめ、デザインを描き、コーディングして、インフラを構築し、システムを設計して、プログラムを書き、データを流し込んで、テストをしたのち、不具合を修正し、プレスリリースをまとめ、メディアに出てから、ユーザーが使い始める。
簡単に書いてこのステップ数ですから、すんなりいく方が珍しいでしょう。
さらにメンバーのスキルが違い、コミュニケーションの方法が違い、得意分野が違い、これまでの経験が違い、抱えている仕事量が違い、これまで生きてきた環境が違い、重視している価値観が違い、年代や性別が違い、楽しく感じることが違います。
いわずもがな、バラけている方が普通です。
ならばと、普通であるはずのベスト“じゃない”プロセスにどんなものがあるかと想像してみるのです。
少し考えると、むしろその方が難しいと分かります。
なんといっても分岐していくパターン数が膨大になりますから、そこから思考が先に進みません。
でもそうすると、ベストじゃないプロセス自体を想定できませんからトレーニングができないことになります。
ベストなプロセスを目指すために、ベストじゃないプロセスへの対応力をつけたくても、ベストじゃないプロセス自体を思い描けないということ。
このジレンマをどう克服すべきなのか?
そもそもあらかじめ人のスキルや経験を標準的に選抜し、プロセスに共通ルールを適用することでブレを最小化するという解決策もあるでしょう。
ですが、本当はベストなプロセスなんて存在しないという感性を共有し、目の前に立ち上がる不完全さにチーム全員が足を止め、納得するまで膝をつけ合わせる時間が重要なトレーニングになるんだろうと思っています。