意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

はじめに 開発者として経験を積んで、「人に頼むよりも自分でする方が早いから」 という考えに固執し、「人に頼まず自分でやってしまう」 という壁にぶつかることがあるかもしれません。リーダーに昇格した直後などは、自分で仕事をした経験はあるけれど、人に頼んだ経験がないなどの理由でそのような選択をするかもしれません。 頼んだ相手が自分よりも大きな見積もりを出してしまうことがあります。その場合、自分に多くの作業を割り振ってしまい、「自分だけが忙しくなる状況」 に陥ってしまうこともあります。 そこで今回は、簡単に読めてこういった状況を避けるのに役に立つ本を3冊程紹介したいと思います。 最強のエンジニアになるための話し方の教科書 技術力(200%) x 伝える力(0) = 真のパフォーマンス(0) (出典：最強のエンジニアになるための話し方の教科書) どんなに技術力があってもちゃんと伝えないとダメなんだな

「人の話が処理出来ない奴へのアドバイス」に関する補足元エントリにはてブが1700もつき、Twitterでも関連ツイートが千バズ、万バズになり、それらの閲覧数の合計が7桁になっていたのにはびっくりした。 「言語化されていないが切実な課題」だったのだな、と強く感じている。 そして、「自分の解釈を傍に置いて読む」ことができない人がたくさんいたのには、予想はしていたけどさすがに笑ってしまった。 まーそれが人間の仕組みだしね、とは思っているけど、やはり笑ってしまう。 その一方で、読めている人が、しっかり読んだ上で切れ味鋭くコメントしてきているのも事実。 世の中はすごい人がたくさんいるな、とも改めて思ったし、賢い人を甘く見てはいけない、という思いを新たにした。 ということで、フィードバックがあった点を中心に、情報を補足したほうが良いと思った点について、自分の考えを箇条書きで書いていく。 議論を理解する

初めて会社を起業する人のほとんどは、集団をマネジメントする方法を学ぶ間に、創業当初の従業員を燃え尽き症候群にさせてしまうと思います。 筆者のアドバイスがそのようなケースを減らせるなら、ここに書いておく価値があるでしょう。 筆者は小規模なチームやスタートアップ企業のマネージャーのためにこの記事を書きました。 ほとんどのアドバイスは、大規模な企業のマネジメントには当てはまらないのではないかと思います。 なお、急成長している企業に入社する人への全般的なアドバイスについてはこちらをご覧ください。 筆者について 中・小規模のエンジニアリングチームを数チーム管理した経験あり On DeckのCTO CoinListの元エンジニアリング担当VP AngelListの元リモート責任者 Product Huntの元CTO それでは始めましょう。 マネージャーはすべての失敗に責任を負う 分かります……とても前

こんにちは、ソリューション開発部の柴﨑です。 私たちのチームでは、日次の朝のミーティング（以降、朝会と書きます）を実施しており、朝会で伝えたいことの準備をして欲しい旨を朝会の前にリマインドしています。しかし毎日リマインドを手作業で送るのは面倒なものです。今回は、Microsoft Power Automate（以降、Power Automateと書きます）のクラウド フローで祝日を除く平日にリマインドする方法をご紹介します。 まとめ[スケジュール]の[繰り返し]トリガーで平日に実行します。[Office 365 Outlook]コネクタの[イベントのカレンダー ビューの取得（V3）]アクションで「日本の休日」予定表からイベントを取得します。イベントがなければ祝日を除く平日なので[Microsoft Teams]コネクタの[チャットまたはチャネルでメッセージを投稿する]アクションでメッセージ

こんにちは、ソリューション開発部の柴崎です。 Excelで表を作ろうとしている最中、最近の若者は表に罫線を引かないと聞きました。なぜ若者は表に罫線を引かないのでしょうか。その謎を解明するため、われわれ調査隊はOOXMLの奥地へと向かいました――。 まとめ罫線を引いている時間がもったいないので、テーブルとして書式設定を使うのがおすすめです。テーブルを使うと構造化参照できるようになり、数式が読みやすくなります。Apache POIでも構造化参照するテーブルを作れます。表を作る罫線を使う方法・使わない方法で表を作ってみましょう。例えば以下のようなデータがあったとします。

