皆様、こんにちは。グリニッジのサウナーことコサカです。最近すっかり暖かくなりましたね。

今回の投稿では、昨年から始まった新規プロジェクトで、サポート担当としてジョインした際の経験談を少し書かせていただきます。
私の準備不足もあり、いろいろ苦労した部分もありましたので、反省も踏まえ、自分の対応したことや改善点などについて記載したいと思います！

新規プロジェクトで対応したこと

・FAQやマニュアルの作成
・社内マニュアルの作成
（ざっと数えてみましたが、マニュアルだけで20～30件近く作ってましたw）
・社内対応フローの構築（POに手伝っていただきながら、対応しました）
・顧客への導入サポート、問い合わせ対応
・メールのフォルダ作成、振り分け設定
・進捗表の作成、管理
・パートナー企業との打ち合わせ（新規プロジェクトの後半から）
・ウェビナーの登壇
...etc

箇条書きで書いてみましたが、普段のサポート業務に追加で上記を対応しておりました。

工夫したこと

ゼロベースでマニュアルを作るとなると、かなり時間と工数がかかってしまうため、マニュアルのサンプルなどを周囲の協力を得ながら情報収集することから始めました。

結果として、ゼロからマニュアル作成する場合に比べて、半分くらいの時間でマニュアル作成することができたかと思います。

また、プロジェクトのテーマとしても「LINE」を活用したものになるため、専門用語や操作画面などが初見の方にも伝わりやすいよう意識してマニュアル作成を行いました。

反省点

新規プロジェクトの開発スケジュールは共有されており、私のタスクとして対応すべきことは概ね明確になっていましたが、計画的にタスクをこなすことができず、機能のリリース直前で慌てて作業する場面もありました。

メモ帳に書き出す、マインドマップやRedmineを使うなど、タスク管理するための手段はあるのにそれを怠ってしまったことが、一番の反省点ですね。

機能が正式リリースされてからは、顧客サポートに時間を割くことが増えるため、リリース前に進めておけばよかったと思うタスクが多々あり、後悔しております...。

まとめ

POやプロジェクトメンバーのおかげもあって、無事リリースできましたが、それに至るまでの道のりで反省点も多く見られましたので、これらの反省を踏まえ、自分が楽するためにも、納期に向けた自身の対応スケジュールを組み立てて、計画的に業務するよう心がけたいと思います。

最後になりましたが、私が担当してたプロジェクトについて紹介している記事がありますので、ぜひ覗いてみてください！！

ビジネスにおいてもプライベートにおいても、人間関係は切っても切り離せないものですよね。
伝えたいことはあるけれど、嫌な感じで伝わったら嫌だな、もっと言葉選びが上手になりたいと思い、読んだ本についてご紹介させていただければと思います。

お願いするときは「否定形」ではなく「肯定形」で

✕よけいなひと言：「それはしないでください」
◎好かれるひと言：「それはこうしてください」

何気なくオフィスのドアを閉めたときに、「あ、ドアを閉めないでください」と指示されるのと、「ドアを開けておいていただけますか」とお願いされるのとでは、どちらが気分的によいでしょうか。
どちらも「ドアを開けた状態にしておいてほしい」との要望なのですが、前者が「○○しないで」という否定形であるのに対し、後者は「○○して」という肯定形による言い方で、印象は大きく変わります。
これは日常のさまざまな場面にも通じることですが、人は「否定形で指示される」よりも「肯定形で依頼される」ほうが、受け止めやすくなります。
「よけいなひと言を好かれるセリフに変える言いかえ図鑑」より

お願いするときだけでなく、指示するときにも同様のことが言えると思います。
でもつい「それは△△ではなくて○○してほしかった」と思った際、
「〇〇をしてほしい」という感情より、「△△しないでほしい」という感情の方が大きくなりがちなので、自分自身を振り返ってみるともしかしたら否定形で指示してしまっていたかもしれないと思いました。否定形が浮かんできてもグッとこらえて頭の中で「○○をしてほしい」と肯定形で伝えられるよう意識していきたいです。

