nDiki : opinion

opinion

スポンサード リンク

2017年6月27日 (火)

イケてない職務経歴書テンプレート

転職エージェントが紹介してくださるソフトウェアエンジニアの職務経歴書ですが、ここ数年見ている限りだいたいフォーマットは数パターンぐらいでだいたい似たり寄ったりな感じです。かかわった業務でのプロダクト概要・チーム人数と担当役割の箇条書きと、使用したプログラミング言語OS・ミドルウェアの羅列、それから工程列の●マークが定番でしょうか。

しかし端的に列挙されているだけだと魅力を感じることができないのですよね。 R & D や特定領域に特化した方を探している場合はともかく、いつでも誰でも学べるものを並べられても評価できません。

具体的にどのような能力を発揮されたか、どんな特別な工夫をしたかなどを(守秘義務を守れる範囲で)書かれていると良いのではないかなと思います。

個人的には定番のあの表形式ではなく、もっと自由な記述のものだと読んでいてわくわくするのになと思っています。せっかくついているエージェントの方はそういうところはフォローしないのでしょうかね。それとも世間一般の採用者はあの表だけで足りてしまうので困っていないのかな。

[ opinion ]

スポンサード リンク
[ 6月27日全て ]

2017年12月14日 (木)

チームで使う共通の言語をもつ

ストラテジーグループという新しい3人チームでプロセス作りをしています。

3人のうち2人は「エッセンシャル スクラム」を読んでいて例えば「経済的フィルター」と言えばアレのことねとなるのですが、もう1人には今は通じません。「エッセンシャル スクラム」を読んでいないのが悪い、あるいは「エッセンシャル スクラム用語で話す2人が悪いという話ではなく、同じ言語を共有していると楽だし誤解が無くていいよねという話になりました。

アジャイルサムライでは

11.4 プロジェクトで使う言葉を共有する (pp.228-229)

で説明されていますね(原著だと Create and Share a Common Domain Language)。

そういえば以前部署で「エッセンシャル スクラムを読む会」を続けているうちに例えば PBI で話が通じるようになったりして楽になったなと感じました。

プロセスについてでもプロダクトについてでも、共通の言語をもつ(作る)というのは大切だなとあらためて感じた次第です。

[ opinion ]

[ 12月14日全て ]

2018年2月14日 (水)

ワークフローを作る時は「誰が」「いつまでに」「なにをするか」を明確にする

「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にしてコミットしよう/リクエストしよう。

というのを自分の行動原則の1つにしています(完全に守れているわけではないのですけれども)。

今日、サービスの不具合管理のワークフローの見直しをチームでしていて、原案が気持ち悪いなと思ったのは「誰が」が不明確だったからでした。「気がついた人が」や「◯◯が役割の人が」は絶対誰もやらないケースが出てきます。思い切って個人に割り当てる(そして無理だった場合はエスカレーションする)ルールの方がきちんと仕事がまわります。

[ opinion ]

[ 2月14日全て ]

2018年8月23日 (木)

違反投稿分類自動化と学習データを作れなくなる問題

ユーザー投稿ができるネットサービスの多くは違反投稿の対応が必須である。ここ数年機械学習を用いてテキストや画像を分類する環境が整ってきたため、違反投稿の判別にも適用が進んできている。人の負担が減ることはとても良いことだと思っているのだが、自動化を進めることで違反投稿対応スタッフを過度に削減することになるリスクも心の奥で感じている。

人力チェックから自動化へと切り替えるタイミングでは、教育されたスタッフによって分類された良質な学習データが使える。だが自動化のあとにスタッフを削減しすぎてしまうと、組織として違反投稿かどうかの判断する力が弱くなってしまい、将来判断基準を変更したり新しい基準での学習データを用意したりすることが難しくなってしまう。ノウハウが失われてしまうリスクが隠れているのである。

[ opinion ]

[ 8月23日全て ]

2018年9月28日 (金)

時間どおりに会を始める

時間通りに会を始めないと、ますます時間通りに人が来なくなるよなーと着席しながら思ってた。

オフ会を主催した時に遅れてくる人を考慮して開始を遅らせたことがあったんだけれど、すでに来ている方に悪いことをしたなと反省したのを思い出した。

[ opinion ]

[ 9月28日全て ]

2019年7月16日 (火)

「調べてから選ぶ」よりも「選んでから調べる」

調べてから選ぶ方が正しいものを選べるように思えるけれども、調べることには時間とコストがかかるので、先に選んで調べちゃった方が良い結果をもたらすことが多いよね。

後で役に立つから調べておくというのも、時間が経つと役に立たない情報になってしまう可能性が高いというのも考えておく必要がある。

早めに深くバックログリファインメントしすぎないの大切。

[ opinion ]

[ 7月16日全て ]

2019年8月27日 (火)

Google フォームでコミュニケーションを省略しない

Google フォームが便利で使い慣れてもきているのはわかる。けれどもコミュニケーションが必要な機微な事柄まで「Google フォームに入力してください」は良くない。特に組織に関する個別の話とかね。

まだ双方向性があるメールの方がマシ。

[ opinion ]

[ 8月27日全て ]

2019年10月23日 (水)

「難しい」という「思考停止語」

最近「難しい」という言葉を受けてそこで議論が進まなくなることが多い。 「実際に難しい」ことと「難しいと思っている」こと、さらには「難しいと思いたい」ことが区別されないまま、動くのをやめてしまうことが起きないように気をつけないとな。

[ opinion ]

[ 10月23日全て ]

2019年10月31日 (木)

トライアル実装について書き出して情報発進するということ

保守が難しくなってきたライブラリを使うのをやめて、まだ導入していない新しいライブラリを使う実験的取り組みしていている担当者に「ドキュメントにまとめておいて欲しい」とリクエストしたら「誰が何のために読む想定で書けばよいか」という良い質問をもらった。質問を受けてドキュメント化で期待する価値について伝えられるよう整理しなおした。

ドキュメント化で期待する価値

今回のトライアル実装のドキュメント化で期待する価値は以下と考えている。

  • 個人の学習: 今回の取り組みメンバの理解が深まる。
  • 資料化: ソースコードから読み取りにくい 「なぜそういう設計・実装にしたか」を今後保守する人が理解する時の助けになる。
  • 組織の学習: 今後同じライブラリを使うことになる組織の他のメンバが将来参考にできる。

ということで「今のチームメンバ」「将来のメンテナ」「将来の組織の他のメンバ」が読者の想定だ。

「詳細設計書」をまとめるより「今回やったこと」「分かったこと」「考えたこと」「気付いたこと」を整理して書き出すことが、形式知化とナレッジ共有に役立つと考えている。

「ドキュメントにまとめておいて欲しい」には「成果物としてドキュメントを残して欲しい」だけでなく「情報発信をするメリットを知って欲しい」という思いも含んでいたりする。

[ opinion ]

[ 10月31日全て ]

2019年11月20日 (水)

他人の行動ではなく自分の行動を変える

「○○さんがやってくれないので進まない」って問題点を嘆いても何も起きない。自分が何をするかを変えないとね。

[ opinion ]

[ 11月20日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.056418s / load averages: 0.41, 0.32, 0.32
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker