エンジニアとしての撒き餌の使い方

エンジニアとしての撒き餌とは実現したいことをマジで実現するために自ら仕掛ける方策とでも言いましょうか、それともワナと言いましょうか。何を実現したいかにそれはよりますが。

撒き餌としての「場」

例えば組織内に技術交流会、勉強会若しくは読書会のような場を作り、たとえ出席者が自分を入れてふたりぼっちになることがあったとしてもそれを続けていると一定の認知を受ける場になるものです。

諦めない限りは。

さて、自らの時間を削って維持する（＝これが大変）場はなんのために行うかは自分の中で認識しておいた方がいいです。最初は。だってエンジニアが集まらないのだもの。そのときに、続けるかどうしようと頭をよぎるものです。やめようかって。そう思ったとき、何のために場を作ったのかを思い出してもう１回は続けてみましょう。

撒き餌としての「ブログ」

なぜ多くのエンジニアはブログを書くのでしょうね。技術力を認めて欲しいとか苦労した話を聞いて欲しいとか将又書籍化したい、とか。

これも書くことの目的を持っていると続きますね。そのうち書かないといられなくなる体質になりますが。

そういえば、この前のエリートさんたちとの飲み会でこんなことを言われました。

「文書を書くのがすごく早いですね」

いや、毎日素振りをしているので。タイムボックスの中でテーマを決めて書く訓練をして入れば自然と早くなります。

ブログだとテーマを自分で決めなければなりませんから、情報収集やテーマ決めや書くこと自体全部即決しながらやらなければなりません。

それに比べらたら、仕事で書き物（企画書、新業務フロー、仕様書など）をするなんて書くテーマが決まっているし、様式や書きっぷりも枠組みがあったりするので楽なものです。

話を戻して、エンジニアがブログを書くのは専門技術で名を売ることだと思うのです。より望む転職（＝ヘッドハンティングとか）かもしれないし、技術クラスタでの認知度かもしれないし、編集に見つけられて書籍を出したい、かもしれない。

そういう目的のために撒き餌としてブログを使うのはいいと思うのです。

撒き餌としての「ソーシャル」

専門技術で先をいくエンジニアと繋がっているとお互いに情報を発信しているので情報が早いです。もちろん、イーブンではないとしてもgive and takeな関係にならないとあれですけど。

先方もこちらを認知しているといいですし、カンファレンスなどでリアルで合う関係であればいつもネットで繋がっているのは心強いものです。情報を知っているので情報のポインタを持っていることが多いですから。

まあ、何となく初めてもいいのですけれど、場もブログもソーシャルも道具ですから、何のためにエンジニアとして使っているか棚卸しをしてみたらいかがでしょう。

エンジニアはついつい自分の欲求に負けて仕事を増やすけど、それムリとムダだし

「ふーん、目次構成だね。おお、随分と細いね」
「あっ、ええ、このくらい具体化しておきたいと思って」
「でもさ、そこまでいらないよね、そのドキュメントとしては」
「そうなんですが」
「ひとついいかな。スケジュールがパツパツだって言っていたじゃない。今もそうなの。それとも追いついたの」
「いや、まだですけど」
「じゃあさ、書かなければならないことを先に書いて、時間があったら書いておきたいところまで書けば」
「ああ、そうですね…」
「全然、そうするつもりないでしょ」
「えへへ」
「終わるならいいけど、わざわざ自分の欲求を満たしたいだけで大変なルートを選ばなくてもいいでしょう」
「そう言われるとそうなんですが」
「そのやっていることは、『ムリ・ムダ・ムラ』の『ムリとムラ』だよ。まるでぐりとぐらみたいだ」
「音だけですね」
「音だけだけど」
「そこまで割り切って仕事するのはちょっと」
「あのさ、まずは期限内に契約の範囲内で最高のアウトプットをするのが専門家としてのエンジニアのイズムだと思うよ。今やっていることは自己満足のために時間を使っているように見受けられるけど。今やることは一旦、専門家としてアウトプットすることじゃないかな。そのあと揉まれるんだし」
「でもちゃんと作らないと手戻りが多くなりますし」
「早く出すのはそれで方向性を確認しながら進めるということなんだ。早く出す＝小さくアウトプットしかできないから、手戻りが少なくて済むんだ。ちゃんとのちゃんとが定量的にどのくらいかわからないけれど掛けた期間が長ければ長いほど手戻りは増えるんだ」
「う…」
「あとさ、期限までにそのちゃんとというやつを本当に実現するためにどうしたらいいか、突き詰めて考えているか自分に問いかけてごらん。終わるのか、それもムリ、ムダなく」

