手当たり次第に書くんだ

飽きっぽいのは本能

仕事

内製化の目的は、製品を作ることではなく主導権を持つことである

内製化の目的は、社員がすべてを作ることではありません。簡単だから内製する、難しいから外部へ任せる、という切り分けも不十分です。要求、判断基準、受入能力、責任分界、切替可能性を自社が握り、システムとサービスの主導権を失わないことが重要です。

属人化は誰の問題なのか – 専門性と独占性を分け、依存関係を設計する

属人化を考えるには、専門性と独占性を分ける必要があります。専門職や管理職の価値まで否定せず、一人へ集中した原因、業務の再現性、不在時のリスクから、組織の依存関係を設計します。

RFI/RFP の考え方 – 社内で何を握り、外部に何を任せるか

RFI/RFP を、社内で決めることと外部に任せることを分ける道具として捉え、ベンダー選定前の整理軸を考えます。

マルチタスクは優秀さではない – 仕事設計とコンテキストスイッチで考える

マルチタスクを優秀さとして扱う前に、仕事が整理されているかを考える。コンテキストスイッチ、集中、タスク分解、業務設計の観点から整理します。

エンジニアと情シスの違い – 技術設計と社内 IT 運用を混同しない

エンジニアと情シスの違いを、能力差ではなく役割構造の違いとして整理します。技術設計、社内 IT 運用、ユーザー対応、責任分界、翻訳役の必要性を分けて考えます。

情シスはなぜ「狭く浅い IT」になりやすいのか – 企業文化と役割設計で考える

情シスを個人の能力問題としてではなく、企業文化と役割設計の問題として整理します。社内 IT 運用、ユーザー対応、SaaS 管理、ID 管理、技術設計との責任分界を分けて考えます。

通信キャリアは土管屋なのか – ネットワーク事業者に求められる技術責任

通信キャリアを土管屋と呼ぶことは、ネットワーク基盤の設計・運用責任を軽く見すぎています。重要なのは、アプリやクラウド事業へ無理に広げることではなく、信頼できる通信基盤を作り続ける技術責任です。

求人票の「高いコミュニケーション能力」が危険な理由 – 要件定義できない組織を見抜く

求人票にある「高いコミュニケーション能力」は、それ自体が悪い言葉ではありません。問題は、具体的な責務や判断範囲の代わりに使われている場合です。要件定義できない組織を見抜く観点で整理します。

VBA を扱う人をエンジニアだと思う企業は非 IT 企業 – 技術職の理解不足を見抜く

VBA を扱う人をエンジニアだと考える企業があります。これ自体は、単に言葉の使い方の違いに見えるかもしれません。しかし、実際にはその企業が IT や技術職をどの程度理解しているかを示す、かなり分かりやすいサインです。最初 […]

トップへ戻る