なにもないへやですがごゆっくりどうぞ

独学フリーランスエンジニアの勉強部屋

思考 本棚

【気づき】デッドライン ソフト開発を成功に導く101の法則【読書感想文】

投稿日:

Twitterのフォロワーさんから紹介していただいた本を読みまくろう!企画、
第2弾はイチゴジャムさんからの紹介で「デッドライン ソフト開発を成功に導く101の法則」でございます。

僕は現在、フリーランスのエンジニアとして仕事をしていますが、複数人チームでソフトウェアの開発を経験したことはないんですね。
そもそも業界未経験からこの世界に足を踏み入れたので、この「ソフト開発」というものがどういったものか、いまいちピンときていませんでした。

でも、本書を読み進めていると今までの仕事で経験したプロジェクトや仕事の進め方と共通する部分があり、非常にわかりやすかったです。

考えてみれば、ソフト開発という特殊なものであったとしても仕事の進め方というところまで抽象度を高めれば、必要な要素はそう大きく異なることはないのかもしれません。

そこで、本書を読んだ中で僕が感じた大切な要素を3つの切り口でまとめてみました。

その3つの切り口とは

・プロジェクトの事前準備
・プロジェクトの進め方
・プロジェクト管理者に必要な能力

です!

 

1.プロジェクトの事前準備

 

プロジェクトを始める前には準備が必要です。
ただ、なんとなく準備すればいいのではなく、
「管理者の仕事は、プロジェクトが始まる前にほとんど終わっている」
と言われるほど事前準備は大切なことであり、
管理者のメイン業務でもあります。

ではどういったことに気をつけながら準備をするといいのでしょうか。

 

必要な人材を採用(配置)する

会社単位でいえば採用、プロジェクト単位でいえば配置、といえます。
まずは業務に適した人材の確保が必要ですね。

ちょっと話は逸れますが、組織はトップで決まります。

トップの考え方、価値観、理念によって組織が形作られます。
会社でいえば社長、プロジェクトでいえばマネージャーですね。
マネージャーも会社の一員ですが、プロジェクトを実際に動かすのはマネージャーですので多くの権限を与えられていることでしょう。

僕が今まで多くの採用業務を手掛けてきた経験からすると、成功する採用活動というのは
「トップの直感と現場の意見を融合させる」
ことができたときです。

トップの直感というのは、なんとなく決めるというよりは、多くの修羅場をくぐり抜けてきた経験に基づく感覚、というものです。
今後の会社やプロジェクトを進めていくうえで、どういった人材が必要になるか、言葉にはできないけど理解している、という状態ですね。

ただ、それだけでは新しく採用される人と既に働いている人がうまくやっていけるかはわかりません。

そこで、現場の意見を取り入れることで、感覚と論理を融合させるわけです。
どれだけ優秀な人であっても、組織の雰囲気や方向性に合わないとうまくマッチしませんので、プロジェクトに誰かをアサインする際には注意深く選びたいものです。

 

仕様書を作成する

 

自社、お客様、外注先など、利害関係者が多ければ多いほど対立が生まれます。
誰かにとっての最善が、他の誰かにとっても最善であることはなかなかないわけですよね。
その場合、Win-Winの関係を作るためには対立を解決する必要があります。
しかし、根本から解決することはなかなか難しいので、その場合は「仲裁」が必要になってきます。
お互いの利益になるところを中心にしつつ、どうしても譲れないところと、譲歩できるところを探ります。
こうした仲裁役はプロジェクトの進行に大きな貢献をすることでしょう。

また、本書では
「入出力の完全なリストのない仕様書は、見込みなしである」
とぶった切ってます。

他のどの要素が入っていたとしても、入出力の仕様が明確でないと成り立たない、ということですね。
この点を意識しながら対立関係を仲裁していく、ということが必要になります。

 

リスクを管理する

 

人は安全な状態が確認できないと、リスクをとった行動をすることができません。
リスクをとらないと失敗することはありませんが、それに伴う利益も得ることができません。
利益を得ないプロジェクトはそもそもやる意味があるのか、ということになりますので、
ここではリスクを避けるのではなく、リスクを管理することが大切、ということになります。

トップを中心にリスクを管理するのですが、大切にしたいキーワードは「予測」です。
リスク管理における予測とは、
リスクが発生する確率を予測する
リスクが発生した際のコストを予測する
リスクが発生しそうな兆候を予測する
ということ。