離席して戻ってきた時にたまたま唸っていたメンバがいたので席の左側によって話しかけてみたら、どう考えてもレベルが次工程までを含めた目次を展開してドキュメントを作り掛けていたので声をかけてみたのでした。

唸りながらも楽しいんですよね、より詳細に仕様を書くことがエンジニアにとっては。でもですね、ドキュメントは扱う内容という決め事があるのです。ここまでを取り扱う、と。

工数の見積もりだって書く内容と分量を想定して見積もっているのですから、見積もり以上のことを自分が書きたいからと言って勝手に書かれてもコストもスケジュールもオーバーラン必至ですし、文書としてばらつきが出るので差し戻しです。

自分で書きたいことがあれば、次工程で手をあげればいいのですし忘れてしまうというならメモを残したらいいのです。

専門家として、エンジニアとしての責務を果たす方が先です。どうしてもやりたいのであれば、求められていることを終わらして、そのあとやればいいのです。終わらずして自分の欲求に負けるのはプロフェッショナリズムが欠けています。

コンサルタントの道具箱

掛かる工数と充足できる工数の差を時間外で埋めてはいけない

某プロジェクトに途中に参画していたベテランエンジニアが担当になった仕事としては割と楽しい（ワタシの個人的な感想）部類だったけれど、引き継ぐ前任者が遅れに遅らした仕事という曰く付きでもあったのです。

一応、オブラートを包んで補足すると、前任者にはこちらから指揮命令権がないので進捗の遅れをどうこういう筋合いではないのでした。

それで、着任して状況把握をしてもらい、引き継いでやることは立て直しな訳です。はっきり言えば。

そこはベテランエンジニアですから、こうしたことには慣れているし、仕事の内容は地の利があるので安心してお任せできるのです。ただ、頑張りすぎてしまうのが日本人のエンジニアなのです。

案の定、情報を集め始めるとウンウンと唸りながら何かを作っているのですが、まあスケジュールですよね、普通。スケジュール作らないと予定がまさに立たないし。

前提事項を整理する

冒頭の補足説明で述べたように前任者からの引き継いだ作業なのです。これ、大事。なぜ大事かというと、

「手をつける前の時点はこういう状況でしたよね」

とスタートの状況がひどいよ、とおおっぴらにする必要があるから。例え、結果が期待に達していなかったとしてもそれはスタートがマイナスポジションを起点にして評価しないといけないので。

制約事項を整理する

前任者がいたということはそれまで色々と何かしら決まっている可能性があります。そんなの全部リセットしてもいいし、そうすれば、と言いましたがそうしないと言っていたので、そう選択をする場合は制約条件とするのです。

あと、スケジュールを引く際にもすでに決まっているマイルストンもあるのでそれもスケジュールを制限する事項ですね。

無理をしないスケジュールを引く

前任者が押しに押したスケジュールをこちらが契約以上をリカバリする筋合いではない、ーただ専門家としての善管注意義務は履行するとしてー、ので頑張りすぎないことが大事。

ここでの頑張りは、結果的に時間外労働として可視化されます。

時間外まで頑張らない、そうないことが大事なのですが、ベテランエンジニアは習性として頑張るんですよ。身に染み付いているのです。

本当面倒臭い。

時間内で頑張るのはいいです。それは専門家としてやってください。時間内で。

でも、時間外までは頑張らずにお家に帰ってください。その方が生産性が出ますので。

掛かる工数と充足できる工数の差を頑張りで埋めない

結局しなければならないのは無理をしない、できるスケジュールを引いて、どれだけの工数がかかるか、かかる工数のうち充当できるのはどこまでかを可視化するのです。

可視化するのは充当できない部分があるなら、その工数を誰かに代替してもらうためです。そうしないと終わらないので。

こうした費用の負担は発注元がすべきで、負担できないなら成り行きで進捗させることを許容しているのと同じです。それでいいならいいですよときちんと情報を出すのが専門家ってものです。

予約忘れてた

ドラゴンクエストXI 過ぎ去りし時を求めて (早期購入特典「しあわせのベスト」「なりきんベスト」を先行入手することができるアイテムコード 同梱)

PlayStation 4 ジェット・ブラック 500GB(CUH-2000AB01)

PlayStation 4 Pro ジェット・ブラック 1TB (CUH-7000BB01)

テストは要件と仕様を検査するだけでテストで品質は向上しない

「テストでバグが出たら直すんだから品質はそれで向上するのでしょう」

「（はっ！何言っているんだこいつ）」

