仕事に行き詰まったときのハックの仕方

仕事をしていると、ざっくりと2つの種類の仕事があることに気づくと思う。1つは定型化された業務である。例えば、経費処理や勤務実績申請などだ。組織に属しているならば誰でも同じて手続きを行わなければならない。他には、プロジェクトなどでも同じような定型化された業務は存在する。進捗報告はその1つだ。決まったフォーマットもしくは分類に従い、求められる情報をスナップショット的に切り取り、情況を報告する。

2種類目の仕事は、非定型の仕事だ。一度きりの仕事である。企画を起こしたり、一品ものの資料を作る、などがある。

2種類目の仕事を『非定型の仕事』とした途端、1種類目の仕事は途端に増える。例えばシステム開発のプロジェクトで非定型の仕事は実はそれほどない。文書を書く作業は基本的に、全ての工程を通して同じ手続きを踏む。文書のネタ＝インプットを集め、集めた情報をもとに仕様を検討　→　文書としてアウトプット　→　文書の品質を検査するフロートなる。モデルにするとこんな感じだ。

情報を収集　→　情況を判断　→　仮説　→　検証

モデルにしてしまうとわかるが、どの工程の、どんな文書の種類でも同じフローである。違うのは文書の中身、コンテンツだけだ。

では、コードを書くフローはどうかというと、同じフローであることがわかる。

情報を収集　→　ロジックを判断　→　コーディング　→　検証

文書作成の仮説は執筆だし、コードはコーディングである。コードを書くことの検証はテストだ。

仮説で文書を書いているときに仕事に行き詰まった感を感じたら、情況を判断する＝文書で具体的に何を書くと仮に決めたことの仮のレベルが仮説で執筆する際に必要な情報の粒度になっていないことを疑うと良い。

さらに言えば、情報として収集した情報の粒度にバラツキがあり、その粒度の違いが情況を判断する際に判断するポイントを誤った判断をさせたり、脳内でそのギャップを解消するために時間を余計に取られたりした結果、仮説で破綻していることが判明して手戻りや無理に突破しようして行き詰まってしまう。

リズムの違う楽器の演奏をいきなり合わせて不協和音になるようなものだ。

定型化された業務は、金銭の処理であれば最終的に勘定科目で仕分けされ、会計処理するためのインプットになるため、最初から情報の粒度が揃えられている。非定型の業務も同じように粒度を決めておけばリズムが揃う。リズムが揃えばあとは作業を片付けるだけになる。片付ければ良いようになれば、どれだけ気が進まなくても1つ片付けることで1つ進捗する。

1つ片付けたら、片付いた事実を見返そう。「行き詰まっていた仕事が1つ片付いたオレすげー」と労おう。それを2つ目、3つ目を繰り返すとテンポが出てくる。 

まあ、「3つだけ終わらそう」と決めて片付け始めるのがいいのだが、揃えてテンポを作る下地はやっておこう。

ハッカーの学校 IoTハッキングの教科書

「読める！読めるぞ！！」

字下げは4文字スペース派か…。 

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

組織の冠を外したとき、自分を『高く』売れるか

これまで自分の転職に対するポジショントークをするのであれば、会社を変える転職は最終手段（ブラックは別）で、まずは組織の中での組織内転職、それもエンジニア（例　アプリ）→エンジニア（例　インフラ）で仕事を変えるということと仕事を変えた後の自分自身の環境変化への順応性の閾値や関係性の構築能力を知るのが良いとエントリでも書いてきた。

一方、いつでも所蔵する組織の冠を外して、市場で『高く』売れるエンジニアであり続ける必要があることも主張してきた。

なぜ、組織を跨る転職は進めないのに、所属する組織の冠を外しても売れるエンジニアでなければならないと言うか、その背景を簡単に書いておこう。

入社した組織が合併や資本参加などがあり、所属する組織は自分の意思とは別のところで変わっていくのだ、と言うことを学んだ。企業価値を高めるために経営者が事業をあれこれするのは当たり前であるのだが。

もう一つは、バブル崩壊を読めずに採用した結果、赤字転落で希望退職を募った経緯があり、やはり、自分ではなんともし難いところで組織は動いていると言うことを学んだからである。

これらのことから学んだことは、組織は組織の都合で変わっていくので「自分を預けてはいけない』と言うことである。

言い換えれば、（組織に属するが）組織をあてにしていると痛い目にあうリスクをエンジニア自身がホールドすることになる、と言うことだ。

そうしたリスクがあるのだから、エンジニアは所属する組織の冠が組織の都合で外れたとき、市場で自分を『高く』売る技術を持っていなければ、全く売れないか、叩き売られる状態になることを予見しなければならない。

なんだか矛盾していると感じたらそれはそれで正しい。転職するくらいなら組織の中でにしておけ。一方、組織なんていつ無くなるのかわからないのだから、いつでも市場で評価されるようにしておけと言っているのだから。

