矩形選択って、たまに使うけど、やり方をすぐに忘れちゃうことってありますよね。
だから、ここにメモしておきます。
OSはWindowsで、エディタはVisual Studio Codeです。
Ctrl + Shift + Alt + 矢印
Shift + Alt + マウス操作
ちなみに、矩形選択を初めて知ったとき、"くけいせんたく"って読めました？
最初は正式名称を知らなかったので、操作方法を検索するのに苦労した記憶があります。
最後まで読んでいただき、ありがとうございました。
参考になったと思ったら、クリックお願いします。
先日、Grafanaを使用してサーバーの稼働状況を監視する方法についての記事を書きました。
今回は、Grafanaから「DBサーバーの使用容量が閾値を超えたよ」と通知が届いたので、使用容量を確認する方法について書きたいと思います。
DBはPostgreSQLで、SQLを使用して確認する場合です。
使用容量の確認
SELECT
datname,
pg_size_pretty(pg_database_size(datname))
FROM
pg_database;
補足すると
pg_database_size：指定されたデータベース名の使用容量を取得する
pg_size_pretty：サイズの単位を付けた読みやすい形式に変換する
ことをしています
これでデータベースごとの使用容量を取得できます。
pg_databaseなどの管理用テーブルからは様々な情報を取得できるので、他にも参考になりそうなSQLがあれば紹介していきたいと思います。
突然ですが、自分たちで管理しているサーバーの稼働状況を把握していますか？
利用者からの問い合わせで「〇〇システムが使えないです！」や「なんか操作が遅いです！」などといった問い合わせがあると、焦りますよね。
しかし、良くないことほど自分たちで把握して対応したいものです。
弊社でも昔は利用者からの問い合わせで、サーバーのダウンや高負荷に気付くことがありました。
そこで、どうしたか？
現在では、サーバーの稼働状況を可視化してくれるオープンソースのGrafanaを導入しています。
Grafanaを使えば、自分だけのダッシュボードを作成して、サーバーの稼働状況を可視化できます。
さらに、以下のようなこともできます。
・サーバーとの疎通が取れなくなったらアラートを出す
・CPU使用率が80%以上になったらアラートを出す
・空き容量が20%以下になったらアラートを出す
これらの設定により、利用者からの問い合わせの前に問題に気付くことができます。
ダッシュボードでサーバーの稼働状況を見ることができるため、状況を把握しやすくなり、閾値を超えそうな場合は事前に対応することもできます。
サーバーの稼働状況を把握して、問題を未然に防いだり、予測できない問題にもすぐに対応することができるようになりました。
Grafana以外にも類似のサービスがあるので、自分たちに合ったサービスの導入を検討してみてはいかがでしょうか？
ちょっと前から花粉症の症状がひどくなり、鼻をかみすぎて真っ赤なお鼻のトナカイさん状態になりました。
いそいで鼻にやさしいティッシュを買いに薬局へ走り、ようやく元通りの鼻に戻りました。
ティッシュと言えば、使い終わった空箱はどうしていますか？
捨てる？いやいや、もったいないですよね。
私はティッシュの空箱を使って、ノートパソコンを置く台を作っています。
6個ぐらいの空箱をくっつけて自分好みの高さに調整しています。
お金がかからない
自分の好きな高さや幅に調整できる（ただし、空箱の大きさによる）
空箱が軽いのでよく動く。いくつかの空箱を重ねると、よくずれます。
そんな時はテープで空箱同士をくっつけましょう。
別にお金がないから空箱を使っている訳ではないですよ。
社内研修で「問い合わせを減らす取り組みとしてヘルプサイトの運用」をプレゼンしたところ、好評を得ることができました。
ちょうどその頃、就業規則や社内マニュアルを整理しており、今よりも有効活用してもらうための手段として、ヘルプサイトの形式（FAQのイメージの方が近いかも）で公開すれば利用頻度が上がり、口頭での説明や知っている人に聞かないと分からないような属人化の課題が解決できるかもしれないという期待から、ヘルプサイトを作ることになりました。
ヘルプサイトを作成・公開するための一般的なWEBサービスを利用するのではなく、以下の技術を用いて社内向けのヘルプサイトを作成・公開しました。
SSG（Static Site Generator：静的サイトを生成するソフトウェア）のフレームワークであるHUGO（ヒューゴ）を使用しました。
HUGOの魅力は、ヘルプサイトに最適なテンプレートが用意されており、WEBサイトを迅速に公開できる点です。
ヘルプサイトの作成から公開までの手順は以下の通りです。
1. HUGOのプロジェクトを作成する
2. ヘルプサイトのテンプレートを選択する
3. 記事を作成する（Markdown形式で作成する）
4. 静的ファイルを生成する（HUGOがMarkdown形式の記事から自動生成する）
5. 生成されたファイルをWEBサーバーに配置する
上司「このヘルプサイトは使いづらいからやめよう」
自分「えっ！？」
プレゼンで好評を得ていたので自信があったこと、ヘルプサイトも公開して後は記事をどんどん書いていこうという段階での出来事でした。
上司「就業規則や社内マニュアルを整理している過渡期で更新頻度が多いけど、更新するたびにMarkdown形式の記事を編集して、静的ファイルを作って、WEBサーバーに配置して・・・って手間だよね」
自分「確かに！」
はい、運用部分の考慮が足りていませんでした。
外部公開するBtoBやBtoCのサービスであれば、HUGOのようなフレームワークを使用してヘルプサイトを公開する選択肢もあると思います。
ただ、今回のケースは零細企業の社内用の就業規則や社内マニュアルを見てもらうための取り組みです。
各種ドキュメントはMicrosoft 365のWordで作成されているので、比較的検索もしやすく、ヘルプサイトで公開するメリットがありませんでした。
今回の反省点は「目的と手段を混同しない」です。
途中からヘルプサイトを作ることが目的になっていたような感じがします。
本来の目的は「就業規則や社内マニュアルを有効活用して、口頭での説明や知っている人に聞かないと分からないような属人化をなくす」ことでしたが、途中からサイト構築に意識が向きすぎて、目的を達成できるか？という視点が抜けていました。
なんでもやってみないと分からないのでやってみることは良いのですが、零細企業の我々は無駄なことをしている余裕がありません。
これからは【目的】を忘れずに新しいことにチャレンジしていきたいと思います。
最後まで読んでいただきありがとうございました。
弊社は20人程度の規模の零細企業ですが、従来のオープンソースのタイムカードから脱却し、クラウドサービスの勤怠管理を導入することになりました。
この導入の理由は、オープンソースのタイムカードで登録した勤怠実績を給与計算用に出力する際、そのままでは利用できず、勤務形態ごとに異なる勤務時間のチェックや、半休や代休取得時の勤務時間が正しく計算されているかを目視でチェックし、間違いがあれば手作業で修正する必要があったためです。
少数の従業員であっても、20人分の勤怠実績をチェックし、修正するための人件費は決して安くはありません。さらに、人間が行う作業であるため、チェック漏れや修正ミスが発生しやすいという課題もありました。
このような手間を省くため、タイムカードのクラウド化を検討し始めました。
導入するにしても、何を基準に選定すれば良いのでしょうか？
キーワード「クラウド 勤怠」で検索すると、たくさんのサービスが見つかります。
弊社では次のふたつの基準で選定を行いました。
ひとつ目は課題を解決できること。
ふたつ目はコストを抑えること。
課題を解決できることはもちろんですが、零細企業の弊社には月数千円かかるサービスを使うことが難しく、なるべく初期コスト、ランニングコストを抑える必要がありました。
そこで見つけたのが「HRMOS勤怠」でした。
HRMOS勤怠では、自由に勤務区分（出勤、有給休暇などの勤務状況）を登録することができます。
この機能を利用して、弊社の勤務形態に合わせた勤務区分を作成し、課題を解決することができました。
勤務区分は、任意の勤務時間や休憩時間を登録することができます。
例えば、8時から勤務開始する社員と9時から勤務開始する社員がいる場合、「出勤（8時）」、「出勤（9時）」のように勤務形態に合った勤務区分を作成しておきます。
あとは適切な勤務区分を選択して打刻すれば、勤務区分に設定された勤務時間に則って計算されます。
以前のオープンソースのタイムカードでは、弊社の勤務形態に合った設定をすることができなかったため、一律で9時からの勤務開始で実績が計算され、8時から勤務開始する社員は別途計算して辻褄を合わせる必要がありました。
しかし、今ではその作業が無くなりました。半休や代休取得時の勤務時間も同様に勤務区分で対応することができました。
初期コストがかからず、ランニングコストも、1ユーザー当たり100円で利用可能なので、コストを抑えることができます。
詳細は HRMOS勤怠のサイト を確認してください。
弊社の勤務形態に合った打刻ができるようになり、勤務区分の登録が間違っていないかのチェックだけで済むようになりました。
従業員ごとに勤務時間まで確認し、間違いがあれば修正を行っていた時と比べて、作業時間が大幅に削減されました。
また、勤務時間を手計算で修正する必要がなくなり、精神的負荷も減少しました。
しかし、「HRMOS勤怠」からダウンロードした実績をそのまま使用できず、一手間かかっている部分がまだあります。この点は今後の課題ですね。
様々なクラウドサービスから自社に適したものを選ぶのは簡単なことではありません。
インターネットで検索して表示されたサービスから選択しようとして、決められなかった経験はありませんか？
そんな時は、まず解決したい課題を明確にすることをおすすめします。
弊社の場合は、解決したい課題が明確にあり、その課題を解決できるかが選定の基準になりました。
選定基準があれば、どのサービスを選べば良いか判断することができます。
会社の規模や業種が異なれば、最適なクラウドサービスも異なります。
皆様の会社で導入する際のヒントになれば幸いです。
