投稿者 岡野 幹生 日時
残業ゼロ宣言をしてから丸三週間が経ちました。
総括するにはまだ早いかも知れませんが、概ね目論見通りで成功だと思っています。
定時の間にするべき仕事内容が明確に意識できて、時間の密度が上がりました。
デッドラインを設定して期限厳守の意識を持つことで、プレッシャーも増え、生産性を高める方向に意識が向いていると思います。
何より、スタッフの顔色が良くなったように感じます。
ゴール地点が見えるからこそ緊張感が持続するのだな、と実感。
しかしこの仕組み、請負業態や営業職だと導入ははるかに困難でしょうね。
その理由は、共に外的要因が多いこと。
営業職だと対外的な渉外活動と内勤のバランスを取る工夫が必要になるでしょう。
外勤と内勤のセットでチームを組んで業務に当たらせる企業もあるらしく、そういう制度的バックアップが無いと画餅になることは明らかです。
請負業態も、完全に仕事をこちらでハンドリング出来ず、常にクライアントの意向や仕様変更なんてのと付き合っていく必要があります。
ある程度までは営業スキルで予防できますが、最後はしわ寄せが来るのでスッキリとは解決出来なさそう。
これは自前のサービスを提供する形態に業態変更しないと解決しないかも知れません。
最近のWeb制作受託単価をめぐるやり取りが賑やかですが、
Dan氏が言うようにそもそも期待収益の低いレッドオーシャンから脱却することを考えないと幸せになれませんよ。
儲かるサービスを提案するなら、自前でやることも真面目に検討してみるべきですよ。
残業ゼロ、幸せな働き方の理想形だと思いますので、導入できそうな会社さんはお試し下さいね。
投稿者 岡野 幹生 日時
本日、全ユーザーさん宛に下記のお知らせをお送りしました。
---------------------------------------------------
いつもお世話になっております。
おちゃのこネットの岡野です。
下記ご連絡事項をお伝えいたしますので、内容ご確認の上ご理解の程宜しくお願い致
します。
記
＜アクセス集中時のアカウント一時停止措置の導入について＞
●背景
最近のサーバーアクセス集中トラブルの多発について、まずはお詫びを申し上げます。
一部のショップさまへの過度のアクセス集中がサーバー全体に影響を及ぼすケースが
増えており、結果的に本来無関係な当該サーバー同居ショップさまに多大なるご迷惑
をお掛けする事態となっております。
上記の事態を回避すべく、本日より、サーバー全体への深刻な影響を及ぼすアクセス
集中時には、該当アカウントを一時停止することといたしました。この措置はサーバー
負荷の低減と悪影響の拡大を阻止し、安定的に運用を継続することを目的といたします。
本措置の導入に伴って下記の通りサービス利用規約の変更を実施し、アクセス集中時
に該当ショップアカウントを一時的に停止する措置を導入します。
●停止措置の実施手順
・アカウント停止措置の実施基準は、当社サーバー管理者によるサーバー負荷レベ
ル監視に依存し、数値基準ではなく運用時の状況を見た都度対応とします。
・アカウントの停止時間は、該当サーバーの負荷改善状況を見ての人的判断による
ものとし、停止措置開始時と停止措置解除時にメールにて該当ショップに通知す
るものとします。
・本措置は、本日より実施します。
●改訂後のサービス利用規約
本措置の導入に伴いまして下記の通りサービス利用規約を変更いたしましたので、
必ずご確認くださいますようお願い申し上げます。
(第8条（サービスの中止）)
http://www.ocnk.net/entry/
●アカウント停止時に表示されるメッセージ
http://kaori.ocnk.net/
↑アカウント停止措置中はこちらに現在表示されている画面が表示されます。
サービスの安定供給のために、このような措置を講じますことを
どうかご理解の上ご協力賜りますようお願い申し上げます。
どうぞよろしくお願い申し上げます。
---------------------------------------------------
当社サービスの提供形態がASPである以上、充分なサーバーインフラ環境をご用意して運用する事が大前提であることは当然です。
現在も、未来も、サーバー環境の改善・充実については可能な限りの努力をお約束致します。
ただ、今回の措置の目的はあくまで”非常時の緊急措置”であり、これが常態化することを想定しているわけではありません。
どんなに頑健なサーバーをご用意しても、そのキャパを上回るアクセスが発生することはあり得ます。
今まで、その様な事態が発生したときの緊急措置に対する取り決めが無かった事自体に問題があったと思っています。
一ヶ月の間に満遍なくアクセスが多くあり売り上げにも繋がってらっしゃるショップさんも沢山あります。
アクセスの繁閑の差がないパターンはこちらも対処がしやすく、負荷の予測が付くため殆ど問題になることはありません。
その意味では大部分のショップさんには今回の措置は影響無いと思います。
問題は、特定のジャンルで人気を博して非常に多数のファンを抱えてらっしゃるお店が、決まった時間をターゲットにタイムセールや新商品発表をされるケースです。
「○○月○○日○○時より、お待ちかねの新製品を発売します。限定○○個ですのでお早めに！」なんてパターンが典型的です。
これがサーバーに過度の負担を与え、結果的にサーバーダウンを招いたりします。
一番申し訳ないのは、該当サーバーに同居している他のショップさんです。
何ら原因が無いのにあおりを食ってショップ表示が出ない、というのは本当に申し訳ない状態で、従来はその時点でこちらとして手を打つ事が出来ず原因となっているアクセス集中が収まるまで様子を見るしかなかったのです。
それを今回の措置で、一時的にですがショップアカウントを一時停止してビジー表示画面を出すことで他のショップさんへの影響を抑えることが出来ます。
これは皆さんにとって納得感のある措置だと思っております。
措置の実施時の数値基準は？というお問い合わせもありますが、文中でお書きしたとおり数値基準を明示することは出来ません。
何故なら、当該サーバーの収容アカウントの状況はそれぞれ異なり、アクセス集中の度合いもサーバー毎、日ごとに違うからです。
同一の数値を基準にしたのでは、停止措置を取るほどではないのに停止してしまったり、逆に停止措置を取るべきなのに停止基準に至らずサーバーダウンなんて本末転倒を招きます。
ご自身のショップが停止措置に該当する様な状況なのか？とご心配になるかも知れませんが、過去にアカウントの停止まで必要な状況に至ったケースはほんの数ショップさんだけです。
都度個別にご連絡を差し上げてご相談しておりますから、該当するショップさんはお分かりのはず。
それ以外の普通のショップさんにはまず無関係なお話しですからご安心下さい。
繰り返しますが、当社が目指すべきは「どんなに大きなアクセスがあっても捌けるサーバーインフラ環境のご提供」であることに変わりはありません。
ですので今回導入した一時停止措置を取らずに済む事が望ましいという認識を持っていることはご理解下さい。
あくまでキャパオーバーした場合の緊急避難措置ですから。
少し技術的な側面からも補足しておきますと、アカウントを最初に取得頂いた登録ユーザーさんは、まず”初期収容サーバーセット”に格納されます。
おちゃのこネットのトップページ上部からログインしている方は、この状態です。
この初期収容セットは、複数のサーバー群から構成されており、
・アカウント管理サーバー
・Webサーバー/キャッシュサーバー × n台
・DBサーバー × n台
・NFSサーバー
・バックアップサーバー
・POP/SMTPサーバー
という構成です。
お試し期間終了後の本契約を済ませて、それなりにアクセスが稼働しだすと”本サーバー”に収容替えをします。
収容替えのご連絡を差し上げて、管理画面へのログインURLが「https://admini**.ocnk.net/admin/」となっていれば、それが本サーバーに収容されている状態です。
この本サーバーは、現時点ではスタンドアロン型で運用しています。
上記のクラスター型サーバー構成は耐障害性が高く高負荷に耐えられるのですが、反面運用が複雑で全体として同一の挙動を示すためにリスク分散の観点からは望ましくありません。
ですので、サーバー環境を個別に切り離し、単一の環境変化が他への影響を及ぼしにくい様にそれぞれが単独で存在する構成を取っております。
ただ、シンプルな環境を目指してスタンドアロン型にしたが故に、突発的なアクセスキャパが発生したときの負荷耐性はあまり高くありません。
これを今後少し負荷の高いショップさん様に構成変更し、スケール感を出せる組み合わせも導入していこうとスタッフと相談中です。
実際問題として、こちらのサーバー管理業務も増えてきており、人手が足りないので追加で管理者の募集も行っているところです。
これもお陰様で順調にご利用者が増え、皆さんのご商売も成長している証ですので、嬉しい悲鳴というところなのですが。
私も随分悩みまして、費用的に出来る範囲の限界があるんじゃないかとか、海外のサーバーは量的制限(HDD容量・月間転送量)を加えているところが殆どなのにウチは商品アイテム数だけの制限で本当にやっていけるのかとか、高負荷タイプの料金コースを新設すべきかなど、色々考えました。
でもせっかくここまでウチのやり方をご信頼頂いてこれだけ多くのショップさんがご利用頂いているのだし、ウチの経営的にもちゃんと黒字になっていることなので、従来のビジネスモデルを変更せずに可能な限りスケールさせていこうと思っています。
ただ安いだけのサービス、そんな事はお客さんもウチも望んでいないのですから。
投稿者 岡野 幹生 日時
こちらの記事に刺激を受けたのが先週のこと。
ずっと引っ掛かっていた事に答えが見つかった気がして、早速取り入れてみることにしました。
引っ掛かっていた事とは、
・ウチが残業代をみなしの年俸込みとしていて、実質サービス残業になってしまっている事
・生産性のアップに繋がる仕組みがなく、”緩い”空気が社内に蔓延していること
です。
恐らくどこのIT企業もそうですが、残業の評価というのは難しく、「好きこそものの上手なれ」でプログラムすることを好きな人の集団なら長時間プログラミングに携わっていても苦痛ではないだろう、という考え方があります。
また、そうであって欲しい、積極的に新しい技術トレンドに取り組んでいるギークの集団であって欲しい、という思いもあります。
実際はよほど求心力のあるギーク社長が率いる企業でない限り、そんな人材がゴロゴロいる会社というのは少ないのですが…。
片や、受託開発をしていない当社のような企業は、社員のスケジュール意識とモチベーションを高く保つことに苦慮する事が多いのです。
顧客からのプレッシャーが無いのは良いことなのですが、それが現場の弛緩に繋がってしまうジレンマも抱えます。
開発プロジェクトにスケジュール管理を強化する方向で臨むと、結果的に残業を強制する圧力が掛かってしまい、それも経営者としては心地悪い話だったりするのです。
で、上記のDan Kogaiの書評にある
本書を読んでみて、
残業はしないが、仕事には必ずデッドラインを設け、厳守させる。これによりホワイトカラーの生産性をアップさせる。
という点にいたく共感した次第なのです。
残業をせずに、業務時間内の労働だけに限定し、なおかつ仕事のデッドラインは守らせる。
これなら、思う存分業務時間内の生産性を上げるプレッシャをスタッフに掛けることが出来ます。
結果的に、仕事の効率と自分の人生の時間の充実が両立すれば、こんなにHappyな事はないでしょう。
恐らく、日本のIT企業で残業ゼロを公式に謳っている企業はどこにもないはず。
これは相当先進的で意欲的な取り組みだと思います。
だから、今日ここで当社は「
残業ゼロ」を公式に宣言することにしたのです。
長時間労働が当たり前になっているソフトウェア業界で、この取り組みが成功するかどうか、新たなチャレンジと言えるでしょう。
