エンジニアのノウハウって意外と広い
エンジニアリングをする中で培った抽象的な能力は割と適用範囲が広い
「開発ができる」ということにフォーカスが当たりがちだが、意外と他にもある
言うまでもないが「非エンジニアはこのノウハウを持っていない」とは言ってない
こういった知見は、プロダクト制作以外にも適用できる場面は多いのではないか
こういうノウハウを自覚しておくことで、日々の生活の中での動き方が変わってくる
例えば、
チームビルディング
アジャイルがどうのこうのといった、チームでのタスクの進め方とか
どういう基準で部署やチームを分けるべきかとか
どういう風に概念を切ると、疎結合で責任の所属が明確になるか、ということをプログラムを書くときも考えている
後輩や他のメンバーにどういうふうに手順を伝えるのが良さそうかの判断
感覚でやってることを言語化して、再現性を高める
他者も自動で実践できるところまで落とし込む
例えば、型のように、人間が努力しなくても秩序が保たれる仕組みを導入する
働き方、リモートワーク
ドキュメント能力
例えば、Scrapboxを使ったドキュメント管理はプログラミングの考えと割と近い
「長期的にメンテするもの」という点でプログラムと大きく関連がある
小さいドキュメントを再利用することで、メンテを楽にするとか、
複数人で同じリソースを管理するときのコツとか、
論理的に考えて言語化するとか(?)
あと単純にタイピングが速い
人の話を聞きながら同時に議事録を書ける
企画、プロトタイピング、検証
ユーザ体験
メンタルモデルの共有
他者とコミュニケーションするとき全般に役に立つ
ユーザへのヒアリング、お問い合わせ対応、委託先とのコミュニケーションなど
何を聞き出せばよいか、どうすれば抽象を効率よく相手に伝えられるか
効率化、仕組み作り
単純作業をどれだけ省略できるかというのを常に考えている
そういう思考が存在するということがまず大きいし、更にそれを形にできる能力がある
利用しているサービスがAPIを公開していたらをそれをサッと組み合わせたり
そもそもそういうツールがないかどうかを探すことができる
これはプログラム外でも応用可能だろう
物流での人間の動きの効率化や、事務処理の効率化だったりを考えられる
データの管理や構造化
データの正規化の知見がある
これは資料やドキュメントを作成する際に露骨に感じられる
そういう風にデータを構造化すると重複が生まれてメンテしづらくなるよ、というのがわかる
etc.
↑
〇〇という能力
エンジニアリングの中での具体例
エンジニアリング以外での適用できそうな例
みたいな感じでまとめるとわかりやすそう
『データモデリングでドメインを駆動する』.iconの終章でもそのようなことが書かれている
基幹系システムとソフトウェアの設計は、デジタル技術にも業務領域でもない第3の知識領域であると。
業務を概観してモデリングし直して、概念を構成し直す部分を誰かがやる必要があって、
経営とテックが互いに歩み寄った時に、どちらに利があるかと言うと、恐らくテック側の方がそういうノウハウが深いのではないか