上記の班のする側のお気持ちにご同意いただけるのであれば大変嬉しいです。「そんなことないよ、バグを直せばいいじゃない」と思われた方にはそういう方なんですねぇとしか感想はありません。

テストで品質は向上しない

さて、この標題で「そうだよね」と思われた方は考え方に近いところがあります。なんでと思われた方とはお仕事したくないです。

テストは何を目的にやるか、です。テストは書いたコードが書いたように動いていることを確認するためにコストを使ってやるものではありません。

要求仕様が実現できているかを現物を使って検証するために行うものです。言い換えれば、コードの検査を行っているのです。

検査ですから生産的な活動はありません。インプットはコード、プロセスの中で試験仕様を作成します。次に試験仕様とコードをインプットに試験を実施することでアウトプットに試験結果を得ます。

この作業プロセスでは生産されるものは試験仕様、試験結果のみです。プロダクトとしてのコードをリファクタリングしたり、品質向上のためのコードの書き換えなどは行っていません。

ですから、テストで品質は向上しないと言っているのです。

品質は上げるものではない

品質という特性を持っているのは仕様書とコードです。仕様書はコードのインプットになるので、仕様書の出来が悪ければコードの出来も悪くなります。また、仕様書の出来は良くてもコーディングの品質が悪ければコードの出来は悪くなります。

このことから、deliverablesを生産する際に、品質という特性を与えているのがエンジニアであることは明瞭なことです。

よく聞くセリフで「テストで品質を向上させる」という考え方は、見方を変えれば

「エンジニアの生産的な活動の質が悪いのでテストで補正する」

と言っているのと一緒です。テストで品質を上げると言っているのはテストでダメ出しを自分でやって、品質の悪いコードを手戻りさせて直しているのです。

プロジェクトマネージャの立場から言えば、最初から手戻りして直すくらいの品質を確保できる作業をしてよ、って感じです。だって、手戻りする工数と時間をかけるくらいなら、最初から1.n倍の工数かけてやってもらった方が安くて美味しいのですから。

テストを書く意味

テスト仕様を先に書く手法があります。あまり流行っていませんけど。テスト仕様を書くタイミングはいつにするかはさておき、テスト仕様を書くということは要件や仕様が実装されているかを検証するために行う検査行為だと認識して書くことに意味があるのです。だって、仕様はこうだ、と理解状況をテスト仕様として可視化するので。

それはエンジニアの要件と仕様に対する理解度がテストケースとして現れる。そういうことです。

ウォーターフォールでコーディングをしてから試験工程に入る場合、テスト仕様はコードを書いてからという順序になります。でも、上記の要件と仕様の検査行為であるとするなら、その要件と仕様に基づいてコードを書いた方が良いわけです。テスト仕様の項目の並びがだいたいコードのファンクションの順序になるのですから。

それってテキストでコードを表現しているようなものですね。疑似コードまではいかないですけど。だからテストケースを先に書く方が合理的なのですけどね。

レガシーソフトウェア改善ガイド

社内横断組織は、体制の位置付けと専任化で貢献した方が良い

nottegra.hatenablog.com

ざっと読みつつ、少し前に受けた相談のことを思い出したのでした。

その相談とは、

「組織の中での推進部門が推進部門として独立している場合の貢献度合いの評価が難しい」

というものでした。もう少しその相談のことを説明すると、全社であるテーマについて推進することになり体制を作る場合、どこに置くのが体制を設けたことに対する組織への貢献になるか、というものです。

具体的には、あるテーマの推進部門をCEOやCTOなどの役員の直下に置くか、事業部門の中に置くのとどちらが良いのか、というものです。

同じじゃないかと思ったエンジニアは残念。実際に両方の位置付けで働いてみると良いですよ。全然違いますから。

話を最初に戻して、引用元のエントリは、
・CTOの不在
・品質問題
・技術広報の不足
の３点が挙げられています。個人的には問題の本質の取り違えとアプローチが適用した組織にフィットしなかったと思うのです。

CTOの不在はCTO不在が問題ではない

これは課題の説明で書かれている認識のとおり、見えている課題はエンジニアのアサインが決まらないというものです。

ではCTOの不在がその問題の本質かといえば、違うと思うのです。

本質は、エンジニアのアサインを決める会議体の開催主旨の曖昧さに全てがあると思います。会議体を仕切りなおす必要があったのです。

対処としては、

・エンジニアのアサインを判断する権限を持つ役員若しくは所轄部門長の出席
・会議目的の明示と意思決定

の２点が改善方法だと思います。極端な言い方をすればCEOが毎回出て意思決定すれば済むのです。

