朝会のメリット
こんにちは。ひさしぶりのエントリになります。
今日は、朝会について書きたいと思います。
今の会社、朝会をしているのは、私のチームだけなんです。何故、他のチームはやらないんだろうか。私は、朝会は無駄じゃないと言いたいのです。
朝会とは、
- 昨日やったこと
- 今日やること
- 仕事を進めるうえで「妨げ」となっていること
の3点に絞って各自が発表する、15分程度の短いミーティングです。
朝会自体は、特に珍しいものでもなく、古くから、多くの職場で行われているものです。また、アジャイル開発においては、デイリースタンドアップミーティングとして、同じような取り組みを行います。
私の感じている朝会のメリットを紹介します。
- チームの仕事を効率的化できる（一番重要）
他のメンバーの今日の仕事を知ることで、チームの仕事にたいして、個人が効率的に動くことが出来る。「それ聞いてれば、こんな無駄な作業しなかったのに...」みたいな、無駄な動きすることありますよね？もし週に1回しか情報共有がなかったら、最悪ですね。朝会で情報共有の間隔を狭めることにも意味があります。 - メンバーの協力を得ることができる
お互いの仕事に関心を持つことで「それなら、こんな協力ができるよ」なんて話に発展もあります。素敵ですね。小さな問題でも皆に話すと、直ぐに反応を貰えたりするし、その場で解決することもあります。「誰か〇〇のこと知らない？」くらい軽い内容でもいいと思うんです。1人でモヤモヤして、時間を浪費するなんてもったいないです。（ただし、15分を守るために深い議論に発展するような内容は、朝会とは別に会を設定します。） - 問題発見できる
個人の体調から仕事のつまずき具合、チームワーク、人間関係の問題など、朝会では色々な問題のサインを拾うことができます。先にも書きましたが、これが週1回だったら、最悪の結果につながることもあり得ます。サインを見逃さず、スピード感をもって対応します。
- １日のリズムが作れる
同じ時間、同じ場所でテキパキと発表することで、朝から活動的になり、やる気スイッチが入ります。だらだらと出社し、なんとなく昨日の流れで仕事を始めてしまうことにNoと言いたいです。
- 成果を認められる
「今日やること」を皆の前で表明（コミットメント）することで、仕事にオーナーシップ、緊張感が生まれます。また、仕事がきちんと完了したときは、達成感を感じられますし、皆に報告することで、仕事を認められるでしょう。
これだけのメリットが15分で得られるなら、やらない手はありません。
朝会で、気持ちよく1日のスタートをしましょう。
ではまた。
1on1を2か月続けてみた感想
こんにちは。
今日は、1on1の続編を書きたいと思います。下記の記事から、2週に1度で計8回の1on1を実施しました。初心者な私ですが、いろいろと気づきがありました。
it-managers-life.hatenablog.com
ここまでの感想としては、
- メンバーが、日々どのような気持ちで仕事に向かっているのか、良く分かるようになった。
- メンバーのほとんどが、やりたいことや改善したいことを具体的に持っていることに気づかされた。
- 回を重ねるたびに、ポジティブな意見が増えてきた。話し終わったら笑顔になる。
と、このような感じです。
1on1の効果として、メンバーひとりひとりの気持ちに寄り添うだけでなく、個人やチームマネジメントするための重要な情報が多くえられる、というのがメリットに感じました。今後の課題として感じていることは、
- ただの意見交換にしない。必ずフィードバック返して話を発展させ、新しい気づきに導くこと。
- 相談されたことは、お互いで納得する解答にたどり着くようにする。メンバーは、話を聞いてもらうだけで満足してしまうケースもありますが、うやむやにはしない。最後まで話し切った感じで終わる。
- テーマがまんねりにならないように、選択テーマをアップデートしないといけない。工夫の余地ありです。
- ここが一番の難しさだと思いますが、1on1でコーチングした結果をチームや個人の目標/成績に繋げていくこと。弊社は目標管理制度がありますので、それの支援にも繋げたい。
今工夫していることは、簡単にメモをとっておいて、終了後にメンバー1人1人の気持ち（発言）の変化を記録として残す（Excelに整理）ようにしています。次の1on1の前にこれを必ずチェックしておいて、話のなかで観察する（追跡する？）ようにしています。
1on1を人事考課に利用するみたいな話を聞きますが、全然そのような気持ちになりません。そもそもメンバーが委縮してしまっては意味ないし、どうやるのかも今のところイメージもできません。私はメンバーのサポートがメインでそれ以上も以下もないと考えています。
もう無駄じゃないかと思うところまでは、1on1は継続していきます。今のところはそんな雰囲気はないですので、嬉しく思っています。やりがいがある。
ではまた。
PhpStormのプラグインを初めて開発してみた。
こんばんわ。
今日の午後は暇だったので（昼寝はしましたが）、PhpStormのプラグインを作ってみました。
会社のLaravelプロジェクトなんですが、ビューファイルの指定方法が独自の仕様になっているので、ビューファイルから呼び出し元を特定して、そこを開くのに苦労していました。それを何とか簡単にできないかと考えていました。どうやら、IntelliJ IDEAを使ってJavaで作れるらしいことはわかったので、ググりながら作業をしました。
手順1. JDKをインストールする。
既にJAVA8が入っていたので、それを使用することにしました。 一応リンク貼っておきます。
Java SE - Downloads | Oracle Technology Network | Oracle
手順2. IntelliJ IDEAをインストールする。
無償のコミュニティバージョンでOKです。
IntelliJ IDEA: The Java IDE for Professional Developers by JetBrains
手順3. プロジェクトを作成していきます。
IntelliJ Platform Pluginを選択します。
手順4. プロジェクト名を入力します。
手順5. plugin.xmlを編集します。
PhpStormでもプラグインが利用できる様に、コメントアウトを外します。
<depends>com.intellij.modules.lang</depends>
手順6. アクションを作成していきます。
srcディレクトリを選択して、画像のようにクリックします。
手順7. アクションを登録します。
今回、エディターのポップアップにメニューを追加するので、GroupsにEditorPopupMenu、ActionsにEditorPopupMenu1を選択しました。
手順8. クラスファイルがでるので、いよいよコードを実装します。
actionPerformedメソッドをオーバーライドします。
コードはこんな感じです。
import com.intellij.find.FindManager; import com.intellij.find.FindModel; import com.intellij.find.findInProject.FindInProjectManager; import com.intellij.openapi.actionSystem.AnAction; import com.intellij.openapi.actionSystem.AnActionEvent; import com.intellij.openapi.actionSystem.PlatformDataKeys; import com.intellij.openapi.project.Project; import com.intellij.openapi.ui.Messages; import com.intellij.openapi.vfs.VirtualFile; public class WhereIsThisViewCalledFrom extends AnAction { @Override public void actionPerformed(AnActionEvent e) { // プロジェクトディレクトリからの相対パス final String viewRelativePath = "/resources/views/"; // プロジェクトの取得 Project project = e.getData(PlatformDataKeys.PROJECT); // viewファイルのパス String viewBasePath = project.getBasePath() + viewRelativePath; // アクティブウィンドウのファイルを取得 final VirtualFile[] vFiles = e.getData(PlatformDataKeys.VIRTUAL_FILE_ARRAY); if (vFiles == null || vFiles.length == 0) { Messages.showWarningDialog("There is no active file.", "Error"); return; } VirtualFile target = vFiles[0]; // viewファイルでない場合はエラー if (!target.getName().contains(".blade.php")) { Messages.showWarningDialog("This is not a view file.", "Error"); return; } /* * 想定しているviewのフルパス * C:/Users/someone/PhpstormProjects/sample/resources/views/XXX/Application/table/detail/sample.blade.php * 検索する文字列 * ないしょ */ // フルパスから不要な文字列を取り除く String filePath = target.getCanonicalPath() .replace(viewBasePath,"") .replace(".blade.php","") .replace("/", "."); // ないしょ String searchText = 独自の処理; // 検索を実行する FindManager findManager = FindManager.getInstance(project); FindModel findModel = findManager.getFindInProjectModel().clone(); findModel.setStringToFind(searchText); findModel.setRegularExpressions(false); // 正規表現 FindInProjectManager.getInstance(project).startFindInProject(findModel); } }
手順9. ビルドして、jarファイルを作成する。
Build→Prepare Plugin Module "" For Deployment をクリックする。
手順10. phpStorm にインストールする。
ここからPhpStormでの操作です。設定→プラグイン→ディスクからプラグインをインストールをクリックし、先ほどのjarファイルを選択する。そして、PhpStormの再起動をすれば完了です。
手順11. 実行してみる。
エディター上で右クリックすると、追加したメニューが表示されます。実行すると期待する検索結果が得られました。
以上となります。 Javaは正直得意ではないですが、なんとか簡単なプラグインの作成に成功しました。 IntelliJ の助けが大きかったです。さすがです。 今後、もっと凝ったことをしたいのですが、開発ドキュメントがネット上に少ないのがツライですね。 また、勉強したら、ブログにします。
ではまた。
1on1始めました。
こんにちは。
しばらく仕事が忙しくて、ブログを更新できていませんでした。
今日は、お休みなので、今週から始めてみた1on1について書きたいと思います。
上司と部下の1対1の面談って、会社の公式には半期に1回しかなくて、少ないと思っていました。目標管理制度は運用するけど、それのフィードバックは半年間ないし、突然、目標達成できてませんね、とか言われた日には、がっかりする訳です。また、普段見てないくせに、こんな時だけ、とか思う人もいると思います。
1on1は知ってました。でも、自分の部下には、あまりしてませんでした。様子がおかしい時に、呼び止めて、会議室とかで話を聞くことくらいはしてましたが。最近、パナソニックで導入されるとのニュースを見て、特に興味が出てきました。
色々調べてみると、短いサイクルで行う、相手の話を傾聴する、コーチング・ティーチングすること、などが分かってきました。今は、具体的な効果がでるのか良く分からないし、うまくやれるか全然自信がないですけど、とにかく、始めてみようと思いました。2週に1度で行うことに決めました。
人事制度と連携させる取り組みがあるようですが、人事の人間じゃないので、そこまでは無理です。まずは、自分のチームメンバーに限定して、モチベーションや、やる気スイッチ、今後のキャリアなど、普段どんなことを考えながら仕事しているのか、もっと知るという目的です。そして、継続してフォロー、コーチングできたらいいなと。
始めるにあたって、気軽に何でも話しましょうでは、ダメなような気がして、事前にテーマを提示して、選んで来てもらうことにしました。どのようなテーマを選んでくるかで、どういう状態なのか分かりますし、回を重ねるごとに変化していけば面白いなと思いました。
（こんなのでいいのか自信がないけど）提示したテーマは次の７つです。
- 仕事でつまずいてること。
- キャリアについて話したいこと。
- 最近、楽しかったこと。
- 最近、面白くなかったこと。
- 今後、やってみたいこと。
- 今後、やりたくないこと。
- 相手に質問してみたいこと。
昨日、第1回をやってみました。
メンバーそれぞれ選んだテーマが異なっていて興味深かったです。若手、中堅で考えてることが違っているし、若手もモチベーション高く仕事してる人とそうでない人で、対照的なテーマを選んできました。些細なことから、将来のキャリアのことまで、幅広い話をしました。
聞き入るばかりで、上手くアドバイスできたかは自信がないですが、終わった時は、みないい顔してたし、雰囲気は良かったです。でも、それで満足してはいけないと思いますので、終わった後、簡単ですが記録を付けました。結論がでなかった話題や、まだ本音が語られてない話題など、次回へのヒントとしてマークしてあります。継続して、課題が解消するように取り組んでいきたいと思います。
1on1の初心者なので、色々な人の取り組みを参考にして、今後も続けたいと思います。
また、2週間後ブログに書きたいと思います。
では。
文章の導入部の大切さ
みなさん。おはようございます。今週も残業続きで疲れました。
今朝は、ビジネス文書の導入部の組み立て方について書きたいと思います。
下記の記事の延長線上の話になります。
it-managers-life.hatenablog.com
１）ビジネス文書の導入部の目的
「なるほど、この文章はこういう用件のものなのだな、では先を読んでみようか」と読み手にコミュニケーションの土台に乗ってもらい、本論に導くためのものです。
２）ビジネス文書の導入部作成の観点
導入部では、コミュニケーションの設定「何について、何のために、誰が、誰に向けて書くのか」を行います。
観点１：コミュニケーション設定の共有
テーマ、期待する反応、読み手、書き手の４点をはっきりさせる。（前回の記事も参考にしてください）
観点２：読み手の視点に立った問いに答える
読み手の視点に立って（これ重要）、以下の問いに答えます。
- なぜこのテーマなのか？
→ 背景の説明があると説得力があがる。 - なぜこの反応をとらねばいけないのか？
→ 読み手に、 反応することへのメリットを伝える。 - なぜこの書き手なのか？
→ 伝えることの理由です。 - なぜこの読み手なのか？
→ 読んでもらいたい理由です。 - 本論に入る前にあらかじめ把握しておくべきことがないか？
→ 位置づけ、情報源、訴求点など。
例）情報源であれば、〇〇の調査に基づきます、とか。
観点２は自分も書けていないこと多いです。 読み手の視点で疑問に思うことを考えて、導入部を書ければ、説得力のある導入部になると思います。
文章は導入部まで作って完結する。手を抜かずに導入部を書きましょう！
では、また次回。
論理的な文書の組み立て方
みなさん。こんばんは。今週は残業続きで疲れました。
今日は、照屋華子著「ロジカルライティング」という本の第３章「本論の組み立て（２）ロジカルシンキングの実践」を読んだ感想を書きたいと思います。
第３章では、具体的例をもとに本論の組み立て方を順を追って勉強しました。第２章の内容を実例を交えて説明していて、作業の具体イメージができました。ブログ記事で説明は若干難しい感じはあります。
第２章の記事は、こちらです。
it-managers-life.hatenablog.com
第２章では、論理的思考ツールとして、MECE、So What?/Why So?の2つと、論理パターンを学びました。論理パターンの図を再掲します。
ここからが、第３章の要旨になります。
論理パターンの組み立て方
上（結論）から下（根拠）に書くか／下から上に書くか悩みますね。次の様に使い分けると良いようです。
- 結論 → 根拠へ： 結論がはっきりしている場合
- 読み手がテーマ設定をし、答えを持っている場合
- 読み手が結論を承知していて、確認だけしてもらえればよい場合
- 全体像を速やかに理解してもらいたい場合 - 根拠 → 結論へ： 何をどうまとめたらよいかわからない場合
- 書き手が自らテーマ設定した場合
- 読み手の反発が予想される場合
- 読み手にもSoWhat?を順を追って理解してほしい場合
論理パターンの選択
２段目の整理の仕方として、下記の2パターンがあります。
- 並列型： MECEで横に列挙
- 解説型： 左から右へ、事実・判断基準・判断内容の順（MECEではある）
問いが状況説明を求めているなら前者、何らかのアクションに結び付けたい場合などは後者が適しているようです。
本論組み立ての第一歩
第一歩は、テーマを問いに置き換えて → 適切な論理パターンを選択すること。
本論組み立てのポイント
- 根拠の作成ポイント
- MECEに整理したら「見出し」を付ける。
- ステップ分けの概念、対象概念などの考え方がMECE分解に有効。 - 縦の横の構造ポイント
- 縦は３段までがよろしい： 多いと根拠と結論の距離が遠くなる。
- 横は３前後がよろしい： 相手の頭に残る数がよい。 - 根拠の記述ポイント
- SoWhat?するための基本：主語・目的語・述語を明快にすること。
- 体言止めは要注意。キーワードの羅列は書き手のただの忘備録である。
- 短くまとめることよりも、具体性を重視したほうがよい。 - 中間層のポイント（縦が３段以上になる場合）
- 「以下のような」「多様な」などという表現でごまかさない。
- 下の段の切り口を埋め込み、上下につながりを作る。 - 結論のアンチパターン
- SoWhat?を放棄してしまう。
- 下段の内容を繰り返してしまう。
- 上下でミスマッチをおこす。 - 結論のポイント
- 問いへの答えを、ひとつ下段からきちんとSoWhat?すること。
- 忙しい読み手が把握できるだけの全体観と具体性を持たせること。
以上、私がこの章を読んで心に残ったことを書きました。第2章に比べて、文章の組み立て方が、だいぶイメージ出来てきました。ですが、これらができるようになるには、かなりの実践が必要ですね。
ではまた次回。
UIデザインの教科書を読んだ感想
こんにちは。
雨降りの土曜日、書斎に籠っています。
今週末は、原田秀司著「UIデザインの教科書」を読みましたので、個人的な気づきを中心に、感想を書きたいと思います。
１）デザイン != アート、= 設計
素人な私は、デザインはアートに近いものと誤解していましたが、そうじゃない。そもそも目的としているものが違う。アートは、個人的な表現によって人々の心を動かすもの、デザインは、より良く、より使いやすく、より分かりやすくすることが目的である、どう見えるかでなく、どう機能するか＝これは設計だ、なるほどー。
２）UX（ユーザーエクスペリエンス）
なんとなく言葉は知っていましたが、正しくは理解していませんでした。UXとは、ユーザーがサービスによって受けるすべての体験、知ることになってから、忘れる去るまである。思ってたより広い扱いなんですね。本の中で、カスタマージャーニーマップが紹介されていました。顧客が経験する一連の行動を、旅の地図のように可視化する手法のこと、知らなかったです。これ、自分の担当製品で、ぜひやってみたいと思いました。
３）インタラクションコスト
インタラクションコストとは、ユーザーが受ける負担、ユーザービリティの良し悪しの指標となるもの。サービスを使うときの労力は、
- アタマの負担 → 読んだり、理解したり、覚えたり。
ストレスの例）見て判断が付きにくかったり、考える必要がある。 - カラダの負担 → クリックする、スクロールする。
ストレスの例）移動が多い、遠い。同じ操作を繰り返す。
そうそう、こんなサイト良くあるわ、と思いながら読んでましたが、自分もソフトウェアを作っている身、思い当たる節が多々あって汗がでました。前者は、なんちゃってフラットデザインのサイトで多い気がするし、後者は、ボタンやリンクの位置に無頓着な業務システムで良く見る気がします。
４）インタラクションコストを下げる方法
次の３点が重要に感じました。
- 一貫性
規則性に従っている。予測できることが大切。 - シンプルさ
人間の認知できるキャパは決まっていて、すべてを目立たせることは無理。 - 共通概念
誰もが知ってるルールなら、新しく学ばなくていい。
まったくもって同意なんですが、SEの私にもできるんだろうか、自信がないです。これを知ってて、意識できるだけでも、少しでも作るものに変化が起こせるのではないかと思いました。
今回、「UIデザインの教科書」を読んで、基礎的な知識が付きました。エンジニアだけど、UIデザインの基礎が学びたい人におすすめです。
ではまた。