こういった予測を積み重ねることで、安心して挑戦することができますし、プロジェクトの成功率を高めることができます

 

設計書を作成する

 

本書では設計書の作成方法について細かく書かれているわけではないので、具体的な方法については他の本で勉強したいと思います。

ざっくりまとめると、
・要件定義
・外部設計
・内部設計
・プログラム設計
・テスト設計
といったことが網羅されていれば良いかと思います。

ベテランエンジニアの方から聞いた話だと、昔は開発のほとんどの時間を設計書作成に費やしていたのだとか。
今では依頼者とコミュニケーションをとりながら、変化に強い開発が主流になりつつあるということで、僕も実際に、設計書がほぼない状態で開発依頼を受けたことがあります。
調べながら、ヒアリングしながら、実装してテストして、挙動を確認してもらって…のくり返しだったので、未経験から手掛けるにはちょっと苦労しましたね…

なので、経験値が少ない人をプロジェクトにアサインするのであれば、この設計書はかっちりとまとめつつ、変化にどう対応していくか?というところがマネージャーの腕の見せ所でしょう。

 

小さくスタートする

 

僕はこの考え方がめっちゃ好きで、いきなり大規模なことを始めるよりもプロトタイプでスタートする方がいいと考えています。
うまくいくかどうかわからないことに多大なコストや人員を割くよりも、小さく始めてうまくいったことにコストや人員を割けばいいんですよね。

受注して始まったプロジェクトならいきなり大規模にやってもいいかもしれませんが、自社開発などのプロジェクトであれば小さく始めましょう。

プロジェクトとは少し違うかもしれませんが、僕が新しくサービスを立ち上げたいと思ったときも、必ず小さくスタートします。
むしろちょっとしたテストぐらいのレベルで始めます。
数人の友人から話を聞き、ニーズを見極めて、なるべくコストをかけずに小さなサービスをつくる。
それをその友人に使ってもらい、フィードバックを得て改良しながら徐々に広めていく。
これならコストをあまりかけられない個人事業主でも何らかのサービスを立ち上げることが簡単になります。

最初の段階でうまくいかなかったら、改良コストも撤退コストもたいしたことがないですしね。
小さくスタートする、という考え方は効果抜群です。

 

2.プロジェクトの進め方

 

プロジェクトの準備ができたら、次は実行の段階になります。

設計されたものを実行するうえで大切にしたいことは

・生産性を高める
・良いコミュニケーションをとる

ということです。

これらを細かく見てみましょう。

 

生産性を高める

 

僕は新卒でメーカーに入社したんですね。
で、一番大きな顧客がトヨタ自動車なので自社の工場に「トヨタ生産方式」を徹底的に取り入れていました。
僕は営業だったのであまり細かいところまでは理解できていませんが、その考え方は工場における生産以外にも広く応用することができます。

その中でも、一番よく言われていたのが
「ムリ、ムラ、ムダを取り除く」
ということ。

生産性を高めるためにはいきなりムダを取り除こうとするのではなく、まず最初にムリな作業を取り除く、ということです。

ムリな作業をするとムラが発生する。
ムラが発生すると対応するためにムダが生まれる。

なので、ムダの原因はムリな作業、ということなんですね。

例えば床に置かれた重たいものを作業机の上に置く、という動きは作業者にとってつらいものです。
つまりムリが生まれています。
そうすると作業者のケガにもつながりますし、落として部品を壊す危険性もある。
重たいものを動かして作業するのでムラも発生し、不良品を出さないためにも厳しい品質チェックなどのムダな仕事が増えます。

そうしたことを防ぐために、
作業机を上下に可動するようなものに買い替えるとか、
床の上に置かず腰の高さぐらいの場所に置いておくとか、
そもそも仕様変更をして軽い部品にするとか、
そういった変更が必要になってきます。

こういった改良は常に行う必要があり、いつも通りやっているから、という理由でなんとなく手掛けていけはだめだということですね。

また、プロセスを改良するには長期的投資が必要になります。
初期投資にコストがかかることが多いのですが、確実に回収できるものであれば投資として実行していきましょう。
上記で言う作業机の変更、生産工程の見直し、仕様の見直しには時間もお金も労力もかかりますが、確実に回収できそうであればすぐにでも実行すべきですね。

 

良いコミュニケーションをとる

 