品質問題はレビューで解決しない

品質問題はその事象毎に原因が違うので、品質が悪いからといっていきなりレビューを展開しても効果が得られるか確証はありません。

様々な品質問題があったかもしれませんが、一旦は、次のようにアプローチするのが良いと思います。現実的に解決したければ。

・今、起きている品質問題を集めること
・会社の存続に関わる品質問題かを評価すること
・優先順位の高い品質問題プロジェクトから潰すこと 

 とてもベージックですが、事業に影響を及ぼさない品質問題を抱えたプロジェクトにリソースを割いている余裕はないはずです。

ソフトウェア開発での品質問題は、組織の文化に根ざしているものが多いのでまずは改めて何に問題があるかを知り、対処方法を確立することが重要です。

実際に解決すれば、それがその組織のプラクティスになるのです。それがたまたま技術レビューかもしれませんがそれは対処できた実績のあるものですから効果が得られる可能性が高いです。

ただ、品質問題は作業プロセスが脆弱で品質問題を産む構造になっていることが多いです。品質問題を起こすべくして起こしているといっても良いです。

横断組織がよかったのか

結論から言えば、CEO直下の組織として配置し、経営上の問題だと認識したプロジェクトに対して権限を持つ組織がよかったのでしょう。

CTO不在の問題の本質は、アサインの意識決定ですからそれをCEOが最終判断すれば良いわけで、CEO直下の会議体に変更することで解決です。いやいや、CEO多忙ですといっているならデレゲートするかアサイン問題は経営に直結しないとCEOが認めていると認識すればいいだけです。

品質問題は、やはり、組織上の配置をやり直し、少数専任のチームで対応した方が良いでしょう。これも事業上の問題であると判断するならです。

このように体制化することで責任範囲が明確になります。冒頭の相談された貢献の可視化もしやすくなります。

まあ、全てにおいて兼務は諸悪を産むのですけれど。

システム開発を成功させるにはコミュニケーションを減らすことだとしたら

システム開発の現場にはコミュニケーションがあふれています。朝会、ランチミーティング、夕会、相談、連絡、周知、レビュー、打ち合わせ、報告会議、トラブル報告、週次報告、月次報告、プロジェクト報告などなど思いつくだけでこれだけ出てきます。さらにメール、チャット、プロジェクトポータル、チケット管理システム、wiki、テレカン、TV会議などITでコミュニケーションを取る手段も多く提供されています。

これだけたくさんのコミュニケーションを取る機会、手段があるにもかかわらずシステム開発はコミュニケーションで多くの問題を抱え、今日も明日もトラブルのです。

どうして。ねぇ、どうしてトラブルの。

トラブルプロジェクトの原因はコミュニケーションとみんな言うけれど

プロジェクトが佳境に入ったり、プロジェクトの進捗の障害となるトラブルを抱えるとさらにコミュニケーションを取るためにミーティングが設定されます。

その勞甲斐無くプロジェクトが失敗すると失敗の原因はコミュニケーションが十分でなかったと報告されます。

本当にコミュニケーションが原因なの、ねぇ。ほんとなの。

コミュニケーションを取らないといけない仕組みが真犯人ではありませんか

本当の、真犯人は別にいるのではありませんか。

忙しいチームがさらに自分の作業を進めるために場やツールを駆使してコミュニケーションをとる必要のある作業プロセスが問題の本質なのではないですか。

いいですか、コミュニケーションを取るのはコミュニケーションを取ろうと働きかける側がこれから行う作業に必要な情報が十分得られておらず、必要とする情報を持っている人から得ようとしているからではありませんか。

もし必要な情報が必要な時に得られるとしたら何が起きますか

もう一度問いかけます。お答えください。

Q　あなたがこれから行うとある作業の情報が全て揃っていた場合、何が不要となりま

すか。

A　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

さてどのように答えられましたか。

正解は、コミュニケーションが不要になる、です。

コミュニケーションを減らす仕組みがシステム開発を成功させる

 これが本当であればどうすれば良いのでしょうか。

ここで取り違えてはいけないのは、コミュニケーションを減らすことが目的ではありません。コミュニケーションが必要なのは、作業をする上で、必要な情報が揃っていないために手に入れるためにコミュニケーションをとっているのです。

ですから、作業をする上で必要となる情報が必要なときに手元にある状態にすることが求める仕組みです。

それを始めるにあたっては、作業（プロセス）と情報の可視化が必要であり、システム開発を行うプロジェクトの中のストリームを可視化から始める必要があるのです。