サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
blog.doyaaaaaken.com
”暗黙知”という言葉はたいていネガティブな文脈で使われます。 ”暗黙知”でGoogle検索すると、対義語の”形式知”について触れつつ「どうすれば暗黙知を形式知に転換できるか」についてのノウハウが書かれた記事がたくさん出てきます。 暗黙知(個人が持つ知識・ノウハウ)を形式知(文書・マニュアルなどに落とし込んだ他者が共有できる形のもの)に変えるメリットとしては、属人化の防止やスキルの伝達などがよく言われます。 しかし逆に暗黙知のほうが優れている点については語られているのは見たことがありません。 今回は『暗黙知を形式知化するのが常に正解というわけではない』というテーマについて書きます。 ============ ※ 形式知の代表例として、社内共有された社内制度・業務ルール等のドキュメントを想定して書きます 形式知化するとコストがかかり続けます。 初めにドキュメント化するコストはもちろんですが、そ
有名な開発フレームワーク”スクラム”が、現代のアジャイル開発にもたらした貢献は多くの人が認めるところだと思います。 私自身も、スクラムの思想である「経験主義」「リーン思考」に強く影響を受けた人間の一人です。 私はスクラムの考え方自体はかなり好きですが、唯一賛成できない点があります。 それは『スクラムの一部を変えたものはスクラムと呼ばない』というルールです。 スクラムガイドには以下のように記載されています。 最後に スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。 ~スクラムガイド2020より抜粋~ おそらくスクラムガイドの著者は「正確な”スクラム”の
CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど
このページを最初にブックマークしてみませんか?
『blog.doyaaaaaken.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く