2017年06月02日

「受託開発の極意」なる本を読んでみた

2712948297_3ba87d8548_z.jpg

こんばんは、komeshogunです。
いいお天気が続きますね。いよいよお外に行くのが楽しくなってきました。
天気のいい日に外に行くだけで本当に気分があがりますよね。
さて、今回は、そんなあがった気分で読める本の紹介です。


結構前の本なのですが、いまも変わらずに「まさにそうだよなー」って思いながら読める本です。
まだ読んだことなくて、受託開発している人はぜひ読んでみて下さい。

ちなみに受託開発とは、

受託開発とは、仕事を受けてシステムやソフトウェアを開発する事を言います。 つまり、どこかの企業や組織から「こんなシステムを作ってくれないか?」 と依頼を受けて、それにあわせたシステムを作り上げることを言います。

受託開発の仕事内容はどんなもの?7つのステップ

P.18 顧客満足は品質・コスト・納期といった「結果として評価できるもの」(「測る」評価)だけではなく、人としての信頼感・組織としての安心感・共に頑張っている感などの「過程を通して評価を感じられるもの」(「感じる」評価)からも得ることができるのです。〜中略〜。技術力や結果だけでなく、過程も重視しましょう。これを「サービス中心主義」と呼びます。

とてもうまく表現されていますが、本当にこれを実感します。前者はできて当たり前のことなので、後者への評価が重要ではないかとすら思っています。もっと言うと、前者で許されるかどうかきわどい失敗をしても、後者が補ってくれることがあります。システム開発をしていると言っても、発注者も受注者も人間なので、こういった感情面は非常に重要です。繰り返しになりますが、前者が出来ているのは「当然」であり、前提としています。しかし、この両者のバランスにかけた話が非常に多いです。両方を意識している人は意外と少ないように思います。だからこそ、両者に目を向けられる人、両者を満足させられる人は評価されるのでしょう。


P20 Socail Change Starts With You

"Social Change Starts With You":An Agile Way
めっちゃいいですね、この考え方。アジャイル、XP、スクラム。このあたりへの興味が今更ながら高まっているのは、こういうところからかな。

P21 お客さまは敵ではありません。解決すべき問題に対して一丸となって臨む姿勢とムード作りをしなくてはならない。

敵をつくったほうがチームの結束力が強くしやすいのでしょうか。以前のリーダーで、すぐにだれか一人を敵に仕立て上げて、それ以外のメンバーとの対立構造を作り出し、メンバーの結束力を強めている人がいました。結束力を高める目的があったのかどうかは聞いたわけではないので分かりません。しかし、特定の方を敵に仕立て上げていたのは間違いないです。その人がプロジェクトから離れると、今まで敵だと言っていなかった人を次の敵にしてしまいました。この敵は、お客さんだけではなく、チーム内のメンバーからも選ばれていました。言葉は悪いですが、出来の悪い人を悪者に仕立て上げる。お客さんの場合はもちろん、陰でコソコソ言うだけですが、メンバーの場合はあからさまに見せしめのごとく、他メンバーの目の前で叱る。それで権力を示したかったようですが、私には逆効果で、こんなリーダーにはなりたくない、二度と関わりたくないなと思いました。あまりにもヒドイので、止めたほうがよいのではと提言しましたが、若造の言葉は聞く耳を持たれませんでした。



p37 「ざっくりと見積もって下さい」などと言われ具体的な話が聞けない場合もありますが、そのような場合でも何らかの理屈付けは必要です。

あるあるワードですね。ほかの業界でも聞くワードなんでしょうか。すごーくゆるーーーい要望がだされて、それをシステムにすると行くかくらい必要ですか?と聞かれるという話です。システムを作るには、人が必要ですし、もちろん、パソコンやサーバーなど機械も必要です。またいつまでに作らないといけないのか、なにかお客さんの会社の制約がないのかを聞き出さないとかかる人件費は変わってくるでしょう。そしてなにより、簡単な業務のシステムなのか、ベテランでも苦労しているような複雑な業務のシステムなのか、複雑な業務でも簡単になるように業務ルールを変えても良いのか等、システムをどういう風に使いたいのかが決まっていないと、システムを作ることはできません。「そんなこと分かっているよ」だけど、システムを作るためには、少なくても何百万という膨大なお金が必要となるため、目処を知りたい。その考えも理解できます。なので、本二も書かれていますが、提案のバリエーションを沢山かいたり、こういう前提で費用を算出していますよ、と前書きしたりします。このバリエーションや前書きがとても大事です。「こいつ、分かっているな」をお客さんは測っています。ざっくりなのに、「こいつ、分かっているな」を提示しないといけないのは本当に難しいことを要求されますが、そういうもんです。


