Usein yksi ensimmäisiä kysymyksiä laskennallisen yhteiskuntatieteen kursseillani on: “Pitääkö tässä oppia koodaamaan?” Koodaustaidon tärkeys (laskennallisille) yhteiskuntatieteilijöille jakaa mielipiteitä niin opiskelijoiden kuin kokeneempien osaajien kesken. On niitä, joiden mielestä ehdottomasti pitäisi ja niitä, jotka vannovat poikkitieteellisen yhteistyön nimiin.
Itse vastaan opiskelijoiden kysymykseen yleensä vastakysymyksellä: oletko nähnyt mitään menetelmää, jossa sen käyttäjät eivät hallitsisi menetelmän välineitä? Määrällisen tutkimuksen puolella tankataan tilastotiedettä ja erilaisia testejä, laadullisen tutkimuksen puolella luetaan oppikirjoja, muiden papereja ja käydään läpi tutkimuksen prosessia. Laskennallisen yhteiskuntatieteen puolella taas valitettavan usein työkalujen saaminen käyttöön vaatii ainakin auttavia ohjelmointitaitoja: dataa pitää esikäsitellä, muiden tekemiä työvälineitä mahdollisesti liimailla yhteen oman datan kanssa jne. Tässä ohjelmointitaito on tärkeä väline, jos siis aikoo tehdä laskennallista yhteiskuntatiedettä.
(Tässä välissä on ehkä syytä tuoda esille, että digitaalista – tietokonekoodin päälle rakennettua – yhteiskuntaa voi tutkia monilla ei-laskennallisilla tavoilla. Esimerkiksi perinteinen tapaustutkimus ja haastattelututkimukset ovat yhteiskuntatieteen puolella olevan kriittisen algoritmitutkmuksen keskeisiä menetelmiä.)
Mutta pureskellaan vastausta vähän enemmän auki:
Mitä tarkoittaa koodaustaito?
Usein vastauksissa, myös omissani, puhutaan koodaustaidosta kuin se olisi binäärinen: se joko on tai sitä ei ole. Todellisuudessa näin tietenkään ei ole. Ihan kuten muissakin menetelmissä, kuinka syvällisesti ohjelmointia pitää oppia eroaa käyttötarkoituksen mukaan. Eli vaikka käytät Studentin t-testiä, niin kukaan ei oleta että osaisit integroida mitään todennäköisyysfunktiota – tai edes, että ymmärtäisit mitä tekemistä tällä olikaan tilastollisen testaamisen kanssa. Tai laadullisessa tutkimuksessa ei ainakaan niissä piireissä joissa itse kirjoitan mennä ihan hirveän syvälle Glaserin, Straussin ja Gorbinin eroihin: sen sijaan keskitymme yleensä luokittelun järkevyyteen aineiston ymmärtämisessä ja jäsentämisessä.
Samalla tavalla ohjelmointiosaamisessa on erilaisia osaamistasoja. Mahdollisesti aloitteleva laskennallisen yhteiskuntatieteen osaaja keskittyy vain automatisoimaan aineiston esikäsittelyä ja puhdistusta muiden laatimia analyysiohjelmia varten, kun taas syvemmällä menetelmissä oleva voi itsekin kehitellä analyysitapoja. Esimerkiksi R-kielelle aihemallinnukseen on olemassa vähintäänkin seuraavat työkalut, jotka toimivat hiukan eri osaamistasoilla
Eli vaikka koodaustaito on tärkeä osa laskennallista yhteiskuntatiedettä, niin se ei tarkoita että jokaisen pitäisi lukea itsensä kandiksi, maisteriksi tai tohtoriksi tietojenkäsittelytieteestä. Tai edes saavuttaa ohjelmoinnissa sellaista osaamistasoa, että voisi tulla palkatuksi ohjelmointialan yritykseen ohjelmoimaan. Ihan kuten suurin osa tilastomenetelmien käyttäjistä ei osaisi integroida todennäköisyysfunktioita tai jokainen grounded theory -soveltaja jäsentää auki tarkasti eri grounded theory -perheiden eroja.
Poikkitieteellinen yhteistyön arvo
Aika usein esille nousee ajatus siitä, että tämä ongelmahan olisi kiva yhteistyömahdollisuus tietojenkäsittelytieteilijöille tai datatieteilijöille. Valitettavasti silloin herkästi unohtuu, että suurin osa yhteiskuntatieteen data-analyysiongelmista on niin yksinkertaista rutiinikamaa, ettei niistä tietojenkäsittelytieteilijän akateeminen ura oikeastaan hyödy – paitsi parhaimmillaankin julkaisuluettelon täytteenä. Syvimmiltään ongelma on, että erilaiset tiedeyhteisöt odottavat hyvin erilaisia lopputuloksia. Van Wijk (2006) pohdiskelee täysin samaa ongelmaa tiedon visualisoinnin piirissä, joten tämä on syvällä akateemisen uramaailman rakenteissa oleva ongelma.
Jos unohdetaan ajatus tutkimusyhteistyöstä ja sanotaan, että se voisi olla muutakin yhteistyötä. Mikäs siinä: monilla aloilla olen käsittänyt, että tilastoanalyysit tekee palkattu tilastotieteilijä, ei domain-tutkija itse. Mutta silloin ajatusmaailman pitää myös muuttua: tehtävään ei pitäisi palkata henkilöä jolta odotetaan järkeviä akateemisia tuotteita, vaan kyseessä on puhtaasti palvelufunktio. Data-analyytikon vapaiden markkinoiden palkka lähtee 3500 eurosta kuussa – tämä kannattaa pitää mielessä, jos tätä vaihtoehtoa miettii.
Toki ei ole vielä täysin selvää, minkälainen laskennallisen yhteiskuntatieteen tutkimuskenttä tulee olemaan. Jos laskennallinen yhteiskuntatiede kehittyy kohti omaa tieteenalaansa omilla säännöillään ja toimintatavoillaan, niin silloin tämänlainen poikkitieteellisyys voi olla helpompaa. Silloin tosin ihmisillä ei pitäisi olla niinkään voimakasta identiteettiä tietojenkäsittelytieteilijänä tai yhteiskuntatieteilijänä, vaan nimenomaan laskennallisena yhteiskuntatieteilijänä. Ihan vielä institutionaaliset rakenteet ja uramallit eivät ole tähän joustaneet.
Laskennallinen yhteiskuntatiede vaatii sosiologista ja teknistä luovuutta
Kuitenkin mielestäni paras perustelu laajaan koodaamistaitoon ei liity työvälineisiin tai institutionaalisiin rakenteisiin. Sen sijaan kysymys on tieteen laadusta. Laskennallinen yhteiskuntatiede mahdollistaa hyvin erilaisten tutkimuskysymysten ja lähestymistapojen kehittymisen. Silloin on tarpeen olla erinomaista käsitteellistä rikkautta (sosiologista luovuutta) kuin myös ymmärrystä siitä, mikä on laskennallisuuden kannalta mahdollista ja uraanuurtavaa (teknistä luovuutta). Jos jompikumpi puuttuu, edessä on helposti jonkinlaista metoo-tutkimusta: tehdään samaa mitä kaikki muutkin tekevät.
Näiden kahden luovuuden synnyttäminen vaatii jonkinlaista yhteistyötä tieteenalojen välillä. Se vaatii ymmärrystä myös toisesta tieteenalasta, sen lähestymistavoista, käsitteistä, tavoitteista ja toiminnasta. Ymmärryksen ei aina tarvitse olla täydellistä, mutta sen pitää olla sellaisella tasolla että voi keskustella toisen alan edustajan kanssa (joillekin tutumpi termi, trading zone; Galison, 1999). Ja käsitteiden ymmärtämiseen tietojenkäsittelytieteen puolella pitäisi olla joku käsitys myös koodaamisesta ja sen työtavoista ja prosesseista.
Rajapinta 