こんにちは
システムチーム プログラマー / マネージャー のAです。
前回の続きで、タスク遂行中の精神面の話しです。
どの業務でも生かせる知見があるので、
参考に出来るよう、書きます。
「成功」の定義が無い
前回の記事で
– サーバー増強というタスク自体に、
– 「どうなればOK」という正解はありませんでした。
と書いたとおり、
サーバー増強タスクの
「正解」や「成功」という概念は、曖昧でした。
機能追加や不具合修正ではないので、
目に見えて、何も変わらない。
だけど、「正解」「成功」と全員が評価できる内容でなくてはいけない。
悩みました。
具体的に話します。
サーバー増強というからには、何か速くなる気がする
本タスクは「サーバー増強」と命名しました。
その言葉から、何かが高速になるイメージを持つのは自然だと思います。
じゃあ、そのイメージを形にすれば正解と定義できる。
では。
デキテルを「速く」しなければいけないとして、
そこで問題になるのが「速いって何？」という話です。
「速い」なんて概念は存在しない
一般的に
「このサイトは速いから良い」と思いながら、
サイトを見る事はありません。
「このサイト“遅いな”」と感じても
「このサイト“速いね”」と感じる事は無いです。
じゃあ
「遅い」の反対は何なのか。
今、デキテルが「遅い」としたら、どういう状態になればいいのか？
・・・
自分が辿り着いた結論は
「何も感じない状態」
でした。
厳密にいうと、
「デキテルと、一般的なウェブサイトを比較した時、速度に関して何も感じない状態」です。
これが現時点での、正解であり、成功だと思います。
デキテルのスピードは、ウェブサイトと比較されている
デキテルはコンセプト的に
「（編集デキる）ウェブサイト」と認識されているように思います。
直感性にこだわって作られた、
ほとんどウェブサイトなUI。
だから、
表示スピードの比較対象は、
「システム」ではなく「ウェブサイト」です。
もしデキテルが
仰々しい、フォームだらけのシステムだったとしたら、
ウェブサイトより遅かったとしても
「システムだから仕方ないね」
で済んでます。
Google Document も、デキテルも、ブラウザを通すウェブアプリです。
Google Document は「ウェブサイト」として認識されない。
もっさりしてるけど、許されてる。自分も許してる。
でも、デキテルは「ウェブサイト」として認識される。
「システムとしては遅くない」のに、
「ウェブサイトとして遅い」と感じてしまう。
中身は複雑な論理で成り立っているのに、
外見は静的なウェブサイトと大して変わらない。
これはややこしい問題です。
しかも、もう1つデリケートな問題があります。
ウェブサイトを見ても、人は「速い」と感じない
デキテルに関して、
どれだけ狂気的な高速化をしても、
一般的に「速い」と評価を受けることはないと思います。
それは先ほども言った通り、
「ウェブサイト」を見て「速い」と感じることは無いからです。
デキテルはウェブサイトとして認識されているので、同じこと。
システムに理解のある方には
「（裏側が複雑な割に）速いね」と評価していただけますが、
一般には、難しいと思います。
だから、
最低限、
周囲のエンジニアだけでも、
速度に関して自分の考えを持つべきです。
幼稚でも良いので、
何か考えを持ち、
自分なりに評価できる人間であるべきです。
と、正直思っています。
でも、それが難しい事も分かっています。
これだけ長々と話せるのは、
自分がチューニングを生業にしてきたからです。
だから、
今後、このような仕事は極力発生しないように、
目に見える、分かりやすいタスクに専念できるように、
負債を全て完済してやろうと思いました。
カッコいい事言ってる風なんですけど
正直、「逃げ」です。
チューニング系のタスクを部下にやらせてみて、
良い形で完了を迎える自信があれば、
別の発想に至っています。
失敗の定義は超明確
しかも、
もっとストレスを感じる問題がもう1つあります。
失敗の定義が超明確であることです。
例えば
・DNSの更新に失敗。編集画面に繋がらなくなる。
・プロセスの制御に失敗。以前より遅くなる。
・編集機能が一時的に破綻する。
・コンバージョン処理にエラーが発生する。
・無料トライアルアカウント発行処理にエラーが発生する。
・テーブルデータがロストする
すべて「大失敗」の一例です。
どれも発生する可能性は十分にありましたが、
絶対に回避する必要がありました。
このプレッシャーを、
何も考えずに受け止めたらパンクします。
だから、自分のメンタルに少し工夫をしました。
アウトプット量とキャパシティをブーストした
※※ココからは非エンジニアの方でも参考に出来ると思います※※
本タスクに取り組むにあたって、
パンクすることは予め分かっていました。
難解なリリース工程を組み替えている最中に
部下のマネジメントや、
別件の決断を下すことは、ストレスフルだと想像していました。
そこで、
リリースまでの2週間だけですが、
意識的に、自分のアウトプット量をブーストしました。
具体的には、
常に仕様のことを考え続け、
考えるのに疲れたら情報をINPUT。
他の何かをするときは、仕事の休憩と割り切る。
ココまでやれば、勝手にアウトプット量は増えます。
アウトプット量が増えれば、予定は前倒しになる。
予定が前倒しになれば、部下に時間を割ける。
結果的に、アウトプット量とキャパシティがブーストされるわけです。
力技ですが、再現は可能です。
期間を決めることが前提ですが、
立派なテクニックだと思います。
以上が、タスクに当たっての精神面の話でした。
次の記事で、まとめに入ります。
次→https://syde.jp/w/archives/11555.html