ところで、ここ最近、少しだけこれまでの主張を変えようと考えに至るようになった。マネージャの経験をそこそこ積んできたところで、開発部門のエンジニアの育成や事業を新しい場所でやってみたいと思うようになった。ベンチャーで数十人のエンジニアの規模になると、エンジニアのキャリアとビジネスを両輪としてマネジメントする必要が出てくる。そうしたオファーがあれば、そういった機会でこれまで経験した知見を出し惜しみすることなく、活かしてみたいと思うようになった。

まあ、自分の年次が進まなければ経験していないことがわかるから、そういったこともあるのかもしれない。いづれにしろ、自分の考えを柔軟にすることにした。

ただ、上述している組織内での転職や市場でいつでも『高く」売れるエンジニアであり続けることの主張は引き続き変えない。変えるのはいい感じに経験を重ねたマネージャをそのまま組織の中で滞留させるより、必要とされる組織外で活かす選択肢を持つことが、価値があると思っているからだ。

まあ、それも市場としてニーズがあればである。

「死ぬくらいなら会社辞めれば」ができない理由（ワケ）

都度編成のチームはギャンブルすぎる

プロジェクトで開発チームを編成して立ち上げ、改めてメンバの顔を見渡すと、一体どれくらいこれまでのプロジェクトで一緒に働いたことがあるメンバがいるだろうか。

プライムのSierだとプロジェクトの規模によるがリーダクラスが数人程度で、顔見知りだったとしても同じプロジェクトで活動したことがあるなんてないケースの方が多いのではないか。まだN次受けのSESの方が、案件ごとにプロジェクトルームにリソースとして供出されるので同じ組織のエンジニアがチャンクに纏められるのでいつもの仲間と同じプロジェクトをいくつも経験しているのかもしれない。

そうした寄せ集め的なプロジェクトチームでは、プロジェクトとしての形式知は集めにくく、個々のエンジニアの経験知として積み重ねられていくが、そうした経験知はエンジニアの中に収まったまま世に出てくることはない。

そうしたプロジェクトチームでは、所謂、統制型か調整型のリーダシップが発揮され、結果的にコマンド＆コントロールがなされる。

プロジェクトの形態をとっていることも、そのプロジェクトが終了すればチームは解散することがわかっているとプロジェクトを終了させることが目的に擦り変わることままあり、言われた通りにしておけばいいという受け身での関与が蔓延する。

保守、維持管理が計画され、開発したチームから残されることが判明しているとしてもそのチームに残るとは限らず、そうしたエンジニアは開発案件しか入れないとする組織であれば焼畑農法的なビジネスを繰り返すのでエンジニアのプロフェッショナリズムは発揮されることはない。

コマンド＆コントロールといえば軍隊組織を容易に想像することができるが、次の文献を読む限りそうした印象は誤ったものかもしれない。

われわれの指揮の哲学はまた、暗黙的に意思疎通する人間の能力を活用しなければならない。暗黙的コミュニケーションーーお互いを理解し合い、言葉の使用をよくわった重要なものだけにとどめ、あるいはさらにお互いの考えていることを察し合うことのほうが、コミュニケーションの手段としては、詳しい明示的な指令を使うよりもっと速くて効果的であると信じる。（『ウォーファイティング』243頁）
引用　知的機動力の本質　野中郁次郎

 これまで、経験知は形式知に、明示的なコミュニケーションを図ったほうが良いと思っていた。これは組織内でチームを都度編成していることを暗黙にしていたから前提のズレがあるかもしれない。

そう言えば、アジャイル開発チームのメンバを入れ替えない方がいいというのは、入れ替えてしまったり、チームを解散させてしまうとそれまでチーム内で醸成していたコンテクストが下がってしまったり、リセットされてしまうためだが、速く効果的な活動を求める切り口であれば指揮命令よりハイコンテクストである方が合理的だからであろう。

ビジネス形態が違うとチーム編成の方針も変わるし、チームに求める価値観も変わってくる。

ただ、そうした速く効率的なチームであっても人員の更新は避けられないが一定のサイクルであればサイクルに応じたレベルで期待はできるだろう。都度編成はギャンブルでしかない。

知的機動力の本質 - アメリカ海兵隊の組織論的研究

コミュニケーションにコストは存在するか

コミュニケーションにコスト感を感じることにとても違和感を覚える。他者がそう感じるのは別に構わないが、コスト感を感じる側がコストを下げる働きかけをしているかといえば残念ながらなさそうだ。

例えばこんなエントリがある。

anond.hatelabo.jp

簡単にまとめれば、依頼する側が依頼の条件を一度に伝えて欲しいと言うものだ。興味深いことに文脈（流れと表現）で推し量れるのであれば良いのだと言う。

確かに、依頼する側が依頼時に条件を全て提示すれば受ける側はそれで依頼側の期待に応える条件を認識することができるだろう。

ただ、ちょっと待って欲しい。依頼する側が依頼する際に条件を提示できるほど決まって依頼しているケースはどのくらいあるのだろうか。

依頼する条件がわかって依頼するのは作業指示書を出すようなものだ。期待する結果があり、その結果を再現できる手順が確立されており、必要とするスキルもしくはそうした条件もなく、手順書を読み、理解できれば期待している結果を得られる。