「あなたは知らないはず」と見下している態度が見え見え

✕よけいなひと言：「ご存じないと思いますが」
◎好かれるひと言：「ご存じかもしれませんが」

ちょっとした内緒話の時などに「ご存じないと思いますが、こんな話があるんですよ」「知らないと思いますが、あの件はこういうことなんですよ」と、よけいなひと言をつけて話し始めたことがある人もいるかもしれません。言った本人に悪気がなくても、「まだ知られてない話を教えてあげる」という特別感を伝えたい、というニュアンスで使うこともあるかもしれません。しかし、これは「これから話すことはあなたは知らないこと。でも私は情報通だから知っている」という態度が見え見えで、相手を上から目線で見下している、失礼な言葉なのです。ですから、仮に相手が100パーセント知らない話でも「知らないですよね？」と強調するのではなく、「ご存じかもしれませんが」と相手を立てて言うほうがいいのです。
「よけいなひと言を好かれるセリフに変える言いかえ図鑑」より

「あなたは知らないと思うけど」という相手のことを見下した前提の心の内が透けて見えるとたしかにムッとするかもしれないと感じました。反対に、「あなたならもう知ってるかもしれないけど」と立てられた言い方であれば、素直に「知らないから教えてほしい」と言いやすいので、その後の会話やコミュニケーションがスムーズに進むと思いました。

謙遜しすぎないほうが好感度大！自虐や卑下は逆効果

✕よけいなひと言：「そんなことないですよ」
◎好かれるひと言：「ありがとうございます」

日本には謙遜を美徳とする文化があるため、人からほめられてもすぐに、「そんなことないですよ」「全然ですよ」と謙遜する人が少なくありません。しかし、謙遜も度を越えると、せっかくほめてくれた相手の気分を害してイラッとさせたり、気を遣わせてしまうことがあります。
たとえば、「大変な仕事をよく頑張ったね」とほめた部下から、「ありがとうございます。先輩のおかげです」と言われるのと、「まだまだ全然ダメですよ」と言われるのとでは、印象がまったく異なりますよね。後者のように謙遜するのは相手の好意を否定する行為ですし、自虐的に自分を貶めるのは、もっと自分を認めてほしい気持ちの表れでもあるからです。
「よけいなひと言を好かれるセリフに変える言いかえ図鑑」より

せっかく褒めたのに謙遜されすぎると気まずい雰囲気になってしまったり、ネガティブな雰囲気になってしまう時ってありますよね。きっと褒めた方は良い雰囲気になるかと思って言ったのに、予想外にネガティブな雰囲気になってしまったら、褒めてくれた方に申し訳ないですよね。謙遜もほどほどにして、素直に「ありがとうございます」と伝えた方が、褒めてくれた方も褒められた方も良い気持ちになれそうだと思いました。

まとめ

全てに共通して言えるのは、ネガティブ発言は相手にもネガティブな感情を与えてしまい、ポジティブ発言は相手のこともポジティブにさせるので、好印象になるのだと思いました。
やはり、話していてポジティブな気持ちにさせてくれる人と話しているとこちらも明るい気持ちになるので、ポジティブな言い方で伝えることをもっと意識していきたいと思いました。

はじめまして。
この度、開発職として中途採用で入社しました橋本と申します。

前職では、監査法人で監査業務に従事しており、今回は未経験ではありますがこの業界にチャレンジすることにしました。

「アレやっておけばよかったなぁ」という後悔をしないように生きたいと思っているので、今回も思い切って転職しました！
毎日分からないことに遭遇し、勉強しなければいけないことが山積みですが、とても充実しています。

ご縁があってグリニッジに入社することになったのですが、先輩方は面白く優しい方ばかりで、また自分の強運を発揮したなと思っています。

趣味は社会人になってから始めたゴルフで、現在住んでいる場所は打ちっぱなしが近いからという理由で決めているくらいゴルフにハマっています！

