ロジカルに伝えることとストーリーを持って伝えること

今では、もう10年も前のことになってしまうが、某部署に異動していくつかのプロマネをした後がどれも技術的に未経験のソリューションで、若干の助走期間があったがプロジェクトが始まってしまえば助走期間でやったことは大して役に立たなかった。

そうしたソリューションの中で、あるエンジニアが考えた手法があった。ただ、その手法は机上でしかなく、考えた本人も実践でその手法が機能するかどうかは確かめたことがなかった。

一般的なシステム開発手法であるウォーターフォールでの局面間の割り当てから言えば、データ設計などが上流により過ぎている感を覚えるような構成なのだが、これは適用するパッケージの導入と構成の制約も考慮した上での仕立てになってた。

顧客から見れば、システム要件を話す時点で、どうしてデータ項目まで言及するのか戸惑うかもしれなかったが、それはそれで後工程が楽になるのとより早い段階から顧客が当事者意識を持つように作用するため、割といいシナリオだった。

脱線するが、なぜデータ項目を早く始めると顧客の当事者意識が高まるか、その理由を考えてみると良いと思う。

話を戻して。

その手法を考えたエンジニアの拘りが、仕様を確定した後の「ドキュメントを読み物として書く」というのがあって正直、それどうなんだと思っていたし、今でもどうかな、と思う。理由は、ドキュメントは仕様を書くもので機能的である、つまり、ロジカルに書かれて入ればよく、読み物として書かれると全部読まないとわからいということだ。

ドキュメントの観点で言えば、ドキュメントはロジカルに書かれて入れば良い。ドキュメントで扱うユニバース(書くことと書かないことの界面)の定義、ユニバースの中の機能分解と仕様。取り扱う数値が記載されていれば良いのだ。

ただ、そのユニバースに到達するための経緯は後のテストで紐解き直す必要が出てくればリファレンスが必要となるが、それは仕様検討の資料に繋がるので問題はない。

ここのドキュメントを作る目的から言えば上述のとおりでそれで十分である。これではドキュメントが刊行されないとプロジェクト全体を把握しきれない。そのために必要となるのがストーリーを持って伝えるということになる。

システム開発でストーリーを持って伝えれば良いのは、プロジェクト全体のフローである。局面の繋ぎ方、登場人物が出てくるタイミング。キャスティングの台本としてプロジェクト全体をストーリーを持って伝えなければ、ステークホルダーサードパーティは動いてくれない。それはチームメンバも同じである。

どちらも関わる人が読み、行動するために作成するのは同じであるが、幾重にもストーリー仕立てになっていると、ゼロイチの実装に近いドキュメントは使い勝手が悪くなってしまう。

そうした考え方から言えば、あるエンジニアの拘りは後の運用維持でそのドキュメントを読むことになる担当者の立場では迷惑でしかないし、拘った部分は履き違えていたのだ。

そのソリューションで設計書をどうしたかと言えば、上述どおり機能をロジカルに書いたし、ストーリーを持ってプロジェクトを進行したのであった。

 

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

 
世界一やさしい右脳型問題解決の授業

世界一やさしい右脳型問題解決の授業

 
自分の答えのつくりかた―INDEPENDENT MIND

自分の答えのつくりかた―INDEPENDENT MIND

 

 

 

 

エンジニアとして大事なことは○○から学んだ

某社の役員と話をしてたら、何となくキャリアの話まで及んで、さらに立ち上げた事業の経緯を赤裸々に聞くことになった。それがまた面白くて自然と前のめりになるような引き込まれ方になっているのに気づいた自分に何か大事なことを聞いているのではないかと問い掛けをしようと思いかけたが、それではその何か大事な話の続きを失ってしまいそうで脇に起きつつ話を続けた。

氏曰く、

 

「人生で大事なことは○○から学んだ」

 

のだそうだ。○○と伏せているのは、まあ、大人の事情だということで。

そういったことを思い出して、さて自分はエンジニアとして、何から大事なことを学んだのだろうと問いかけをしてみたが○○を埋められる言葉がさっと出てこない。

何だろうなと思案しつつ、まあ、プロジェクトマネジメントだよな、と。苦笑しつつもエンジニアの専門として選んだ仕事、職種なのだから当然すぎて面白くない。