柴田(@4bata)です。「それぐらいわかるだろ･･･」が通じなくなるタイミングがあるんだなという発見です！ 考えたきっかけ：「オープンでフラットだと思ってたけど、結構閉鎖的なところもある」というセリフを聞いたその人に情報が伝わってなかったのかな。私の最初の感想は「前からそうだった気がするけどな･･･」。以前から整った形で情報はちゃんと流れてない。私にとっては、今働いている会社が閉鎖的には見えてない。実際には閉鎖的な部分があるのだろう。その差を理解してみたくなった。 情報の伝わり方を単純化して考える近くにいる人には自分の活動内容や背景にある意図が勝手に届くとする。携帯の電波が届く範囲、みたいなイメージ。 接触頻度が高い人同士は、いろいろ理解できている。 人数が少ないときは、何もしなくても相互に活動内容や意図が伝わっている・自分が理解できない情報も、一緒に仕事してる隣の人に聞けば情報の背景が

平川 英司 放送系システム開発、データカタログ製品開発など様々な分野の経験を持ち、顧客業務にも幅広い知識を持つ。 フットワークの軽さが長所であり、短期間でモックアップを作成、ユーザインタビューを行い、新製品の企画・開発に貢献。 * ; cls: uk-animation-slide-bottom-medium; delay: 10" class="article-body" data-v-45c0ee78>ラジオ放送局員からフロントエンド技術者に▲コンサルティング部シニアマネージャー平川 英司 2020年現在、MBPジャパンDX推進事業部コンサルティング部のシニアマネージャーを務める平川は、放送・印刷・WEB関連・パッケージ製品開発などさまざまな業界での業務経験を経て現在にいたっています。 そんな平川の社会人としてのキャリアは、ラジオ放送業務からスタートしました。 平川 「学生時代からボブ

こんにちは、ソリューション開発部の柴崎です。 最近、まじめな記事ばかり投稿してしまったので、ゆるい記事を書きます。 さて、複数人から無作為に発表順を決めるなど、ランダムに並べ替えたいことはよくあると思います。そんなランダムに並べ替える各種言語やツールに対して、コードゴルフ的に挑戦します。LT 大会で発表順を決めたいなど言われたら、これでドヤ顔しながらコーナーで差をつけろ!! ルール説明 適当な数人をランダムに並べ替えるコードの短さを競います。 人数と名前は可変とします。今回の例では、佐藤, 鈴木, 高橋, 田中, 伊藤の5人にします。出力結果を見て順番が分かれば OK とします。コマンドラインで実行できるワンライナー限定です。各種ツールの2020年2月時点での最新かそれに近いバージョンで実行します。Windows のコマンドプロンプトでは動かないものがあるかも (未検証) ???レギュレー

こんにちは、ソリューション開発部の柴崎です。 Spring Boot でウェブアプリケーションを実行可能な Jar/War 形式として作る場合、依存ライブラリだけでなくアプリケーションサーバーも単一のファイルに含まれます。ライブラリだけでなくミドルウェアも同時にアップデートにできる便利な世界になりました。同じように Java 実行環境も簡単にアップデートしたいというのは当然の発想かと思います。 Project Jigsaw の登場により、必要なモジュールのみで構成された Java 実行環境を作ることできるようになり、Java 実行環境のディスク使用量を節約できます。使用容量が減ることにより、Java 実行環境も併せて配布しやすくなります。Docker を使うという場合でも、より小さいイメージを作れる可能性がありますので、方法を知っておいて損はないかと思います。 まとめ2019年12月時点で

こんにちは、ソリューション開発部の柴崎です。 前回、以下の記事で Java 11 の jdeps/jlink を使い、Spring Boot ウェブアプリケーションを動かすための最小構成の Java 実行環境の作成に挑戦しました。一応の解決をみせましたが、--print-module-deps オプションを指定するとエラーになっている部分を深堀りできていませんでした。今回の記事でさらなる解決を目指してみます。 まとめJDK 内部 API は使わない。自分たちのコードだけでなく依存するライブラリにも気をつける。特に JDK 内部 API で削除されたクラス (JDK removed internal API) に依存するライブラリがないか要確認。 JDK 内部 API で削除されたクラス (JDK removed internal API) を参照していると、jdeps の --print-

おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess

本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ

