こんにちは。Jildin(ジルディン)のイルカちゃんです。漢字で書くと海豚です。昔の人が豚に似ていると思ったのが語源らしいですが、ちょっと理解に苦しみます。 本日は、私が選ぶビジネスマナーの豆知識3選をご紹介いたします。 １．相手と正対している時は左目を見て話すべし 左目は感情を、右目は論理を司ると言われています(右脳、左脳のお話と一緒ですね。脳とは役割が逆になります）。なので、相手の情に訴えかけるためには左目を見ながら喋るのがベストなんだとか。ちなみに、右目を見ながら喋ると敵対の意味になってしまうそうです。 私が受講したビジネスマナー研修では、座って商談する際は5cmくらい右にズレて座るとベターと教わりました笑 ２．第一印象を決める要素（メラビアンの法則） 人は見た目が9割という本が昔流行しましたが、以下の３つの情報で、第一印象のまさに9割が決定してしまうそうです。 弊社のトラさんもこち

こんにちは。Jildinのハゲタカです。 社会人になってからずっと業務アプリ開発に携わってきました。 そんな僕がずっと困っていることがあります。 「プログラムやITの知識が無い人にシステムの概要やメリットを伝えること」です。 うちのシステムはどんなシステムで、何が凄いのか伝えるのって凄く難しいのです。 なので今日はコードが書けるだけではなく、ユーザ目線でシステムを設計して、それをアウトプットできるようになるために僕がやった男磨きを紹介したいと思います。 その名も「高級料理を食べる」です。 高級料理を食べる 高級といっても一食10万円とかするものでなくて良いです。 ドレスコードがあるようなお店に行って、テーブルマナーを意識しながらフレンチでも食べましょう。 料理に自己投資すると自己成長が加速します。 美味しい料理はどんな味か？美味しいと美味しく無いの差は何か？ 社会人として、高級な料理店で恥

こんにちは。Jildinのトラです。 Jildinではiphone appはreact nativeを使って構築しています。 特にエンジニアの方であれば共感を得られると思いますが、ダブルメンテや機種依存、ブラウザ依存の問題って結構しんどいですよね。 そんなところに時間を割くくらいであれば機能追加のコーディングに時間を使ったり何を作るかを考えるところにフォーカスしたいじゃないですか。 そんな想いがあってできるだけダブルメンテ、トリプルメンテが発生しないようにすることを基本的に考えています。 特にスタートアップであれば機能の実装スピードは命なので ではスマホアプリを作る上でダブルメンテになりうるものって何か。 当然Androidとios問題ですよね。 Jildinではwebアプリケーションも作っているのでそこも連携できればベストでした。 ただ、そもそもPCでの操作とスマホでの操作で求められるこ

こんにちは。Jildinのハゲタカです。 今日はUIの考え方について紹介します。UIについて書くのは初めてなので、今日は誰でも出来る「色づかい」の部分について書きたいと思います。 悪いUI さて。実際のJildinの画面を2つ貼ってみました。 これは悪い例なのですが、どこが悪いか考えてみてください。 良い例 こっちは良い例です。 先ほどの「悪い例」と見比べたときに、「色を見るだけで違いがわかる」ようになっています。 実はこの色の考え方はユーザがシステムを利用する上で、ストレスを与えないようにするときに非常に大切です。「一色一意味」が徹底されているUIは直感的になるため、ストレスがかかりにくくなります。 まとめ 「画面を作るときは色は３色まで」と言うルールを提唱している人もいます。が、僕はそのルールこそイケていないと思っています。デザイナーがどう考えるかって実はさほど大事ではありません。大事

こんにちは。Jildin(ジルディン)のイルカちゃんです。NARUTOに出てくるイルカ先生の本名は「うみのイルカ」なので、私がモデルです。どうでもいいですね。 前回の記事で、提案営業をする際には相手のソーシャルタイプに分けて提案の手法を変えてみよう、という記事を書きました。 jildin.hatenablog.com その中で、私はこう述べました。 営業の確度を高める要素は、事前準備が9割と言われています。 今回はこの事前準備についてブレイクダウンしてみようと思います。 提案の準備をする時に気をつける３つのポイント 商談に際しての事前準備のポイントはずばり３つです。 目的を明確にする ストーリーを作成する とにかく練習 それぞれについてみていきましょう。 ①目的を明確にする 目的とは、つまりゴールです。まず一番最初に「今回の商談のゴールはなにか」ということをはっきりさせましょう。 ここで、

こんにちは。苦労で禿げそうです。 どうも、Jildinのハゲタカです。 先日Cassandraについて記事を書きました。 jildin.hatenablog.com 今日はその先のお話。実際にCassandraを使ってサービスを運用していく中で困ったことや苦労していることについて書きたいと思います。 Transactionという概念 CassandraにはOracleのようにtransactionという概念がありません。 なのでここからここまでの処理が全部終わったらデータベースに処理を反映してね、っていうことができないのです。いままでOracleがよろしくやってくれていたことができなくなってしまいます。 それでですね。なんでこのtransaction管理がないのが致命的にまずいのかちょっと事例を紹介したいと思います。 Transactionで困った話 Jildinは主にSFAの機能を備えた

こんにちは。Jildinのトラです。 fluxを初めて知った時、ディスパッチャーだのストアだのアクションだのビューだの 結局何がしたいんだよ！っていう感じでした。 よく出てくるあの図ですね。 reduxはもう少しシンプルな図になりますね。 それではfluxやreduxを一言で説明してみます。 「アクションでしかデータが変わらないようにすること」 うーん、どうですかね。あまりわかりやすくできている自信がないので解説します。 もともとfluxはfacebookが提唱しているアーキテクチャです。 膨大なソースコードで動くソフトウェアを作っていると、機能を追加する時や 不具合を直す時に、何がどうなってんの状態になりがちなんですね。 で、特に 「このデータはいつどこで変更されたの？」とか 「このデータってどこで触ったらいいの？」ってなるわけです。 型がある言語であれば オブジェクトをきちんと守ること

背びれに関する雑学を書こうと思ったのですが、「背びれ」という単語がわからず「イルカ　でっぱり」「イルカ　角」などで検索しつづけました。 こんにちは。Jidin(ジルディン)のイルカちゃんです。 本日も営業に関する記事です。でも、これは対人関係という意味ではお読みいただいている全員が対象になることです。 ラポールとは？ 突然ですが、営業活動を行う上で「ラポールが大事だよ！」という言葉を聞いたことありませんか？ ラポールとは親密な信頼関係が築けている状態を指します。信頼関係なくしては、そもそも提案なんて不可能ですよね。なので重要だと言われるのです。 え、そんなことはわかってるから、ラポールはどうやったら作ることが出来るかって？ 様々な方法がありますが、最も近道なのは相手のコミュニケーションのタイプに自分を適応させていくことです。相手にとって、話しやすい・馬が合う相手になることが出来れば、おのず

新社会人の皆さんおめでとうございます！ 入社して2週間目の週中日。そろそろ疲れも溜まってくる頃かと思います。いっぱい頑張った証拠ですね。身体と心はしっかりと休めてくださいね。 どうも！ハゲタカです。社会人ストレスでハゲたわけではないので安心してください。 4月ということで今日も前回に引き続き新卒特集の記事を書こうと思います。今日は「僕が新卒のころに知りたかった５つのこと」がテーマです。 9時始業なら8時半には会社に行け！ 9時始業ならば8時半には会社に行くようにしましょう。 なぜか？信頼を勝ち取るためです。 あなたが学生時代にどんな実績をあげたかなんて関係ないのです。どれだけ仕事ができるかなんて関係ないんです。それはあなたがいつかチームをもつようになればわかります。 チームをもつと「部下が毎日安定した時間に出社すること」にすごく気を使うようになります。なので安定した勤怠の社員はそれだけで評

こんにちは。Jildinのトラです。 「5年後の離職率5割」 例えば新入社員だったとして、こんな会社が目の前に現れたらどうしますか？ 僕が就職活動をしていた時はテンションが上がっていました。 仕事が全然面白くないのかもしれない。 仕事が相当大変なのかもしれない。 採用担当の人が話していることと実態の乖離が激しいのかもしれない。 こういう可能性も十分ありえます。離職率が高いのには理由があるはずですから。 もしそんな会社であれば地獄ですよね。辛すぎます。 じゃあ、離職率が低ければ低いほうがいいのか？ 僕は「ファーストキャリアにおいて」は高ければ高いほうがいいと思っています。 結構偏った思想かもしれません。なので、一意見として聞いてもらえればと思います。 僕は就職活動をする時に2つの基準を満たす会社を探していました。 ・離職率が高い会社 ・優秀な人が集まっている会社(入社することが比較的困難)

皆さん、こんにちは。こんばんは。Jildinのイルカちゃんです。夢占いによると、夢にイルカが出て来ると吉夢なのだそうですよ。 今回は、私が広告提案の営業を行う中で大切にしている、商談の成約率を高めるための２つのポイントについてお話します。 １．ヒアリングに命をかける！ 商談のフェーズとして、大きく３つに分けることが出来ます。 ①ヒアリング - 相手の現状の課題を聞き出す ②提案 - 実際のご提案 ③クロージング - 予算についてお話する ヒアリングは、提案よりも前の段階で行います。 ヒアリングはとても重要な要素です。相手が課題に思っていることは何か、営業側に求めていることは何かを聞き出せた個数と成約率は比例するといっても過言ではありません。 彼氏・彼女に手料理を振る舞う際、相手の好きな食べ物、昨日食べたものといった情報があるかないかで、相手が喜ぶ料理を出すことが出来る確率は変わりますよね＿

どうも。ハゲタカです。 最近まじでハゲてきたんじゃないかと不安になっています。 先日、トラさんが良い感じの記事を書いてくれました。 jildin.hatenablog.com ちなみにトラさんは「Java」か「ruby」と言ってましたが、僕は「Java」か「C」だと思っています。 さて、今日はそんなトラさんの記事に便乗して、僕は「新卒で初めて開発者として仕事をする人に意識してほしいこと」を書きたいなと思います。ちなみに今回はBtoB Javaエンジニア編です。 コードに触る時間のうち９割は・・・ 前職の時、新人研修担当として３０人近い人数を見ていました。 そのときに「先輩相談させてください。」と僕のもとに駆け込んできた新人と話しているとある勘違いに気づいたのです。 彼らはみんな「コードを書くフェーズで悩んでいた」のです。 実装方針が思いつきません こうやって書いて見たんですけどOutOfM

こんにちは。Jildinのトラです。 これからプログラミングを学んで、webで自分のプロダクトを作っていきたいとか、 ソフトウェアエンジニアの道に進みたいと思う人に向けて書きたいと思います。 ただ最初に伝えたいのは、ソフトウェアの業界というのはものすごい勢いで変わり続けます。 なのでこの言語を覚えておけば大丈夫というものは存在しないんですね。 そしてプログラミング言語というのは宗教的な要素も持っています。 いろんなところで絶えず戦いが勃発している領域ではあるので あくまでwebアプリ開発をしてきた一個人の意見として見てもらえればと思います。 重要なポイント ・ネットに出ている情報の量 ・モチベーション 最初に学ぶ言語を決める上で重要なことはこの二つだと思っています。 ・ネットに出ている情報の量 これは初めてプログラミングを学ぶ人にとっては一番重要だと思います。 プログラミングってどれだけ長

こんにちは。Jildinのハゲタカです。 ハゲタカといいつつ髪の毛はもさもさです。 皆さんはCassandraはご存知ですか？ 今流行りのNoSQLの一種です。慣れてしまうと使い勝手もよく、割とイケている子なのですがいかんせんロゴがキモいのが玉に瑕(たまにきず)です。 今日はそんなCassandraについて記事を書きたいと思います。 CassandraはReadかWriteしかない RDBに慣れ親しんだ開発者の多くがこの仕様に殺されるところを見て来ました。それはそれは酷い死に方でした…。 そうなんです。CassandraにはReadとWriteの概念しかないのです。つまりどういうことかというと「INSERT」「UPDATE」「DELETE」がぜ〜んぶ同じなんです。 すでに存在しているキーに対してUPDATEをかけるだけでなく、存在しないキーにUPDATEをかけることだってできちゃうんです。

こんにちは。Jildinのトラです。 「頑張り屋さん」とか「一生懸命だね」とか 一般的には褒め言葉だと思いますが、これを言われるのはあまり好きではありません。 なぜなら頑張りたくないからです。 多分これだけでページを閉じられるとただのクソ野郎なのでもう少し説明させてください。 努力とは 目標の実現のため、心身を労してつとめること。ほねをおること。 僕にはやりたいことがたくさんあります。 プライベートも今僕は20代なので一番楽しい時期と先輩方からたくさん言われます。 なので友人と遊んだり、趣味に没頭したりする時間も大切です。 仕事も同じです。 まずはJildinをもっと世の中に広めて、営業職の非効率を全て無くしたい。 そのあとは接客業の仕事をもっと楽にしたい、マーケティングに必要な情報収集をもっと楽にしたい、エンジニアがもっと楽に開発できるようにしたい。。 ゆくゆくは今人がしている労働を楽に

こんにちは。Jildinのイルカちゃんです。 今回は不具合を防止するための心構えと、具体的な方策に関する記事です。 というのも、私が空前絶後の不具合を出し、他の社員に迷惑をかけてしまったため、自戒と反省の意味も込めて今回の記事をリリースした次第です。 さて、不具合を出さないためにはどうしたらよいのでしょうか。 誰が見ても機能がわかる記述をする それは、わかりにくいコードを書かない、ということです。この事に関しては、ハゲタカさんが以前に記事にしていました。 jildin.hatenablog.com つまり、不具合が起こったとしてもすぐに原因の場所が特定出来るようなコードを記述しよう、ということなのです。 具体的には、「メソッド単位での記述」が挙げられます。機能毎にメソッドを作成し、引数の受け渡しだけをする。こうすることで、不具合が起こった際に、不具合が起こった機能のメソッドだけを直せばいい