○○に当たるところは、活動する目的やテーマが当てはまるだろう。だから、自分の場合はプロジェクトマネジメントが当てはまるのだ。

○○を実現するために様々なエンジニアや顧客と関わることになる。関わるということは場を作り、その場に集まってもらって、スポンサーが実現したいことをその場で構築する。構築を介してリレーションが複雑性を増し、深くなっていく。

その場が顧客のやりたいことを実現する場であるということは、その場が顧客を変えていくということではないか。

ここまで思い至った先で辿り着いたのは、顧客を変えていくことをしているのに、自分自身はそのまま変わらないでいられるか、ということだ。

もし、顧客が変わろうとしているのに自分が影響を一方的に与え続けていられるのか。それは間合いを広くとって、実は変わることを避けているのではないかと思うのだ。

顧客が変わろうとしている。その場を(プロジェクトとして)作りながら、自分も変わる。

だから、困難なことが次々と起こったとしても、逃げずにやってこれたのではないか。

もちろん、それは一人でではなく、その場に集まった人がいたから、だが。

そうした場で耳にする言葉が自分を変えてきたのだろう。その意味でも、エンジニアとして大事なことは○○から学んでいるのだろう。

現場にいる限りは。

 

新・人生に必要な知恵はすべて幼稚園の砂場で学んだ

新・人生に必要な知恵はすべて幼稚園の砂場で学んだ

 

 

抜け出そう!デスマあるある

前にも書いたことがあるような気がする(いつも思いつくまま書いているので何を書いたか覚えていない)が、デスマは身体を壊さない程度で自分の閾値をテストする意味でしか経験する意味合いはない。もちろん、デスマなのに超過労働分の手当が支給されないのなら、経営者でもなければやる意味はない。労働者は労働力と引き換えに対価を得ているのだから。

それはさておき、こんなシチュエーションを体感していたら即刻避難した方が良い。

  • はっきりしないスコープ
  • ロジックのない価格設定
  • 提案に意思がない
  • 総花的な機能
  • 営業の出来るよね

はっきりしないスコープとは、顧客もプロジェクトの目的、目標を伝えられない状態で、提案サイドも提案スコープを決められないことを指している。リミットとなる界面か基準がなければスコープはクリープするだけである。ましてや提案サイドが提案時にスコープのクリーピングにキャップを掛ける意識がないならクリープすること間違いなし、である。

ロジックのない価格設定とは、言い換えれば見積もり根拠を持っているか、である。面白いのが、たとえ工数提供であっても、提供時間を厳密にコントロールして超過したら無慈悲に請求するか(もちろん減額請求には応じない)、業務量の調整で提供時間を超えさせないとデスマにならない。見積もり根拠を持っていないと、価格調整があった場合の条件闘争で交渉できないと思った方が良い。最初の価格と規模から減額した場合の価格に見合うスコープが導き出せないからだ。

提案に意思がないとは、御用聞き営業でなんでもやりますというアレだ。工数提供であればそれも選択肢であるが、そういった提案には業務課題の解決方法や改善を提案されることはない。なぜなら、エンジニアも指示されたように実現をすることに訓練されているからだ。

総花的な機能とは、実現したい業務課題のITによる解決策の提供ではなく、あれこれと使わない機能まで含めて提案していることを指す。使われない機能を作ることにエンジニアが萌えるかといえばそれはない。

営業の出来るよね、は営業が提案する技術、ソリューションを理解していないということだ。つまり、こじれた時に全く頼りにならないのだ。開発責任者が仕切れれば、というケースもあるかもしれないが、仕切れるくらいなら、営業がエンジニアにつけを回すような発言はさせないだろう。そういうことだ。

あなたのプロジェクトにはいくつあるか。

 

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

 

 

 

ふりかえりの呪い

別にKPTをすると呪われるわけではない。ふりかえり=KPTになっていることがある種の呪縛なのだ。

ふりかえりをするのは、何かしらの目的があるはずだ。この目的を意識してふりかえりの手法を選択する。

例を挙げると以下のような手法がある。年齢層が高かったり、IOS9001をやっている組織が知っていそうな順に並べてある。