まだまだ分からないことだらけではありますが、自分がエンジニアとしてどれだけ成長できるかとてもワクワクしています！
グリニッジに貢献していけるよう日々精進して参りますので、どうぞよろしくお願いいたします。

こんにちは、窪田です。

最近話題になっているコードエディタ「Cursor」をご存じでしょうか。

CursorはAIを搭載している革新的なエディタで、開発作業の効率が飛躍的に向上すると評判です。

どれくらい便利なのか気になったので、プライベートで少し使ってみたところ、確かに非常に便利だと感じました。

今回は次世代エディタのCursorの使い方を簡単に紹介したいと思います。

Cursorのインストール方法

公式サイト：https://www.cursor.com/

まずは上記の公式サイトからインストーラーをダウンロードします。

インストーラーを起動し、次へを選択していくと以下の画面が表示されます。

Keyboard欄ではキーバインドを設定します。Default(VS Code)を選択していますが、他にはVim、Jetbrains、Emacs、Sublime、Atomなど一般的なエディタが選択できます。

Language for AI欄はエディタに搭載されているAI機能が使用する言語設定なので、日本語を選択しています。

Codebase-wide欄はコードベース全体に関する質問をするための設定です。

Enabledになっているので、コードベース全体の質問機能が利用できることを示しています。

Add to Command Line欄はコマンドラインからエディタを起動するための設定です。

ここは特に変更しなくて良いので、Continueボタンをクリックします。

次は以下の画面が表示されます。

Use Extensionsボタンをクリックすると、VS Codeの拡張機能、設定、キーバインディングをインポートできます。

続いて以下の画面が表示されます。

ここはデータ収集に関する設定です。

データを収集を許可してエディタの改善に協力するか、データを提供せず自身のプライバシーを優先するかを選択できます。

基本的にはPrivacy Modeを選べば問題ないと思います。

次の画面でログインを求められるので、会員登録を済ませてログインします。

Cursorの使い方

まずはCursorの日本語化を行いましょう。

上部メニューのView > Command Paletteをクリック > Configure Display Languageと入力し、日本語を選択してCursorを再起動します。

AIによるコードの作成・編集

Cursorの基本的な設定は完了したので、プログラムを書いてみましょう。

例えば『フシギダネ、ヒトカゲ、ゼニガメの中から一匹をランダムで選ぶ想定で、選んだケースにより「○○、きみにきめた！」と表示させるプログラムを作成したい』という要望があったとします。

作成したファイルをCursorで開いた状態で「Ctrl + K」を押すとAIによるコード生成ができます。

入力欄が表示されるので、作成したいコードの内容を入力します。

Generateボタンをクリックすると、コードが生成されるので内容に問題が無ければAcceptボタンをクリックします。

指示した内容のプログラムが作成できましたね。

作成されたコードを範囲選択して「Ctrl + K」を押すと、コードに対して編集の指示ができます。Acceptボタンをクリックすると、AIが提案してくれた編集内容がコードに反映されます。

編集後のコードを実行すると、ピカチュウの場合だけ表示が変わるようになっていますね。

AIとのチャット

Cursorを開いた状態で「Ctrl + L」を押すとAIとチャットができます。

コードの解説と実行結果は同じで異なる書き方のコードについて聞いてみました。

紹介した機能の他にも、フォルダやファイルなどを参照したうえでAIとチャットを行うことができたりと、便利な機能があるようです。詳しくはこちらの公式ドキュメントを確認してみてください。

まとめ

今回はAIが搭載されているエディタのCursorというソフトを紹介してみました。

エディタから手軽にAIを活用できるのは、やはり便利ですね。

VS Codeを参考にして開発されているようなので、見た目もVS Codeに似ていて使いやすい印象でした。

Cursorが気になった方は、ぜひ試してみてください。

突然ですが

Babyには適切な室温というものがあります。

我が家では、いたるところに温度計をおいて室温をチェック・調整しています。

冬場には睡眠時に暖房と加湿器を使います。