デザイン会社で管理職に就いていたとき、部下とのコミュニケーションで一番気を付けていたことは
「悪いことほどすぐに報告してもらえるような関係をつくる」
ということでした。

やっぱり自分がかかわっている案件でのミスというものは、できれば上司には隠しながら解決したいものです(…ですよね?笑)
ただ、うまく解決すればまだいいかもしれませんが、経験値が低いうちにはそれもまた難しい。

なので、傷口がどんどん広がって、自分一人では対応できないぐらいまで悪化する可能性の方が高いです。
ですので、まだ傷口が浅いうちに、なるべく早く上司に報告する必要があるのです。

これはプロジェクトにおけるリスク管理に近い考え方かもしれません。
ちょっとでもうまくいかないな、おかしいな、と感じたことについては、さっさと上司に報告する方がいいです。
「そんな細かいところまで報告しなくてもいい」
と言われるまで(言われても)報告したほうがいいですし、自分が管理者の立場であればそういった報告をしっかりと受け入れられるような人格を持つ必要があります。

また、悪い報告をしてもらうことと同様に、わかったつもりで動く、動いてもらう、ということもNGですね。
あまり理解していないのに重要な業務を担当していると、必ずミスが発生します。
理解をしていないと作業内容や数字の違和感に気づかず、そのまま進めてしまうからです。

実際に、僕が前にいた会社で、経理担当者が事業の売上や原価の規模をあまり把握していないまま処理をしてしまい、利益の桁が2桁以上変わってしまうようなミスをしていたこともありました。

やはり自分がかかわる業務に関しては、わかったつもりですとそういった違和感に鈍感になってしまい、気づいたときには大きなミスをしていた、という事態になりかねません。

 

3.プロジェクト管理者に必要な能力

 

ここまではプロジェクトにおける事前準備と進め方を見てきました。

ではそういった仕組みがあれば問題なくプロジェクトが進むのか?と言われると、一概にそうとは言えません。

プロジェクトの成功は、管理者の能力にかかっています。

では、管理者に必要な能力とは何なのか。

これはGoogleの社内調査「プロジェクト・アリストテレス」という有名なプロジェクトがありまして、
「社員の生産性を高めるためには、チーム内での心理的安全欲求を満たす必要がある」
ということです。

心理的安全欲求とは、自分をさらけ出しても大丈夫だと思いたい、という欲求ですね。
仕事における対人関係ですと、友人や家族のように素の自分をさらけ出すことは難しいかもしれません。
しかし、成果の高いチームはこの「受け入れる風土」がしっかりと根付いているとのことなのです。

もちろん、なんでもかんでも出していいというわけではありませんが、
たとえば
「怒られるから悪い報告をしない」
という先ほど出てきたことを、どれだけマネージャーが受け入れられる雰囲気を作るのか、ということです。

また、
・プレッシャーをかけない
・脅さない
・怒らない
ということも管理者にとって必要な能力です。

これらのことを行って、プロジェクトが潤滑に進んだことがあるでしょうか?
多くの場合はメンバーが委縮してしまい、プロジェクトの進捗が滞ることがほとんどではないでしょうか。
メンバーも居心地が悪くなり、能力を発揮することもできず、プロジェクトは失敗の方向に向かいます。
そうするとマネージャーはさらにプレッシャーをかけ、脅し、怒ることによってメンバーを動かそうとします。

これらは管理者の能力不足を表しているので、マネージャーとして向いていないのかもしれません。

本書では簡潔に2つの表現を用いて、この必要な能力を表現しています。

 

①心で指揮をとる、腹(直感)を信じる、組織に魂を吹き込む、くだらないものを嗅ぎ分ける鼻をもつ
②「個人の権力と影響力の目標」が「組織の目標」を上回ったらそのトップは辞めるべき

 

プロジェクトの管理者はこの2つの考え方を頭に叩き込んで、実際に行動することによりメンバーの心理的安全欲求を満たし、プロジェクトを成功に導いてほしいものですね。

 

まとめ

 

以上のように、エンジニアによるソフト開発だけでなく、いろんな仕事に当てはまりそうなところをピックアップしてまとめてみました。

会社やチームのやり方、方針などはあるかと思いますが、少しずつでも本書に書かれていることを取り入れることができればプロジェクトを成功に導くことができるかもしれません。

ぜひ参考にしてみてください!

-思考, 本棚

Copyright© 独学フリーランスエンジニアの勉強部屋 , 2019 All Rights Reserved Powered by STINGER.