PDCAは言わずと知れた手法だ。ISOにはマネジメントシステムとして取り入れられている。plan do check actionのループを続ける。ポイントは、actionからplanへ繋げることころだが、checkで止まってしまうかactionからplanに繋がらないままで放置されるケースが多い。

なぜなぜはトヨタで知られている手法だ。不具合が起きたら、なぜ(起きたか原因を探るために原因を探る質問)を5回繰り返す。このなぜの質問を3回続けると大体のエンジニアは怒り出すか、黙ってしまう。怒り出すエンジニアは、バグが出たら直せば良いと思っている傾向があるので不具合を起こした真因に自力で辿り着くことは出来ない。

KPTはケプトと呼ぶ。けーぴーてぃーではない。大事なのはTのTryだが、もっと大事なことは次に繋げる、ということだ。プロジェクトの完了後にKPTをやっても意味がない。やるなら、プロジェクト期間中に繰り返し行う必要がある。

YWTは、やったこと、わかったこと、次やることで、全体的なトーンとして後ろ向きの言葉を使っていないところが好感が持てるのではないか。

運用する際のポイントは、見える文字にしてから話す、だ。口頭で話し出すとモヤっとし始めて、そのうち一番辛かったことの原因を作ったエンジニアに対する個人攻撃になってしまう。これが気をつけないと自然とそうなってしまう。

慣れの問題もあるので、だから、プロジェクト開始後にルーチンとしてふりかえりを導入することを強く勧める。「金曜16時からはふりかえり」とするのだ。これはアプリ開発に限定しない。インフラのプロジェクトでも、とても効果的だ(実証済み)。

 

以下、 KPTで検索したら出てきた参考書籍。

これだけ!  KPT

これだけ! KPT

 
これだけ!  PDCA

これだけ! PDCA

 
アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう!?

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう!?

 

 

 

アジャイル開発をウォーターフォールの局面に採用する意味はない

これ意味がわからない。

 

tech.nikkeibp.co.jp

 

期間限定公開らしいので、

 

f:id:fumisan:20180530073553p:plain

引用 アジャイル開発で成果出す、浮かび上がった3つの現実解 | 日経 xTECH(クロステック)

 

何がわからないかというと、一部のフェーズに、というくだり。

ウォーターフォールの一部に取り込むということは局面を別の手法に取り替えるということだ。

おかしいと気づいて欲しい。ウォーターフォールアジャイル開発も「システム開発手法」である。まず、プロジェクトの特性を知り、プロジェクトの特性にフィットする開発手法を選ぶことが重要だし、最初にやることだ。

混ぜたシステム開発手法を選ぶということは、プロジェクトの特性を理解できていない部分があると思った方が良い。

その上で、これを読むとさっぱりわからない。

 

 アジャイルのプロセスやプラクティスはどうやって取り入れるのか。代表的なのが、従来のウォーターフォール開発の一部フェーズに適用するパターンである。

引用 同上

 

では、図式化して比較してみよう。ウォーターフォールの一部をアジャイル開発に置き換えた場合のウォーターフォールの局面である。

 

f:id:fumisan:20180530074622p:plain

 これではアジャイル開発を部分的に採用する意味はない。例え、イテレにリリースまでを含めたとしても、要件を見直ししないのであれば、それはアジャイル開発と呼べるのか。

ではと、要件定義まで入れてたら全部アジャイル開発になる。一部分をという発想は破綻しているのではないか。

アジャイルをやった風を周回遅れのSIerや顧客に吹き込むのやめて欲しい。 

 

 

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

 

4年目のエンジニアへの仕事の振り方

新卒で入社から3年まではわかばエンジニアということで、いつでもなんでも聞く権利を持っているから先輩が忙しく働いていようが気にせずに質問しなさい、と言っている。

4年目になったら中堅エンジニアだよ、と。

何も4年目になった途端、質問してはいけないということはない。気兼ねてしたり、誰に質問すればいいか、そんなことからわからないのがわかばエンジニア。

とにかく、知らないことばかりなはずだから、それを臆せずなんでも気になったことを聞いて回れたり、誰が何を知っているかを知ることが大事だ。