暖房を忘れることはないのですが、加湿器には水を足すのを忘れたりします。

毎日Babyを寝室に連れていき、その後大人は別の場所で過ごし、ちょこちょこと寝室に置いてある温度計を見に腰を上げ、温度と湿度をチェックしに行ってました。

主に、この見に行く手間を省略したいのと、湿度の対策をしたくてラズパイを使ってみました。

冬の適切な温度と湿度

ちなみに適切な温度と湿度は以下の値とされています。

・室温: 20℃ ~ 23℃

・湿度: 40% ~ 60%

用意したもの

• RaspberryPi zero 2W
  • https://www.amazon.co.jp/dp/B09N8LMWLS?ref=ppx_pop_mob_ap_share
  • https://www.amazon.co.jp/dp/B094XX899V?ref=ppx_pop_mob_ap_share
• 温湿度センサーモジュール
  • https://www.amazon.co.jp/dp/B010GXAH4E?ref=ppx_pop_mob_ap_share
• 小物入れボックス
  • https://jp.daisonet.com/products/4550480216522

できあがったもの

子どもがいたずらするのでダイソーの小物入れの中に本体とセンサを入れて稼働させています。

小物入れの中に熱気がこもらないように通気性を上げるため、はんだごてで穴をあけたので少しプラスチックがドロりんちょしています。固まっているので問題はないです。バリのような細かくとがった部分はやすりで削ってあげて子どもがケガをしないようにします。

これを使ってなにをしているか

• センサを使った温度と湿度の測定
• slackへの通知

何を通知しているか

• 現在の温度と湿度
• 子どもが寝る前の加湿器への水足しリマインド
• 多分加湿器の水切れているよ
• 換気忘れてるよ

このうち加湿器への水足しリマインドは毎日19:30に通知する設定でslackのリマインダー機能を使用しており、それ以外の3つをラズパイから通知しています。

現在の温度と湿度

15分に1回その時の温度と湿度をslackで通知しています。

多分加湿器の水切れているよ

1時間の中で継続的に合計5%湿度が下がった場合に通知しています。

換気忘れてるよ

しっかり湿度をキープするということはカビとも戦わなくてはなりません。

我が家は寝室が北側にあるので、特に気を付けないとすぐカビが生えてしまいます。

なので寝ているとき以外は極力換気するようにしています。

それを忘れないように日中の計測時には、3回連続で40%を上回る場合に通知を出し続けます。

使ってみて

わざわざ温度と湿度を見に行かなくてもよくなったので、いくらか気が楽になりました。

ただ、寝顔を見たくなるので結局何回も寝室を訪問します。

今後の展望

今後、スマートスピーカなどを利用するようなことがあればslack通知とともにそちらを操作するようにしてみたいですね！

そもそも

多分温度も湿度も表示されるベビーモニターがありそうな気がします。

我が家ではそこまで考えずに買ったベビーモニターで温度しかわからないし、温度が上がりすぎても下がりすぎてもお知らせしてくれるわけではないのと、ちょっと久しぶりにラズパイを触りたくなったので工作してみました。

以上

Webアプリケーションを作っていて「あれ、9時間前の時刻なんだけど・・・」みたいなことありませんか？
私はよくあります、というかよく見かけて修正します・・・

なぜ起きるのか？

JST時刻だと思って表示したらUTC時刻でした！というだけなのですが・・・これ、意識しないとなかなか面倒なんですよね。

例えば、基本的にプログラム上で明示的にタイムゾーンの指定をしていない場合には以下のように動作します。

この時に

であれば、Web画面のカレンダーの日付と時刻とかtimePickerなんかの時刻もそのままサーバーに渡して、サーバー側でそのままnew Date(<渡された日時>)なんてしても問題は起きません。
（暗黙のうちにタイムゾーン同じなので）

これが以下の場合はどうでしょう？

Web画面では日本時間だと思って「2025/3/11 12:00」と入力したとします。

サーバー側で「2025/3/11 12:00」という文字列を受け取って

const date = new Date("2025/3/11 12:00");

