って思いますか…?
投稿タイミングを確認してみる
例えば入学式について説明した記事は入学式の前日公開でした。
例えば履修登録について説明した記事は履修ガイダンスが行われた2日後の公開でした。
もっと早く公開されていればもっと参考にできたかもですね。
これには戦略的側面と、現実的側面があるのです…。
戦略的側面
突然ですが、2000年問題とか元号問題ってご存知ですか?
どちらも「システムエンジニアとかプログラマーが死ぬぞ」って感じの問題なのですが。
例えば元号問題。ついこの前新元号「令和」が発表されましたね。
これまで元号として平成を表示するようにしていたシステムやプログラムは5月以降令和と表示されるようにしなければいけません。
その改修のために忙しい~って感じの問題です。
2000年問題は、例えば西暦下2桁を年として扱ってるシステムがあったとします。
1900年を00年、1998年を98年、1999年を99年って感じですね。では2000年はどう表されるでしょうか?00年ですね。
1900年と2000年で表し方が被ってしまいます。
それによるエラーが起こらないように修正するの忙しい~って感じの問題です。
さて2000年問題、「大して大きな騒ぎにならなくて良かったね~」という評価がされることがあるようです。
ただ大きな問題が起こらなかったのはシステムを直す人たちが騒ぎにならないように事前に頑張っていたからです。にも関わらず「2000年問題は大した問題じゃなかった」と認識されることを憤ってる人もいるようです。
前置きが長くなりました。
つまり事前に先回りして問題を解決しても、それが当然になってしまって評価されないのでは…?と考えるわけです。
事前に大きな問題が起こらないようにしていたエンジニアは低く評価された。でも大きな問題が起こった後でパパっと解決したら救世主なのでは…?
と、意図的に投稿タイミングを遅める戦略を取ってる面があります。
新入生同士で「どうしたら良いんだ…?めちゃくちゃ不安だ…」となってるとこに投稿するわけです。
これが事前に先回りして投稿していたらその情報が得られるのが当たり前で、「記事によって問題が解決された」ことすら認識されないのでは?という懸念です。
現実的側面
戦略的側面などと書いてみましたが、若干後付けだったりします。
いや、確かにそう考えてる部分もあるのですけど…。
実際問題、大きな要因はこっちです。
手が回ってない。
手が回ってないです。そもそも投稿タイミングをずらしたいだけなら記事を書くこと自体は前々から済ませておいて、あとは投稿するだけーという状態にしといた方が良いでしょう。
しかし現実としては、書いたらすぐに投稿しています。
どの時期にどんな内容が求められるのかはある程度分かってはいるのですが、先回りしてストックしておける程の余裕がありません。
なのでTwitterで話題になってるのを見てから「あぁ…書かなきゃ…」となってから書くことがほとんどです。
なので
当サイト「新大情報どっとこむ」で記事書いてもらえないですか…?
という募集でした。
誰か…助けてください…。
寄稿について詳しくは下記記事を参照してください。
コメント