三回目となった勉強会。
今回は趣向を変えてというか、司会を変えて行いました。
もともと、持ち回り性で行いたいなって思ってましたしね。
今回のテーマ、議題は司会者の方におましました。
んで、議題は
「OAuth認証について」
「見積、契約で失敗しないために…」
になりました。
まず、OAuth認証について。
いわゆる、Facebook認証やTwitter認証ですね。
最近のWebサービスやログインを伴うアプリケーションにはほとんど実装されていますし、大規模なサービスを提供しているサービスにはOAuth認証APIを提供しています。
ユーザ管理の煩わしさが軽減されるのと、ユーザにとってもいちいちユーザ情報を入力する必要も無く便利になりますね。
実装の方法等の説明を交えながら、質疑へ…。
質疑では、便利さの裏側にあるいわゆるセキュリティの問題が議論になりました。
…てか、問題にしちゃいました（笑）
一時期OAuth認証での漏洩なんかも問題になりましたしね。
まあ、漏洩が発生したのはOAuth1.0ってバージョンで2.0ではだいぶ強化されていること、トークンっていう認証情報は有効期限が決められるっていうことのようで、セキュリティ面も年々強化されているみたいですね。
またひとつ勉強になりました。
続いて、見積、契約で失敗しないために…というテーマで何個か事例を出して、ディスカッションを行いました。
【事例１】
司会者氏は設計を端折ったのと期間が短かったのが敗因とおっしゃりました。
はい、ここで私がいつも通り噛み付きます（笑）
期間が短いのが失敗の原因であり、期間が長ければ炎上せずに済んだか？
期間が長ければそれだけ人件費がかかりますね。納期というスケジュールは守れたかもしれませんが、赤字を回避出来たかは…。
私も含め、エンジニアってのは見積もりって言えば工数、スケジュールに視点が行きがちではありますが、会社やプロジェクトとしては見積もり工数をオーバーしていても、損益分岐点を下回っていなければ、まあ、赤字ではないですよね。
１エンジニアにはなかなか難しいことかもしれませんが、やはり原価をある程度把握出来ることって大事じゃないのかなと思ってます。
単価って原価＋マージンですよね。通常はその単価にそって工数を算出します。
もちろん、非生産部門給与や会社の備品のような経費も関わってくるので、こういった単価について考えるのは経営部門の話なんですけど…。
でも、仮に１人月（１６０時間）の仕事を、１ヶ月定時内で終わらせたのと、残業や休日出勤で半月で仕上げた場合、エンジニア的には後者の方をよくやったって言いがちですが、儲けとしては時間外手当分、損してますよね。
ここら辺くらいは考えても良いのではないかと思ってます。
さてさて、ここらで議論は工数についてのお話になっていきました。
工数を見積もる場合、みなさんどうしてますか？
通常は順調にいった場合の工数＋リスクって言うので出していると思うんっすよね。
ただ、こういったのって、経験則に基づくってのが多いじゃないですか。
仕様が大雑把な場合は経験則ってのでしか工数を出しようがないのは事実ですね。
リスクがどこにあるのか、この顧客はコロコロ仕様を変更があるとか、この技術はこういった箇所がネックになるとか…
経験でしか分かりません。それを定量的に把握するためには、キックオフ、進捗会議、反省会ってのが大事ではないかと思ってます。こういった場で、予定オーバーした要因を把握することで次ぎに活かせるのではないかなと。
ただ、そのPMやPLの頭にだけあるのではなく、しっかりドキュメント化していくことで、次のPM、PLの失敗を軽減できると思ってます。
【事例２】