第三回目 2013.09.13

三回目となった勉強会。

今回は趣向を変えてというか、司会を変えて行いました。

もともと、持ち回り性で行いたいなって思ってましたしね。

今回のテーマ、議題は司会者の方におましました。

んで、議題は

「OAuth認証について」

「見積、契約で失敗しないために…」

になりました。

まず、OAuth認証について。

いわゆる、Facebook認証やTwitter認証ですね。

最近のWebサービスやログインを伴うアプリケーションにはほとんど実装されていますし、大規模なサービスを提供しているサービスにはOAuth認証APIを提供しています。

ユーザ管理の煩わしさが軽減されるのと、ユーザにとってもいちいちユーザ情報を入力する必要も無く便利になりますね。

実装の方法等の説明を交えながら、質疑へ…。

質疑では、便利さの裏側にあるいわゆるセキュリティの問題が議論になりました。

…てか、問題にしちゃいました（笑）

一時期OAuth認証での漏洩なんかも問題になりましたしね。

まあ、漏洩が発生したのはOAuth1.0ってバージョンで2.0ではだいぶ強化されていること、トークンっていう認証情報は有効期限が決められるっていうことのようで、セキュリティ面も年々強化されているみたいですね。

またひとつ勉強になりました。

続いて、見積、契約で失敗しないために…というテーマで何個か事例を出して、ディスカッションを行いました。

 【事例１】

Accessの生産管理システム

・バージョンアップ

・SQLServerリプレイス

・新機能追加

・一部不具合修正

 

旧システムの仕様をさらっと確認したSEが見積もりを出し受注。納期ぎりぎりになり要員がいない状況。仕方がないので、設計書なしで製造したが、テスト時に旧システムがバグだらけ！と気づく。旧システムのバグも修正するはめになったが、納期が迫り、必須機能を先に段階的に納品し、一方で新規機能を平行開発する。納品後に追加要望あり軽微であったため、修正を行ったが、新規機能の開発が遅れ、検収されずグダグダ。

結果、大赤字。

 

う〜ん、よくある炎上プロジェクトですな（笑）

 

どこに問題があったのでしょうか？

司会者氏は設計を端折ったのと期間が短かったのが敗因とおっしゃりました。

はい、ここで私がいつも通り噛み付きます（笑）

期間が短いのが失敗の原因であり、期間が長ければ炎上せずに済んだか？

期間が長ければそれだけ人件費がかかりますね。納期というスケジュールは守れたかもしれませんが、赤字を回避出来たかは…。

私も含め、エンジニアってのは見積もりって言えば工数、スケジュールに視点が行きがちではありますが、会社やプロジェクトとしては見積もり工数をオーバーしていても、損益分岐点を下回っていなければ、まあ、赤字ではないですよね。

１エンジニアにはなかなか難しいことかもしれませんが、やはり原価をある程度把握出来ることって大事じゃないのかなと思ってます。

単価って原価＋マージンですよね。通常はその単価にそって工数を算出します。

もちろん、非生産部門給与や会社の備品のような経費も関わってくるので、こういった単価について考えるのは経営部門の話なんですけど…。

でも、仮に１人月（１６０時間）の仕事を、１ヶ月定時内で終わらせたのと、残業や休日出勤で半月で仕上げた場合、エンジニア的には後者の方をよくやったって言いがちですが、儲けとしては時間外手当分、損してますよね。

ここら辺くらいは考えても良いのではないかと思ってます。

さてさて、ここらで議論は工数についてのお話になっていきました。

工数を見積もる場合、みなさんどうしてますか？

通常は順調にいった場合の工数＋リスクって言うので出していると思うんっすよね。

ただ、こういったのって、経験則に基づくってのが多いじゃないですか。

仕様が大雑把な場合は経験則ってのでしか工数を出しようがないのは事実ですね。

リスクがどこにあるのか、この顧客はコロコロ仕様を変更があるとか、この技術はこういった箇所がネックになるとか…

経験でしか分かりません。それを定量的に把握するためには、キックオフ、進捗会議、反省会ってのが大事ではないかと思ってます。こういった場で、予定オーバーした要因を把握することで次ぎに活かせるのではないかなと。

ただ、そのPMやPLの頭にだけあるのではなく、しっかりドキュメント化していくことで、次のPM、PLの失敗を軽減できると思ってます。

【事例２】

 AccessからWebシステムへのリプレイス。

 要件定義を作成する。この工数は最終的に製造見積もりに乗せるし、 失注時は要件分は請求可 （何と！！）。

ユーザは「金額高杉ワロタwww」って状態。

契約もままならなくなったので、次回からの案件では要件定義って内容で契約することって上司から言われた。

要件定義の工数ってどう出せばいいでしょうかね？

 

 

ここら辺で時間がなくなったので、だいぶ駆け足になりました。

 

わたしも、とりあえず意見だけ述べるに集中（笑）

 

要件定義の工数って確かに難しいですよね。

製造のような積み上げるべき具体的なものもないですし。

個人的にはプロジェクト全体のスケジュールから割ける時間を割り出すしかないと思うんですよね。

 

 

そんなこんなで時間が来て終了。

う〜ん、ちょっと不完全燃焼ぎみ。

わたくしが自分の意見を述べすぎたかと反省…。

 

 

でも、見積もりって様々な人間模様が入り交じったものですし、

もっと深く掘り下げても良いかもしれませんね。

また題材としても面白いと思います。

 

 

司会者氏の感想

人の意見を引き出すことが難しかった。もうちょっと人の意見を引き出せるような発表を出来るようにしたい。

との事でした。

 

 

 

さて次回は誰かやりたいって人いないっすかね？