P55 システムで「なにを実現したいのか」を聞き出すには、普段「どうやって実現するのか」を中心に考えている開発者には思いのほか難しいことなのです。

上の話から繋がりますが、見積りや要件定義のときには、目的をききだすようにしないとあとでえらい目にあいます。こんなもの作られても誰が使うの?使える人いないよ?いまの業務にあわないよ!といったところです。ITが好きなお客さんや既存のシステムに詳しいお客さんにヒアリングをすると、やり方・変えて欲しいところをピンポイントで依頼されることもあります。しかし、そんなときこそ注意しないといけません。本当に奥のほうまで仕組みを理解していたらいいですが、あまりそんなことはありません。想像で語っておられる事が多いので、この場合でもやはり「目的」を聞くようにしましょう。そして、「なるほど、それならおっしゃる方法で出来ますね」と言えばいいだけの話です。


P73 ドキュメントは保守のために書かれます。開発者と保守担当者が異なる受託開発にとって、ドキュメントは絶対に必要なものです。

今の組織にきてからというものドキュメントの書き方、内容の細かさに驚いています。誰がここまで見るんだろうと思っていたのですが、ほんとうに細かいところまでドキュメントをみて保守・運用されています。ソース見たらいいやん、の考えがあったし、保守メンバーもそうやって最終はソースみていて、対応していました。でも、ここではそれが通じません。なぜならソースを見ないからです。スキルアンマッチのために、ソースを見れないんです。ドキュメントに書かれていることが全てであり、ソースとドキュメントがズレていることも許されません。細かな部分に至るまで同期していないといけません。また、ドキュメント化する際も、ソースが読めなくても、技術が分からなくても仕組みがわかるように書く必要があります。ユーザ説明用の仕様や要件定義をまとめた資料ならまだ理解できるのですが、プログラムの設計書もそのレベルでかからないといけません。保守担当もソースが読めないため、こういう対応になります。まだ近くにいるなら良いのですが、開発と保守は別会社だったりもします。「保守の人でも読めるように書いてください」なんてお客さんから指摘されることもありますが、「え、このレベルがわからないなら保守任せないほうがいいよ」と思うのですが、政治的なナニカがあるみたいです。保守ってシステムにとっては大事な役割だと思うのですが、ちょっと軽く見過ぎじゃないかなあ。困ったら「開発の皆さんのフォロー」を期待されても困ります。


P99 定期的な作業はもちろん、アドホックな対応の場合でも、作業が極力自動化し、次の作業に再利用できるようにしておきます。

つねに次に同じことをやることを見越して手順を整備したり、ツールを用意するようにしています。でも、周りを見渡すとコレをやっていない人が多くてびっくりしますね。どうやってやったんですか?なんて質問すると、「こうやって〜」ととてもめんどくさそうな、根性がいるような手順を説明されます。「面倒くさくなかったですか?ミスしてしまいそうですね」と言うと「そうですか?こんなんまだマシですよ。あれなんて〜」となぜかさらに面倒くさいものを教えてもらうという謎の流れになります。きっとこういう事の積み重ねが残業につながっているんだろうな。そして、工夫した方が早く終わって、簡単に終わったかのようになって、溢れた人の仕事を丸投げされたり、されなかったら給料が少なくなったりする。工夫したほうが負けみたいなのはどれだけ考えてもやっぱりオカシイですね。こんなことを毎回書いていますが、全く言えないようになるのはいつになることやら。


P142 正しい変え方とは、「外部からのフィードバックをモチベーションに、今までの自分との連続性を意識して、途切れること無く続けられる」やり方となります。まず、変化を開始するには今の自分を知り(know)、その連続線上に変わったあとの自分を思い描きます(Image)そして変わるための行動(Move)を継続するためにフィードバックを得やすい仕組みを盛り込み、最後に変われた自分を好きになれた(Love)ところで、変化はいったん完了します。

怪獣活動においては、Moveまではなんとか出来ている気がする。さいごのLoveの境地なんてたどり着けるんだろうか。実務ではどうだろうか。Imageまで出来ているけど、Moveのフィードバックの仕組みなんて無理だな。面談の時間でさえ、あの有様なんだから、より細かなフィードバックなんて夢のような話だ。「社員だけのチームミーティングをしませんか」と提言しても「そういうのを大事だと思っている。」だけ言われてアクションがないと、それはオオカミ少年だ。余計に信頼がなくなっていくだけ。実務に期待せず、貢献も意識せず、どう活かせるかだけを考えて行動していこう。

なにかひとつでも気付きがあれば「MeetUp大阪@FBページ」に「いいね!」をお願いします。

posted by @komeshogun at 18:00 | Comment(0) | TrackBack(0) | @komeshogun | このブログの読者になる | 更新情報をチェックする
なにかひとつでも気づきがあれば、Facebookページに「いいね。」をお願いします。