こうした作業にコミュニケーションコストという感覚は持ち合わせるのだろうか。多分にないだろうと思う。

ではどういったときにコミュニケーションコストだ、と感じるのだろうか。

自分の経験則では、コミュニケーションを取る時点で相手に期待する結果がある。例えば、先方の情報を提供して欲しいと言うケースがあったとする。その照会先が複数あるとすると、まずここで面倒くささを感じるが、予め想定できる作業だから面倒臭いだけである。

次に考えられるのは、照会先からの回答が期待とズレている場合である。再度、照会し直さなければならないためだ。引用した増田もそれをいっているのだろう。

照会先の回答のズレ度合いは、事前には既知な関係でなければ予測できない。大きく外れるか、期待どおりでしか無く、期待どおりをベースにするならそれ以外は全てマイナスでしかない。

そうしたマイナスをベースラインである期待値に戻す手間や時間をコストとと捉えるかどうかである。

コストと捉えると、対策としてはガイドなどを作り、配布することになる。またこれが誤解を生みかねないのだが。

経験則の続きを話すと、先方の数と依頼内容と手段でどのように進めるかを考える。

具体的には、照会内容以外の回答が得られないように仕組み化する。照会内容がアンケートであれば先方に自由度を与えない方式を提示する。枠組みを作り、リスト、単位など誰でも同じ理解可能な方式を取ることが多い。

言い換えれば、相手に考えさせることをさせないと言うことだ。

さて、こうした段取り的な仕組み化はコミュニケーションコストなのだろうか。

異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

プロジェクトが問題だらけな理由

エンジニアを続けていると感覚が麻痺するのかもしれない。プロジェクトが立ち上がるとどこからともなくメンバと称するエンジニアが集められ、具体的なプロジェクトの内容も知らないまま納期までに作業をするように指示される。

システムエンジニアリングだという人がいる。エンジニアリングなら開発手法もプロジェクトマネジメントも、様々な手法や方法論が確立され、技術的にはある程度決まったやり方で、システム開発ができることを期待しても良いだろうが、現実はそうではない。

ウォーターフォール開発にしろアジャイル開発にしろ、概念や思想があるが、これがテンプレートだという開発手法が存在しない。エンジニアの読み手や解釈、それまでに経験してきたノウハウが互いに影響し合い、読み手の解釈に基づくプロジェクト運営が行われる。

プロジェクトチームが編成され、メンバが召集され、そのメンバに示されるプロジェクトのやり方は過去に誰も経験したことがないやり方をプロジェクトに参画してから提示される。いきなり初見でこのやり方に合わせてやれとアドリブに完璧を求められるのだ。

メンバはメンバで、誰一人同じ経験をしていないから、示されたプロジェクトのやり方の解釈は必然と違うものになるし、解釈されたことは似ているかもしれないが根本の意思決定では違う判断をなされているのだ。

ではと、プロジェクトのやり方のテンプレートを作ったとする。そのテンプレートを素直に使ってくれるかと言えば、そんなようには受け入れられない。今まで経験してきたやり方と違うから使えない、このプロジェクトには合わない、などと使わない理由をいくらでも述べるのだ。

もちろん、テンプレートに問題もあって、テンプレートを作るタイミングでたまたま成功した事例を雛形にテンプレート化するから個別事情が色濃く反映される。それをやってきたらプロジェクトが成功したのだと言われるとモデルを抽出することに長けた才能を持つ人がテンプレート化しないとそうなってしまうのだ。

複数の事例からテンプレート化することを進めると原理主義がまかり通り、個別事情を徹底的に排除する勢力が台頭するため、テンプレート化されるのは概念モデルだけで、実務で必要なプラクティスが根刮ぎ削られてしまう。

プロジェクトの問題は得てして以下のことから起きている。

• 誰一人同じ経験を持っているエンジニアはいないことを認識していない。
• プロジェクトチームでやるやり方なのに当事者のエンジニアにそのやり方でやれるかを問われることがない。
• テンプレートは使わない理由をつけられ使われない。

プロジェクトの問題を減らしたいなら、逆のことをすればいい。

• 異なる経験を持ち寄り、違いを理解する。
• チームのやり方は全員で小さく試し、出来ることを確かめる。
• テンプレートをチームのやり方にカスタマイズする。

テンプレートが無いなら、これからやる作業を書き残すか写真に撮り、残しておくこと。

 
amazon kindle『50%OFF以上』　IT・専門書フェアから選り抜き書籍

ピープルウエア　第3版

パーフェクトソフトウエア

amazon kindle『50%OFF以上』 IT・専門書フェア～2018年7月5日（木） 23時59分

『50%OFF以上』　IT・専門書フェア
期間：2018年6月22（金） 00時00分～2018年7月5日（木） 23時59分（日本時間）
対象タイトルが、50%OFF以上！

amzn.to

 基礎スキル的なテーマのものをピックアップ。

プロフェッショナルプレゼン。　相手の納得をつくるプレゼンテーションの戦い方。

ひとつ上のチーム。［新装版］

デスマーチ 第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか

あなたのセキュリティ対応間違っています

なぜ、システム開発は必ずモメるのか？