概要 †
- 技術マネジメント、経営マネジメントの方法
- 苦手なもので戦ってはいけないし戦わせてもいけない
有能さ †
- 他人のリスクを把握すること。他人を尊敬すること。
- これができないやつとは仕事したくない
- プッシュしない。他人の専門はまかせる。
- 穴だらけの知識の中でも、チームで価値を生み出せること
- 穴を高速に必要な部分だけ埋める、穴を避けて語る、穴を高速に埋められる人にお願いする人脈
- 部下のモチベーションを上げること
- 能力だけでなく、自分がいるコミュニティに貢献すること。
- オーバヘッド
- ルール決めるとコストになるので，各自の裁量でやってください．
- 技術的難度と開発コストを見積もれることはエキスパートの条件
下位ページ †
目的意識 †
- 組織は目的を共有する人の集まりである。
- 必要な目的設定を見誤らないこと
- 課題解決への熱意のなさに「いらっ」とくる
- 「人工知能」という単語を無邪気に使うかどうかが、信用できる人かどうかの分かれ目みたいなところある。
得意分野 †
モラル †
- セクハラめいたことをスタッフや学生がやりだしたら、即座に100%否定して不快感を示す
- 大人の対応しましょうねとか被害者に言うというは一番ダメ
- 失敗した原因に関する詳細なレポートを求められると全部成功したことになるのはあまりにも有名。
技術維持 †
- 技術向上し続けることが大事
- 上司「刃を研ぐのは業務外だから時間外にやれ」
- 経理「砥石を買う予算なんてありません、自費で用意してください」
- 監査「会社の備品を私物で整備することは認めない」
- そうじゃないとウェブマンみたいに買い叩かれることになる
- どれくらいのバランスがよいのか？
部下の指導 †
- 「言いたいこと言うだけの無責任なアドバイス」はダメ
- 自分の意思だけ伝えて、「ほらアドバイスしたのにー」だけは言ってはいかんのだよな。
システムは自動的に回らなければならない †
- 人間の努力や注意力に依存したシステムは必ず破綻する
- 人間がミスしないことを前提にした運用は必ず破綻する
部下への仕事の振り方 †
- 「まずスケッチを描きます、つぎに奴隷をみつけます、そしてうなぎを食べさせ、レッドブルを与えます」
納期 †
- エンジニアは納期を守らない
- 正確な見積ができない
- 新しい技術が必要なことがある
- もちろん古い技術を使えば早く実装できるが、新しい技術を取り入れていかないと、時代に取り残される
- 新しい技術を取り入れないとエンジニアのモチベーションが保てない
- 見積もり段階で決まっていない仕様がある（60-160%の誤差がある→3倍の時間で見積もるということになる）
- 正確に見積もるために
- 見積に失敗したら
- めちゃめちゃ強い火消し屋を投入する
- それが無理なら、開発範囲・費用・期間・品質のどれかを犠牲にする
- 犠牲にしないと品質が落ちるので、次の開発でバッファになる
- 人数を追加すると絶対遅れる
人員配置 †
- 技術に関してスペシャリストを集める際にバックグラウンドが近い人が最低2人は組めた方がいい。
- reviewがお互いにできる
- discussionが深くならないとそもそも働いてる側は楽しくない
- 知的好奇心を満たせるパートナーがいないと辛い
チームワーク †
- 他人をリスペクトする
- デザイナーがいるなら、どうすべきと研究者コミュニティの議論をする必要はないのだ！
- ディスらない。直接言う。
- 美しくないコードをuncodeとかクソースなどと呼ぶ人もいる
- これらの言葉は開発者を傷つけるので、最近アプレッソでは、あまり美しくないコードを「ひよコード」、美しくない箇所は「ここがピヨピヨしてる」と表現するようにしています。未熟だけど伸び代はあることを意味しています。
- 程度の副詞の程度に注意する。
- マネジメントがうまく言っていない場合、きちんと口に出す。きちんと皆で仕事をする。
合目的的であれ †
階層として上から順に、フィロソフィー（こうあるべき）、ビジョン（こうしたい）、コンセプト（どう実現するか）、そしてテクノロジーがあると思うんだけど、テクノロジーの制約のためか分からないけど、そのビジョンには届かないとか違う方向を向いているコンセプトをたまに見て解せぬ気持ちになる
「今回採用した方法に限界があってビジョンにはつながらないことは承知の上で今できることをやることに意味がある」という考えなのかもしれないけど、「何も問題がなければ今回採用した方法を拡張していけばそれがそのままビジョンの実現につながる」ものをコンセプトとするべきなんじゃないのかなって
例えば「空を飛びたい」というときに超音波浮揚の実験とかするのは違うだろうっていう話（波長より小さいものしか浮かない）
デザイン思考disじゃなくて（むしろ階層分けとして整理できていいなと思っていて）「それをやりたいと言っているのになぜそれができない方法を選択した？」「何をするかはどうでもよくてその方法を使いたかっただけちゃうんか？」的なのに対する感想
技術も含め現状利用できる/近い将来手に入るリソースへの洞察が無いとコンセプトへの着地に失敗する、もしくはありきたりなコンセプトになってしまう。そんな例をたくさん見てきました。だからデザイン思考さえあれば技術を知らなくても良いというのは大間違い。何故なら技術を知るとは選択肢を増やすということに他ならないから。一方で「まずこの技術を使って」というのも他のより良い選択肢を無視するという意味でもったいない。技術を知った上で一旦忘れて俯瞰することが大切。必殺技だけで格闘技は勝てない。
安全は事前計画する必要 †
- 安全をあとから考えるとメカ、電気、ソフトの作り直しが生じて結局手戻りしちゃうんですよ。それで年単位で浪費してしまう。可能なら最初から安全対応しておいた方がよいのです。
できますね。医療福祉系は少数生産がほとんどなわりに安全の比重が高いので、品質保証も通常の製造業に比べてしっかりやらざるを得ないので興味をもってくれる人が多いかも。
手戻りは必要以上に恐れると開発スピードが劇的に落ちるけど、チームのモチベーションを落とす手戻りは極力避けたいところ。改良のための手戻りならまだしも安全性に問題があるから手戻りって辛すぎる。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