チームのスキルマップを作るのは有効だし、マネージャとしても育成の観点で有用だ。ただ、作ったチームのスキルマップを見て聞いて回るほど、わかばエンジニアには余裕がない。余裕がないわかばエンジニアにスキルマップを見て質問しなさい、では本末転倒でしかない。

4年目のエンジニアがいて、扱いとしては中堅エンジニアの入り口に立ったばかりだ。他のチームから移って来たので実は良く知らない。たぶん、普通に優秀な部類の学生だったのだろう。なにせ、処理能力は早い。

年下のエンジニアがチームにいるとついつい単純作業をさせてしまいがちだ。だがそれではエンジニアは育たない。そんな単純な仕事なら派遣を雇ってやってもらった方がコスト的にも有利である。社員は価値のある仕事をやってもらわなければならない。

それをリーダ役のエンジニアは考えて仕事振る必要がある。

  • 考える仕事を与えること
  • 自分で仕事を選ばせること
  • 流れのある業務の全てを渡すこと
  • 成果物、インプット、をすり合わせること

ポイントは、仕事をパーツにしてから渡すのではなく、担当する仕事の世界観を掴ませさせることだ。

こうした仕事の渡し方を繰り返しすることで経験を積ませる。たとえ、チームの中での分担であっても、仕事の進め方が覚えられる。

こうした仕事のやり方を覚えずに中堅エンジニアのまま年数を重ねているエンジニアが少なくない。

ただ、仕事を振る側が考えている結果を摺り合わせと称して実態は押し付けるようなことはしてはいけない。それでは単に仕事を振る側の業務を代行しているだけになってしまうので。

その仕事をする主役は中堅エンジニアなのだから。

 

誰からも「気がきく」と言われる45の習慣

誰からも「気がきく」と言われる45の習慣

 

 

 

 

 

自分で決めたことを実現するのは実はとっても大変という話

また、人と歓談した際の気づきである。ある役員にインタビュー形式でその方のキャリアを聞いているとき、途中でこんなことを口にされた。

 

「自分が言ったことをやる、ということは大変だった」

 

実際にはその大変だったこと実現されて、分掌が変わったときに代替わりをしたので肩の荷が下りたらしい。世代交代もどうしたものかと思っていたら、部下から手が挙がったのが嬉しかった、と。

 

「自分が言ったことをやる」ことについて、自分自身を振り返ってみると、やはり出来ていないことの方が多い。あれこれしようと思っていてもそのとおりになっていない。仕事は大見得を切ることはないので淡々とこなしているが、思い通りにならないのは仕事以外のことばかりだ。

あれこれやりたいと思っても出来ること、やらなければならないことを優先してしまうので、もう少し新しいことなり、基礎力的なところをやろうとするとついつい後回しになってしまう。

「言ったことをやる」だけにフォーカスすると、逆に出来ていないことは「言わなかったこと」ばかりだ。よく自己啓発系の本や自己実現の本に書かれているように、言語化したり、可視化しないと実現できないというのは、こうしたことの裏返しなのかもしれない。

ただ、それだとおかしなことになるのが、実現できたことも誰にも言わなかったことばかりだ。仕事なら共同作業や分業をするだろうから、言語化したり可視化しないと協働するためには言葉として発する。

権限や予算をつけてもらうなら、上司なり決裁者の許可なり、同意を得るためにやはり言葉にする。

そう考えると、オフタイムで何かをするということは、実は仕事以上に大変なのではないかと思い至る。

なぜ大変かということを考えるとき、誰が許可をしているかという観点があることに気づく。仕事なら上司や決裁者である。そのリソースを使って良いという判断がなされる。

では、オフタイムでは。

権限を持つのは自分であり、自分が自分にやって良いと意思決定しなければ始まらないし、更に言えば、自分か自分に対してやろうと言わなければならない。

ここで出来ることや外部制約的にやらなければならない方を優先していると結果的にオフタイムでは手付かずのままで時間だけが消費されているのだ。

言ったことをやるだけでも大変なのに、言ってないことを実現するのはもっと大変なのだ。とは言え、あれこれやりたいとベラベラと口に出してもワナビーなのだが。