ケース3：ワークフローの見直し
3つ目については「ワークフローの見直し」について。
パクえ氏は過去に、「ものの数分で終わるような作業、それこそ『ポチッとな』で5分で終わる作業を『お金が掛かるから』という理由で止められ、実施する為に関係各所に了解を得る形でワークフローを進めることになり、結果として作業を行うまでに5日間も掛かってしまった」という状況に遭遇したことがあるようです。読者の皆さんも、このようなケース（時間の長短はあるにせよ）に遭遇された経験もあるのではないでしょうか。
この問題の要因はズバリ「導入時にワークフローを見直していない」という点に尽きます。解決の第一歩は「タイムスパンに着目して作業の洗い出しを行う」こと。これを行うことでボトルネックが分かるようになり、スケジュールのサイクルを月から日、日から分へシフトさせることや、権限譲渡を行うべき箇所を明確化することができます。権限譲渡を行うべき箇所が出てきた場合は、それらを既定に落としこむことでワークフローの改善を行うのです。
この点については「結構、心して掛からなければならないお仕事でもある、と思います」とパクえ氏はその危険性について解説。
「とある勉強会で『APIを叩いて一気にサーバ200台立てました、イエィ！』というデモを行った場面があったとしましょう。見る分には面白い光景かも知れませんが、そもそもこのアクション、許可されているものなのでしょうか？ 小さい組織の場合ですと、こういった光景（莫大な利用料が会社の経費・財政を圧迫）は会社にとって致命傷となる可能性があります。APIを使った作業については注意しておかないと揉め事に発展するケースも有り得ますので、一度関連情報を見直してみる必要があるでしょう。今時点でなければ、これから用意すれば良いのです。効果はあります」と、参加者がイメージし易いような例を挙げて、問題点と改善点についてコメントしました。
ケース4：管理方法も状況に応じて変えていくこと
4つ目のケースは「PaaSを使っているが、アジャイルにならない」というもの（※パクえ氏の発言の後、ひと呼吸置いて会場から乾いた笑いが起きていました）。
原因は「管理方法が従来のままである」というのが原因です。せっかくPaaSを導入したのに、「要件定義して実装し、納品しました！」「その後上手くサイクル回せてますか？」「いや、サイクル回してません……要件増えても困るので要件定義を長めに、書類を多めにしています」というような状況に陥ってしまっていては本末転倒です。そんな状況に直面してパクえ氏は「デプローイ！ って1回しか叫べないんですね……」と捻りを効かせた（？）コメントを残したと言います。
この件の対応策については、「タスクサイズを小さく、実践サイクルを短くしてループを回す手法にシフトする」ことがあるそうです。このサイクルを回し、まずは小さな成功体験を目指し、その成果を見せてやる。そうすることで周囲も「こういうサイクルで動くんだな」と考えるようになり、工数を定めて要件をどう進めていくかを決める「良いサイクル」を回していくことができるようになります。失敗が減っていき、お客様が望む姿を実現できていくようになります。
この事象に関しては、パクえ氏はRuby on RailsのScaffoldの仕組みが「すごく良かった」と好例として挙げました。お客様の要望に対し、Scaffoldによるプロトタイプの作成をその場で実践して見せて、データの流れ、処理の内容を現場で見てもらう。反応を伺いながら作業を進められるのでイニシアチブを取ることができ、作業も進め易くなったのだそうです。
ケース5：クラウド導入における学習コストの増大
5つ目は「クラウドを導入したら学習コストが増大した」というケース。
これについては、「新しい機能を追いかけることが正しいことだという文化になっている」ことがその要因となっています。
クラウドサービスは既存のオンプレミス環境とは比較にならないくらいのスピード感・ボリューム感で進化・改善を繰り返しています。全ての情報をリアルタイムで逐一ウォッチして行くというのは至難の技とも言えるでしょう。
では、どの様にしてこの課題を解決していくか。
知識面でのアウトプットを行って情報の共有を促進させていくこと、学習にも工数が掛かっているというコスト意識を持つこと、また何の為に学習を行うのかという「課題」を明確化していくことがこの状況を改善・打破していく「処方箋」だとパクえ氏は力説します。