※ キャンペーンは終了しました。多数のご参加をいただきまして、誠にありがとうございました。結果発表はこちらから iOS・Androidアプリがカラースターに対応したことを記念して、豪華プレゼントキャンペーンを実施します！ 6月8日（水）23時59分まで、はてなブックマークのアプリからこのページをブックマークするともれなく全員に「グリーンスター」を、「カラースターあるある」をTwitter連携でコメントすると、さらにレア度が高いカラースターが当たります！ 詳しい応募方法はこのエントリーの最後をご覧ください。是非この機会にキャンペーンに参加して、カラースターを使ってみましょう。 カラースターって何？ カラースターとは、ブックマークやコメントに付けて気持ちを伝えられる星の形をしたアイテムのひとつです。はてなブックマークで見つけた面白いエントリーやブックマーク、コメント、はてなブログ記事など、はて

「会社には、経営理念がある」ということは広く知られているが、「なぜ理念が必要なのか」については意外と知られていない。 いや、正確に言えば「理念がなぜ存在するか」についての本当の理由が間違って伝わっている事が多い。 私が「経営理念」について、初めて考えさせられたのは、コンサルタントになって二年目の事だった。 ある、鉄鋼業界出身のコンサルが、印刷会社の社長に「経営理念」について指導していたのを見ていたのだ。 そのコンサルタントは言った。 「社長、この会社の経営理念はなんですか」 「お客様のために、誠意を尽くして商売をする、です。」 コンサルタントはそれを聞き、声を荒げた。 「あのねえ社長。こんな世のため人のため、みたいな、なんとでも取れる経営理念なんて、何の役にも立たないよ。テンプレート通りにつくってるから、会社がダメになるんだよ」 今思えば、相当失礼な言い方だったが、その指摘は的を射ていた。

記事のタイトル通り、競馬で回収率100%を超える方法を見つけたので、その報告をする。 ちなみに、この記事では核心部分はぼかして書いてあるため、読み進めたとしても「競馬で回収率100%を超える方法」が具体的に何なのかを知ることはできない。（私は本当に有効な手法を何もメリットが無いのに公開するほどお人好しではないので） 本当に有効な手法を見つけたいのであれば、あなた自身がデータと向き合う以外の道は無い。 ただし、大まかな仕組み（あと多少のヒントも）だけは書いておくので、もしあなたが独力でデータ解析を行おうという気概のある人物なのであれば、この記事はあなたの助けとなるだろう。 ちなみに、これは前回の記事の続きなので、読んでない方はこちらからどうぞ。 stockedge.hatenablog.com オッズの歪みを探す さて、前回からの続きである。 前回の記事のブコメで「回収率を上げたいならオッズ

この記事は、JavaとScalaの例外分析・パフォーマンス監視のツール Takapi の blog に投稿されたものです。 Javaのマイクロフレームワークとは何か、推奨される理由とは？ どんなプログラミング言語にも、長所と短所はあるものです。例えばJavaは、安全性の高さや、厳しいテストを経ていること、後方互換性などの利点を持つ言語です。しかし、その代償として、アジリティ（俊敏性）や合理性といった面が少なからず犠牲になっています。冗長で、Java自体が肥大化しているという事実も否定できません。とはいえ、新規開発や大規模な開発を行いたい場合、JVM（Java仮想マシン）はバックエンドとして非常に魅力的です。JVMはパワフルな上に、非常に厳しい環境でテストされています。このような利点があるため、結果的にJavaは広く使用され、積極的にデプロイされているのです。 しかし、このJavaの現状を皆

1. 各々の入力欄に、常に見えて分かりやすいラベルを付けよ 記入する前の入力欄にだけ、フォームのラベルを表示するのがWebデザインの主流になっています。これはユーザネームやパスワードなどを入力する際にはシンプルで使い勝手がいいのですが、それ以上に長い文字列になると少々勝手が悪くなります。 そのため余白があるのであれば、ラベルを表示すべきです 特に、長いフォームの場合では、ユーザは入力したものを見直すでしょう。どのラベルが入力欄と合致するのか分からなければ、間違いがないよう見直すことなどできるはずがありません。 改善前:入力欄中にラベルが記入してあります。今は見やすいかもしれません。 しかしフォームに入力するとラベルが見えなくなってしまい、間違いを見つけにくくなってしまいます。 改善後:それぞれの入力欄に、クリアでいつでも見えるラベルを付けましょう。 2. 十分な大きさのフォントを使用せよ