質問ができるようになるために必要だったもの
今思い出しても、エンジニアとして仕事をし始めた頃からしばらくは、本当に期待されている成果が出せていなかった。技術力が全くマッチしていなかったというか、技術力も知識もなかったので、何がわからないかそれさえわかっていなかったのではないかと思う。
みなさんにとっては当たり前なのかもしれないが、こうやればこういう結果を得られるという仕事の仕組みの勘所がわかるまで、仕事の理解もわからないことの質問もろくななものではなかった。
では何をきっかけに仕事を理解したかというと、こうすればこういう結果になるだろうと仕事をする前に、期待する結果を期待するとおりにできるようになってから、ではないか。ここが変わったポイントだとはっきり言えないのは、いつの間にかできるようになっていたからだから、としか説明しようがない。
その『こうすればこういう結果を得られるだろう』と思うために、裏には、体系的な知識や実体験が必要だ。まず、こうすれば、の『こう』を知らなければそれを思いつかない。『すれはこういう結果を得られる』も『こう』の行為の結果であるから紐づくのも当然である。
『こうすれば』を別の言い方をすると『引き出し』ということがある。とにかく知っていなければ、引き出しにもならない。順番的にはある程度の成功体験を得て、仕事の仕方を覚えたのだろう。その後で、体系的な知識を得て、結果的に引き出しを一つ、一つと増やすことができたのかもしれない。
そうした積み重ねは、『こうすれば』と思うようになり、知りたいこと、理解したいことを質問できるようになったのだろう。もしそれが他の人にも当てはまるなら、仕事の成功体験と体系的な知識の習得を本人の意思で得られる環境を作ることが必要なのだろう。
コミュニケーションが経営課題のIT部門がslackを導入するときに考えておくこと
少し前にslackでのやり取りで礼儀作がどうのこうのという、職位やお気持ちでコミュニケーションをとることがさも当たり前だというのを見て、つくづくそういったことに縛られない組織で働くことの良さを感じる。
ベンチャーでもなければ、組織は勝手に官僚主義になり、コミュニケーションも中身より礼儀作法や手続きを重視し始める。そうした旧来のコミュニケーションを重視するような組織にslackやTeamsを入れても何ら効果はない。
それでもコミュニケーションの不足はどの組織でも課題に上がるから、IT部門は導入せざるを得ないし、新しい施作をやりたいIT部長やCIOからしたら、新型コロナウイルス関連というリモートワークの推進という格好のチャンスを逃すには勿体無い。
そこで、slackやTeamsを機能させるために、機能させるためのポリシーを決めておきたい。
openチャンネルをデフォルトとして、openチャンネルとprivateチャンネルの比率の目標を設定してしまう。もちろん、DMはprivateに加え、オープンなコミュニケーションを強要する。
このとき、扱う情報を意識するようになる。今までいい加減だった情報の扱いは、本当に機密かどうかの線引きが変わるだろうし、業務委託への情報の提供もメールやファイルサーバよりクラウドサービスの方が追いやすいとなるだろう。
根は真面目なので数値目標の扱いを上手に手懐けると、どうしたらオープンにできるかを考えてくれる。結果的にprivateチャンネルは統合され、openチャンネルが増える。
そこまでやってコミュニケーションに課題が続くようなら、組織の意思決定の不具合であるから、諦めるしかない。
![[スラック] スニーカー Clude メンズ White/White US 8(26 cm)](https://m.media-amazon.com/images/I/31WJN187HML._SL160_.jpg "[スラック] スニーカー Clude メンズ White/White US 8(26 cm)")
議論のリアクション次第で老害にも他人事にも受け止められる
某所でウォーターフォールはいつからウォーターフォールと呼ばれたかとやり取りをされているのを見かけて、開発手法なんぞ事業課題の解決に適した手法を選べば良いのではないかと思ってしまう。
もう大分見かけなくなったが、ウォーターフォールをアジャイル開発がイケていないと煽るスライドは見ていて興ざめする。ウォーターフォール型のシステム開発に合っていない業務課題の解決プロジェクトに使っていることには全くもって賛成もしないし、それで失敗することに哀れみを持つことはないのだけれど。
何度も書いてきたが、システム開発のプロセスの標準プロセスがないのが問題の起因なのかもしれないが、あればあったで、標準プロセスどおりにやったのに上手くいかないのは標準プロセスに欠陥があるからだと言うのだろう。
手段を知らなければその手段さえ選択肢に入ることはない。要件を理解しようとしなければ、適切な手段を選ぶこともできない。そして、そう言ったことを考えるエンジニア自体が希少なのである。なぜなら、全てのエンジニアにそう言ったことに関して関心を持っているなら、死屍累々に多くのプロジェクトの山となっているはずはない。
見方を変えると、こうしたシステム開発手法について議論にふけるようなエンジニアは現場から一歩も二歩も引いて全体を俯瞰しようしている視座を持つことをできるようになった特異なエンジニアなのかもしれない。
それで議論をできるほどの知識と経験を持っているとそれに縛られて語るようになる。無意識に自分を縛ってしまうのは、ある意味老害の始まりではないか。
自分自身を振り返ると、話を聞いていて、秒で言い返したくなるときは、まさにそれで、議論ではなく言い返したいだけになっていることが多かった。今は、そうだねと聞き流し過ぎで、他人事のように思っているように受け取られることがあるようで、リアクションはなかなか難しいものである。
ダメな見積もり
- 人足見積もり
エンジニアの頭数だけ揃えて、時間単価か月の単価を書いた見積書と言う見積もりしかない。過去に指示されたとおりの経験があるだけでましで、プロジェクトで必要とされるスキルセットを持っていないことはザラ。 - いいね！見積もり
顧客の予算に合わせた工数で見積もったり、見積書を作り、エンジニアを現場に送り込むか、常駐しているエンジニアに丸投げする。見積書には受託業務がふわっとしか書いておらず、現場が顧客に詳細を聞きに行くと、スコープが膨らみ、ねじ込まれる。見積もるエンジニアも営業も当事者でない。 - 勘と経験と度胸
顧客からの見積もり仕様があったとしても、過去の類似している案件と似ていると思い込みを根拠とした見積もり。ろくに要求を確認していなかったり、顧客の業種や客バカ度を考慮していなかったり、送り出すチームのエンジニアも決まっていないまま見積もるため、見積もりと実績の乖離が必ず生じるが、それはエンジニアチームのせいだと責任を押し付ける。 - ギャンプル
勘よりひどい。類似はもちろん、未経験分野でも無理くりに見積もる。それは見積もりと呼べるものではなく、博打でしかない。 - LoC
Line of Codeの略で、言語の標準的なステップ数と工数を掛け合わせて見積もる。実態は逆で、期間（時間的な長さ）や工数（工期と時間の掛け算した面積）が瀬制約条件で押しつぶされて面積の削減の辻褄をあわせるとき、生産性向上できるだろうと勝手に月あたりのステップ数を増やされたりする。同じコードを書いたとしてもIDEを使わずフルスクラッチでピュアな環境とIDEを使って書いたコード量が違うので信憑性はない。その点で、プログラムを共通化やライブラリ化せず、コピペして１−２行書き換えるような作り方をしているとコードの生産性は上がると言う矛盾を持っている。
スキップ
調子が悪く、一回お休み。
リモートワークで浮いた通勤の2時間はどこに消えたのか
リモートワークは、働き方改革で声高に言われていたが、なんだかんだ延々と進んでこなかった。それが新型コロナウイルス、COVID-19の登場で、今までリモートワークを渋っていた経営者も強制的にせざるを得ないと、判断させるまでの状況になっている。
こうしてみると日本は本当に外部からの強力なインパクトがないと変わらないのだな、と思う。
リモートワークをやってみると、今までの日常の無駄が浮かび上がる。通勤時間を筆頭に、話すことのない会議も出る必要はないと実感しているのではないだろうか。
カンファレンスや勉強会に出て行くようなエンジニアは一握りで、実はそう言ったエンジニアは意識高い系エンジニアだとメディアの役員に『あなたのことだよ』と言われたときに何を言っているのだと言い返してから久しい。
そのカンファレンスは、ことごとくキャンセルになるし、一部は実験的にオンラインに移行し始めている。勉強会やLTなどは規模もトラックもないからそれをやり易い。
在宅での通勤時間の無駄な体力の消耗やカンファレンスのオンラインが定着すると、移動時間が丸っと手に入る。ドアツードアで片道1時間なら、24時間中2時間が生まれる。
その2時間で何をするか。
採用面談でキャリアシートをみると、これから取り組みたい技術や興味のある技術を記載しているエンジニアを割と見かける。定型的なフォーマットだと、そういったことを書くことを無意識に書かなければならないと思っているのか、書く。もしかしたらエージェントに書くように指導されているのかもしれない。
ではその取り組みたいと思っていることをするチャンスではないか。毎日、通勤で消耗していた2時間丸々手に入る。それをどう使うかは取り組みたいことのあるエンジニア自身のことだが。
一つ言えることは、取り組みたいことがあるエンジニアは実際にはやらない。ずっとやらない。やるエンジニアは無理くりにでも時間を作ってやっている。なぜなら、自分でやりたいと思ったからだ。やりたいこと、取り組みたいことを実際にやっているエンジニアは、すでにやっている状態であるのでさらに次のやりたいことを見つけられる。
自分で自分を取り組みたいと書いた時点に置き去りにするのは、取り組みたいと書いたエンジニア自身である。組織でも、忙しい仕事でもない。
自分に指を向けて。