とします。

さて、このdateの中身はどうなっているでしょうか？

日本時間の「2025/3/11 12:00」になっていると期待しますが、UTC時刻の「2025/3/11 12:00」となってしまいます。

つまりdateの中身は「2025-03-11T12:00:00+00:00」(=2025-03-11T12:00:00Z）となっています。

このdateを日本時間に変換をすると「2025-03-11T21:00:00.000Z」(=2025-03-11T21:00:00.000+09:00）となって、日本時間の12:00として処理を始めたつもりが、内部では日本時間21:00として処理されてしまいます。

これが+9時間で日付をまたぐ場合、指定した日付がずれて違う日付のデータを処理してしまう・・・なんてことが起こって、今度は「1日ズレする！！」みたいなことが起こります。

ではどうするのか？

Web画面（クライアント側）からバックエンド（サーバー側）でデータを送信するときには、日付や時刻の文字列を入力されたそのままで渡すのではなく、日時のフォーマット（ISO 8601）にしてから送信します。

{
  "date": "2025/3/11 12:00"
}

ではなく

{
  "date": "2025-3-11T12:00:00+09:00"
}

ですね。

こうすることで、「どのタイムゾーンでの時刻表示なのか？」が情報として含まれるようになるので、クライアントとサーバーでのタイムゾーンが違っていても同じように時刻を扱えます。

サーバー返却するデータフォーマットも同様です。

些細な事ですが、これを明確に決めないでクライアントとサーバー間のデータ通信を実装すると、タイムゾーンの時刻ずれを起こして「クライアントとサーバー側、どっちで直す？？」みたいなことが発生、しかも一部はたまたま一致しててうまく動いてて、一部はずれてて・・・・結局影響範囲どこまであるんだ？？みたいな非常に厄介な問題に広がったりします（しました・・・）

時刻制御でハマる人が少しでも少なくなることを祈ります・・・

Javascriptで変数を宣言するとき、理解して var let constを使用しているつもりですが、
改めて、違いを整理したいと思います。

var let const の違いを理解する重要性

ES6（ECMAScript 2015）以前は var が主に使用されていましたが、新しい let や const が導入されたことで、より安全で予測可能なコードを書くことが可能になります。
それぞれの違いを理解し、適切に使い分ける方法を解説します。

var の特徴と問題点

var の基本的な使い方

var x = 10;
console.log(x); // 10

var のスコープ（関数スコープ）

var は 関数スコープ を持ちます。
つまり、関数の中で宣言された var はその関数の中でのみ有効です。

function example() {
  var a = 100;
  console.log(a); // 100
}
console.log(a); // ReferenceError: a is not defined

var の巻き上げ（Hoisting）とは？

var は 巻き上げ（Hoisting） により、宣言がスコープの先頭に移動されます。

console.log(b); // undefined
var b = 20;

上記のコードは内部的に以下のように処理されます。

var b;
console.log(b); // undefined
b = 20;

var の問題点

• 再宣言が可能
• ブロックスコープがない

var x = 1;
var x = 2; // エラーにならない
console.log(x); // 2

let の特徴と使い方

let の基本的な使い方

let y = 10;
console.log(y); // 10

ブロックスコープとは？

let は ブロックスコープ を持つため、 {} の中でのみ有効です。

if (true) {
  let z = 50;
  console.log(z); // 50
}
console.log(z); // ReferenceError: z is not defined

var との違い

• 再宣言不可
• ブロックスコープを持つ

let a = 1;
let a = 2; // SyntaxError: Identifier 'a' has already been declared

const の特徴と使い方

const の基本的な使い方

const PI = 3.14;
console.log(PI); // 3.14

値の再代入ができない

const num = 100;
num = 200; // TypeError: Assignment to constant variable.

const でオブジェクトや配列を使う際の注意点

const で定義したオブジェクトや配列は、プロパティの変更は可能 ですが、再代入は不可です。

const person = { name: "Alice" };
person.name = "Bob"; // OK
console.log(person.name); // Bob

person = { name: "Charlie" }; // TypeError

varとの違い

• 再宣言不可
• 再代入不可
• ブロックスコープ

const a = 1;
const a = 2; // SyntaxError: Identifier 'a' has already been declared

var let const の使い分け

どんな場面で let を使うべきか？

ループや一時的な値を管理する場合に適しています。

for (let i = 0; i < 5; i++) {
  console.log(i);
}
console.log(i); // ReferenceError

const を基本にしつつ、let を補助的に使う考え方

基本的に const を使い、必要な場合のみ let を使う ことが推奨されます。

var を使うべき場面はあるのか？

ほとんどのケースで var は不要です。
var を使用すると意図しないバグが発生しやすいため、let や const を推奨します。

比較

まとめ

• var：古い書き方。巻き上げやスコープの問題があるため非推奨。
• let：ブロックスコープを持ち、再宣言ができない。
• const：再代入が不可で、安全に変数を扱える。

基本は const、必要な場合に let を使う。var は非推奨です。

Javascriptを書く際は、ご参考ください。

社会人になってから、昔より、覚えられなくなってきている、、気がして、効果的な学習方法を科学的な根拠に基づいて紹介する本を読んでみました。
最初にまず科学的に効果が高くない勉強法が紹介されます。教科書や本は何度も繰り返し読んだ方が良いとどこかで聞いたり、読んだりしたことがあると思いますが、、
今までの自分のやり方が・・・非効率なものが多々ありショックをうけました。。
まず非効率な勉強法が紹介されます。

非効率的な勉強法

繰り返し読むだけの学習

繰り返し読むだけの学習は長期的な記憶定着に効果が低い
単純な再読は「わかった気になる」だけで、深い情報処理が行われにくい
再読した学生と1回だけ読んだ学生の間で、ほとんどの場合に優位な差がなく、再読に大きな学習効果がないことを裏付ける結果となった。
2回目以降の読み込みでは、文章に慣れて「わかった気」になりやすく、深い情報処理が行われにくい。

ノートに単純に書き写す

教科書や参考書の内容をそのままノートに書き写す、まとめることは、学習効果が低い
アメリカの高校生を対象とした研究では、文章をそのまま書き写した生徒の成績は、ただ文章を読んだ学生と変わらなかった

マーカーを引くだけの学習

テキストにマーカーを引くだけでやった気がになってしまい効果的な学習にならない　

・・・・・完全やった気になってます。
これらの勉強法に共通する問題点は、表面的な情報処理に留まり、深い理解や長期的な記憶定着につながりにくいことです。特に、「流暢性の錯覚」と呼ばれる現象により、実際には内容を十分に理解・記憶していないにもかかわらず、理解した気になってしまうリスクがあるようです。

効果的な勉強法

アクティブ・リコール

学習内容を単に復習するのではなく、意識的に思い出すプロセスを通じて記憶を定着させる学習法です。この方法は、科学的に証明された最も効果的な記憶法の一つとして広く認識されています。
学んだ内容を積極的に「思い出す」ことを中心に構成されています。
なるべく手がかりなしに記憶から引き出そうとする作業が重要
・練習問題、過去問を解く、模試をうける
・暗記カード、フラッシュカードを使う
・紙に書きだす

反復と間隔を空けた復習

短期間に詰め込むのではなく、時間を空けて復習する「間隔効果」を利用することで記憶が定着しやすくなる。

アウトプット重視の学習

インプット（読む）から アウトプット（思い出す、教える）に重点を置き学んでいく

モチベーション維持の方法

学習内容と自分との関連性を考え、紙に書き出す
自分に関連した情報の方が記憶に残りやすく、モチベーションも維持しやすい

本を読んでみて

効率的な学習法を科学的な視点から解説しています。この本では、実際の学習理論や心理学的な研究を元に、より効果的に勉強を進めるための方法、事例が詳しく紹介されてました。

自分自身にも試す価値のあるものが多かったです。取り組んで見ようと思いました。