パスワード文字数の超おおざっぱな最小長の計算
ふと軽く気になったので、おおざっぱに。
前提として「パスワード 定期的 変更」というキーワードがありまして。
個人的に
パスワードの最適変更間隔とその定量的効果の評価
https://docs.google.com/document/d/1RWDerFjLc24nr_lDhF8s0vEOJ8DPKhEnEAYG9qr_oBY/pub
ここが非常に気にっております(笑*1
さて。
パスワードの「最低文字数」をどれくらいにするか……の前提として「空間の広さ」を検討付けておきたいかなぁ、と。
どっかで「5万語の英単語からランダムで5つ」ってのを記憶してたのですが……微妙に記憶違いしていましたな。
https://twitter.com/HiromitsuTakagi/status/978648962449129473
私の推奨は「5万語の語彙の辞書（広辞苑など）をランダムに開いて3つの語を選んで繋げる」（オフライン攻撃想定の「暗号の鍵」の場合は5つの語を選んでつなぐ）という提案。（NISCは採用していない。）
まぁおいちゃんの専門エリアは「オンライン」なのですが、せっかくですので(なにが)。
「5万語から５つ」の場合
50000 * 50000 * 50000 * 50000 * 50000 = 312,500,000,000,000,000,000,000
………単位がもはやよぉわからん(苦笑*2
一応「5万語から４つ」の場合も。
50000 * 50000 * 50000 * 50000 = 6,250,000,000,000,000,000
これもごいすー(笑
当初のお話の「5万語から３つ」だと
50000 * 50000 * 50000 * 50000 = 125,000,000,000,000
いやまぁ十分以下略。
もう一つ、こちらは「パスワードの最適変更間隔とその定量的効果の評価」にある「辞書に載っている10万語を2語組み合わせてパスワード」。
100,000 * 100,000 = 10,000,000,000
………なんだろうこの数値が穏当に見えるｗ
………うん、一旦、目安として「5万語から4つ」を採用してみましょう。なんとなく。
区切りを抜いて数値だけにすると
6250000000000000000
となります(625京………こんな単位、まぁ滅多に使わんなぁｗ)。
ので、これと同じくらいの空間をゲットしてみたいなぁ、と。
まずは「英大小文字＋数字」。文字種類は26+26+10 = 62となります。
計算をしますと
10文字 → 839299365868340224
11文字 → 52036560683837093888
なので、まぁ「11文字以上」で十分な広さが確保できそう。
次に「英大小文字＋数字＋記号」。記号は一旦<>!\"#'$%&()=-@;:,.?*[]{}
の25種類と仮定します。
文字種類は26+26+10+25 = 87パターン。
9文字 → 285544154243029527
10文字 → 24842341419143568849
こちらは「10文字」でいけました。1文字の差を、大きいとみるか小さいとみるか。
で、まぁ、せっかくなので「５万語５文字」への対応も。
記号無し
13文字 → 200028539268669788905472
14文字 → 12401769434657526912139264
記号あり
12文字 → 188031682201497672618081
13文字 → 16358756351530297517773047
なので。
全体的に「14文字以上くらいあればよいかなぁ」と言えそうな感じですねぇ。
「ナニを基準にしてるんだよナニを」とか言われそうですが、あんまり気にしない方向で。
………どっかに「英単語５万語とか10万語とかの辞書データ」落ちてないかしらん？
とかたまに思うんですが、どうなんですかねぇ？？？
歴史………
この世界は、数万年という長い歴史を持っている。
それに間違いはない。
なぜなら、記録にも文献にも、或いは痕跡にも遺跡にも、若しくは記憶にも語り部にも残っている「事実」だから、だ。
とある異端の、狂った学者は言う。
「"数万年"の痕跡がおかしい。これは"本当に数万年を閲している"とは思えない。わずか、10年足らずの、未熟な考察によって"捏造された"歴史なのではないのだろうか？」
そんな狂気にも等しいお話は、人々の物笑いの種にすらならず、虚空へと消え去っていく。
いったい、なんびとが「数万年の歴史を、その記録と文献と痕跡と遺跡と人々の記憶と語り部と、に残せる」ほどの奇跡を使えるというのだろう？
ありえない。それは、どう考えてもありえない。
ありえない。
それはつまり………………………
PMの必要条件に「技術力」は含まれるのか？
インスパイア元は、直近としてはこの2つのツイート。
https://twitter.com/toukatsujin/status/1063208694123393024
いまだに「システム開発のプロマネは技術者でないと務まらない」と主張する人がいて愕然とした。ナンセンスな話で技術者ならやりやすいだけ。技術を知っているしメンバーからの承認も得やすいからね。でもそれに安住して大炎上のパターンもあり。逆に技術者でないとプロマネのコアスキルが鍛えられる。
https://twitter.com/toukatsujin/status/1063212787587903488
この人に「多分そうだろうな」と思って聞いたら、やはりそうだった。「プロジェクトが炎上したらプロマネであっても例えばコードを書いたりするの」に「当然でしょ」の返事。それって戦争で指揮官が職務放棄して最前線で銃をぶっ放すのと同じ。部隊は全滅、開発チームには地獄のデスマが待っている。
先においちゃんの手元を明かすと
・PMは「やってる」けど「特に得手分野ではない」
くらい。
なのでまぁ「1現場の意見」程度に、という前提で。
んと……まず「PMがコードを書くか？」という問いについては
・おいちゃんは基本的に「自分がコードを書く」ために自分でPMをやる(事が多い)
ので(自分で仕切ってたら「自分がコードを書く時間」を自分でひねり出せるでしょ？)。
「指揮官が最前線で銃をぶっ放す」については、普通に肯定的。
ただ「炎上したらコードを書く」「職務放棄して最前線で銃をぶっ放す」だとすると、「炎上しなくても書いてる」し「職務は放棄せずに前線で銃をぶっ放している」ので。
「炎上したからやむなく」とかその結果として「PMとしての職務を放棄して」とかだと、まぁ確かに「それは崩壊の、序曲ってよりもうちょっと先のほうだねぇ」とは思う。
コードは書いても良いけど「職務の一端として"PM"を握ってるんだからね」ってのは、まぁ、肝に銘じていたいところ。
…………いやまぁ「がっつりPMやった上で数人分のコーディング」とか、やると色々死ねるので*1、その辺は適宜、自制したり自重したり自愛したりしてください。
んで。、本題。
「システム開発のプロマネは技術者でないと務まらない」のか？ ってお話。
んと……「技術者」の定義が、不明ではあるんだけど。
一端「相応(以上)の技術力がある」或いは「前線で一級レベルの技術力がある」人、と仮定。
あと。PMのお仕事については。大まかに
・(主にステークホルダーと)利害の調整をして
→げとれるリソース(主にお金)とスコープの調整をして
・リソース(お金、人員、時間 等)を確保して
・計画を立てて
・タスクを人員に割り振って
→品質管理して
→必要に応じて計画のリスケをして
→スコープ、リソースなどを再調整して
→人員間の(コミュニケーション)調整をして
・最終的に納品をする
ってあたりだと一端仮定します＠大体PMBOK参照。
………いやまぁ大概「どんだけ上級職業だよ」とか思うわけなのですが。
上述のうち
・リソース(お金、時間)確保
・ステークホルダーとの利害調整
・人員間のコミュニケーション調整
あたりは、技術力は「あってもなくても」なんですが。
一方で
・リソース(人員)確保
・計画を立てる
・品質の管理(のための手法の選定など)
・「計画のリスケ」のために必要な諸々(と、人員への(技術的)フォロー)
・「スコープ、リソースなどの再調整」に必要な前提知識など
については、基本「結構がっつりした技術力が必要」なんじゃないかなぁ？ と、個人的には思うです。
いやまぁ勿論「PMには技術力がなくて、でも人員で技術力が高い人を入れておく」でもいいのですが。
単純に質問なんですが「そのエンジニアが"本当に"技術力が高いかどうか」って、どうやって判断するんでしょ？？？
その辺の物差しって、せいぜいが「本人のスキルレベルの2倍程度」までしかはかれないと思うんですよ経験上。かつ「スキルポイント割り振ってない方向のスキルの判定は出来ない」ってのが、これは恐らく、ガチ。
ちなみに経験上「しゃべらせたら弁が立つんだけどコードを書かせたらさっぱり妖精が団体でお越しになる」ケースも散見されるので、最近は「まずコードを見せろ。話はそこからだ」って感じになったりしてますねぇ、的余談。
そうすると。
結局の所「PMさんに、相応のスキルレベルがある」事が求められる可能性が高くて。
そうでない場合は「ランダムながちゃ引いて"いいエンジニアさんが当たったらいいなぁ"」な、博打にしかならないと思うんですよねぇ。
いやまぁ「技術力なくてもしっかりとPMが出来ていて、それが運任せじゃなくてちゃんと理論背景に基づいている」ケースが、あるのかもしれないんですが。
知っている限りでは
・技術力のないPMが計画とかそれ以前の「ステークホルダーとの調整」の時点で「できねぇ事を出来るとかほざいて」「あり得ない線を引いて」から現場に持ってきて初手から燃えまくり
なケースを大量に見ているので。
次点で
・いわゆる「リーダー格のエンジニア」が、びっくりするほど「駄目くさい」
ケース。
んで、それって「ちゃんと"技術力"があって、考えればわかる話ですよね？」で一通り以下略した後は敗戦処理、ってなケースが多いので。
ぶっちゃけると「技術力低いPMとか、ないわ～」って思っちゃうんですよねぇ。
経験的には。
いやまぁ「技術力なくてもイけるPMのやり方」とか興味あるんで、なんかコメントとかで「よい」感じのお話とか聞けると興味深いんですけどねぇ。
実際、どうなんだろ？？
*1:比喩的にも現実的にも実体験………
「目で盗め」もきついけど「懇切丁寧」が良いってわけでもなくてねぇ………
直接の発端は、こちらのツイート。
https://twitter.com/tatamin_ttmn/status/1062271330895056896
そういうことやるからあらゆる職人業界の技術継承が廃れていくんだろ…
はっつけてある画像は、確か「将太の寿司」だったかな(うろ覚え)。
「この店では誰も技術を教えてはくれない
仕事のやり方は自分で覚えるしかないんだ」
「えっ……」
「親方の考えじゃ
楽に教わった技術は決して身につかない
苦労して人から盗みとった技術が長くその職人の技術になるんだって「目で盗め」
って言われてるんだ」
こんな台詞のやりとり。
うん………まぁ「技術継承が廃れる」の文脈が、わからないでもない。
ないんだけど、一方で………例えば「法演の四戒」という禅語には「好語不可説尽(こうご ときつくすべからず)」って言葉がある。
もうちょっと続けると
好語説き尽くすべからず。
好語説き尽くせば人かならずこれを易（あな）どる。
って感じ(あと三つの戒があるんだけど、ここでは省略)。
なので。
技術を「全部、自分で盗め。一切教えない」はアウトなんだけど、一方で「懇切丁寧に全部教える」のも結局は「アウトになりやすい」ので。
どうしても「身体で覚えていく」しかないフェーズ、ってのは、あると思うんだよねぇ。
この辺は、どっち側に「極端に」倒しても、あんまりお互いに幸せになれないんじゃないかなぁ、って、割と常々、思ってたりするです。
「じゃぁどの辺が適当なのさ？」ってお話になるんだけど。
多分、この辺は結局、山本 五十六さんの、この言葉に集約されるのかもしれない。
「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。」
ちと、かみ砕いて。
「やってみせ」ないと、そもそも「それ、本当に出来るんですか？」とかって疑念がわいたら、守破離どころの騒ぎじゃないので、まず「出来る事を見せる」のは、信頼を得る意味でも、必要だと思う。
で、それに対して「そら学べ」ではいささか突き放し感が強いので、「言って聞かせて」理論背景の説明をする。
説明を聞いてわかった"つもり"になったところで、じっさいに「させてみせ」て、「つもり」の部分を洗い出してあぶり出して。
あとは出来ているところを「ほめてや」りつつ、出来てないところを「やってみて 言って聞かせて させてみて」の、loop。
……いやまぁこんな丁寧な教育がどこまで出来るか？ ってのは、色々と難しいところではあるのですが。
できるだけ、その辺を目標に「見て学べ」でもなく「好語を説き尽くす」でもなく、良い感じのバランスを追い求めていけたらなぁ、とか、思ってみたり。
「そんな教育をすることが出来るビジネスとスキーム」を作るのが、もしかしたら、喫緊の課題なのかもしれないんだけどね(苦笑
「手作業で30分掛かるものを3秒で終わらせるために3時間掛ける」のは正解なのか？
いやまぁほぼそのまんまな内容で、元ネタも、以前にツイッターで拝見した
https://twitter.com/wakamesoba98/status/1020496602132180992
手作業で30分掛かるものを3秒で終わらせるために3時間掛けるのがエンジニア、という持論を大切にしていきたい
https://twitter.com/poyopoyochan/status/1021258011724079105
これ非難してる人がいてびっくりしたんだけど、6回実施で収支がほぼあって、7回目以降は使えば使うほど効率が高まることに気が付いてないらしい。
あたりのお話なんですが。
端的には「正解なケースもあれば誤りなケースもある」という、まぁ、身も蓋もないお話になります。
ただ、どちら側にも割とバイアスのかかりやすいケースかなぁ、と思うので、軽く。
とりあえず
・「作業」がある：作業
・手作業だと30分：手作業時間
・コード組んで自動化したら3秒：自動作業時間
・でも自動化するコードをくみ上げるのに3時間：コード作成時間
と仮定します。
また、上述のうち「自動作業時間」は「他でなにか別のことが出来る(と思う。3秒で何が出来るかはアナタ次第だｗ)」ので、ほぼ無視してよい時間だと思われるのですが、まぁ。
さてまず「自動化が圧倒的に正解」なのが
・「作業」が、毎日とか週1とか週2とか
・作業内容が定型なので、コード化が100%可能
・定型作業なので、そう簡単には変わらない
ようなケース。
このケースだと割とすぐに「作成コストがペイ出来る」ので、自動化しない理由が特に見当たらない感じですね。
まぁごく稀に*1「コンピュータは信用できない」とかいう御仁がいらっしゃるようですが、じゃぁ人間はそこまで信用できるのか？ と、小一時間。
さて、議論と考察はここから。
前提条件が少し変わってくると、当然ながら出力にも変動が見られます。
まず
・作業頻度が月1
とかの場合。さらには
・作業頻度が年1
とかの場合。
一端、前提条件だと「6回の作業でトントン、7回以上で自動化のメリットあり」になるのですが。半年、あるいは6年の間に「定型作業に全く変更がない、かどうか」が、鍵になってきます。
半年くらいならなんとかなりそうな気もしますが、6年だと、微妙な感じがしますねぇ。っつか「6年間、全く変わらない業務」ってのも……ありそうなんですが、同じくらい「なんだかんだ、毎回微妙に差異がある」ケースもあって、汎化しにくいように思われます。
でまぁ上述にかかってくるのですが。本来的には
・作業内容は、本当に不変か？
というのが出てきます。
細かく変更があったりする場合、変更に応じて、もしかすると「コードをメンテナンスする」必要があるために、コード作成時間が「3時間」ではなく、もうちょっと*2かかるようになります。
この「コードの修正時間」が積み重なると、結局は「トータルして、手作業のほうが早くない？」って突っ込みが入る可能性と危険性が懸念されたり危惧されたり。
さて。
この手の話題が出てくる時に、割とあるのが
・非エンジニアは「作成コスト」に神経質になる
・エンジニアは「手作業をすること」に神経質になる
傾向があるように思われますが、どんなもんでしょうか？
言い方を変えたり追加したりすると
・非エンジニアは「作成コスト」が気になるので、どちらかというと「手作業したほうが早いじゃんなんだよ30分の作業に３時間とか」ってお話になり
・エンジニアは「手作業」を忌避しがちなので「手作業とかありえないでしょ一度作れば以降ずっと同じ処理をほぼ一瞬で出来るのに毎回30分とか正気ですか？」ってお話になり
まぁここにいくつかスパイスとかポイントとか会員ランク( https://gallu.hatenadiary.jp/entry/2018/10/11/234610 )とかの変数が合わせ技になると、割といい感じでバトルになります。
で。いったん「To エンジニア」な発言をしましょう。
「手作業を忌み嫌う」気持ちがわからんではないのですが、「トータルコストとのバランス」を放置すると、あんまり良い顔をしてもらえない事も多いと思うのですねぇ。
で、そんなエンジニアには、こんなアドバイスと入れ知恵を。
まず
・「ある程度変わりそうな所」があったら「手作業と自動化のハイブリッド」でうまいことやる
ってあたりが、一つのポイント。
よくわからん仕様を「100%コード化」するのは、色々と難儀です。
なので「よくわからん、かつヌルヌルと仕様が揺れ動く所」は一端手作業にしてしまって、それ以外の「明らかに機械的な処理」から順次機械化していくです。
ゆっくりゆっくり、業務を侵食していけば、そのうち100%が機械の身体になる日だって、訪れようというものです。
次にもうちょっとえぐるような話をすると
・修正や追加がしやすい、キレイで素直なコードを書く
・少し丁寧に、コメントやドキュメントを残す
あたり。
そのコードを「誰かが引き継ぐ」事までを考えて、あんまりテクニカルにややこしい事はせず、素直にキレイに書いておくと、追加もメンテナンスも引き継ぎもしやすかろう、ってもんです。
こんな風にすると、これらのスキルって「普段の開発」でも普通に役に立つのではなかろうか、と。
で、ここで「非エンジニア」勢にお伝えしたいのが
・「自動化」は、上述のスキルを鍛え上げるために割と便利なので、「トントン」くらいなら、社内のエンジニアのスキルが磨かれるから、十分にメリットがある
って事。
「どこまでを教育コストとして飲むか？」ってのもあるのですが。
ちゃんと意識して書かせたりチェックしたり成果物の批評をしたりすれば、エンジニアのスキルが伸びる方向に行く可能性はとても高いので。
せっかくの機会ですし、単純に「目の前の成果物」だけではなくて、少し中長期的な視野とかを持ってみてもよいかと思うのですが、如何でしょうか？？
もう一つえぐると
・「業務のルーティンの見直し」になる
ってのも、案外と見逃せないポイントです。エンジニアの「厄介でうざい質問」って、見方を変えると「今まで何となく、適当に決まり事なく人によってばらばらに作業している」箇所だったりしませんかね？
そういった箇所を一端「他人の目で洗いなおす」ってのも、業務運用において、割と重要なんじゃないか、とかおもってみたりします。
でまぁその辺を考慮したうえで
・完全に手動がいいのか
・部分的に手動、部分的に自動がいいのか。その場合、どの部分を自動化するか
・完全に自動がいいのか
を、冷静に冷徹に、コストとメリットを天秤に載せながら考えてみるのも良いのではないか？ と思うのですが、どんなもんでしょうか？
ポイントカードと会員ランク(比喩)
西原理恵子先生に曰く
・女の人の感情ってポイントカード
・日常の細かいことをずっとカードに判子で押して
・ポイントがたまると「キャッシュバックキャンペーン」
ってなお話をされてますが。
別に男でも同じようなものなんじゃないかなぁ、と思う事は、少なからずありまして。
お仕事において
・やらかされると、カードに所定のポイントがついて
・ポイントがたまると「キャッシュバックキャンペーン」
ってな感じになるのは、まぁ割と見かける光景でございます。
かつ。
ポイントカードには、大概「会員ランク」とかがあって、ポイントがたまると「ランクアップ」するので。
上位の会員ランクに登り詰めますと、普段は「ポイントがつかないようなほにゃらら」でも、場合によっては微に入り細を穿つように「丁寧に"特典"付きでポイントがつく」場合、なんてのもまた、あるんですよねぇ。
時々「些細な事で急に現場が怒り出したから現場コワイ」とかいう向きがありますが。
一度、自分の「ポイント履歴」とか「会員ランク」とかを確認してみるとよいんじゃないかなぁ、とか思ってみたりみなかったり。
「どこでどうやって確認するのか」は知りませんが。
ただ。
「キャッシュバックキャンペーン」で溜まったポイントは一端下げられても、会員ランクが上がっていれば「簡単にたくさんポイントがつく」ようになっているので、そこをどうにかするのはまぁ「至難の業」ではあるんですよねぇ。
特に「普段からこまめにキャッシュバックをしている」御仁と比較して「普段はポイントを貯めても特に"サービス"がない」御仁のほうが、キャッシュバックキャンペーンとか会員ランク上昇とかの時の「特典」が、大きかったり派手だったり豪華だったり苛烈だったりするので。
とりあえず
・貯めたいポイントは貯めておく
・貯めたくないポイントは貯めないようにする
という、ごく当たり前のお話が重要になってくるように思われるのでございます。
………まぁ気づくのが大抵「キャッシュバックキャンペーンが発生したタイミング」だったりもするので、難しいお話ではございますが。
準委任の請け方
後でまた整理をしたいのですが、ちょいと喫緊で説明をしたほうがよい状況が出てきてしまったので、半ば私信に近いですが、一旦記述します。
「半ば私信」なので、身もふたもない記述も多いので、その辺はお目こぼしいただければ幸い。
さて。
請負は「発注側有利」ですが、準委任は「受注側有利」になります*1。
んで、ぶっちゃけますと。うちらのお仕事は「基本的には準委任のほうが契約的には安全なんじゃないかなぁ」と思う事しきり。
なんでか。
んと………請負で。「完了条件」が、クリアかつ明確かつMECEかつ計測可能で誤解の余地のない状態で存在するのであれば、本来的には「請負だろうが準委任だろうが金額は変わらない」はずなんです。
だって「同じ作業」なんだもん。
勿論、一方に「受注側(＝開発側)」の見積もりの精度、ってのはあるのですが。
もう一方で「どれくらいの"想定外タスク"が発生するか」ってのがありまして。
端的にぶっちゃけると、そもそもとして「完了条件をしっかりとクリアかつ明確に出す」のって、結構なスキルと結構なコストがかかるです。
だって端的に「一度、脳内で全部システムを組み上げないと」わからないわけだし。
もちろん、発注側としては大前提として「システムを完成させてほしい」ってのがありますし、ただ一方で「詳しくとか言われても専門家でもないのにそんなにクリアに明文化とかできるかい」ってのもあれば「"やってみて気づく"事だってそりゃあるよねぇ」ってのは、それはそれで理解できます。
だからまぁ「当初の具体的なお話には出ていないかもしれないけれどもそれがないと"完成したシステム"にはならなくて困るんだから当初想定のお見積もりで全部作ってよ」、と、まぁそうなるわけでございます。
その辺から、よくあるのが
・「仕様の明確化とか抜け漏れのない要求とか」そんな高コストは払ってられない
・からとりあえず「なんとなくこれくらい」で見積もって受注して欲しい
になって。
大体は
・大丈夫、ちゃんと配慮してあげるから無理無茶は言わないから後で美味しい案件も回すから
って言われるんだけどいざ作業が始まると
・あれも追加、これも変更、それも足りない、これも必要
になったうえで
・請負なんだから金額は増やさないけどこっちがOK出すまで全部やれ
って話になるです。………えぇもちろん「ごくまれに」ですが*2。
「過去に小さな案件でスムーズにいった」としても、次の案件とかで「先方に何かがあった瞬間」に豹変、とか、割とありがちなお話なので、気を付けたほうがよいです。
………まぁそもそもとして「下請法*3とか知ってるのかしらん？」 とか思ってみたりみなかったりするのですが、おいといて。
その辺の諸々を考えると
・準委任でお願いします
ってほうが、まだしも「マシ」なんですな。
受注側は「むやみな追加変更を避けられる」し、発注側も本来的には「がっつりした発注書を作らなくてすむ」ので＆予算が確保できるんなら「ある程度、我儘も言えるから」。
もし「あれも追加、これも変更」ってなったら、基本的には「作業時間が増えますんでお支払いが増えますまいどありチャリン」って会話が可能で、泣き寝入りせずにすみますし、受注者も(ある程度)気持ちよく変更を受け入れてくれます*4。
ここで「そんな事したらビジネスが回らないので(スコープは可変だけど)金額だけは固定でお願いしたい」とかいう方は「下請法で禁止されてるようなことをやらせたいんですね」で以上終了なのでお帰りくださいませ。
ただ、準委任って、ものすごく悪い見方をすると
・ダラダラとお仕事時間を引き延ばしてお金をもらいつつ
・やっている仕事の品質もめちゃくちゃで
・仕事を完成もさせずに途中でほっぽらかす
とか可能なわけです。
発注側としては、だいぶんと無視できないリスクなんじゃないかなぁ、と。
なので。
「準委任を、できるだけ発注者側にリスクの少ない形でご提案」とかできるとよいんじゃないかなぁ、とか思うわけですよ。
そうしないと、お互い疑心暗鬼だしね。
まず品質については、下限は「善管注意義務」あたり。
ただ「そこだけ」だとだいぶんと色々、アレがナニなので。「これくらいのスキル持ってて、これくらいの品質を担保しまっせ」ってお話はちゃんとしておいたほうがよいです*5。
個人的によくあってよくやるのが「Webアプリ作るときのセキュリティ」。「IPA準拠」は、わかりやすくも好ましい指針の一つかと思われます。
お次が「仕事の完了」ですが、これについてはまぁ「頑張ります」としか。
言い方を変えると「途中で逃げ出したくなるようなやらかしがなければやり遂げます」と。この辺はまぁ信頼関係ですな。
ラスト。一番大事なのがご予算。
発注側が「請負にしたい」理由の割と大きな一つがここで、つまり「この事案、おいくらかかるの？」ってあたり。
先方にしても「社内稟議とか通して予算をもぎ取ってきている」関係上「予算をオーバーされると色々と社内的にツライ」とか、事情はあると思うのです。
なので、その辺に配慮をしてあげると、色々とお互いに幸せになりやすいんじゃないかなぁ、と。
ちなみに、丁寧に設計しても「当初想定の1.4～1.6倍」くらいになる事が多いので、その辺を踏まえた上で予算を確保しておくとよいです。
「雑な設計」なら、1.6～1.8倍程度。2倍を超えるようだと「想定が甘すぎるか、要求仕様のツメが甘すぎるか、前提条件に誤りがあったか、途中でお話がコロコロ変わっているか」のいずれかである事が多いような。
でまぁこの辺。
やり方は色々あろうか、と思うのですが。おいちゃんは、以下のようにやることが多いです。
・まず「予算」を確認
・ある程度細かい目にマイルストーンを引いて「ここまでに何時間(＝おいくら円)」のスケジュールをざっくりとlocalで作成＆受発注者でスコープ*6を合意
って下準備をして。
あとは
・マイルストーンで「遅れそうな気配」がした時点
で、速攻でご連絡。
おいちゃんは
・「遅延確率20%くらい」で、一旦軽くご連絡：ちょっと不安がよぎったので、軽くご連絡いたします
・「遅延確率40～50%くらい」で、原因分析を含めてご連絡：この辺に起因して、遅れそうな気配があるのでご連絡いたします
・「遅延確率70～80%くらい」で、確認を含めてご連絡：このままだとほぼ確実に時間(＝お金)が伸びますが、どうしましょう？
ってな感じかなぁ。
この手の連絡は「早め早め」のほうが、先方も「寝耳に水」にならんですむので、割合と安心感があると思うのです。
とか、まぁまぁ。
フリーランスとかでお仕事をいただく時の「一つのヒント」くらいにでもなればなぁ、と。
