帰りのきっぷ

えきねっとで帰省の切符を予約していたのですが、手配に不備があって帰りの切符の予約がとれていないことが発覚。みどりの窓口でハニワ顔になっちゃいましたよ。

まぁ、しゃあないので、もう一度予約を試みるのだけど、難しいだろうなぁ。最悪、飛行機かな。高いけど。つーか、飛行機も空いているのかしら。何がきついってね、このえきねっとのUIが恐ろしく使いづらいのよね。そりゃ、この予約システムを開発したPM/PL/SE/PGさんは大変なご苦労があったとは思うですけど、満席だった場合に最初から条件指定をやり直さないといけなかったりってのは・・・とってもつらいのユーザとして。無理からなスケジュールの前に品質落としたりとかあったのかしら・・・などなど『黒い展開をリアルにイメージしてしまう』のですが、同業者として。他にもねぇ、「あぁ、たぶんここ、この仕様で納得してもらうの大変だったろうなぁ。よかったねぇ。でも、やっぱユーザ的にしんどいよ？」な箇所が色々^^;自分もそうだけど、目の前に納期をぶら下げられるとね、関係者にとってはもぅそれが絶対になってしまって、他の色んなところ、特に品質要求、性能要求、そしてユーザの使い勝手の要求は無視されがちなんだよね。でも、結局、無理矢理納期に間に合わせたところで、使われない、使いにくいシステムじゃ、それまでに投入したリソースが台無しになってしまう。開発側にとっては開発するまでがプロジェクトのスパン、スコープになってしまいがちだけど、顧客にとってはそのシステムを使って、目的の成果をあげるところまでがスコープだから。

当然ですけど、納期に間に合わせなくていいなどと言っているわけではないです。納期に間に合わせるために、プロジェクトの目的に照らして必須ともいえる要求がモレたり、制限をつけざるを得ないような事態に至ることが問題ですよね。プロジェクト毎に事情は違うと思いますけど、約束できないスケジュールを提示したり、受け入れてしまったり、プロジェクトの目的を抑えずに無軌道に余計な機能を増やしちゃったり・・・大抵、そんなこんなの積み重ね。少ない経験ですが、それでも経験上思うのは、プロジェクトの成功にはPM/PL/SE/PGの各人の様々な貢献が影響しますが、失敗は大抵PM/PL/SEの問題ということですね。プロジェクト管理の問題が実装部隊を大変な思いをさせ、また、その努力を水泡に帰させることの多いこと。えきねっとでいえば、たぶん、数人でよいからユーザテストを定期的に実施し、フィードバックを得ることをスケジュールに組み込むべきだったんじゃないかな。その必要性をPMはちゃんと顧客に説明できなくちゃいけなかったし、顧客担当者にもベンダーにその実施を訴えるぐらいのことはできてしかるべきだったんじゃないかと、そう思います。他山の石にせねば。